There are some considerations in modifying the Active Directory schema. I am hoping this will be helpful to others that may have similar questions. Despite the short intro, let's get into the details:
Main player: The Schema Master
The Schema Master is one of the 5 FSMO roles in Active Directory. By default, the first domain controller in the domain is the Schema Master. This is a role that only one domain controller is allowed to hold this role and will accept changes to the schema. This is done to prevent conflicts.
When you do make changes to the schema, the best practice is to be connected directly to the Schema Master itself, otherwise the domain controller will refer the request to the actual Schema Master role holder. Also, in the interest of security, use the Schema Admins group sparingly. Meaning: Add the admin who needs access to this change, run what you have to run, and revoke group membership. Do not leave anyone in this group unless there is a specific job to run.
To find the Schema Master quickly, you can use this quick little PowerShell. Get-ADForest | Select-Object SchemaMaster. This certainly beats the old ntdsutil method. 🙂
Replication of Active Directory
When a Schema modification is made, all domain controllers will have this information replicated for consistency. While replication is occurring, you can expect to see an inconsistency in the domain controllers temporarily. This really is a good reason to make sure replication is healthy prior to making any schema change.
How the domain controllers stay consistent is that replication occurs and is retried specifically from the originating server. If an object is missed (say it wasn't replicate yet on the originating server), a re-replication takes place which will insure that consistency.
Schema changes are considered urgent in Active Directory, and changes to "Attribute-Schema" (located in the Schema partition) will block other replication until the schema changes are performed.
Slow down, replication partner
One thing that insures consistency in replication is single threading. Single threading may seem old and archaic, but the best practice is never to modify the Active Directory Schema by more than one process at a time.
Example: Say you are extending the schema for Exchange while extending the schema for SCCM at the same time. It is very likely one of these installs will fail, because a thread for Exchange was trying to overlap a thread for SCCM to extend the schema. This is important, because a process that modifies the schema may not reinstall cleanly, especially if some of the objects have been created already.
Putting your minds at ease
I've used Active Directory since Windows 2000 Beta, which has been around for just over 20 years now. I got into it about 1998, and since then have yet to see a schema update when done by best practice ever cause Active Directory to collapse. Has it happened? I've just not seen or heard of it. There are plenty of safeguards built into the schema that helps with this.
This isn't a directive to "go crazy" on updating the schema, or to be careless in your environment. I've seen schema updates not take for a variety of reasons and saw some who would stop replication while they updated the schema successfully. If it failed, they killed the domain controller, seized the role, and rebuilt the old domain controller. Always exercise good caution when making these changes.
I hope this was a good and more simplified take on not just how the Active Directory Schema works, but also how it replicates.
— Easy link to my blog: http://aka.ms/leesteve —
If you like my blogs, please share it on social media and/or leave a comment.