Active Directory is the true heart of Windows 200x domains. Its proper functioning is critical to the network and the many applications relying on it. Exchange is no exception. Indeed it is one of the most avid consumers of Active Directory (AD) objects. Exchange immediately establishes its close AD ties on installing the first server. This is done during the forestprep step, a process that creates a plethora of schema extension objects.

Keeping AD in good health is a broad topic that no single article can cover. Today I will focus on one aspect, schema extensions. I will use AD Schema Diagnose, to verify that the system is ready to handle extensions. We will see the type of tests this freeware tool performs, and how to interpret its output report.

Schema Extension Walkthrough

Let's have a quick look at the extension process. This is a rough description of what forestprep and other extension applications need to perform in-order to get their job done.

First of all the Schema Master machine must be identified. This is a special domain controller that handles all schema extensions for the forest. In all there are five roles that must be taken by one or more servers so as to ensure proper functioning and maintenance of AD. These are known as the Flexible Single Master Operation FSMO roles. In organizations with a single domain controller all roles are handled by the same server. In larger organizations these are normally more distributed.

Once identified, the application creating the new schema objects must connect to the Schema Naming Context. There are three naming contexts in AD. Each stores different types of AD objects. As you can imagine, the schema partition is where schema extensions are stored. The other two are the Domain and Configuration naming contexts. The former is where domain objects such as Users, Groups and Computers are stored. The latter stores application configuration objects.

On Windows 2000 machines an extra step is also required before extending the schema. This is the setting of the 'Schema Update Allowed' registry value under:
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

This must be set on the Schema Master machine. Thus remote registry access might be necessary. Setting this DWORD value to 1 enables schema extensions. If missing or set to 0 extensions won't be allowed.

Things That Could Go Wrong

In the above discussion we saw a nice straight forward scenario where everything just works. Of course when it is your turn to do it, things tend to work a bit less smoothly. So I go through some common pitfalls.

To begin with, there might be no Schema Master. Yes this FSMO role is sometimes a bit elusive. This most commonly happens when the Schema Master machine is removed from the network without handing over its role to some other machine. This is something I came across quite a few times. Administrators very often only realize it is missing on attempting a schema extension.

Another show stopper is access rights. Extensions must be run by a user member of the Schema Admins Universal Security Group. The fact that the schema partition is common to the entire forest, the fact that schema extensions are sticky and difficult to get rid off, clearly demand limiting the users who can perform these extensions.

Yet another pitfall is schema replication. Once the Schema Master gets hold of an extension this must be replicated over the entire forest. This means that depending on the replication schedules, schemas might take some time until these become visible to the entire network. This in turn means that creation of AD Objects might not be immediately possible.

Apart for the delay, pending replications also cause failure of subsequent schema extensions. Thus, one needs to make sure there are no replication issues and that all pending replications are complete. For this reason I will elect replication as one of the trickiest source of problems in this area.

Finally for those running the Schema Master on Windows 2000, the registry flag introduces yet another trap. This is especially true when the schema extension is run from a remote machine. In this case you clearly need remote registry access. So if you have a mix of 2000 and 2003 machines try to hand over the Schema Master role to a 2003 server.