The Schema Master is the only DC that has permission to WRITE to the schema itself. In addition, while making changes to the schema, the user must log in to the domain as a member of the Schema Admins group. Because of the rights and permissions given to this group, membership should be very limited or even none, until the schema modification is needed. This group should be closely monitored, especially with a monitoring product such as System Center Operations Manager which can alert you if changes to a group’s membership are detected. When an administrator is a member of the Schema Admins group logs into the schema master, changes to the schema are allowed. Changes to the schema can be easily made by using the Schema snap-in accessed within a Microsoft Management Console (MMC). Before the snap-in will be available as a choice within the MMC, you must first register the DLL using the following command: Using the RUN command, regsvr32 schmmgmt.dll: Once the DLL has been properly registered, the system will display the following message: In addition to modifying the schema manually, which you shouldn’t do unless you fully understand the risks associated with that action, a more common method is to run a software package that has been fully tested and will modify the schema automatically. For instance, when you install Microsoft Exchange, you must modify the schema before you can actually install the product. Another example may be when you are planning an upgrade of Active Directory to the next revision. Running ADPREP.exe modifies the schema. After the schema has been updated, the Schema Master will replicate those changes to all DCs in the forest. Do keep in mind that once the schema is modified, those changes cannot be rolled back. It is possible to disable the additional objects added to the schema, but they cannot be removed. To completely revert back to a previous state, you would have to rebuild the infrastructure using backups prior to the schema update. If the server holding the Schema Role were to fail, you wouldn’t see an impact until you attempted to run a transaction that modified the schema. Therefore, this role can be offline for quite some time since the role is rarely needed. Of course, if you plan on bringing down the Schema Master for extended maintenance, you should gracefully transfer the role. There are two methods for transferring the Schema Master role. You can use the Schema snap-in (only if both DCs, source, and target, are operational), or ntdsutil.
