Single-Domain Migration

100 percent Win2K—AD and all

Staying with Windows NT might have made sense to the administrators of small shops and single domains: Although NT Server isn't as sexy as Windows 2000 Server, when correctly installed and configured, NT Server is stable and reliable. Also, requirements to meet and concepts to learn clutter the Win2K migration path. However, DNS and Active Directory (AD) offer great benefits, and Microsoft has made the upgrade process as simple as possible. Now is the time for single-domain administrators to migrate their NT infrastructure completely to Win2K—DNS, AD, and all.

Putting Pencil to Paper
After you brush up on the concepts behind AD and DNS, you'll be ready to make a few decisions about your migration. For information about AD and DNS, see Mark Minasi, "DNS and Active Directory," page 39 and "Related Articles in Previous Issues," page 46. Because planning results in a smoother migration, I don't recommend making migration decisions on the fly.

First, you need to choose a name for your top-level Win2K domain. Rather than choose company.com and confuse your company's private and public domain names, choose a name of the form company.internal. DNS servers use both the machine name and the domain name to reference a machine in an AD network. Because your domain name will be a part of every host name in your network, I recommend keeping the name short and applicable. You probably don't want chicago.il.company.internal to be the domain name attached to every host name in your network—especially if your organization opens an office in a city other than Chicago.

You also need to plan around any existing DNS infrastructure your NT network might have. Most NT networks that have DNS infrastructures use DNS for only client-side Internet communications. Your NT network's client workstations are likely configured one of two ways for Internet DNS resolution: Workstations send requests to either your ISP's DNS servers or a DNS host server in your NT network.

Workstations configured to use your ISP's DNS servers send all DNS name resolution requests to those servers. This configuration is acceptable for NT networks, whose only DNS resolution requests are for external DNS names. But after you migrate to AD and adopt internal DNS host names, you don't want your Win2K network's workstations sending their internal DNS name resolution requests to your ISP's DNS servers. Those servers most likely would not know a system named www.company.internal.

Workstations in an NT network with an internal DNS host server send all DNS requests to that server. If you want to use this DNS server in your AD network, the server needs to support service resource records (SRV RRs). NT's DNS service won't cut it.

Both of the above DNS infrastructures require you to install Win2K's DNS service when you upgrade. You have two options for installing DNS on your network: building a standalone DNS server before migration or letting the DC promotion program, Dcpromo, install DNS on the first domain controller (DC) you migrate to Win2K. Using Dcpromo is the path of least resistance and the approach I recommend.

Upgrading your PDC
Of course, you'll back up your PDC, DCs, and member servers before you begin the migration. You'll also need to verify that each system you intend to upgrade meets (or preferably, exceeds) Win2K Server's minimum hardware specifications. Migrate your NT domain's PDC first.

To begin the upgrade, insert the Win2K Server CD-ROM into your PDC, then choose the Upgrade option or run winnt32.exe from the CD-ROM's i386 directory. Both approaches launch a Win2K Server upgrade and leave the server's settings in place. Win2K Server installation takes time, so get a cup of coffee and check your voicemail while you wait. The installation process eventually logs on as Administrator and starts Dcpromo.

Dcpromo is one of Win2K's most significant advantages over NT. Not only can you use Dcpromo for your Win2K upgrade, you can also use it to remove the DC function from or add it to a server without reinstalling Win2K Server from scratch. The program's straightforward Active Directory Installation Wizard asks several questions, but the two most crucial are Do you want to create a new domain tree or a new child domain in an existing domain tree? and Do you want to create a new forest or join an existing forest?

For a single-domain migration, the answer to the first question, which Figure 1 shows, is obviously to Create a new domain tree. The term tree is simply AD parlance for a series of domains that connect to one another through a contiguous DNS namespace—for example, microsoft.com might be Microsoft's top domain in a domain tree that includes the subdomain redmond.microsoft.com. If you worked for a large organization and wanted your Win2K domain to join the domain tree of a preexisting domain structure, you would select Create a new child domain in an existing domain tree, instead.

The second question, which Figure 2 shows, is whether to create a new forest or join an existing forest. A forest, in AD terms, is a collection of domain trees. Let's say, for example, that Microsoft makes its Hotmail division a separate tree with-in the company's existing forest. The forest permits some information-sharing between the domain trees while maintaining each tree (i.e., microsoft.com and hotmail.com) as a top-level domain. Because a single domain doesn't have an existing domain forest to join, single-domain administrators need to select Create a new forest of domain trees.

The wizard prompts you to name your domain, then asks you to specify where you want to store the AD database and log. If your server has two hard disks, I recommend storing the database on one hard disk and the log on the other. However, performance in your single-domain environment is typically better than in large organizations' environments, and putting both files on the system's main hard disk might be acceptable.

The wizard's next screen, which Figure 3 shows, prompts you to specify the system volume (SYSVOL) folder's location. AD DCs automatically replicate the SYSVOL directory and any changes to the files within it. However, don't use SYSVOL to replicate user data (e.g., Microsoft Word documents). Rather, look into Win2K Server's Dfs capabilities. (For information about Dfs, see "Related Articles in Previous Issues.") Also, Win2K doesn't support NT's directory replication service—the logon script replication you might have configured for your NT DCs is useless after you migrate. For information about developing an alternative method for replicating logon scripts on your Win2K Server machines, see "Logon Script Replication," February 2000.

After you supply the wizard with AD database, log, and SYSVOL folder locations, the wizard attempts to contact your DNS servers and determine whether they support features such as dynamic DNS (DDNS). Typically, NT networks won't have a DNS server or their configured DNS servers won't meet AD's requirements (specifically, SRV RR support), and the check will fail.

