By now, you've heard a lot about Windows Server 2003 and the advantages it might hold for your Active Directory (AD) infrastructure. If you've looked at the product documentation, you've probably discovered that the Windows 2000–to–Windows 2003 domain controller (DC) upgrade process is straightforward. But you might not realize that before you can upgrade to a Windows 2003 AD infrastructure, you need to use the Adprep utility to prepare your Win2K AD forest schema and structure.
The Adprep process appears to be straightforward. The utility has two options: Forestprep, which you run once for the forest, and Domainprep, which you run once in each domain. Although executing the process doesn't take long, you need to make sure that you fully understand the utility's prerequisites and prepare for its effects because Adprep has a permanent impact on the entire forest.
Adprep Prerequisites
As with any major system change, you should review the Microsoft Knowledge Base for any information related to Adprep that didn't make it into the product documentation. For example, the Microsoft article "Hotfixes to Install on Windows 2000 Domain Controllers Before Running Adprep /Forestprep" (http://support.microsoft.com/?kbid=331161) details which service pack level and hotfixes you should have in place before you run the utility. Essentially, you should have at least Win2K Service Pack 2 (SP2) installed on your DCs. If you have a lot of DCs or a large AD database (the article doesn't define large), you should install SP3 because it contains a fix that makes indexing for new attributes an operation that has little impact on a DC's performance. Because SP4 is the current service pack, this requirement shouldn't present a problem.
Even though the schema upgrade is a well-understood process with few failures, it's also irreversible. After you execute Forestprep and its changes have replicated to your forest, performing an authoritative restore of your entire AD infrastructure is the only way to back out. Before you run a large schema upgrade, make sure your AD infrastructure is healthy. You should have system-state backups of at least two DCs in each domain, and you should have tested the backup restores. If you have a large AD database (C:\%systemroot%\ntds\ntds.dit), you should have backups of every DC; a restore from tape is faster than replicating and rebuilding the database. The Microsoft article "How to Upgrade Windows 2000 Domain Controllers to Windows Server 2003" (http:// support.microsoft.com/?kbid=325379) provides up-to-date details about upgrading your Win2K DCs to Windows 2003 and discusses auditing your domains for down-level clients and making sure your DCs are at the correct software level. If you run or intend to run Microsoft Exchange 2000 Server in your forest, check out the article's discussion about how Forestprep redefines three non–Internet Engineering Task Force (IETF) Request for Comments (RFC)–compliant attributes: houseIdentifier, secretary, and labeledURI. If you've already run the Win2K InetOrPerson Kit, you shouldn't have a problem. If you haven't and you run Forestprep, you might mangle the attributes. Therefore, before you run Adprep, run a Lightweight Directory Access Protocol (LDAP) Data Interchange Format (LDIF) file that fixes the Exchange schema problems. See "How to Upgrade Windows 2000 Domain Controllers to Windows Server 2003" for details.
Another little-known consideration of the DC upgrade is that it disables the Distributed Link Tracking Server service, a service that pairs with the Distributed Link Tracking Client service to track links (e.g., shortcuts) as files move on a computer or among computers. Microsoft recommends that you disable the service on DCs (do so now; you don't have to wait until you install Windows 2003) to reduce replication overhead and delete the Distributed Link Tracking tables in AD to reduce database size. See the Microsoft article "Distributed Link Tracking on Windows-Based Domain Controllers" (http://support.microsoft.com/?kbid=312403) for details.
Forestprep Execution and Console Output
To run Forestprep, log on to the forest's schema master console with an account that's a member of both the Enterprise Admins and Schema Admins groups. By default, the schema master is the first DC in the forest. You can identify the schema operations master by running the Netdom Query FSMO command (from the Microsoft Windows 2000 Resource Kit).
Although you could separate adprep.exe and its required files, prestaging the entire \i386 folder to a temporary folder on the schema master and all infrastructure masters is easier and lets you locally execute the Forestprep and Domainprep commands. The Forestprep command is simple:
adprep /forestprep
After giving you a warning about the need to upgrade all your DCs to at least Win2K SP2, Forestprep gives you the following prompt to make sure you've installed Win2K SP2 or later:
\[User Action\]
If all your existing Win2K DCs meet this requirement, type C and press Enter to continue. Otherwise, type any other key and press Enter to quit.
After you type C to confirm that you want to run Forestprep, then press Enter, the utility will start upgrading the schema, working its way from version 14 to version 30. Figure 1 shows a portion of this upgrade.
Before you can take the next step and run Domainprep in a domain, the schema changes must replicate to at least the infrastructure operations master in that domain. I recommend that you let the Forestprep schema updates replicate throughout the entire forest before you move on to Domainprep.
Forestprep Under the Covers
Even though the Forestprep operation is a significant schema upgrade, it doesn't add or remove any attributes in the partial attribute set. The partial attribute set is a subset of all the AD attributes in the Global Catalog (GC). In Win2K, changing which attributes are marked for the GC will cause a resynchronization of the GC on every DC in the forest. In a forest that contains large domains, such an operation on a DC can take days. If you have an application such as Exchange 2000 that depends heavily on the GC, the impact on your users will be even greater. The Forestprep operation doesn't affect the GC, however.
Forestprep performs two major functions. First, it runs schupgr.exe, the Win2K schema upgrade utility. Schupgr executes sequentially against the C:\%system-root%\system23\schxx.ldf files, in which xx changes from 14 to 30. These files contain the changes Forestprep makes to AD, so if you want to identify the AD updates, look in these files. If for some reason you must restart Forestprep, the process will continue from the most recent successful schxx.ldf file update. Second, Forestprep changes ACLs in the configuration partition. In Win2K and Windows NT 4.0, the Everyone group includes the Guests group (i.e., anonymous logons). Windows 2003 has tightened this definition; the Everyone group now contains Authenticated Users but not Guests. For DCs to read information in other domains, you need to adjust some ACLs on existing objects by adding Read rights for the Enterprise Domain Controllers group.
Adprep maintains detailed logs of all its activities in C:\%systemroot%\system32\debug\adprep\logs\YYYYmmDDhhMMss\adprep.log, where YYYYmmDDhhMMss represents the year, month, day, hour, minute, and second when you ran Adprep. This naming convention ensures that each Adprep execution gets its own unique folder, which also contains detailed logs of the execution of each LDIF file. These logs describe the execution's success on the schema master.
But how do you know when these changes have replicated throughout your forest? After Forestprep has successfully finished, it creates a Windows 2003 Update container in CN=ForestUpdates,CN=Configuration,DC=rootdomain,DC=company, DC=com, where rootdomain and company are the names of your root domain and company. An easy way to track the schema updates throughout the forest is to connect to the bridgehead servers of your major sites with ADSI Edit to determine when Forestprep creates this container.
Another way to determine that Forestprep replication has reached a particular DC is by checking the value of the ObjectVersion attribute on that DC. You can use ldp.exe (in the Win2K Support Tools) on the DC whose version you want to check. To do so, launch Ldp and select Connection, Connect; enter the target DC in the Connect dialog box; and click OK. Next, bind to the DC with a valid account and password. Select Browse, Search, and the schema container (CN=Schema,CN=Configuration,DC=yourdomain,DC=xyz, where yourdomain and xyz are your domain's name and extension—e.g., com, org, net). Enter the LDAP query (objectversion=*) in the Filter text field and select Subtree on the Scope tab to search the schema container for the value of ObjectVersion beyond the base distinguished name (DN) and throughout the subtree. Your output should look something like
ldap_search_s(ld,"CN=Schema,
CN=Configuration,
DC=domain1,DC=deuby,DC=net",
2, "(objectversion=*)", attrList,
0, &msg)
Result <0>: (null)
Matched DNs:
Getting 1 entries:
\>> Dn: CN=Schema,
CN=Configuration,
DC=domain1,DC=deuby,
DC=net
1> objectVersion: 30;
Controlling Forestprep
Chapter 12, "Upgrading Windows 2000 Domains to Windows Server 2003 Domains," of Designing and Deploying Directory and Security Services (Microsoft Windows Server 2003 Deployment Kit; http://www.microsoft.com/windowsserver 2003/techinfo/reskit/deploykit.mspx) recommends that you keep the schema master online during the upgrade. But is this recommendation a good practice? Engineers and systems administrators are conservative by nature; they might not feel comfortable executing a low-risk but extremely high-impact (if it causes schema corruption) operation without having any control over its spread or having a backout plan. If your Forestprep process fails, you won't find any easy backout plans. The best you can hope for is that replication still works so that you can perform an authoritative restore of your schema partition or execute a forest recovery. You can download a forest recovery document from the Microsoft Web site (http://download.microsoft.com/download/win2000srv/utility/1.001/nt5/en-us/forestrecovery.exe).
Microsoft recognizes this problem. The Windows 2003 Help files recommend that you disconnect the schema operations master from the network before you run Forestprep. However, the Microsoft article "Windows Server 2003 Help Files Contain Incorrect Information About How to Update a Windows 2000 Domain" (http://support.microsoft.com/?kbid=821076) says that the Help file recommendation is incorrect. Why is disconnecting the schema master incorrect? On the surface, disconnecting the schema master from the rest of the network makes perfect sense. If you do so and the schema becomes corrupted during the schema-upgrade process, the corruption won't replicate throughout the forest. But Microsoft development tests of Forestprep on a Win2K SP3 schema master discovered that when the isolated master is rebooted, it doesn't reassume the schema master role if it doesn't have another DC with which to replicate. Therefore, if you take a second DC off the public network, you must alter DNS records to get the two machines to communicate correctly. If you haven't restored all the records to their original state (incidentally eliminating communication between the two machines) when you bring the systems back online, the altered DNS records will replicate throughout the domain. This method isn't worth the trouble because a simpler method exists: You can effectively control the replication of Forestprep and Domainprep changes by isolating the schema master to its own site and controlling replication between that site and the rest of the forest sites.
You can take this quarantine concept a step further by isolating an existing site (usually the site on which the schema master typically resides) both from the schema master site and the rest of the forest. Although having a schema master site is a great idea, you can perform only so much AD testing on one isolated DC. You need to test the Forestprep changes on your crucial AD-aware applications such as Exchange 2000 before you can certify that the upgrade is good. Only then can you release the schema upgrade to replicate throughout the forest.
Let's take a look at the quarantine process. Let's call the schema master site the stage 1 quarantine site and the other site the stage 2 quarantine site.
The Forestprep Quarantine Process
The first step in creating the stage 1 quarantine site is to create the site link and site, as Figure 2 shows. The site link should connect the stage 1 quarantine site and the stage 2 quarantine site with an interval of 15 minutes and a cost of 1. You might want to use a naming convention that includes both the physical location and schema so that the site's purpose is obvious. For example, if your company's schema master and several other DCs reside in Muleshoe, Texas, and the AD site is named Muleshoe, you can name both the stage 1 quarantine site and its site link Muleshoe-Schema. The stage 2 site can keep its original name.
Move the schema master into the stage 1 quarantine site by launching the Microsoft Management Console (MMC) AD Sites and Services snap-in, drilling down into the schema master's current site, right-clicking the schema master's computer object, and selecting Move. Select the stage 1 quarantine site as the object's destination and click OK. You don't have to assign subnet information to this site because you'll use the site only for replication purposes (not for client logon). Therefore, you don't need to add subnet information or change the IP settings on the schema master. At this point, your actions will have had little impact on production operations.
Move all domain PDC and Relative Identifier (RID) operations masters from the stage 2 quarantine site to another site. This action ensures that the quarantine doesn't affect these crucial infrastructure roles.
Isolate your stage 2 quarantine site from the rest of the forest. To pause replication, identify all site links and manual connection objects (COs) between the stage 2 quarantine site and the rest of the forest. Then, for each site link you've identified, use the AD Sites and Services snap-in to edit the properties of the site link. Follow these steps:
- In the left pane, select Sites, Inter-Site Transports, IP.
- In the right pane, right-click the identified site link and select Properties.
- Click Change Schedule.
- Select Replication Not Available and observe that all blocks in the replication schedule table change from blue to white.
- Assuming today is the implementation day, select the blocks on the schedule for 12:00 a.m. today up to the time when the replication quarantine will become active.
- Select Replication Available and observe that all time blocks for today (before the replication quarantine) change from white to blue, as Figure 3, page 60, shows. If you don't select at least some time for replication to occur, AD will ignore the schedule and replicate anyway.
- Click OK twice.
You also need to pause replication on each manual CO that pulls replication from your stage 2 quarantine site; otherwise, the changes will leak out through the COs. If you haven't kept a record of the manual COs, the only way to pause replication is by examining the NTDS settings of every DC in the forest (except for the quarantined DCs) for incoming COs from the quarantine sites. To pause replication on a CO, launch the AD Sites and Services snap-in. In the left pane, select Sites (the remote site that has the manual CO), Servers (the server that owns the manual CO), then NTDS Objects. In the right pane, right-click the CO and select Properties. Pause replication on the object by following steps 3 through 7 of the technique I described earlier.
Pause replication between the stage 1 quarantine site and the stage 2 quarantine site by using the technique of manipulating the replication schedule that I described earlier. You won't have to deal with any manual COs. You've now established the two-stage quarantine of your schema master.
The quarantine will prevent the rest of the forest from seeing any changes made to AD inside the quarantine. Without this prevention, problems can arise. For example, if you don't direct Help desk AD-related operations to a DC outside the quarantine, users might not see the results of the Help desk's changes for many hours.
You're now ready to run Forestprep as I described earlier. After you run the utility, check adprep.log for any errors. Run Dcdiag (in the Win2K Support Tools) and check the event logs for any unusual error messages.
If you have to back out of the upgrade for any reason, take the corrupt schema master offline for good and use Ntdsutl to seize the schema master role to another DC. Seizing simply designates the new master and doesn't attempt to transfer the existing master's configuration to the new master. (If the corrupted master is still online when you attempt to seize the role, Ntdsutl will automatically transfer—rather than seize—the corrupt schema out of your quarantine.) Then, rebuild the former schema master from scratch, not from backups. This master is no longer the schema master, so restoring it from backup would create two schema masters in the same forest.
When you're satisfied with the Forestprep results, release the stage 1 quarantine by enabling replication along the stage 1 quarantine site–to–stage 2 quarantine site link. After giving the schema changes time to replicate through the stage 2 quarantine site, make sure that all your AD-aware applications are working satisfactorily. Backing out at this point is painful but less painful than having to recover the entire forest. Make every effort to solve your application incompatibility rather than back out. If you must back out, route replication around your stage 2 quarantine site, seize the schema master to an offsite DC, and rebuild the DCs in the site. You can perform a restore from tape of all DCs except for the schema master.
If you're satisfied with your testing results, you can open the schema changes to the rest of the forest. You can use the ReplMon tool (in the Win2K Support Tools) to force replication from the stage 2 quarantine site to each remote site with which it has site links. Follow these steps:
- Right-click Monitored Servers and add a DC in the remote site as a Monitored Server.
- In the left pane, select Monitored Servers, the target remote site, then the target DC in the remote site.
- Open the schema replication-naming context under the DC's name.
- Right-click any replication partner inside the stage 2 quarantine site, select Synchronize with this replication partner, and monitor the resulting replication.
- Reset the site link and manual CO replication schedules to normal to remove the quarantine.
Domainprep
After the Forestprep changes have replicated, you can start the Domainprep
process. Compared to Forestprep, Domainprep is disarmingly simple. Log on to the infrastructure master of each domain and execute the command
adprep /domainprep
After Domainprep executes, the console output will display the message: ADPREP successfully updated the domain-wide information. At this point, check adprep.log for any errors, run Dddiag, and check the event logs for any unusual error messages.
Microsoft has identified one quirk of Domainprep: It changes some container-inheritable access control entries (ACEs) in the \%systemroot%\SYSVOL folder, which triggers the File Replication Service (FRS) to perform a full synchronization of its content. This synchronization isn't a problem for most domains, but it will have an impact if your SYSVOL is large (i.e., contains a lot of Group Policy Objects—GPOs—large logon scripts, or roaming profiles). Microsoft will supply a fix in Windows 2003 SP1 that will remove this operation from the standard Domainprep, and you'll have to supply a special switch to run the operation.
When Domainprep has successfully finished, it will create a Windows 2003 Update container in CN=DomainUpdates,CN=System,DC=rootdomain,DC=company,DC=com. Note that this container is different from the container that Forestprep creates. Like Forestprep, however, Domainprep creates an Operations container with subcontainers that identify Domainprep operations. You can track the Domainprep updates through the domain by monitoring the existence of these containers.
Domainprep Under the Covers
Domainprep makes changes to AD's logical structure and increases security (adds ACEs) on several objects. It also implements a more efficient way of managing Security Descriptors (SDs—the AD structure that contains ACLs) than Win2K does by moving unique descriptors from objects to a table and replacing the descriptors in each object with a link to the table. This process shrinks the database and makes operations such as granting an administrative group Write access to an organizational unit (OU) much faster, without growing the database the way Win2K does. The space you gain will be white space—free space internal to the database—which the database will use if objects are added to AD. You won't see the actual ntds.dit file size decrease, however, until you use Ntdsutil to perform an offline defragmentation.
Because the changes Domainprep makes are internal to AD, if you test a DC that Domainprep has updated against your AD-aware applications, you probably won't have to quarantine the Domainprep operation. If you choose to quarantine the operation, erect a quarantine based on the scope of the domain in which you're running Adprep rather than the entire forest.
Adprep Best Practices
I recommend that you start your update on a Friday night. Doing so will allow enough time for you to set up the two-stage quarantine on Friday night, for Forestprep to replicate throughout the forest overnight Friday, and for Domainprep to replicate in each domain on Saturday. If you have international offices that work on Sundays, you have only until about midnight on Saturday to finish your maintenance.
I also recommend that you tightly control the membership of the Schema Admins group by putting it in the Restricted Groups section of the default domain GPO. This step will ensure that any unauthorized membership changes will be removed (and logged, if you have auditing enabled) within 5 minutes. When you have to become a member of this group, use Group Policy to add yourself to the group.
At every step in which you reconfigure systems, COs, and sites, verify that replication is working correctly. Allow enough time for this process in your procedure; start the nondisruptive steps such as site creation and system moves well ahead of the formal implementation time.
If any operations master roles are on DCs in the stage 2 quarantine site, transfer them before the upgrade. This action lessens the impact any backout will have on the domain's operations.
You can also use Repadmin (in the Win2K Support Tools) to disable replication. (Although this method is easier to execute than the two-stage quarantine, you're probably better off creating and managing the quarantine because it provides more thorough testing.) The following Repadmin command on a DC will disable outbound replication:
repadmin /options <DC> +disable_outbound_repl
To enable replication again, change +disable to -disable.
A Simple but Necessary Process
Adprep is the deceptively simple process you must go through before you can upgrade your Win2K DCs to Windows 2003. Don't underestimate the resources involved, especially in a large company that has change-control boards and a lot of DCs. Do some serious advance planning to ensure that your first step toward upgrading to Windows 2003 is a smooth one.
