Using Active Directory Schema

The schema is the blueprint of Active Directory, dictating what kinds of objects can exist in the database and what the attributes of those objects are. To customize Active Directory for use on a network, you can modify the schema to create new object types, add new attributes to existing object types, and modify the type of information installed on an attribute. To do this, use the MMC snap-in called Active Directory Schema.

Modifying the schema is a task that the average administrator will never have to perform. At most, you'll change the schema occasionally or perhaps only once. Modifying the schema is subject to the same cautions as modifying a Windows 2000 system's registry, except on a larger scale. Just as improper registry modifications can adversely affect a single system, improper schema modifications can have a devastating effect on the entire network.

Before you can add any Microsoft Windows .NET Server family domain controllers to an existing Windows 2000 forest, you must upgrade the schema using the Windows .NET Server CD-ROM.

Examining Schema Security

Because modifying the Active Directory schema isn't something you should do casually, Windows 2000 uses several safety mechanisms to prevent the schema from being modified accidentally or injudiciously. You can modify the schema only when the requirements of all three safety mechanisms have been satisfied.

Schema Administrator Permissions

To modify the schema, you must be logged on to a Windows 2000 server or workstation using an account that is a member of the Schema Administrators group. This is a built-in group created during Active Directory installation that grants its members permission to write to the schema object. The Administrator account is automatically made a member of the Schema Administrators group. Users who aren't members of this group can also modify the schema if an administrator has granted them the appropriate permissions to the schema object.

Flexible Single Master Operations

Active Directory uses a multiple-master replication system for modifications of the database contents, but for schema modifications, it uses a single-master system. This means that only one domain controller can modify the schema at once. Unlike most single-master replication models, which require all modifications to be written to one designated system and subsequently copied to the other replicas, administrators can modify the Active Directory schema from any domain controller. The mechanism that makes this possible is called Flexible Single Master Operations (FSMO). While an administrator is modifying the schema on one domain controller, write access requests to the schema on all of the other domain controllers will be denied.

To move the FSMO role, see the section entitled Transferring the Schema Master, later in this chapter.

Read-Only Schema Access

Finally, all domain controllers are configured by default during Active Directory installation to permit read-only access to the schema. To enable write access, you must create a new entry in the registry. Using one of the Windows 2000 registry editors (Regedit.exe or Regedt32.exe), browse to this key:

 HKEY_LOCAL_MACHINE\System\Current Control Set\Services\NTDS\Parameters 

Create a new DWORD entry called Schema Update Allowed. Assign the entry a value of 1 to enable write access to the schema. Change the value to 0 to disable write access again after the modifications are complete.

Launching Active Directory Schema

Because of its infrequent use and potential dangers, the Schema Manager is two removes from the Administrative Tools menu. To view or change the schema, you must first install the Administrative Tools (as described in Chapter 10). Then run the Active Directory Schema snap-in in an MMC console by following these steps:

  1. Click Start and select Run. Type mmc and press Enter.
  2. Select Add/Remove Snap-In from the Console menu.
  3. Click Add and select Active Directory Schema from the list of snap-ins provided. Once the snap-in is loaded, you can save the console screen to a file to provide easy access to the snap-in in the future. When the view pane opens, you see two containers in the console tree, which hold the object classes and the attributes that make up those classes, shown in Figure 12-7. Selecting either of these two containers displays Active Directory's classes or attributes in the result pane.

Figure 12-7. Schema Manager object classes and attributes stored in Active Directory.

However, before changing the schema, be sure that the schema snap-in is accessing the Active Directory database on the domain controller that is currently functioning as the master (that is, the one domain controller to which write access is permitted). To determine which domain controller you are currently accessing, follow these steps:

  1. Select Active Directory Schema and choose Change Domain Controller from the shortcut menu. In the Change Domain Controller dialog box (Figure 12-8), you'll see the current domain controller and be able to change the focus to any other domain controller, or you can specify a particular controller.
  2. Right-click the Active Directory Schema object in the console tree and choose Operations Master from the shortcut menu.
  3. In the Change Operations Master dialog box, you'll see which domain controller is the operations master and specify whether the schema can be modified on that system. To change the schema, either change the master replica to the domain controller you're currently using or change the replica you're using to the master.

Figure 12-8. The Change Domain Controller dialog box.

