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.
AD Schema Diagnose
Schema Diagnose saves you from having to remember all this stuff. It conveniently verifies if these requirements are being satisfied. So let's get the application installed:
Start by downloading Schema Diagnose from the application homepage.
The application may be run on any machine with Window 2000 Professional and higher. Extract the downloaded executable to the machine from which the final schema extension is to be performed.
Run the application and have a close look at the generated report.
Schema Diagnose produces a report broken down into a number of sections. We next go through each section and see how these map to what we discussed so far.
The application runs under the security context for the current user. The first report section lists the user group membership. From here we can immediately see whether the current user is member of the Schema Admins group.
Next the Schema Master is identified. The report includes the machine fully qualified name, its LDAP path, operating system, service pack and build.
Thirdly Schema Diagnose connects to the Schema Master through LDAP. In this manner we clearly determine whether the machine is alive and accessible.
The next step verifies registry accessibility and the current status for the 'Schema Update Allowed' value. As we said (and as the report reminds us) this is only necessary for Windows 2000 machines.
The final report section is an interesting bonus. Schema Diagnose directly verifies the complete set of access rights for the current user over the AD schema container. Whereas the first test enables visual inspection for the 'Schema Admins' security group, this test determines the exact access level and the set of rights the user is granted over this container.
Troubleshooting Replication Problems
When looking into replication problems, the Replication Monitor (Replmon.exe) is the tool for you. This is part of the support tools included on the Windows Installation CD. Through it you can force immediate replications, and identify machines causing replication failures. This is exactly what we need to resolve any schema replication problems.
Replmon is a very powerful feature-rich tool. For more details on how to use this tool follow the link at the References section.
References
AD Schema Diagnose
Replmon.exe: Active Directory Replication Monitor