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.
Prev. page
1
2
[3]
4
5
next page 
