10 Steps to Prepare for Windows 2000

Take action today and meet Win2K halfway

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:

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:

Step 3: Learn the Ways of DNS
Name resolution is central to TCP/IP standardization and deployment. Most current TCP/IP-based NT networks use WINS servers or LMHOSTS files to resolve NetBIOS names to IP addresses. But in Win2K, you query AD to resolve names. AD uses a dynamic form of traditional DNS that offers Win2K networks the best of both DNS and WINS.

In Win2K, DHCP servers automatically register clients in AD's DNS-compliant namespace and automatically unregister them when the DHCP lease expires or is released. As a result, you don't need to manually maintain dynamic DNS (DDNS) zone files, as you do with traditional DNS. Furthermore, DDNS delivers a name-resolution method that is far more scalable and robust than WINS.

Another nicety of the DDNS design is that it unifies the namespaces an organization uses on the Internet and on the internal network. This feature lets companies leverage their existing DNS knowledge to support one type of namespace (i.e., DNS). However, this convergence might create internal battles in organizations that house DNS servers on UNIX rather than NT systems.

In addition, Win2K automatically stores its DDNS namespace within and replicates it throughout AD. The consistency that this approach establishes means your DNS namespaces will have a level of fault tolerance that isn't possible with traditional DNS or WINS implementations.

To facilitate migration to Win2K's DNS environment, verify that existing computer and network names within your organization are DNS-friendly. DNS stipulates that domain and host names contain only the following characters: A through Z, a through z, 0 through 9, and hyphen (-), with no spaces or underscoring. If a domain or a host uses names that don't follow the DNS convention, make the names conform. In the case of workstations, this step probably won't be a big deal. However, in the case of domains or servers, illegal names will require a bit more planning on your part.

