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.

End of Article

Prev. page     1 2 3 4 [5]     next page -->



You must log on before posting a comment.

If you don't have a username & password, please register now.

 
 

ADS BY GOOGLE