In-Place Upgrade of an NT4 Domain
At this point, you should have a clear roadmap of your deployment plans. You should know which classic domain controllers you are going to upgrade and in what order. All the prerequisites should be complete. You have brewed a big pot of coffee, and you're ready to begin.
Figure 9.7 shows a classic NT multiple-master domain with a single resource domain. In a production network, there could be many resource domains with interlocking trusts to several account domains. The configuration in the diagram shows a user in the second account domain who accesses a shared resource on a server in the resource domain.
Figure 9.7. Classic NT multiple master domain.
The server cannot validate the user directly because there is no trust between the resource domain and the user's account domain. Classic NT domains are not transitive. The user must either log on using credentials from the first account domain or present an alternate set of credentials when mapping to the resource.
The following examples describe how to upgrade this multiple master NT configuration to a single Windows Server 2003 forest. The administrators in this example have decided to retain the same domain structure in Active Directory as they now use in NT. The "Migrating from NT and Windows 2000 Domains to Windows Server 2003" section discusses how to collapse the classic domains into a single domain.
Here is the order of events:
Install a placeholder domain to act as the root domain of the forest.
Upgrade the PDC of the first account domain.
Upgrade the BDCs in the first account domain.
Shift the functional level of the first account domain to Windows Server 2003.
Upgrade the PDC and BDCs of the resource domains under the first account domain or migrate all the users and computers to the newly created Windows Server 2003 domain.
Shift the functional level of any upgraded resource domains to Windows Server 2003.
Upgrade the PDC and BDCs of the second and subsequent account domains and shift the functional level to Windows Server 2003.
Shift the forest functional level to Windows Server 2003.
Install a Placeholder Domain
If you have several NT account domains that you plan on preserving after the upgrade to Windows Server 2003 and Active Directory, you should strongly consider installing a placeholder domain to act as the root domain of the forest. This is sometimes called an empty root because it has no production user accounts. Figure 9.8 shows an example.
Figure 9.8. NT domain upgrade beginning with new Windows Server 2003 domain acting as placeholder above existing NT account domains.
The empty root clearly defines who manages the forest you're building. Both the Configuration naming context and the Schema naming context are considered a part of the root domain even though all domain controllers have a replica of them.
When promoting Windows Server 2003 to a domain controller, the SAM hive in the Registry is deleted and replaced with a standard hive containing the Administrator account, a disabled Guest account, and the standard Builtin groups for a server, except that the Power Users group is included rather than the Server Operators group.
If you have been using a server for file-and-print duties and it has local groups or user accounts, be sure to replace the access control list (ACL) entries for these accounts on the data files and printers prior to promoting the server to a domain controller.
Domain administrators in the empty root have control over these forest-wide naming contexts, whereas domain administrators in the child domains are free to manage their own naming contexts but have no forest-wide authority. Without a placeholder root, the first account domain to be upgraded would become the root domain of the forest, and the administrators in that domain would have extensive authority.
Because the placeholder domain has no preexisting NT4 or Windows 2000 domain controllers, it is simple to install. Obtain at least two servers that meet your specification for domain controllers and install Windows Server 2003 on them. These servers can also act as DNS servers with Active Directory integrated zones and DNS Application naming contexts. Later on, you can place these DNS naming contexts on selected domain controllers in other domains to create a separate DNS replication topology.
Using a placeholder domain also simplifies initial installation. Creating the first domain controller in the placeholder domain, and the forest, requires simply running Dcpromo on Windows Server 2003. The domain functional level can be shifted to Windows Server 2003 as soon as the new domain controller is operational.
Use the steps in Procedure 9.1 to promote a server running Windows Server 2003 to a domain controller and initialize the first domain in a forest. Make sure the server is configured to point at the DNS server you have designated to host the Active Directory zone.
Procedure 9.1 Promoting the First Windows Server 2003 Domain Controller
Launch Dcpromo from the Run window. The Active Directory Installation Wizard starts.
Click Next. The Domain Controller Type window opens. Select Domain Controller For A New Domain. Keep in mind that this action will delete the existing SAM and Security hives in the Registry (see Figure 9.9).
Figure 9.9. Dcpromo—Domain Controller Type window.
Click Next. The Create New Domain window opens. Select Domain In A New Forest. This designates the new placeholder domain as the root domain in the forest.
Click Next. The New Domain Name window opens. Enter the fully qualified DNS name you've selected for the placeholder domain (see Figure 9.10).
Figure 9.10. Dcpromo—New Domain Name window.
Click Next. The wizard queries WINS and broadcasts to verify that no other domain or NetBIOS entity has registered the flat name that corresponds to the DNS name you entered.
If no name collision occurs, the NetBIOS Domain Name window opens and displays the flat name for the new domain.
Click Next. The Database and Log Folders window opens. Enter the path to the volume you've prepared to hold the Active Directory files (see Figure 9.11).
Figure 9.11. Dcpromo—Database and Log Folders window.
Click Next. The Shared System Volume window opens. Enter the path to the volume you've prepared to hold the Sysvol folder. This can be the same volume that holds the Active Directory database files.
Click Next. The DNS Registration Diagnostics window opens (see Figure 9.12). The DNS analysis tool reports the results of a diagnostic check. If the DNS server is available and the zone is present and configured for dynamic update, the analysis tool reports a success. Otherwise, the error is reported and followup actions are suggested.
Figure 9.12. DNS Registration Diagnostics window.
Click Next. The Permissions window opens (see Figure 9.13). If you no longer have NT4 RAS servers on the network, select Permissions Compatible Only With Windows 2000 or Windows Server 2003 Operating System.
Figure 9.13. Dcpromo—Permissions window.
Click Next. The Directory Services Restore Mode Administrator Password window opens. Enter the password to be assigned to the Administrator account in the new SAM that will be installed on the server. This account provides access when Active Directory is not available.
Click Next. A summary window opens.
Click Next. The wizard begins installing the directory service. This takes between three and five minutes depending on the speed of your server. When installing new domain controllers in an existing domain, allow sufficient time for the Active Directory contents to replicate to the new domain controller.
When the promotion has completed, the machine restarts. When you log on following the restart, use the Administrator account you defined during the promotion.
Before proceeding, make sure that the SRV records for the domain were registered correctly in the DNS zone. This registration is performed by Netlogon. It takes a few minutes to complete, so check back with the DNS server five minutes after you are able to log on at the console of the server. If the SRV records fail to appear, resolve the problem immediately. If the problem were an incorrect DNS configuration at the domain controller, you can register the DNS records manually by starting and stopping Netlogon.
Troubleshoot Promotion Problems
The most common cause of promotion problems is improper DNS configuration. If you get an inexplicable failure during promotion, check your DNS setup carefully. There are many subtle ways that DNS can derail a promotion. Other potential sources of problems are the following:
Corrupt SAM or Security hives
Registry corruption or improper Registry settings involving critical services
Running out of memory or drive space during the promotion (could be due to massive fragmentation rather than actual drive space limitations)
Network connection problems
Driver or file corruption
During Dcpromo, the Configuring Active Directory window gives a running report of the actions taken by the promotion wizard. The wizard writes a full report to Dcpromoui.log located in \Windows\Debug. Another log file, Dcpromo.log, describes the gory details of each API call and error reports, if any.
Table 9.1 shows a typical sequence of events during a domain controller promotion as logged by the AD Installation Wizard in Dcpromo.log. Check this list if you have a failure and you want to see what a successful promotion looks like.
Add More Domain Controllers
You do not want to operate for an extended period with Active Directory files hosted on a single domain controller. This tempts Murphy. Promote a second domain controller as soon as the first one is operating satisfactorily.
The only difference between promoting a second domain controller and promoting the first one is the selection of a domain type at the start of Dcpromo. The Select Additional Domain Controller For An Existing Domain option tells the wizard to replicate the contents of Active Directory from the existing domain controller.
If you want to avoid the tedious replication of a large Active Directory database across a slow WAN link, you can opt to populate the database on the new domain controller from a restored copy of the database from another domain controller.
To use this option, first run a system state backup at an existing domain controller then restore the backup tape or file to a temporary folder at the server you are going to promote. Be sure to give the temporary folder lots of elbow room. It needs to hold at least 300MB at a minimum, not including the size of the Ntds.dit file, because Ntbackup will only let you restore the entire system state, not just the Active Directory files inside the system state.
Table 9.1. Dcpromo.log Entries for a Successful Domain Controller Promotion
Paths to Active Directory database, logs, and Sysvol checked and created, if necessary.
Verifies that domain flat name is unique.
Netlogon is stopped and target folders created. Sysvol configured for replication.
Active Directory Installation
Credentials verified to have sufficient privileges for domain creation. Active Directory files created. Schema naming context created and populated. Configuration naming context created and populated. Domain naming context created and populated.
User, group, and computer accounts moved from SAM to Active Directory. Original domain SID assigned to new domain.
LSA policies copied and prepared. Windows Time Service initialized. Netlogon configured. LSA policies initialized.
Domain controller (DC) promotion security template applied to Registry.
DC promotion security template applied to system files and folders.
Upgrade temp files and old Netlogon information removed.
Wizard is informed of the successful completion of the promotion.
To get the option for using a local copy of the AD files, launch Dcpromo with the /adv switch: dcpromo /adv. In this advanced mode, when you elect to create an additional domain controller for an existing domain, the wizard presents an additional window called Copying Domain Information that permits you to point at a backup file. Figure 9.14 shows an example. Point the wizard at the temporary folder where you restored the system state files.
Figure 9.14. Active Directory Installation Wizard—Advanced Options—Copying Domain Information window showing the option for using a backup file to populate the Active Directory database.
If the AD source files came from a Global Catalog server, Dcpromo queries if you want the new domain controller to be a GC, as well. You can say No and the wizard will only import the naming context for the source domain plus the Configuration and Schema naming contexts.
When the promotion is complete, verify that the Knowledge Consistency Checker (KCC) establishes connections to other domain controllers in the site. Use AD Sites and Services to view the Connection objects and verify replication. See Chapter 7, "Managing Active Directory Replication," for details.
If you want, you can create an external trust to one or all of the NT account domains. This is not required for the forest deployment, but it can be reassuring to know that administrators in the account domains can view resources in the root domain. Any External trusts you create between the root domain and the NT domains will be converted to Domain trusts when the account domain is upgraded.
Set Domain Controller Roles
The first domain controller in a domain is a Global Catalog server, by default. When configuring an empty root domain, configure the second server to be a Global Catalog server, as well. This ensures fault tolerance. If you choose to leave one of the servers as a standard domain controller, it is very important to transfer the Infrastructure Master role to that server.
Use the AD Sites and Services console to configure a domain controller as a GC. Open the Properties window for the NTDS Settings object under the server. Check the Global Catalog option. Figure 9.15 shows an example.
Figure 9.15. NTDS Settings object for a newly promoted domain controller showing the Global Catalog setting.
Give the server a while to replicate the contents of the Global Catalog from another GC server or to collect the partial naming context replicas from domain controllers in the various domains in the forest. You can follow the result of this replication in the Event log.
You can verify the identity of the Global Catalog servers in a forest using Replmon. Right-click a server and select SHOW GLOBAL CATALOG SERVERS IN ENTERPRISE from the flyout menu. You can also configure the ADSI Editor (Adsiedit.msc) from the Support Tools to query just port 3268, the port used for handling LDAP queries sent to a GC. If the server responds to queries on this port, you know it is a GC server.
You can leave the remaining FSMOs with the first domain controller unless you have some other reason to transfer them. For example, the second server might have a faster processor or dual processors, making it a better choice for PDC Emulator. You should transfer the RID Master along with the PDC Emulator. This is not strictly required, especially when operating at a Windows Server 2003 functional level, but it makes recovery a little less complicated when you do not split the PDC Emulator and RID Master roles between servers.
If the server is the first server in a site, it will become the Inter-site Topology Generator (ISTG) and the bridgehead server to the connected sites. Use AD Sites and Services to ensure that the domain controller establishes connection to its fellow bridgeheads and that it replicates according to the schedule and frequency you have assigned to the site links.
Shift Root Domain Functional Level to Windows Server 2003
By default, the functional level of a new Windows Server 2003 domain is set to Windows 2000 Mixed. There is no need to retain a low functional level in the placeholder domain, so before proceeding to the upgrade of the NT domains, shift the root domain functional level to Windows Server 2003.
Use the AD Users and Computers console to shift domain functional levels. Right-click the top of the tree and select RAISE DOMAIN FUNCTIONAL LEVEL from the flyout menu. This opens a window that permits you to select either Windows 2000 Native or Windows Server 2003 functional level. Figure 9.16 shows an example.
Figure 9.16. Using the Raise Domain Functional Level window to set a domain to Windows Server 2003 functional level.
After shifting the Domain functional level to Windows Server 2003, you must restart the domain controllers to gain full access to the new Windows Server 2003 features.
Active Directory Integrated DNS Zones
You can choose to move forward with the account domain upgrades, but you may want to pause for a while and reconfigure your DNS infrastructure. When you promoted the domain controllers in the root domain, they registered their SRV records with a preexisting DNS server. If you prefer to use Active Directory integrated zones, you can install DNS onto the new domain controllers and configure them to be the primary DNS servers for the Active Directory zone.
Be careful to configure the TCP/IP settings for one DC to point at the other DC as its primary DNS server. This avoids problems where a failure of replication causes a failure to update DNS records when then solidifies the inability to replicate. See Chapter 5, "Managing DNS," for details on installing DNS and changing zone types.
In Windows 2000 Mixed or Native functional level, the resource records for an Active Directory integrated DNS zone are stored in the Domain naming context. This is satisfactory if you have a single domain in your forest, but it can cause problems when you have multiple domains with domain controllers that reside in geographically remote locations. Clients need access to SRV records representing servers throughout the forest.
In Windows 2000, you could provide local access to forest-wide SRV records by creating a separate primary zone for the forest-related SRV records in _msdcs and placing secondary copies of this zone on DNS servers in the various domains.
Windows Server 2003 handles the problem more elegantly. When you shift a domain functional level to Windows Server 2003, you can put the DNS resource records in their own naming contexts rather than into the Domain naming context. Windows Server 2003 creates two naming contexts for this purpose, one for domain-related SRV records and one for forest-related records. You can see these new naming contexts using the Replication Monitor utility from the Support Tools. Figure 9.17 shows an example. You can view the contents of the naming contexts using the LDAP Browser, Ldp, which also comes in the Support Tools.
Figure 9.17. Replication Monitor showing the new DNS naming contexts created when a domain is shifted to Windows Server 2003 functional level.
Upgrade the PDC in the First Account Domain
After the placeholder domain is in place, you're ready to upgrade the first account domain. Figure 9.18 shows the result of this stage. The first step is to upgrade the PDC. A domain controller upgrade has two stages. First, the operating system is upgraded, followed by an automatic launch of Dcpromo to create the Active Directory domain. During the promotion, you will join the domain to the forest root in the placeholder domain.
Figure 9.18. NT domain following upgrade of first account domain PDC.
If you do not use a master license or volume license copy of Windows Server 2003, you must activate the server following installation. You have thirty days to do the activation, but the system will kvetch at you regularly until you comply, so you might as well get it out of the way as soon as you upgrade.
When the prerequisites have been met and your disaster recovery actions have been taken, follow Procedure 9.2.
Procedure 9.2 Upgrading an Account Domain PDC
Insert the Windows Server 2003 CD or initiate Winnt32 from a network drive. This launches the upgrade wizard.
When prompted, accept the End User Licensing Agreement (EULA) and enter the 25-character Product Key. The remaining portions of the operating system upgrade proceed without further user input.
Following the final restart after the network operating system upgrade, the Active Directory Installation Wizard, Dcpromo, launches automatically. At this point, the classic SAM and Security hives are still intact but the server does respond to logon requests. Users can still log on to the domain via the BDCs.
Before commencing Dcpromo, open a command prompt and verify using Nslookup that the server can see its DNS server and that the DNS server hosts the zone that will form the Active Directory domain.
In the Dcpromo wizard, click Next. The Create New Domain window opens. Select Child Domain In An Existing Tree. This prepares the domain to join the forest rooted at the placeholder domain.
Click Next. The Network Credentials window opens. Enter the name and password of an account with administrator privileges in the root domain along with the fully qualified DNS name of the root domain.
Click Next. The Child Domain Installation window opens. Under Parent Domain, enter the fully qualified DNS name of the parent. In this example, the parent is the root domain of the forest. Under Child Domain, enter the flat name of the NT domain you are upgrading.
Click Next. The Database and Log Folders window opens. Enter the path to the Active Directory files and the log files. This should be a separate spindle than the operating system.
Click Next. The Shared System Volume window opens. Enter the path for the Sysvol folder. This can be on the same spindle as the Active Directory files if the server will not be heavily loaded during morning logons. The volume must be formatted as NTFS.
Click Next. The DNS Registration Diagnostics window opens. This presents a report of the DNS connectivity for the server. If it was able to find a DNS server that hosts the specified zone and the zone can be dynamically updated, the wizard reports a success. Otherwise, it points you in the direction of the problem and gives you a chance to fix it before proceeding.
Click Next. The Permissions window opens. If you have no legacy NT4 RAS servers in production, select Permissions Compatible Only With Windows 2000 or Windows Server 2003 Operating Systems.
Click Next. The Directory Services Restore Mode Administrator Password window opens. Enter the password that you will use to access the server when Active Directory is not available. This password is assigned to the Administrator account in a new SAM installed at the completion of the promotion.
Click Next. A summary window opens.
Click Finish. The wizard begins the promotion.
Following the promotion, the server restarts to finalize the settings. The next section contains a set of verification checks you should perform to make sure everything went well.
Following the upgrade and promotion of the PDC, perform a quick set of checks to make sure critical services installed during the upgrade work as expected. This includes the following:
Account Replication to BDCs.
Make sure that the upgraded PDC, which is now a Windows Server 2003 PDC Emulator, is able to replicate to its downlevel BDCs. You cannot verify this directly by running User Manager from the BDCs because User Manager always points at the PDC. Verify replication by running Server Manager at the BDC, highlighting the BDC name on the list, and selecting COMPUTER | SYNCHRONIZE WITH PRIMARY DOMAIN CONTROLLER from the menu. This starts a replication cycle. Check the Event log to verify that the replication occurred.
DNS record verification.
Make absolutely sure that the SRV records for the new domain are registered in DNS. This registration is performed by Netlogon. It takes a few minutes to complete, so check back with the DNS server five minutes after you are able to log on at the console of the server. If the SRV records fail to appear, resolve the problem immediately. You can stop and start Netlogon to reregister the SRV records. By default, the server will refresh its registration once per hour.
Log on at a variety of client desktops to ensure that you can get authenticated. Some forms of SAM corruption cause a situation where Windows 98 users can logon but NT users cannot. This is due to a failure to import the NT password hash during the Active Directory promotion.
Log on from XP and Windows 2000 desktops to verify that you get Kerberos authentication and that you get group policies from the newly upgraded PDC. This can be verified quickly using the Kerbtray utility from the Resource Kit.
Verify that users get their roaming profiles and home directories as specified in their user accounts.
Test at least one dial-in user to verify that the account works to permit dial-in and that the RAS server is able to check the user's credentials.
Restart at least one of each type of NT-based client to ensure that computer accounts were copied successfully to Active Directory. If you have thousands of computers, you may want to check that the total number of computers present after the upgrade matches the total before the upgrade.
Log on at a desktop in a resource domain using an account in the newly upgraded domain to ensure that the trust is still in place. If you have a two-way trust between account domains, do this for accounts in both domains. Also, use the AD Domains and Trusts console to check the presence of each trust.
Logon script and system policy verification.
Check to make sure that the existing logon scripts and system policies were migrated to the \WINNT\Sysvol\Domain\Scripts folder. (The system folder is not renamed during an upgrade.) Put the alternate copy method in place to refresh the Netlogon share at the BDCs, and then log on at various clients to ensure that they get the logon scripts.
Share point verification.
Verify that any pre-existing shares are still in place. This includes the administrative (dollar-sign) shares. The simplest way to do this is using the NET SHARE command.
If the server was running special applications prior to the upgrade, make sure those applications are still functioning. This includes items such as backup agents (or the backup application itself), antivirus agents, web sites, and Simple Network Management Protocol (SNMP) agents.
Upgrade Account Domain BDCs
You can operate for a while in Windows 2000 Mixed, but to get the benefit of the new Active Directory features in Windows Server 2003, you need to shift the domain functional level to Windows Server 2003. This means getting the classic BDCs off the wire, either by upgrading them or decommissioning them. Figure 9.19 shows the configuration following this stage.
Figure 9.19. Mixed NT and Windows Server 2003 domains following upgrade of remaining BDCs in first account domain.
If the servers acting as BDCs have suitable hardware for Windows Server 2003 and are relatively free of legacy applications, you can upgrade them to Windows Server 2003 domain controllers in the same way that you did the PDC upgrade. The only real difference is the source of the files for creating the local replica of Active Directory. The BDCs do not convert their local SAM and Security hives. They copy the contents of Active Directory from an existing domain controller.
If the BDC is in the same location as the PDC, the upgrade and promotion should not take long. The Active Directory database is not large or complex at this stage of the deployment because of the backwards compatibility with existing BDCs. If you have several thousand users, you can use backup files as described in the placeholder domain upgrade.
You can also build new Windows Server 2003 domain controllers in the same site as the newly upgraded PDC then ship them out to the remote locations. When the domain controller arrives at the remote site, have a local administrator put the server on the wire and configure the TCP/IP settings. At that point, move the server to the correct site based on its new subnet.
Following the BDC upgrade, ensure that the newly promoted Windows Server 2003 domain controller replicates correctly with the other domain controllers. If this is the first domain controller in its site, verify that it acts as the bridgehead server and consider configuring it as a Global Catalog server. Also verify that it has connections to bridgeheads in the other sites as defined by the site link objects.
Upgrade Resource Domains
You've now finished the first stage of the upgrade and you need to decide what to do with the resource domains, as shown in Figure 9.20. You can upgrade them, in which case they are controlled by domain admins similar to the management processes used by classic NT, or you can migrate the computer accounts to the newly upgraded Windows Server 2003 domain and leave the resource domains behind.
Figure 9.20. Mixed NT and Windows Server 2003 domains following upgrade of domaincontrollers in the resource domain.
If you decide to retain separate domains, it is important to shift the functional level to Windows 2000 Native as soon as possible. This permits downlevel clients to access resources in the other domains via transitive Kerberos trusts on the intervening domains.
Upgrade Remaining Master Account Domains
At this point, you've completed the migration of an entire classic NT domain, including the account domain and all resource domains. Now you need to upgrade the remaining account domains and join them to the Windows Server 2003 forest.
Follow the same procedure for upgrading the remaining account domains as you did for upgrading the first one. The DNS domain name you select for the domain must be contiguous with the root domain. Be sure to verify user access to resources and replication between domain controllers, especially if the domain controllers are in different sites. Don't make the mistake of assuming that inter-site replication will just work all by itself. Sure, often it does, but you cannot be sure until you check.
You should also be careful to verify the transitive trust relationships that are created between the domains (see Procedure 9.3). Use the Trust Wizard in the AD Domains and Trusts console for this purpose.
Procedure 9.3 Verifying Transitive Trust Accessibility
Open the AD Domains and Trusts console at one of the domain controllers.
Open the Properties window for one of the domains. Select the Trusts tab (see Figure 9.21).
Figure 9.21. Properties window for showing Tree Root trust.
Highlight the trust and click Properties.
In the Properties window, click Validate. You'll be prompted for credentials in the remote domain.
If the validation is successful, it means the secret account that the two domains share is accessible and they both know the password. If it fails, you may need to reset the trust. When these checks show that you have full functionality in the resource domain, promote the remaining domain controllers.
Shift the Forest Functional Level to Windows Server 2003
When all downlevel domain controllers have been purged, you're ready to shift the forest functional level to Windows Server 2003. This opens up many additional features, primarily the ability to replicate discrete group members rather than the entire membership list. It also lets the Inter-Site Topology Generators (ISTG) and KCCs in each site use a streamlined spanning tree calculation to keep track of replication topology, increasing the scalability of the forest.
Shift the forest functional level using the AD Domains and Trusts console. Right-click the top of the tree and select RAISE FOREST FUNCTIONAL LEVEL from the flyout menu. This opens the Raise Forest Functional Level window shown in Figure 9.22.
Figure 9.22. Raise Forest Functional Level window showing selection of Windows Server 2003.
Click Raise to implement the change. You will not be offered the option as long as any domains in the forest operate at any functional level other than Windows Server 2003. You must restart all domain controllers in all domains in the forest to implement the change completely.
After you shift the forest functional level to Windows Server 2003, you are officially FINISHED with the deployment! The final step is to use your favorite search engine to look for a great vacation spot.