Work with a name-registration authority (you can find information about these organizations at the Internet Corporation for Assigned Names and Numbers—ICANN—http://www.icann.org) or an ISP to obtain a domain name for your organization if you don't have one, whether you're connected to the Internet now or not. This task is important because when you migrate to Win2K, your AD structure will drive your DNS naming structure. If you've developed a naming structure for your organization that doesn't conform to DNS standards and you later connect to the Internet, you'll have to observe Internet DNS standards and use a name that another organization hasn't already taken. You can avoid this hassle by registering DNS domain names for your organization now that will work later if you decide to connect to the Internet. And by acting now, you have a better chance of getting the domain name you want for your organization. If you wait, someone else might take the name you prefer.

You can run separate internal and external DNS namespaces for your organization; you don't have to use one shared internal/external namespace. For example, you might want to run one namespace outside a firewall for Internet users and another inside the firewall for internal company users. For more information, read the Microsoft white paper "Windows 2000 Namespace Design" (http://www.microsoft.com/ windows/server).

Action Plan:

Step 4: Download and Install the NT 4.0 Option Pack and Service Pack 4 (SP4) or Later
If you're a developer or an ISP and want to develop applications that use the technologies Microsoft provides in Microsoft Message Queue Server (MSMQ) and Microsoft Transaction Server (MTS), the NT 4.0 Option Pack is for you. The Option Pack is a downloadable set of OS updates for NT Workstation 4.0 and NT Server 4.0 that installs several updated services and components (a Windows 95 version also exists). For example, the Server component of the Option Pack includes Microsoft Internet Information Server (IIS) 4.0, MTS 2.0, Microsoft Index Server 2.0, Microsoft Certificate Server, and MSMQ. The workstation component of the Option Pack updates Peer Web Services to the latest (IIS 4.0-compatible) version and installs client components for the latest version of RAS, MTS, and MSMQ.

In addition to the Option Pack, update your NT systems to SP4 or later. These packs provide the latest NT bug fixes and enhancements and include the Security Configuration Editor (SCE), which is a Microsoft Management Console (MMC)-based security tool that will be a standard Win2K feature. This utility is available on only the SP4 and later CD-ROMs or via a separate download from Microsoft's Web site—Microsoft doesn't include it in the downloadable service pack versions. Learning and using SCE now will give you a jump on learning Win2K security administration.

Because these services are advanced releases of Win2K services, you can learn about some of Win2K's components by downloading and installing the Option Pack and the latest NT service pack now. For more information and to download the Option Pack and service packs, visit Microsoft's Web site (http://www.microsoft.com/ntserver/all/ downloads.asp).

Action Plan:

Step 5: Get Rid of the SID Skeletons in Your Closet
A unique 32-bit SID number represents every NT computer in a domain (and such entities as the domain itself and user and group accounts). When you install NT, it automatically assigns the machine a globally unique SID. However, disk-duplication utilities bypass the SID assignment process when you use them to clone NT installations: The cloned systems use the source system's SID. Many organizations have used the cloning method to speed the process of installing NT onto workstations and servers.

Although cloning doesn't cause problems under NT 4.0 or NT 3.x, it probably will under Win2K. This likelihood is because AD employs the SID to identify a particular system within the directory. Therefore, if multiple machines use the same SID, confusion and problems will result. Microsoft has waffled a bit about exactly how cloning will affect networks under Win2K. Stay on the safe side, and don't practice cloning to install Win2K in your environment. If you must have some duplication, duplicate after the text-mode portion of setup, before the GUI-mode portion begins. At this stage of the installation process, Win2K hasn't assigned a SID. Duplicating your system after the text-mode portion of the setup doesn't produce system cloning as exact as that of a full duplication of a customized and integrated NT installation. However, this method doesn't risk the potential problems of SID duplication. You can use automation components such as customized unattend.txt files and the sysdiff.exe utility to minimize legwork in NT installations.

Another solution to the system-duplication problem has recently appeared. PowerQuest announced a new product, SIDchanger, that automatically changes the SIDs and computer names of duplicated NT computers to unique numbers. SIDchanger is available free to registered users of PowerQuest's Drive Image Pro drive-duplication utility: Download it from PowerQuest's Web site (http:// www.powerquest.com). Microsoft's Sys-Prep is another utility worth mentioning. Microsoft designed SysPrep to solve the SID uniqueness problem and complement drive imaging utilities. In addition, this utility handles SID changing on the front end rather than the back end. You run SysPrep just before you use a data-imagining utility to image a system's data, at which time SysPrep makes the changes necessary to ensure SID uniqueness. Then, the system is ready for mass duplication without fear of duplicating SIDs. (For more information about SysPrep, see Mark Joseph Edwards, "Microsoft's New SysPrep Tool," April 1999). Microsoft provides SysPrep to only its Enterprise, Select, and Open License customers, but you might be able to obtain a copy using one of the following methods:

These utilities can help you prevent or resolve your SID duplication problems and remove the SID skeletons from your closet.

Action Plan:

Step 6: Obtain the Win2K Beta and Set Up a Lab Environment
One of the most important steps to prepare for Win2K is to start using it now. Get your hands on a copy of the latest Win2K beta via the Win2K Corporate Preview Program (CPP—http://www.microsoft.com/ windows/preview), and prod, poke, and run it through its paces. This situation will also give you an opportunity to test the product with your legacy hardware and software products and assess what compatibility considerations you'll face when you migrate. Learn about the Win2K beta program from the Win2K beta Web sites (http://www.microsoft .com/windows/professional/beta and http://www.microsoft.com/windows/ser ver/beta).

In addition, create a lab environment that simulates your existing NT 4.0 network. This setup will let you test migration scenarios, application compatibility, and interoperability between OS versions, and determine hardware baselines required to support Win2K. This information is invaluable for a smooth rollout. To create an ideal lab environment, restore backups of your applications and data backups from your existing NT domain controller, applications, and file servers. You can use these backups in your lab to emulate your existing production environment.

Finally, consider participating in the various Win2K beta-related Internet newsgroups. Several organizations, including Microsoft, sponsor active discussion lists and newsgroups.

Action Plan:

Step 7: Inventory, Schedule, and Budget
Most seasoned NT users won't be surprised to learn that the new technologies in Win2K are likely to add to system-resource requirements, and thus increase the price of Win2K systems. The base recommended memory configuration for Win2K is 64MB for workstations (it's more like 96MB for servers). If you're keeping score, this requirement is about three times the minimum recommended configuration for a comparable NT 4.0 system. Win2K's disk space requirements will probably see even greater increases, particularly if you implement IntelliMirror client-side caching features.

You aren't obliged to install Win2K on every workstation and server on your network. However, you'll probably want to migrate as many machines as possible to Win2K because you can't take advantage of many of Win2K's coolest features, such as multimaster replication, until you've migrated the last non-AD client. Therefore, begin the process of deciding when your organization will be financially, logistically, and politically ready to begin deploying Win2K, and don't forget to factor migration costs into the budget. Some companies plan rollouts on a percentage basis: X percent by this date, Y percent by this date, and so on until they've migrated 100 percent of the organization. Committing to a deployment time frame now is important because the migration process might be lengthy and involved, and creating a budget will be difficult without a migration schedule.

To begin budgeting, you'll need baseline hardware requirements (i.e., what each machine in your organization needs to set up a baseline Win2K configuration). This requirement means you need a current hardware inventory and a recommended minimum Win2K requirements list tailored for your organization's needs. To create the inventory and a requirements list, you can employ a network inventory package.

Although every network's minimum Win2K hardware requirements differ, you can keep in mind a few baseline figures when planning your Win2K migration. For Win2K Professional (Win2K Pro) workstations, you'll need at least a Pentium Pro or Pentium II-based system or better with a minimum of 64MB of RAM and a 4GB or larger hard disk. You won't need that much space to install Win2K, but 4GB is a realistic minimum figure for a hard disk that holds the OS, local profiles and application support files, and data that users store locally. However, a full installation of Win2K Pro and a local installation of Microsoft Office 2000 on a 4GB hard disk will feel crowded.

For servers, don't even think of installing Win2K on less than a Pentium II system with 128MB of RAM, and use a SCSI-based disk subsystem to minimize CPU utilization and maximize performance. Microsoft provides 128MB of RAM as a baseline figure for a very basic Win2K file server. For domain controllers, application servers, and services providing numerous networking services to users, 256MB is a more realistic starting figure. The correct amount of memory depends on the server's role and the various applications it will run.

These numbers are baseline figures rather than totals, so add the appropriate requirements for each application you plan to run. To assist you in assessing your hardware requirements, run the Win2K beta in a preproduction test environment as I mentioned previously.

Action Plan:

Step 8: Start Using the Zero Administration Kit (ZAK) Now
Total cost of ownership (TCO) has become an important concept in the industry, and Microsoft has responded by developing the Zero Administration for Windows (ZAW) initiative, a set of core technologies to make the administration and control of user workstations simpler and more automatic. The first phase of ZAW is available now in ZAK for NT 4.0, Terminal Services, and Win9x. (For more information about ZAW, see Darren Mar-Elia, "Zero Administration Kit: The Answer to Your TCO Woes?" January 1998).

ZAK presents numerous important features that Microsoft will fully integrate into Win2K. You can use MMC snap-ins to manage these features in Win2K. However, you don't have to wait until Win2K ships to reap the benefits of these new features—you can download the NT 4.0 version of ZAK from Microsoft's Web site (http://www .microsoft.com/windows/zak).

Action Plan:

Step 9: Obtain an Object Identifier (OID) for Your Organization
One of the most interesting features of Win2K's AD is its extensible schema. This feature means you are free to customize your AD structure by defining new object classes and attributes that you can store inside the directory. Although most organizations won't need this feature, it might be useful to developers and administrators who want to tailor their AD structure to their organizations' needs and extend the structure to incorporate new information and network services. However, schema modification can jeopardize the stability of your Win2K network. A special management snap-in for the MMC comes with Win2K to facilitate management of AD's schema.

One gotcha with schema extensions is that you must acquire a special number called an OID for each new attribute or class you define. An OID is an assigned number that identifies an object class or attribute within AD. Like IP addresses and DNS namespaces, issuing authorities within a country assign OIDs. In the United States, ANSI is the issuing authority for OIDs.

An OID is in the form of a dotted decimal string (e.g., 1.2.3.4). Organizations and individuals obtain a root OID from the issuing authority in their country, then divide the assigned OID into additional branch OIDs for use within their directories. For example, Microsoft has a root OID of 1.2.840. 113556, which the company has broken down into multiple branch OIDs for different uses (e.g., one to allocate OIDs for AD classes, another for AD attributes) within Microsoft's AD.

You can apply now for your organization's OID, which will save you time later, when you'll be busy migrating your entire network to Win2K. Visit ANSI's Web site (http://web.ansi.org/ public/services/reg_org.html), or send an email request to the OID contact person at [email protected].

Action Plan:

Step 10: Plan for a NetBIOS-free Universe
Believe it or not, Microsoft designed Win2K to free you from the bondage of NetBIOS. Because AD uses a DNS-based naming architecture rather than a NetBIOS-based one, Win2K theoretically can let you have zero NetBIOS traffic running on your network. For TCP/IP purists and those of us who detest the load NetBIOS traffic places on our networks, this concept is welcome. However, eliminating NetBIOS from your network won't be as easy as it sounds. Many, if not most, current Windows utilities and applications rely on a NetBIOS API layer to function (e.g., even simple commands, such as the NT Net commands, require NetBIOS).

To completely remove NetBIOS from your network, you must first eliminate all machines that use NetBIOS naming (which means they must join the Win2K network as AD participants) and all applications that require NetBIOS. Don't pull the plug on NetBIOS until you've used your existing applications to thoroughly explore the ramifications of doing so in a test environment. The good news is that you can continue to run NetBIOS on your Win2K network until you've upgraded all your clients to use AD and until you've eliminated all NetBIOS-based applications.

Action Plan:

And Keep in Mind
If you follow the steps I've outlined, your company's migration to Win2K will be about as smooth as anyone can make it. Here are some additional pointers to help you move easily to Win2K. First, Microsoft recommends that you install or continue to run WINS throughout the Win2K migration process. According to Microsoft, running WINS during your migration will make it go much more smoothly. In addition, Win2K includes an improved version of WINS that addresses many of the problems that plague NT 4.0 WINS. As a result, managing your enterprise NetBIOS namespace under Win2K will be easier than it has been.

Second, do at least one complete dry-run migration before your live deployment of Win2K. A good way to do this dry run is to create a test environment that duplicates your network environment as closely as possible. For example, you can restore a backup of your domain controllers onto test machines and set up an array of test workstations to represent your user workstations. Then perform a sample migration and create your AD structure. If you're running in a WAN-based environment, obtain some figures on the total bandwidth utilization of your new network to compare it with your previous configuration (and to ensure that you haven't exceeded the capacity of your links). You can do this checking with Performance Monitor or a network monitoring utility such as the Network Monitor, which comes with Microsoft Systems Management Server (SMS). Although Win2K should create less traffic on WAN links than earlier versions of NT did, if you run a mixed Win2K and NT 4.0 domain environment you might increase the overall bandwidth utilization on your network—a situation you'll want to watch out for.

Finally, keep up-to-date with all the changes that occur during the development of Win2K. One lesson I've learned from previous Microsoft beta cycles is that new features or product revelations appear out of nowhere. Such is life in the brave new world of NT evolution.

EDITOR'S NOTE:
This article updates the version that appeared in the February 1998 issue of Windows NT Magazine.

Corrections to this Article: