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.
Register
