SQL Server Magazine

Are you anxiously awaiting Windows 2000 (Win2K)? By now, you're probably intrigued by the rich and impressive features this new version of Windows NT promises: Active Directory (AD), the incorporation of Win2K Server Terminal Services, Group Policies, 64-bit very large memory (VLM), IntelliMirror, Plug and Play (PnP), and Windows Driver Model (WDM) support, to name a few. Perhaps you're assuming that, as in the past, Microsoft will make the migration process easy and painless: You'll just buy the software, install it, and be on your merry way. If that's your fantasy, think again.

Because the next version of NT promises to be as revolutionary as it is evolutionary, the new technologies will affect your network and your life as an administrator in several ways. To begin, you'll have to do more planning for Win2K than for any previous upgrade. Fortunately, you can start today to prepare for your migration to Win2K. In this article, I discuss several Win2K migration topics and recommend specific steps you can take to be ready for Win2K when it arrives.

Step 1: Prepare Your Domain Structure for AD
One of the most important aspects of the Win2K rollout is the migration of your existing domain structure to Win2K's AD. The complexity of this process depends on your network's architecture. If you have a single-domain model (perhaps with local BDCs at remote sites for quicker logons and access to local network resources), the process of migrating to AD will be fairly straightforward, and AD will give you new options for further optimizing the administrative structure and network traffic of your existing domain model. But if you've implemented a complex multidomain model with decentralized administration, your planning process will be more involved.

Because of the limitations of the NT 4.0 and NT 3.x domain architecture, many organizations have implemented multidomain models that use centralized administration (e.g., master domain or multiple master domain models) and centralized account domains with remote-resource domains. Such designs might fit an organization's administrative structure, particularly if the IT staff is in one central location. But in other organizations, this design doesn't fit administrative structure. Those organizations implement multidomain models more to avoid complete-trust models (with their inherent multiple one-way trust relationships and resulting administrative burden) than to accommodate the needs of the organization.

Win2K will change this complexity. An organization will be able to choose from a variety of multitiered network designs that it can fashion around any number of criteria, such as its organizational model, geographical layout, or a combination of the two. Furthermore, if you've had to create master or multimaster domain models to minimize the administrative hassles of placing user accounts into multiple domains, AD will let you move those accounts safely back to the domains in which they belong.

Granularity is the key. Win2K enables these possibilities because of its granular design. NT 4.0 and NT 3.x group administrative entities (e.g., Administrators, Server Operators, Back-up Operators) into a limited number of groups with a generic set of administrative rights, but AD will let you set administrative rights down to the individual permission level. This granularity means you can easily assign to user accounts in particular domains the amount of access they require to administer their local office, and you can do so without compromising the overall security or design of your network. No longer must you choose between administering these resources yourself remotely and assigning second-level administrators into a limited set of stock account groups.

AD's granularity has benefits that extend into other areas of administrative life. For example, you can use AD to assign particular user or group permissions to particular applications as well as to traditional resources such as file and print shares. By breaking permissions and rights down to a more detailed level, AD lets you tailor your directory to fit your organization's actual structure and administrative requirements.

Preparing for life in AD. With all this in mind, what can you do now to prepare for life in AD? If you administer a multidomain environment, consider the advantages of flattening (i.e., consolidating and reducing) your multidomain structure before the arrival of Win2K in your organization. Flattening and restructuring your domains now can pave the way for a better and simplified AD design later. Also, you can undo some of the kludges that limitations of earlier NT versions might have forced you to introduce into your network design. I know what you're probably wondering right about now: Won't that approach mean manually moving all my users, groups, and computer accounts to another domain? Believe it or not, you won't necessarily have to.

Several utilities provide domain migration and restructuring capabilities. FastLane Technologies' FastLane DM/Manager is part of FastLane's DM/Suite suite of enterprise-management products. DM/Manager is a multipurpose tool that lets you reconfigure your NT domain infrastructure without forcing you to rekey user account data or invalidate ACL security settings applied to resources in the domain. DM/Manager's interface, which Screen 1 shows, lets you use a simple drag-and-drop process to migrate user, group, and computer accounts from one domain to another. When you finish a migration, users can log on to the new domain without knowing that you moved their accounts. In addition, DM/ Manager's rollback feature lets you undo domain structure changes and migrations. DM/Manager is an impressive and invaluable product for simplifying your organization's domain structure before you migrate to Win2K.

Mission Critical Software's Domain Migrator, which is part of Mission Critical's OnePoint suite, is another domain-restructuring utility that provides a comprehensive set of domain migration and restructuring tools. This product provides rollback features that let administrators undo domain restructuring actions. Microsoft recently announced that Win2K will include Domain Migrator. Through feedback from the Win2K beta Rapid Deployment Program (RDP), customers told Microsoft that they want to be able to restructure and upgrade domains in one fell swoop. The inclusion of this utility will be a nice bonus for Win2K customers; however, organizations that want to reorganize their NT 4.0 domains now can use products such as DM/Manager and Domain Migrator. In addition, Microsoft might decide not to include this tool with Win2K, or the company might provide a watered-down version that doesn't satisfy the needs of large organizations.

