Installation of Schema Extensions

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

• Extending the schema by using LDIF scripts. This allows customers to update the schema separately and in advance of the rest of the installation.

• Extending the schema programmatically.

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:

• A statement that describes the authority from which your object identifier prefix was obtained.

• The common-name (cn), the LDAP-Display-Name, the object identifier, and the description of each new class and attribute and its expected use. Also answer the following questions:

  • Is the attribute configured for replication to Global Catalog servers?

  • Is the attribute configured for indexing?

  • What are the expected update frequency and expected size of the attribute, which allows the customer to make calculations of replication impact?

  • What are the rangeLower and rangeUpper values?

• A class hierarchy showing newly created classes.

• If defined, the values for the Default-Security-Descriptor and the NT-Security-Descriptor.

The schema installation program must allow the user to exit the program prior to your making any changes to the schema.

Specify the Schema-ID-GUID

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.

Naming

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.

Common-Name (cn)

• Choose a company prefix. This section of the prefix must be the registered DNS domain name of the company and the current year (four digits, separated by a hyphen (-).

• Make the next token in the cn a hyphen (-).

• Choose a product-specific prefix. This section of the name must be unique within your company and a succinct identification of the product and needs to begin with an uppercase letter. The letters in the remainder of the prefix can be uppercase or lowercase as you deem appropriate.

• Make the next token in the cn a hyphen (-).

• Make the next section of the cn the name of the attribute or class separated by hyphens.

LDAP-Display-Name

• Use the Common-Name (cn) as the starting point for the LDAP-Display-Name (lDAPDisplayName).

• Make the first character LDAP-Display-Name lowercase.

• Make the character that immediately follows each hyphen (-) uppercase.

• Remove all hyphens that follow the product-specific section of the prefix except for the hyphen that immediately follows this section.

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

Modifying the Schema

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 snap-in is not listed with the default MMC snap-ins that are provided with Windows 2000 Server. To make it appear in the list of available MMC snap-ins, you must run Regsvr32 on the dynamic-link library (DLL) (Schmmgmt.dll) from the command prompt.

To enable schema modification

1. Open the Active Directory Schema console in MMC.

2. Right-click Active Directory Schema (Manager) , and select Operations Master .

3. Select The Schema may be modified on this server check box, and then click OK .

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.

Schema Administrators Group

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

1. Open the Active Directory Users and Computers console.

2. Expand the domain for the account by clicking the plus sign (+) next to it.

3. Double-click the Users folder.

4. Double-click the Schema Admins security group, and then click the Members tab.

5. If the account is not listed under Members , click Add .

6. Select an account from the displayed list, or type the name of the account.

7. Click Add , and then click OK .

Schema FSMO Role

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

1. Open MMC, and install the Active Directory Schema snap-in.

2. Right-click the Active Directory schema, and then click Operations Master .

3. The Current Operations Master that is displayed is the schema master. 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 \%SystemRoot%\System32 folder. For more information about transferring FSMO roles by using Ntdsutil, see "Managing Flexible Single-Master Operations" in this book.

To change the schema master by using Ntdsutil

1. Start Ntdsutil by typing ntdsutil at the command prompt. (Note that at any prompt in this tool, you can type a question mark ( ? ) to see the list of valid commands for that prompt.)

2. At the Ntdsutil prompt, type: roles

3. At the fsmomaintenance prompt, type: connections

4. To display the current connection information, at the server connections prompt, type: 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.)

5. To return to the fsmo maintenance prompt, type: quit

6. To do a graceful transfer of the Schema FSMO, type: 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

1. Start Ntdsutil by typing ntdsutil at the command prompt. (Note that at any prompt in this tool, you can type a question mark ( ?) to see the list of valid commands for that prompt.)

2. At the Ntdsutil prompt, type: roles

3. At the fsmo maintenance prompt, type: connections

4. To display the current connection information, at the server connections prompt, type: 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.)

5. To return to the fsmo maintenance prompt, type: quit

6. To perform a forced transfer ( seizure ) of the schema master, type: seize schema master

For more information about FSMOs, see "Managing Flexible Single-Master Operations" in this book.

Order of Processing When Extending the Schema

If you decide to extend the schema either programmatically or by using scripts, apply updates in the following order:

1. Target your update at the FSMO Role Owner. Bind to the schema on the domain controller that is the schema master. Avoid unnecessarily changing the schema master role between domain controllers. Only one domain controller is allowed to perform critical operations like updating the schema at any one time. This domain controller is known as the FSMO Role Owner. If you have more than one Windows 2000 server on your network, your current server might not be the FSMO Role Owner. You have to ensure that you target your update at the FSMO Role Owner.

2. Ensure that you have sufficient administrative privileges to perform the schema update. Check the allowedChildClassesEffective property of the Schema container to see if you can create attributes or classes. If attributeSchema and classSchema are not values in that property, you do not have sufficient rights to add attributes or classes to the schema. Only members of the Schema Administrators group are allowed to alter the contents of the schema. You must ensure that your user account is a member of this group. (The Administrator account is automatically a member of the Schema Administrators group.)

3. Create the registry entry that allows write access to the schema. By default, access to the schema is read-only. This entry, known as the safety interlock, can be found in the registry in HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\NTDS\Parameters\ Schema Update Allowed . This entry must exist and its value must be nonzero for schema updates to take place. Check that the safety interlock is engaged before removing it. Note the value that you found for this entry, and make sure to leave the value in the same state afterward. Note that you only have to create the safety interlock on the server that holds the FSMO role.

4. Add your new attributes.

5. Add your new classes.

6. Add attributes to classes. Any new attributes need to be referenced by object identifier because their names are not going to be present in the cache yet. Unless you trigger a schema cache reload after you add new attributes, an attempt to use an attribute by name is going to fail.

7. Each domain controller updates its schema cache five minutes after a schema change. If the extensions are going to be used within five minutes, you must trigger a cache reload.

8. If you had to create the safety interlock before you added your new classes or attributes, it is recommended that you re-apply the safety interlock again after you add them.

9. If you are installing a schema extension by programmatic means (script or ADSI), you must make sure that the extension is provided as a separately installable routine. This means that you must be able to do it separately from the application installation process.

10. Before you create a program to perform a schema extension, see the Microsoft Platform SDK link on the Web resources page at https://windows.microsoft.com/windows2000/reskit/webresources . Follow the links to "Active Directory Programmer's Guide" and then to "Schema Extensibility."

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.