Modifying the Schema

The process of modifying the Active Directory schema involves creating or modifying the classes and attribute object types displayed in Schema Manager. Classes are essentially collections of attributes that either form an Active Directory object type by themselves or contribute certain attributes to another object type. The latter instance is known as an auxiliary class. To add attributes to an existing object type, the best method is to create a new class containing the new attributes and add it to the object type as an auxiliary. This method is more manageable and less dangerous than modifying the class representing the object type itself.

Third-party software products might supply their own schema modifications that create entirely new object types, but adding attributes to an existing object type is the most common form of schema modification manually performed by administrators—for example, adding attributes to the user object type that enable you to store additional information about the user in Active Directory. This relatively easy process consists of the following steps, which are examined in more detail in the following sections:

  • Creating new attribute objects corresponding to the information fields you want to add to the object
  • Creating a new class object to be used as an auxiliary to the existing object type
  • Adding the newly created attributes to the new auxiliary class
  • Adding the auxiliary class to the existing object class

Creating Attributes

Creating an attribute is a matter of supplying a name by which the attribute will be identified and specifying the type of data that will be stored there. The data can be text or numerical, and you can apply constraints that limit the data to a particular length or value type. For example, to add an attribute to hold the user's social security number, you would specify that the attribute's data should be in integer form and limited to nine digits. To create an attribute object, follow these steps:

  1. Right-click the Attributes container in Schema Manager's console tree and choose New Attribute from the shortcut menu. This produces the Create New Attribute dialog box shown in Figure 12-9.

    Figure 12-9. The Create New Attribute dialog box.

  2. In the Identification box, specify the name for the new object. The Common Name field should contain the name by which the attribute will be listed in standard dialog boxes, and the LDAP Display Name field should contain the name by which it is known in the LDAP directory hierarchy. (LDAP stands for Lightweight Directory Access Protocol.) Often, these two names are the same. The Unique X500 Object ID field must contain a numerical string that uniquely identifies the attribute object in the X.500 namespace. Standards bodies like the International Telecommunications Union issue Object IDs (OIDs) to ensure that they have unique values.
  3. In the Syntax And Range box, define the nature of the data to be stored in the attribute. The Syntax field provides more than a dozen options that define the types of information that can be stored in an attribute. The Minimum field and Maximum field enable you to define a range of possible values. You can also specify whether the attribute should be able to have multiple values.
  4. Click OK, and the manager creates the new attribute object.

Don't be tempted to make up your own OIDs. Even if you're running Active Directory on an isolated network, it's all too easy to supply an OID for a new attribute or class that duplicates one of the hundreds of other OIDs already assigned to Active Directory objects.

Configure the new (or any other) attribute object by opening the Properties dialog box from its shortcut menu, shown in Figure 12-10. From this window, you can specify a description for the object, modify its range of possible values, and enable any of the following options:

  • Show objects of this class while browsing
  • Deactivate this attribute
  • Index this attribute in Active Directory
  • Ambiguous Name Resolution (ANR)
  • Replicate this attribute to the Global Catalog (GC)
  • Attribute is copied when duplicating a user

Figure 12-10. The Properties dialog box of an attribute object.

Creating Object Classes

Attribute objects by themselves are useless until they belong to an object class. You can add the attribute objects you've created to an existing class, but creating a new class object for them is generally more practical. To create a class object, right-click the Classes container in the schema snap-in and choose Create Class from the shortcut menu. This displays the Create New Schema Class dialog box shown in Figure 12-11.

Figure 12-11. The Create New Schema Class dialog box.

As with an attribute object, you must first specify a common name, an LDAP display name, and a unique X.500 object ID. Then, in the Inheritance And Type box, specify the parent class for the new object (that is, the class from which the new object should be derived), and choose one of the following three class types:

  • Structural class The typical directory objects that you work with in programs like Active Directory Manager. A structural class object can have either an abstract class or another structural class as its parent object.
  • Abstract class Objects from which structural class objects are derived. You can also specify an existing abstract class as the parent of a new abstract class object.
  • Auxiliary class Collections of attributes that you can add to either an abstract or structural class object to augment its capabilities. New auxiliary class objects can be derived only from abstract classes.

To hold your new attributes, you should create an auxiliary class type.

Adding Attributes to a Class

Once you've created the attribute objects and the class object that will contain them, you must add the attributes to the class. You do this by opening the Properties dialog box for the newly created class object. The dialog box for a class object has four tabs, including the standard Security tab. In the General tab, supply a description for the object and specify whether the object class should show while browsing. You can also disable the object by selecting the Deactivate This Class check box.

In the Attributes tab (Figure 12-12), add your newly created attribute objects to the class by clicking Add for either the Mandatory or Optional list and selecting the objects by name. When an attribute is mandatory, you must supply a value for the attribute when creating a new object of that class. If, for example, you create a social security number attribute, add it to your auxiliary class as a mandatory attribute, and then add the auxiliary class to the user class; the next time a new user object is created, a social security number will be required for the user. Values for optional attributes aren't required.

Figure 12-12. The Attributes tab of the Properties dialog box.

Adding an Auxiliary Class to a Structural Class

An auxiliary class object can't store attribute information until you add the auxiliary class object to a structural class object, like a user or computer. To do this, open the structural class object's Properties dialog box and select the Relationship tab (Figure 12-13).

Figure 12-13. The Relationship tab of the Properties dialog box.

In this tab, click Add for the Auxiliary Classes list, and select the class object you just created. This causes Active Directory to add the attributes in the auxiliary class to the structural class. In the Possible Superior list, specify which other object classes can contain the current object class. For example, the user object class has the organizational unit object class in its Possible Superior list, which enables the creation of new users in OUs. The opposite is not true, however; you can't create an OU beneath a user, so the user object isn't a possible superior of the OU object.

Modifying Display Specifiers

Once you've added new attributes to a class, the attributes exist in the Active Directory database, but you can't see them in utilities like Active Directory Users and Computers. To view, add, or modify the values of the new attributes, you must first alter the display specifiers that control how attributes appear in applications. Display specifiers are Active Directory objects that define the labels for the attributes that appear in a dialog box and control the contents of the shortcut menu that appears when you right-click an object of a modified class.

For example, you might create a new attribute intended to store users' social security numbers and name it SocialSecurityNumber. You probably don't want the attribute name to appear this way in Active Directory Users and Computers, so you create the display name Social Security Number and make it the equivalent of SocialSecurityNumber. To modify the display specifier objects, you can use a Microsoft Visual Basic script and execute it from the Windows 2000 command prompt.

The following script assumes that two new attributes, called SalaryLevel and SocialSecurityNumber, have been created and added to an auxiliary class called HumanResources, which has, in turn, been added to the user object class. The first section connects to the display specifiers container in Active Directory.

 Dim oRoot
Dim oDisp
Dim oCont
Dim aMenu
Dim iCount
Dim sNewMenu
Dim oFileSystem
Dim sOutFile
Dim sSystemFolder
Set oFileSystem = WScript.CreateObject("Scripting.FileSystemObject")
sSystemFolder = oFileSystem.GetSpecialFolder(1)
Set oRoot = Getobject("LDAP://RootDSE")
Set oCont = GetObject("LDAP://" & "CN=409, CN=DisplaySpecifiers," & _
oRoot.get("configurationNamingContext"))
Set oDisp = oCont.GetObject("displaySpecifier","cn=user-Display")
MsgBox "Display Specifier: " & oDisp.Name

The following routine assigns display names to the two new attributes. These names appear in all dialog boxes providing access to these attributes.

 oDisp.PutEx 3,"attributeDisplayNames" , _
Array("SalaryLevel,Annual Salary", _
"SocialSecurityNumber,Social Security Number")
oDisp.SetInfo

The next routine creates a new entry, called HR Info, on the shortcut menu that appears when you right-click a user object in the My Network Places window. When you access this shortcut menu item, the program executes another Visual Basic script called Hrshell.vbs that enables users to view the values for the new attributes.

 MsgBox "Adding Shell Context Menu item"
iCount = 0
If Not IsEmpty(oDisp.shellContextMenu) Then
aMenu = oDisp.GetEx("shellContextMenu")
For iCount = LBound(aMenu) to UBound(aMenu)
MsgBox "Existing Menu item: " & aMenu(iCount)
Next
iCount = iCount + 1
End If
sNewMenu = CStr(iCount) & ",&HR Info...,hrshell.vbs"
oDisp.PutEx 3,"shellContextMenu" , Array(sNewMenu)
oDisp.SetInfo

This next routine creates the Hrshell.vbs script:

 MsgBox "Adding Shell Context Menu Program"
Set sOutFile = oFileSystem.CreateTextFile(sSystemFolder & _
"\hrshell.vbs",True)
sOutFile.WriteLine "Dim Args"
sOutFile.WriteLine "Dim oUser"
sOutFile.WriteLine "Set Args = Wscript.Arguments"
sOutFile.WriteLine "MsgBox " & Chr(34) & "LDAP Path: " & Chr(34) & _
" & Args(0)"
sOutFile.WriteLine "MsgBox " & Chr(34) & "Object Class: " & _
Chr(34) & " & Args(1)"
sOutFile.WriteLine "Set oUser = GetObject(Args(0))"
sOutFile.WriteLine "MsgBox " & Chr(34) & "HR Info" & Chr(34) & _
" & vbCRLF & " & _ Chr(34) & "Salary: " & Chr(34) & _
" & oUser.SalaryLevel & vbCRLF & " & Chr(34) & "Soc Sec No: " & _
Chr(34) & " & oUser.SocialSecurityNumber"
sOutFile.WriteLine "Set oUser = Nothing"
sOutFile.WriteLine "WScript.Quit"
sOutFile.Close

The following routine adds a similar entry to the user shortcut menu in Active Directory Users and Computers, causing the application to execute the Hradmin.vbs script. This script creates a dialog box in which administrators can modify the values for the new attributes.

 MsgBox "Adding Admin Context Menu item"
iCount = 0
If Not IsEmpty(oDisp.adminContextMenu) Then
aMenu = oDisp.GetEx("adminContextMenu")
For iCount = LBound(aMenu) to UBound(aMenu)
MsgBox "Existing Menu item: " & aMenu(iCount)
Next
iCount = iCount + 1
End If
sNewMenu = CStr(iCount) & ",&HR Admin...,hradmin.vbs"
oDisp.PutEx 3,"adminContextMenu" , Array(sNewMenu)
oDisp.SetInfo

The next section creates the Hradmin.vbs script and terminates the script:

 MsgBox "Adding Admin Context Menu Program"
Set sOutFile = oFileSystem.CreateTextFile(sSystemFolder & _
"\hradmin.vbs",True)
sOutFile.WriteLine "Dim Args"
sOutFile.WriteLine "Dim oUser"
sOutFile.WriteLine "Dim temp"
sOutFile.WriteLine "Set Args = Wscript.Arguments"
sOutFile.WriteLine "MsgBox " & Chr(34) & "LDAP Path: " & Chr(34) & _
" & Args(0)"
sOutFile.WriteLine "MsgBox " & Chr(34) & "Object Class: " & _
Chr(34) & " & Args(1)"
sOutFile.WriteLine "Set oUser = GetObject(Args(0))"
sOutFile.WriteLine "temp = InputBox(" & Chr(34) & "Old Salary: " & _
Chr(34) & " & oUser.SalaryLevel & vbCRLF & " & Chr(34) & _
"New Salary" & Chr(34) & ")"
sOutFile.WriteLine "if temp <> " & Chr(34) & Chr(34) & _
" then oUser.Put " & Chr(34) & "SalaryLevel" & Chr(34) & ",temp"
sOutFile.WriteLine "temp = InputBox(" & Chr(34) & _
"Soc Sec Number: " & Chr(34) & " & oUser.SocialSecurityNumber & _
vbCRLF & " & Chr(34) & "New Number" & Chr(34) & ")"
sOutFile.WriteLine "if temp <> " & Chr(34) & Chr(34) & _
" then oUser.Put " & Chr(34) & "SocialSecurityNumber" & _
Chr(34) & ",temp"
sOutFile.WriteLine "oUser.SetInfo"
sOutFile.WriteLine "Set oUser = Nothing"
sOutFile.WriteLine "WScript.Quit"
sOutFile.Close
MsgBox "Quit..."
Set oDisp = Nothing
Set oCont = Nothing
Set oRoot = Nothing
Set oFileSystem = Nothing
WScript.Quit

When you save this script to a text file with a .VBS extension and execute it from the command prompt, Windows 2000 adds the shortcut menus to the My Network Places window and the Active Directory Users and Computers snap-in and creates the scripts that selecting those shortcut menus executes. This part of the schema modification process is obviously the most complex. After you create your own scripts, carefully test and debug them on a nonproduction network before executing them on live domain controllers.

Performing Batch Importing and Exporting

MMC snap-ins like Active Directory Users and Computers make it easy to create and configure new objects in Active Directory, but deploying the directory service on a large scale might require the creation of thousands of objects. In cases like these, manually creating individual objects is impractical. Anticipating the need for the mass creation of Active Directory objects, and particularly user objects, Windows 2000 includes tools that enable administrators to perform batch imports and exports of Active Directory objects. Among these tools is Ldifde.exe, a command-line utility for importing, exporting, and modifying Active Directory objects using the LDAP Data Interchange Format (LDIF).

Using the Ldifde.exe Utility

Active Directory uses LDAP to define its namespace and it supports LDIF. LDIF is a standardized format for saving directory service information in text files. If you're running another directory service that also supports LDIF on the network, you can import its data into Active Directory by using the Ldifde.exe utility. You can also use Ldifde.exe to export Active Directory objects to LDIF files and modify existing objects.

The syntax for using the Ldifde.exe utility is as follows:

 Ldifde [-a username password] [-b username domainname password]
[-c FromDN ToDN] [-d RootDN] [-f filename] [-g] [-i] [-j] [-k]
[-l attributes] [-m] [-n] [-o attributes] [-p scope] [-r filter]
[-s servername] [-t] [-v] [-?]
[-a username password] - specifies the user name and password for
simple authentication to the LDAP directory.
[-b username domainname password] - specifies the user name, domain
name, and password for the SSPI bind method (by default, the
utility logs in to the LDAP directory as the current user, with
the SSPI bind method).
[-c FromDN ToDN] - replaces all occurrences of FromDN with ToDN.
[-d RootDN] - specifies the root object where the utility should
commence its search (default = current naming context).
[-f filename] - specifies the name of the LDIF file that the utility
will import data from or export data to.
[-g] - disables paged search.
[-i] - causes the utility to operate in import mode (default = export
mode).
[-j] - specifies the location of the utility's log file.
[-k] - causes the program to ignore "constraint violation" and
"object already exists" errors.
[-l attributes] - specifies the attributes that the utility should
look for during a search of an LDAP directory.
[-m] - enables Windows NT's Service Account Manager (SAM) logic
during export operations.
[-n] - prevents the utility from exporting binary values.
[-o attributes] - specifies the attributes that the utility should
omit from inputting.
[-p scope] - specifies the search scope (Base, OneLevel, or Subtree).
[-r filter] - specifies the objects for which the utility will search
(default = "(objectClass=*)").
[-s servername] - specifies the name of the server to which the
utility will bind (default = domain controller of the currently
logged on domain).
[-t] - specifies a port number to use when communicating with the
LDAP service (default = 389).
[-v] - causes the program to operate in verbose mode.
[-?] - displays help information for the program.

Exporting Objects To export Active Directory information to an LDIF file, execute a command like the following:

 ldifde -f research.ldif -s cz2 -d "ou=Research,dc=scribes,dc=com"
-p subtree -r (objectCategory=CN=Person,CN=Schema,CN=
Configuration,DC=scribes,DC=com)"

The -f parameter specifies the name of the LDIF file that the utility will create. The -s and -d parameters identify the server that the utility should use to access Active Directory and the OU where the export process should begin. The -p parameter specifies that the utility should export the entire subtree below the Research OU, and -r specifies that the program should export only person (that is, user) objects. When you execute the command, Ldifde.exe searches Active Directory, starting in the Research OU and traveling down the subtree to the bottom, writing the information about each user object it finds to the Research.ldif file. A typical LDIF entry for a user object (in this case the Administrator object) appears as follows:

 dn: CN=Administrator,CN=Users,DC=scribes,DC=com
changetype: add
accountExpires: 9223372036854775807
badPasswordTime: 0
badPwdCount: 0
codePage: 0
cn: Administrator
countryCode: 0
description: Built-in account for administering the computer/domain
instanceType: 4
isCriticalSystemObject: TRUE
memberOf: CN=Domain Admins,CN=Users,DC=scribes,DC=com
memberOf: CN=Enterprise Admins,CN=Users,DC=scribes,DC=com
memberOf: CN=Schema Admins,CN=Users,DC=scribes,DC=com
memberOf: CN=Administrators,CN=Builtin,DC=scribes,DC=com
lastLogoff: 0
lastLogon: 125652212356113520
logonCount: 7
distinguishedName: CN=Administrator,CN=Users,DC=scribes,DC=com
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=scribes,DC=com
objectClass: user
objectGUID:: RedjUwbB0hGJSwBgl7B3yg==
objectSid:: AQUAAAAAAAUVAAAAiqcyP/CUyF8WwOoy9AEAAA==
primaryGroupID: 513
pwdLastSet: 125631016521025648
name: Administrator
sAMAccountName: Administrator
sAMAccountType: 805306368
userAccountControl: 66048
uSNChanged: 2113
uSNCreated: 2113
whenChanged: 19990210163330.0Z
whenCreated: 19990210163330.0Z

Importing Objects To import users or other objects from another LDAP directory service, you must first export the information using whatever tools the other product provides, and then import the LDIF file into Active Directory using a command like the following:

 Ldifde -i -f newusers.ldif 

In this example, the -i parameter puts the program into import mode, and the -f parameter specifies the name of the LDIF file you created from the other directory service.

Modifying Objects You can also use Ldifde.exe to modify the information stored in Active Directory objects, albeit in a roundabout way. After exporting Active Directory object information to an LDIF file, modify the attribute values in the file using any text editor, and then import it back into Active Directory. The new information overwrites the old, effectively modifying the Active Directory object information. If faced with a situation in which you have to make a great many similar changes to the directory, such as a company move requiring new mail addresses for all users, use Ldifde.exe and a text editor with search and replace capabilities to quickly modify thousands of objects in the Active Directory database.

Understanding Operations Master Roles

Domain controllers must handle five operations master roles in every Active Directory forest. Some of the operations master roles are critical to your network, and if the machine providing them fails, you'll know about it at once. Others can be unavailable for a long time without you or your users being any the wiser. The roles are as follows:

  • Primary domain controller (PDC) emulator Acts as a Windows NT primary domain controller in domains that have Windows NT backup domain controllers or computers without Windows 2000 client software
  • Schema master Controls all updates and modifications to the schema
  • Domain naming master Controls the addition or removal of domains
  • Relative identifier (RID) master Allocates relative IDs to each domain controller
  • Infrastructure master Updates changes to group-to-user references when memberships in groups are changed

Normally, you have no reason to interfere with the operations master roles. Transferring of roles is relatively trivial. You make a transfer when the original role holder is available. In serious circumstances when the controller holding the role is unavailable, you can seize a role, but it's a drastic measure and you should not take it lightly. In all cases, except with the PDC emulator, when an operations master role is seized (rather than transferred), you must not bring the original holder of the seized role back online without completely reformatting the boot disk and reinstalling Windows 2000. The next several sections explain the operations master roles in more detail.

Primary Domain Controller Emulator

When upgrading a Windows NT domain, only one domain controller can create users, groups, and computer accounts—the basics of security. This Windows 2000 domain controller is configured as the PDC operations master and emulates a Windows NT primary domain controller. The PDC emulator supports the Kerberos and NTLM protocols, allowing Windows NT domain controllers to synchronize with a Windows 2000 environment running in mixed mode.

Every domain must have a domain controller that acts as a PDC emulator as long as the domain contains either clients without Windows 2000 client software or Windows NT backup domain controllers. If the controller acting as the PDC emulator isn't available, it will affect users because the network itself will be disrupted. So if you know that the controller acting as the PDC emulator will be unavailable, transfer this role.

Transferring the PDC Emulator To transfer the role of PDC emulator, follow these steps:

  1. Launch Active Directory Users and Computers from the Administrative Tools folder.
  2. Right-click the domain node and choose Connect To Domain Controller from the shortcut menu.
  3. Select the domain controller that you want to give the role of PDC emulator. Click OK.
  4. Right-click the domain node and choose Operations Masters from the shortcut menu. Click the PDC tab to see the current focus (the controller that will become the PDC emulator) and the controller that is the current operations master.
  5. Click Change and then click OK.

Seizing the PDC Emulator If the PDC emulator becomes unavailable unexpectedly and it can't be returned to service quickly, you'll need to seize the role of the PDC emulator and force it to another domain controller. To seize the PDC emulator, follow these steps:

  1. Choose Run from the Start menu (or open a command window), type ntdsutil, and press Enter.
  2. At each prompt, supply the following information and then press Enter:
    • At ntdsutil, type roles
    • At fsmo maintenance, type connections
    • At server connections, type connect to server followed by the fully qualified domain name of the controller that is to be the new PDC emulator (Figure 12-14)
    • At server connections, type quit
    • At fsmo maintenance, type seize PDC
    • At ntdsutil, type quit

When the original PDC emulator becomes available again, you can use the same procedure to return the PDC emulator role.

Figure 12-14. Using Ntdsutil to seize and move the PDC emulator role to a new server.

Schema Master

Not surprisingly, the schema master handles all updates to the schema. Only one schema master exists in an entire forest. The schema master role is assigned to the first domain controller in a domain and remains there unless you change it. Because modifications of the schema are uncommon, the schema master can be nonfunctional for an extended period without affecting users.

Transferring the Schema Master

To transfer the schema master role, follow these steps:

  1. Open the Active Directory Schema snap-in.
  2. Right-click Active Directory Schema in the console window and choose Change Domain Controller from the shortcut menu. Change the focus to the controller that will assume the schema master role.
  3. Right-click Active Directory Schema in the console window and choose Operations Master from the shortcut menu. Click Change and then click OK.

Seizing the Schema Master

Don't seize the schema master unless there's no hope of returning the original controller to service. Before seizing the schema master role, the original schema master must be disconnected from the network. To seize the schema master role, follow these steps:

  1. Choose Run from the Start menu (or open a command window), and then type ntdsutil and press Enter.
  2. At each prompt, supply the following information and then press Enter:
    • At ntdsutil, type roles
    • At fsmo maintenance, type connections
    • At server connections, type connect to server followed by the fully qualified domain name of the controller that is to be the new schema master
    • At server connections, type quit
    • At fsmo maintenance, type seize schema master
    • At ntdsutil, type quit

Seizing the schema master role is a radical step. Don't do it unless the original schema master is permanently out of service. If you ever bring the original schema master back online, you must reformat its boot disk and reinstall Windows 2000 to prevent serious problems with the updating of the schema.

Domain Naming Master

Only one server in the enterprise performs the role of domain naming so that the domain naming master is created in the first domain and the role remains there no matter how large the forest. The domain naming master can be unavailable for some time, and the network will be unaffected until there's a need to establish a new domain. Therefore, unless the controller playing this role is to be permanently removed from the network, you usually won't need to either transfer or seize this role.

Transferring the Domain Naming Master If you need to transfer this role to another controller, follow these steps:

  1. Launch Active Directory Domains and Trusts from the Administrative Tools folder.
  2. Right-click Active Directory Domains and Trusts and choose Connect To Domain Controller from the shortcut menu.
  3. Select the domain controller that you want to give the role of domain naming master. Click OK.
  4. Right-click Active Directory Domains and Trusts again and select Operations Master from the shortcut menu. A dialog box opens, showing the current domain naming master and the computer that will become the domain naming master.
  5. Click Change and then click OK.

Seizing the Domain Naming Master If the domain naming master must be unexpectedly and permanently removed from the network, you can seize the domain mastering role and reassign it to another domain controller. To seize the role, follow these steps:

  1. Choose Run from the Start menu (or open a command window), and then type ntdsutil and press Enter.
  2. At each prompt, supply the following information and then press Enter:
    • At ntdsutil, type roles
    • At fsmo maintenance, type connections
    • At server connections, type connect to server followed by the fully qualified domain name of the controller that is to be the new master
    • At server connections, type quit
    • At fsmo maintenance, type seize domain naming master
    • At ntdsutil, type quit

Before seizing the domain naming master, the controller holding the domain naming master role must be disconnected completely from the network. Seizing the domain naming master role is a radical step, and you should not do it unless the original domain naming master is permanently out of service. If you ever bring the original domain naming master back online, you must first reformat its boot disk and reinstall Windows 2000.

Relative Identifier Master

When a domain controller creates a security object—a user, a group, or a computer account—it assigns a unique security identifier (SID) to the object. The SID is made up of two parts: the domain security ID that is common to all security objects in the domain, and the relative ID that is unique to each object. The RID master is the controller in each domain that allocates and tracks the sequences of relative IDs.

Users won't notice temporary loss of the RID master. Administrators are also unlikely to notice unless they're creating security objects and the domain runs out of relative ID numbers. So transferring the RID master role isn't usually necessary unless the RID master is to be removed permanently from the network.

Transferring the RID Master If you need to transfer this role to another controller, follow these steps:

  1. Launch Active Directory Users and Computers from the Administrative Tools folder.
  2. Right-click the domain node and choose Connect To Domain Controller from the shortcut menu.
  3. Select the domain controller that you want to give the role of RID master. Click OK.
  4. Right-click the domain node and choose Operations Masters from the shortcut menu. A dialog box will open. In the RID tab, the current focus (the controller that will become the RID master) is shown, as well as the current operations master (Figure 12-15).
  5. Click Change and then click OK.

Figure 12-15. The RID tab of the Operations Master dialog box.

Seizing the RID Master If the RID master must be unexpectedly and permanently removed from the network, you can seize the RID mastering role and reassign it to another domain controller. To seize the role, follow these steps:

  1. Choose Run from the Start menu (or open a command window), and then type ntdsutil and press Enter.
  2. At each prompt, supply the following information and then press Enter:
    • At ntdsutil, type roles
    • At fsmo maintenance, type connections
    • At server connections, type connect to server followed by the fully qualified domain name of the controller that is to be the new master
    • At server connections, type quit
    • At fsmo maintenance, type seize RID master
    • At ntdsutil, type quit

Before proceeding with the seizure, the controller holding the RID master role must be disconnected completely from the network. Seizing the RID master role is a radical step. Don't do it unless the original RID master is permanently out of service. If you ever bring the original RID master back online, you must first reformat its boot disk and reinstall Windows 2000.

Infrastructure Master

The infrastructure master is responsible for keeping up with the changes in group membership and distributing updates to other domains. One infrastructure master exists in each domain. If the controller holding the infrastructure master role becomes unavailable, it won't affect users. Even administrators won't notice until a number of user account changes don't show up in other domain controllers. Therefore, it's best not to transfer the infrastructure master role unless the controller is going to be unavailable for a considerable period.

Real World

Placing the Infrastructure Master Role

Unless the domain has only one domain controller, don't assign the infrastructure master role to the controller hosting the Global Catalog (GC). To find out whether changes need to be distributed to other domains, the infrastructure master looks to a GC and updates itself using the GC information. If the GC and the infrastructure master are on the same controller, the infrastructure master will never find any outdated data, so nothing is replicated to other domains. See Chapter 11 for more on the GC.

Transferring the Infrastructure Master To transfer the infrastructure master role to another controller, follow these steps:

  1. Launch Active Directory Users and Computers from the Administrative Tools folder.
  2. Right-click the domain node and choose Connect To Domain Controller from the shortcut menu.
  3. Select the domain controller that you want to give the role of infrastructure master. Click OK.
  4. Right-click the domain node and choose Operations Masters from the shortcut menu. Click the Infrastructure tab to see the current focus (the controller that will become the infrastructure master) as well as the controller that is the current operations master.
  5. Click Change and then click OK.

Seizing the Infrastructure Master If the infrastructure master is unexpectedly and permanently removed from the network, you can seize the infrastructure master role and reassign it to another domain controller. To seize the role, follow these steps:

  1. Choose Run from the Start menu (or open a command window), and then type ntdsutil and press Enter.
  2. At each prompt, supply the following information and then press Enter:
    • At ntdsutil, type roles
    • At fsmo maintenance, type connections
    • At server connections, type connect to server followed by the fully qualified domain name of the controller that is to be the new master
    • At server connections, type quit
    • At fsmo maintenance, type seize infrastructure master
    • At ntdsutil, type quit

Before proceeding with the seizure, the controller holding the infrastructure master must be disconnected completely from the network. Seizing the infrastructure master role is a drastic step. Don't do it unless the original infrastructure master is permanently out of service. If you ever bring the original infrastructure master back online, you must first reformat its boot disk and reinstall Windows 2000.



Microsoft Windows 2000 Server Administrator's Companion
Microsoft Windows 2000 Server Administrators Companion
ISBN: 0735617856
EAN: 2147483647
Year: 2003
Pages: 320

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net