Windows Insider

(Almost) Painless Schema Mods

You might want to take a few precautionary steps prior to initiating ADPREP.

• By Bill Boswell
• 02/01/2005

You're an administrator in a large company—a very large company. You're responsible for a Windows 2000 Active Directory forest made up of several domains, with a total user count well in excess of 100,000 and an equal number of computer accounts and group objects.

The Ntds.dit file (which holds the AD database) on a typical Global Catalog (GC) server in this organization is nearly 4GB. A copy of this file resides on hundreds of domain controllers scattered across the globe. Many of the sites containing these domain controllers have frame relay connections with a Committed Information Rate (CIR) in the low double digits, some as slow as 28Kbps.

As the administrator for this forest, you've been given the task of preparing AD for an upgrade from Exchange 5.5 to Exchange 2003. To achieve this goal, you must (insert scary music here) modify the Active Directory schema.

PAS Considerations
Among the many schema changes that Exchange 2003 performs, quite a few involve changes to the constituents of the Partial Attribute Set (PAS). The PAS determines the content of the Global Catalog. Of the more than 1,400 Win2K AD schema attributes, only a couple of hundred are in the PAS, which helps to reduce the overall size of the GC.

Changing the PAS has an important consequence in a large Win2K AD. You see, Win2K has this tiny little architectural—um—feature. If you change even one constituent in the PAS, AD rebuilds the entire GC, then replicates those changes to all the GC servers in the forest.

In an organization with a couple of thousand users and groups and computers, this GC rebuild might go unnoticed. In an organization with thousands and thousands of objects and hundreds of domain controllers, many of which sit behind frame relay connections with speeds slower than a rusty old modem, a GC rebuild would create a tsunami of replication traffic.

It turns out that Windows Server 2003 does not share this architectural feature with Win2K. There is no rebuild of the GC following a change to the PAS. So the most straightforward way to avoid a flood of replication when installing Exchange 2003 is to first upgrade the domain controller to Windows 2003.

It'll take a while to upgrade hundreds of domain controllers, but the alternative is to impede operations for a considerable number of days while the GC adjusts itself to the changes made by Exchange.

Wait, You're Not Done Yet
OK, so you upgrade your domain controllers to Windows 2003. You've managed to dodge the bullet of a GC rebuild, but now you have another challenge. Before you can deploy the first Windows 2003 domain controller, you must prepare AD with the additional attributes and classes required to support all these new features. Once again, this requires (insert more scary music here) modifying the schema.

The utility that performs AD changes for Windows 2003 is called ADPREP. The schema modifications that ADPREP performs do not change the PAS, but they do modify a significant number of objects in the schema, not to mention making changes to many security descriptors in the Configuration naming context.

In many organizations, before you can perform an evolution like running ADPREP, you must first fill out a change control form. Every such form I've ever seen contains a couple of line items that look something like this:

• Potential negative consequences:
• Rollback procedure:

These innocent-looking entries may cause you to sputter a bit when you encounter them. After all, the potential negative consequences of a schema modification are tremendous. If ADPREP scrambles the schema, then AD stops working and, shortly thereafter, you might be asked to stop working as well.

The rollback procedure looks equally nasty. You would remove every domain controller from operation, restore a domain controller in each domain from tape (hoping against hope that the trust relationships between the domains in the forest survive after the tape restore), then reinstall the other domain controllers from scratch and watch as the contents of AD dribble out to the domain controllers that sit behind slow WAN links. That's not exactly a recipe for a fun weekend, month, or even career. With all this in mind, you might want to take a few precautionary steps prior to initiating ADPREP.

Controlling Schema Modifications
Start by creating a temporary site on a separate physical network that you can isolate from the main network. In this site, install a new Win2K domain controller for each domain. You'll be removing these servers from the production network for a while, so include a DNS server so the domain controllers can replicate with each other. To reduce the hardware requirements for this temporary site, you can use VMware or Microsoft Virtual Server to create virtual domain controllers.

Before running ADPREP, transfer the Schema Master role to the forest root domain controller in the temporary site. You must modify the schema at the console of the Schema Master.

When you're ready to do the schema modifications, remove the temporary site from the network, make sure the domain controllers can replicate with each other, then run ADPREP/FORESPREP at the Schema Master. Let the changes replicate to the other domain controllers in the isolated site.

(Note: If something goes tragically wrong at this point, you haven't lost a nanosecond of production time. Simply leave the domain controllers isolated from the production network. Seize the Schema Master role back to a production server using NTDSUTIL. Remove the temporary domain controllers from AD metadata using Knowledge Base article 216498 as a guide. It's a simple rollback process, one that only takes a couple of lines to describe on the change control form.)

If the isolated site seems to be stable following the schema modification, connect the domain controllers back to the production network and force replication out to the remaining domain controllers in the forest.

You can control the wave of replication as it moves out across your network using a Repadmin switch called /option to manually turn replication off and on at each domain controller. The syntax to turn off both inbound and outbound replication is:

Repadmin /option +Disable_Outbound_Repl +Disable_Inbound_Repl

To turn on replication, issue the same command but replace the + with a -. (These switches, and other advanced settings, are documented in repadmin /experthelp.) Windows 2003 leaves a telltale object in AD when all the updates have been applied to a particular domain controller. The distinguished name for this object is:

CN=Windows2003Update,CN=ForestUpdates,CN=Configuration,
DC=domain_name,DC=domain_root

You can look for this object using ADSI Editor or LDP, the Windows LDAP browser or a script.

Once you've replicated the FORESTPREP changes to all your domain controllers, run ADPREP/DOMAINPREP at the Infrastructure Master for each domain. DOMAINPREP does a set of low-impact updates and doesn't require isolation. The telltale object indicating completion of the changes has the distinguished name:

CN=Windows2003Update,CN=DomainUpdates,CN=System,
DC=domain_name,DC=root_name

With DOMAINPREP out of the way, you can now promote a Windows 2003 server in each domain.

Limiting WAN Traffic
To control WAN traffic as you install additional DCs, take advantage of a new Dcpromo feature in Windows Server 2003 called Install From Media (IFM). Here's how it works: First, use NTBACKUP to do a System State backup of a Windows 2003 domain controller to a backup file. Back up a GC server to capture the maximum amount of information.

Maintain tight security over this file because it contains every password hash for every user and computer in the domain. If you need to copy the file to portable media, encrypt it first. A handy utility for this kind of work is SecureZIP from PKZip (www.pkzip.com).

Next, copy the backup file to the Windows 2003 server that you intend to promote to a domain controller. Use NTBACKUP to restore the System State files to a temporary folder on the server. Don't put the files where you're planning to put the AD files.

Now run Dcpromo /advanced. The advanced switch adds an extra window to the wizard where you can specify the location of the restored System State files. The wizard populates AD with the contents of these files. An IFM promotion takes less than 15 minutes to complete, even for an AD domain with 100,000 users.

When you restart the domain controller following Dcpromo via IFM, the DC will synchronize with an existing DC to retrieve any updates since you did the backup. Don't use a backup file older than 60 days, the tombstone interval for deleted objects in AD.

By maintaining tight control over schema mods, you give yourself a manageable rollback method and minimize WAN traffic. If you have questions about the details of this process, e-mail me.