Active Directory Schema |
The recommended practice is to strictly control the schema updates at most customer sites. If a service requires schema extensions, you must be able to install them separately by using one of the following methods
In addition to providing a separate installation procedure for schema extensions, it is recommended that the nature of the schema extensions be clearly documented. The documentation needs to contain the following:
The schema installation program must allow the user to exit the program prior to your making any changes to the schema.
Specify the schemaIDGUID when you create attributes or classes in Active Directory. The schemaIDGUID is a globally unique identifier (GUID) that uniquely identifies all classes and attributes in the schema. Unlike object identifiers, which are issued by a central authority, a special algorithm generates GUIDs. SchemaIDGUIDs are used in ACLs to provide attribute-specific or class-specific privileges.
When you modify the schema, you must adhere to the following rules with respect to specifying the relative distinguished name attribute (which is common-name [cn]) and the LDAP display name (lDAPDisplayName).
Table 4.6 illustrates the naming rules as they are applied to the Common-Name (cn) and the LDAP-Display-Name (lDAPDisplayName):
Table 4.6 Naming Rules
Common-Name (cn) |
LDAP-Display-Name (lDAPDisplayName) |
---|---|
Microsoft-Com-1999-MQ-Attribute-1 | Microsoft-Com-1999-mQAttribute1 |
Microsoft-Com-1999-EXCHANGE-Attribute-2 | Microsoft-Com-1999-exchangeAttribute2 |
To allow a domain controller to modify the schema, use the Active Directory Schema console in MMC on the selected server.
Note
Because of the serious nature of schema modification, the Active Directory Schema MMC
To enable schema modification
The value of the The Schema may be modified on this server check box is stored in the registry in the Schema Update Allowed entry (in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters). Active Directory adds this entry to the registry when you use the Active Directory Schema console to change the default value.
Caution
Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or MMC whenever possible.
To modify the schema, you must use an account that is a member of the Schema Admins group. By default, the only member in that security group is the Administrator account in the root domain of the enterprise. If you want to add other accounts, you have to add them explicitly.
Caution
Membership in the Schema Admins group must be highly restricted to prevent unauthorized access to the schema because modifying the schema improperly can have serious consequences.
One way to verify that an account is a member of the Schema Admins group is to use the Active Directory Users and Computers console in MMC.
To verify that an account is a member of Schema Administrators
Active Directory performs schema updates in a single-master fashion to prevent conflicts. Simultaneous schema updates on two different computers might conflict with each other. The one domain controller in the enterprise that is allowed to perform schema updates at any specific time is referred to as the schema master. Only one domain controller in the entire enterprise, the domain controller holding the schema master role, accepts updates to schema objects.
Note
To update the schema, the domain controller holding the schema master role must be online.
You can change the domain controller that serves as the schema master at any time according to your needs. This is what is meant by the word "flexible" in FSMO. The current schema master in the enterprise is identified by the value of the fSMORoleOwner attribute on the Schema container of the domain. By default, the first domain controller that is installed in the enterprise is the initial schema master.
Although the domain controller that is the current FSMO Role Owner for schema operations is the only one that can make the actual schema modifications, you do not have to be connected to that domain controller when you make schema modifications. If you are connected to a domain controller that does not have that role, it generates a referral to the current FSMO Role Owner to process the modifications.
If you want to do so, you can transfer the role of schema master to another domain controller by using the Active Directory Schema console in MMC.
To view or change the current schema master by using the Active Directory Schema console in MMC
To retain the current schema master, click OK.
– Or –
To change the server that is the current FSMO Role Owner for the schema, click Change.
If the current domain controller (the one that is listed in Current Focus) is also the current operations master, you must use the Active Directory Tree console to focus on another domain controller before you can change the operations master. This is because you must be connected to the domain controller that you want to have as the FSMO Role Owner. You cannot direct the connected domain controller to make another domain controller the FSMO Role Owner.
For more information about using the Active Directory Schema console, see "Modifying the Schema" earlier in this chapter.
You can also use the command-line tool Ntdsutil to transfer the Schema FSMO. The tool resides in the \
To change the schema master by using Ntdsutil
roles
connections
info
If necessary, type the appropriate command to connect to the server that is to become the schema master. (Use the ? command to see a list of valid commands.)
quit
transfer schema master
You can also perform the schema master role transfer in a program. Before a program can make changes to the schema, it must check explicitly whether the domain controller is the current schema master and, if it is not, explicitly request the transfer operation.
To understand the transfer process, consider a scenario in which computer A is the current FSMO Role Owner and computer B must perform some schema updates. To request an FSMO Role Owner transfer from computer A, a program must add the operational attribute becomeSchemaMaster with value of 1 to the rootDSE (that is, to the object with a blank distinguished name) on computer B. It is an operational attribute that is never defined in the schema and does not require any storage. Generally, when you set an operational attribute, you trigger some immediate action on the server.
In this case, the action taken by the server (computer B) is its sending out a request to computer A for a role transfer. Computer A, upon receiving such a request, changes the fSMORoleOwner attribute on its Schema container to the name of computer B and sends this new attribute value back to computer B. It also sends back any schema changes that were implemented on computer A but were not yet incorporated by computer B. (This kind of discrepancy is possible as a result of replication latencies.) Computer B, upon receiving the reply from computer A, applies all changes that were sent back from computer A and, in the process, becomes the current schema master.
Note
Computer B, the new schema master, now has all previous schema updates in the enterprise and, hence, the latest version of the schema.
If the old schema master is unavailable or has crashed, you can forcibly transfer (seize) the schema FSMO so that a new domain controller can make schema changes. However, it is recommended that you take this step only as a last resort. When the schema master is forcibly transferred to a new domain controller, recent schema changes that were made at the old schema master might not be propagated to the new schema master and might be lost. The transfer also can result in conflicting updates at other domain controllers in the forest, which might require an extensive offline cleanup of the directory.
Caution
Seizing the schema master is a drastic step that you must consider only when the current schema master is no longer able to function and is never going to be available again. Before you seize the current schema master, remove it from the network. Verify that the domain controller that seizes the role is fully up-to-date with respect to updates performed on the previous role owner.
To seize the schema master by using Ntdsutil
roles
connections
info
If necessary, type the appropriate command to connect to the server that is to become the schema master. (Use the ? command to see a list of valid commands.)
quit
seize schema master
For more information about FSMOs, see "Managing Flexible Single-Master Operations" in this book.
If you decide to extend the schema either programmatically or by using scripts, apply updates in the following order:
Note
A cache update is not necessary if the schema extensions are not to be used immediately. Depending on system load, the extensions appear in the schema cache in approximately five minutes.