To facilitate the flattening process, AD contains an important new feature, the organizational unit (OU). OUs are AD container objects that let you subdivide your organization, even within a single domain. As a result, you don't need to create multiple domains to divide your organization into administrative subdivisions.

Keep in mind that although domain flattening might be appropriate for some organizations, it isn't appropriate for all organizations. For example, if you want to separate your organization's divisions into separate domains under AD, you'll want to retain your existing domain structure until migration. Another reason for you to retain your existing domain structure as you migrate to Win2K is that AD supports transitive trusts. In a transitive trust, the established trust (domain A trusts domain B and domain B trusts domain C) also means that domain A trusts domain C. Figure 1, page 90, illustrates this trust arrangement. NT 4.0 and NT 3.x didn't support transitive trusts; thus, administrators had to create additional trust relationships to establish a relationship between domains not related through established trusts. Obviously, you'll have fewer headaches creating multidomain security relationships under Win2K than you're experiencing with NT 4.0 and NT 3.x.

The forest for the trees. Win2K's AD design integrates the concepts of forests and trees. A tree is a group of NT domains in AD that form a contiguous namespace and share a schema. For example, assume a domain named bigcorp.com exists in your AD structure. The two subdivisions of bigcorp.com are europe and us, and us has a subdivision called sales. Within AD, the names of these domains might be europe.bigcorp.com, us.bigcorp.com, and sales.us.bigcorp.com. This arrangement demonstrates the hierarchical structure of AD and its namespace: These domains are all part of one contiguous related namespace in the directory; that is, they form one domain tree. The name of the tree is the root level of the tree: In this case, bigcorp.com. Figure 2 shows this single-domain tree.

Let's take this concept to the next level. Assume that within your AD, a parent organization oversees bigcorp, and this parent organization owns another subsidiary, called bigbiz, which is listed in AD with bigcorp. One subdivision, us.bigbiz.com, is beneath bigbiz in AD. Although your company wants both bigcorp and bigbiz defined within the same AD for administrative reasons, you don't want them to share a namespace. So, you define bigcorp and bigbiz as separate trees within the same forest. Figure 3 illustrates this arrangement. All trees in a forest share a schema, configuration, and Global Catalog. Furthermore, all trees in a forest trust one another because of the transitive, hierarchical Kerberos trust relationships that AD is structured on.

To plan your organization's AD structure and namespace effectively, you can read two Microsoft white papers: "Migrating from Microsoft Windows NT Server 4.0 to Windows 2000" and "Windows 2000 Namespace Design." Both papers and others relating to Win2K migration are available on Microsoft's Web site (http://www.microsoft.com/ windows/server).

Action Plan:

• Learn about AD, and download the Microsoft Win2K white papers.
• Start planning your AD structure.
• If appropriate, flatten and consolidate your domain structure.

Step 2: Standardize Your Network on TCP/IP
TCP/IP is the future of networking, and it has become the network protocol of choice for Win2K because it provides a uniform platform that supports many different OSs. TCP/IP is the only protocol Win2K installs by default during clean installations (legacy environments might still implement NetBEUI and IPX/SPX). This situation means that one of the best things you can do to prepare your organization for Win2K is to make TCP/IP your standard primary (preferably sole) network protocol. Making TCP/IP your standard primary network protocol will give you an additional benefit: Because TCP/IP is a highly efficient, routable protocol, you won't hit the types of bandwidth and usability ceilings that occur with NetBEUI (which is nonroutable) and IPX/SPX (which, although it's routable, has higher overhead than TCP/IP in WAN environments).

If you haven't already implemented TCP/IP on your network but will do so before your Win2K migration, you must address NetBIOS-to-IP address-name-resolution concerns. To address these concerns, you can deploy either WINS or DNS servers or you can use a centralized LMHOSTS file to resolve names. In addition, if your network is connected to the Internet, you must create an appropriate firewall to protect the network against intruders.

Get on the TCP/IP bandwagon now rather than later. TCP/IP can be slightly more difficult to administer than NetBEUI and IPX/SPX, so if you don't have much experience with TCP/IP, begin now to learn about TCP/IP administration. For information about TCP/IP administration, see Todd Lammle, Monica Lammle, and Mark Minasi, Microsoft TCP/IP Training (Microsoft Press, 1997) and Mastering TCP/IP for NT Server (Sybex, 1997).

Action Plan:

• Learn about TCP/IP routing and administration concerns.
• Deploy TCP/IP as the primary file and print service protocol within your organization now. If possible, make TCP/IP your sole network protocol to minimize protocol overhead and administrative problems on the network.

   Prev. page   [1] 2 3     next page