The wizard will then ask whether you want Dcpromo to install DNS on your system or whether you want to install and configure DNS on your own. Wizard-driven installation is a helpful feature for administrators who are new to DNS: After you've given the wizard the information it needs, Dcpromo installs and configures the DNS server for proper AD support. Although Dcpromo requires you to install DNS on the first server you upgrade (unless your existing DNS configuration meets Win2K's requirements), you can thereafter choose the other—if any—servers on which you'll install DNS.

The wizard also asks whether you want to permit Anonymous access to particular information in the AD database or enforce authentication before users can query the database. Enforcing authentication is the more secure configuration. However, some NT services—RAS, in particular—depend on sending anonymous queries to a DC. Thus, as Figure 4, page 48, shows, you select Permissions compatible with pre-Windows 2000 servers (which permits anonymous queries) or Permissions compatible only with Windows 2000 servers (which enforces user authentication).

If you plan to migrate all your servers in one weekend, you might choose Win2K-only compatibility. However, I prefer to migrate more gradually and upgrade servers one at a time. If you prefer the same approach that I do, you need to permit anonymous queries so that legacy NT services can function properly while you migrate. After you've finished the migration, you can remove the Everyone group from AD's Pre-Windows 2000 Compatible Access group to upgrade security.

Finally, the wizard asks you for a Directory Services recovery password. This password becomes an alternative administrator password. If you lose the Administrator password or someone changes it without your knowledge, you can use the Directory Services recovery password and AD's Directory Services Restore mode or the Recovery Console to log on. Although you can leave the password blank, I recommend providing a value. I like to use the serial number of the server on which I'm installing Win2K. Serial numbers are unique, typically complex, and always available.

Enter a password, and you'll have provided all the information necessary for installing AD. The wizard processes the information and migrates your user and machine accounts to AD. You then can access all your users and computers through the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in.

BDCs and Member Servers
After you migrate your PDC, that machine will emulate a PDC under Win2K to permit interoperation with the BDCs and member servers you haven't yet migrated to Win2K. When you migrate your remaining servers, begin with the BDCs. To begin the migrations, insert the Win2K Server CD-ROM, then choose Upgrade or run winnt32.exe from the CD-ROM's i386 directory. Win2K Server installation proceeds as it did for your PDC and eventually logs on as Administrator and starts Dcpromo.

Dcpromo is intelligent. It recognizes whether your server was a BDC or a member server and, as Figure 5 shows, asks whether you want to run the system as a DC or a member server in your Win2K network. If you choose the Leave as a member server option, you exit the wizard immediately—the servers you designate as member servers will inherit their previous domain memberships, so they'll automatically migrate to your AD domain. However, because I recommend having at least two Win2K DCs, I suggest you instead select the Make a domain controller option when you migrate your NT network's first BDC.

The PDC and BDC migration processes are similar. Dcpromo needs to know your DNS server's location and requires a username and password for accessing account data from the first DC you migrated (i.e., your former PDC). Dcpromo then replicates this account data from the first DC you migrated to the server you're currently migrating. Dcpromo's wizard also asks for some of the same information that it needed to migrate your former PDC (e.g., where to store the AD database and SYSVOL directory). When you enter this information, use the same guidelines you used for PDC migration.

Finishing Touches
Before you're finished, you need to consider your network workstations' OSs and their configurations, then make the necessary changes to these workstations. You'll likely need to reconfigure your workstations to send their DNS name resolution requests to your network's new host DNS server. To migrate completely to Win2K, you eventually need to kill WINS and rely solely on your network's DNS server for internal name resolution.

I recommend letting your internal DNS server handle your clients' external name resolution requests as well. If you follow this recommendation, you need to configure your DNS server as a forwarder. A forwarder sends external requests that it can't resolve to your ISP's DNS servers. When the request is for a legitimate host name, your ISP's DNS servers can resolve the request and pass the IP address to your internal DNS server. Your internal DNS server receives the answer and passes it to the client machine that requested the name. When the process works correctly, it's faster and requires less overhead than you might expect. For more information about forwarders, see "DNS and Active Directory."

Native Mode
For downlevel compatibility with NT systems, Win2K installations default to mixed mode. This mode lets Win2K DCs act like NT PDCs: The DC can send PDC-emulating messages out on the network and respond to PDC-targeted requests, such as requests for the domain master browser. However, you ultimately want to switch to native mode. Only in native mode can you take advantage of features such as multimaster replication. This mode switch is the last step in a complete Win2K migration.

You can't undo a move to native mode, so as a test-run, I recommend manually stopping the WINS service for several workdays before you make the switch. If users have name-resolution problems, restart the WINS service and diagnose the problem. Before you switch to native mode, you need to make sure that none of your internal systems depend on NT-style name resolution and that your network functions solely and reliably on DNS name resolution. If your network functions as usual after you stop WINS, you've most likely done everything you need to do to make the permanent switch to native mode.

When you're ready, use any DC's MMC Active Directory Domains and Trusts snap-in to make the switch to native mode. Right-click your domain, and open the Properties page. In the General tab's Domain Mode area, click Change Mode. After you click through a few confirmation dialog boxes, the irrevocable shift from mixed to native mode begins. Your DCs will communicate with one another for a while, then your domain's servers will be 100 percent Win2K.

Reap the Rewards
Of course, a migration demands plenty of additional obligatory tasks, such as cleaning up the user database, group memberships, and share permissions. Overall, however, a single-domain migration to Win2K is fairly painless. And moving all the way to native mode significantly increases your network's stability, reliability, and manageability.