Please let others know how useful this tip is via the rating scale at the end of it. Do you have a useful Exchange or Outlook tip, timesaver or workaround to share? Submit it to our tip contest and you could win a prize.
The Active Directory schema controls what objects can be listed in AD and what their attributes can be. In a Windows domain, the server that has the schema master role performs whatever updates and modifications are needed to the schema.
A malfunctioning Active Directory schema can cause all sorts of problems for Exchange, from replication issues between servers to Exchange not working at all. An administrator not aware of possible problems with the AD schema might be inclined to (mistakenly) blame the problem on Exchange itself.
If your domain's schema updates are not taking place or seem to be having problems, there is a utility from WinDeveloper.com that can take some of the pain out of debugging problems with schema updates. Active Directory Schema Diagnose (ADSD) runs several tests to determine whether or not the schema can be successfully updated, and also where a problem might lie if it can't.
When run, ADSD performs five tests:
- It gets the security context information the application itself is running under. This ensures that the user running the application is part of the Schema Admins group. If you're logged on as Administrator, this should work by default, but if something's been done to the group membership for that account, this should sniff it out.
- It retrieves the schema's master machine details -- the machine name, distinguished name (as listed in AD), machine object name, and what OS/service-pack level is on the machine in question. If there's a mismatch between the machine name and its distinguished name, the machine may need to have its role reset.
- It tests LDAP connectivity to the schema master. If the connection test fails, but the other tests so far succeed, that might indicate a network misconfiguration.
- It tests connectivity to the scheme master machine's registry. If this fails, check to make sure the user in question has the rights to set the "Schema Update Allowed" registry value -- either because they don't have the rights to modify the registry in general, or because that particular subkey/value has the wrong permissions set on it.
- It tests the access level(s) the user has on the AD schema container. This makes sure that the user has all the needed individual rights as well (i.e., the right to create object children or write object properties).
For the best results, ADSD should be run by an administrator, as running the program in a limited-privileges context may cause some of the tests to fail. (This isn't a symptom of anything wrong per se; lowered privileges just inherently cause many AD actions to fail.)
About the author: Serdar Yegulalp is editor of the Windows Power Users Newsletter,
Do you have comments on this tip? Let us know.
Related information from SearchExchange.com: