Understanding Organizational Units

An organizational unit (OU) is a container that logically organizes and groups Active Directory objects within domains. OUs are not part of the DNS namespace. They organize Active Directory objects into logical administrative groups. OUs therefore serve as containers in which users can create and manage Active Directory objects. OUs are considered the smallest unit to which an Administrator can assign permissions to resources within Active Directory.

An OU enables users to apply security policies, deploy applications, delegate administrative control for Active Directory objects, and run scripts. An important thing to understand is that OUs are not security principals. The user accounts, group accounts, and computer accounts within the OUs are security principals.

The Active Directory object types that can be located in OUs are listed below:

• User, group, and computer objects; shared folders, printers, applications, and other OUs from the same domain.

User objects are the main security principals used in Active Directory. A user object consists of the user name, password, group membership details, and other information that define the user. A group object prevents Administrators from setting individual user permissions. A set of users can be grouped then assigned the appropriate permission to Active Directory objects. A computer object contains information on a computer that is a member of the domain. Because OUs can contain other OUs, an Administrator can hierarchically group resources and other Active Directory objects to reflect the organization’s structure. The process of adding OUs to other OUs in a hierarchical manner is referred to as nesting OUs.

A few benefits of OUs are summarized below:

• OUs can be nested to support different hierarchy levels
• Each domain in the Active Directory environment can have its own OU structure. One domain’s OU structure is independent of another domain’s OU structure.
• It is fairly simple to change an OU structure. OU structures are much more flexible than domain structures.
• Objects in child OUs can inherit OU configuration settings.
• Group Policy settings can also be applied to OUs
• Users can delegate administrative control of Active Directory objects through OUs

OUs typically delegate administrative control for Active Directory objects to hide Active Directory objects and to administer Group Policy. When a user delegates administrative control over an OU, he/she enables other users or groups to administer the OU. Higher level administrators usually delegate administrative control. Delegation of control over OUs enables users to transfer management tasks to various users within the organization.

The administrative tasks that are usually delegated are listed below:

• Create, delete, and manage user accounts
• Create, delete, and manage groups
• Reset passwords on user accounts
• Read all user information
• Modify group membership
• Manage Group Policy links

Administrators that are responsible for domain management activities have full control over all Active Directory objects within the domain. This is the default configuration setting. These Administrators therefore create domain controllers, domains, and the OU for the domain. If there are units within the organization that need to manage and define their own OU structure, users can delegate the Full Control permission for an OU to these individuals. This would enable those individuals to perform all the previously mentioned management activities for the particular OU. In other instances, users might need to only delegate control for specific object classes for an OU.

As mentioned before, OU can also hide sensitive domain objects from particular users. This is done by creating an OU for those domain objects that will be hidden or that the user does not want everyone to view, then assigning only those users that should be allowed to give these objects the necessary permissions. After the appropriate permissions are configured for the OU, move the sensitive Active Directory objects to the OU.

Group policies can be defined as a collection of permissions that users can apply to Active Directory objects. Group policy settings can be linked to sites, domains, and OUs, and can apply to user accounts, computer accounts, and group accounts. Group policy settings are applied to OUs in the form of Group Policy Objects (GPOs). The GPO contains the Group policy settings that can be applied to users and computers in an OU.

Group policy is applied in the following order:

• Local computer policy
• Site policy
• Domain policy
• OU policy, commencing with the parent OU

However, Active Directory includes a No Override and Block Inheritance setting that can be used to control how policies are applied. The No Override setting can be enabled to stop a child OU’s policy setting from overwriting the parent OU policy setting. The Block Inheritance setting can be enabled to prevent a child OU and any objects that it contains from inheriting group policy settings from its parent OU.

Planning an OU Structure

When planning an OU structure, identify and define the following:

• The manner in which the enterprise is managed
• The OU structure for each domain
• The OUs that need to be created
• The manner in which group policy needs to be applied.
• The OUs for which administrative control will be delegated and the users that control will be delegated to.
• The sensitive Active Directory objects to be hidden from users.

The following strategy is generally recommended for an OU structure: Create an OU with the end result being that one group administrates the Active Directory objects within the OU. This enables users to grant the particular group the identical rights to all Active Directory objects in the particular OU and to the OU itself. Avoid an OU structure that results in the same group needing to manage objects over many different OUs. This would mean that the appropriate rights would need to be individually granted in each OU.

It is also good practice to assign an owner to each OU. The OU’s owner would be responsible for performing the following management tasks:

• Create, delete, and manage child OUs
• Apply group policy
• Delegate administrative control over objects in the OU

Also, separate service admin objects from the remainder of domain objects. Hiding service admin objects prevents all domain users from viewing its properties and attributes and it also enables users to effectively apply group policy so that only service admin users are able to perform certain administrative tasks.

Creating and Managing OUs

The Active Directory Users and Computers console in the Administrative Tools Menu is used to create OUs. When users create an OU, they are basically adding it to a particular domain first, then adding Active Directory objects to it, delegating administrative control for the OU or applying a GPO.

The OU’s Properties dialog box has a few tabs that manage the properties of the particular OU:

• General tab: Specify a description, street address, city, state or province, ZIP code or postal code, and country or region information for the OU on this tab.
• Managed By tab: This is the tab used to administer the settings of the OU’s owner. Enter the following information for the OU’s owner: name, office location, street address, city, state or province, country or region, telephone number, and fax number. The tab also contains the following buttons:
• Change: Click the Change button to set the user account that will be responsible for managing the OU.
• View: To view or change the properties of the user account currently managing the OU, click the View button.
• Remove: To remove a user account, click the Remove button.
• Group Policy tab: This tab contains the following buttons:
• New: To create a new GPO for the OU, click this button.
• Edit: To change the existing GPO settings, click the Edit button. The settings that can be specified for a GPO are categorized into Computer Configuration settings and User Configuration settings. Each of these is separated into the following categories: Software, Windows, and Administrative Templates.
• Add: To link a GPO to the OU, click this button to create the new GPO link.
• Options: To disable the GPO or ensure that the child OU’s GPO does not override the parent OU’s GPO, click this button. The options available are the Disable and the No Override options.
• Delete: To delete a GPO, click this button.
• Properties: To manage GPO properties, click this button. The GPO’s properties dialog box has a General, Links, and Security tab. The General tab has a Summary and Disable pane. Users can view information such as the GPO name and create a last modified date in the Summary pane. They can disable Computer Configuration settings and User Configuration settings in the Disable pane. The Link tab lists each site, domain, and OU to which the particular GPO is applied. The Security tab is where users set permissions for the GPO: Full Control, Read, Write, Create Child Objects, Delete Child Objects, and Apply Group Policy.

How to Create an OU

1. Open the Active Directory Users and Computers console
2. In the console tree, locate and right-click the appropriate domain, click New, then click Organizational Unit from the shortcut menu.
3. In the New Organizational Unit dialog box, enter a unique name for the OU in the Name box.
4. Click OK.
5. Right click the new OU and select Properties from the shortcut menu.
6. When the OU’s Properties dialog box opens, enter a description for the OU on the General tab.
7. Click the Managed by tab to specify an owner for the OU.
8. Click the Change button and choose the desired user account from the Users and Groups list box.
9. Click the Group Policy tab.
10. Click the New button to create a new GPO for the OU.
11. Enter a name for the GPO.
12. Configure all appropriate GPO settings for the OU with the remainder of the available buttons on the tab.

How to Create an OU Structure to Hide Sensitive Active Directory Objects

1. Open the Active Directory Users and Computers console.
2. In the console tree, locate and right-click the appropriate domain, then click New and Organizational Unit from the shortcut menu.
3. In the New Organizational Unit dialog box, enter a unique name for the OU in the Name box.
4. Click OK.
5. Right-click the new OU and select Properties from the shortcut menu.
6. When the Properties dialog box for the OU opens, click the Security tab.
7. Remove any existing permissions for the OU.
8. Click the Advanced button.
9. When the OU’s Advanced Security Settings dialog box opens, uncheck the Allow Inheritable Permissions From The Parent To Propagate To This Object And All Child Objects checkbox. Click OK.
10. In the Security tab, select and grant the appropriate group the Full Control permission. Grant the Read permission to those groups that should be able to read the OU’s contents.
11. Click OK.
12. Move the sensitive Active Directory objects to this particular OU.

How to Delete an OU

1. Open the Active Directory Users and Computers console
2. In the console tree, locate and expand the domain, then right-click the OU to be deleted and click Delete from the shortcut menu.
3. Click Yes in the message box to verify that this particular OU should be deleted.
4. Click Yes if another message box is displayed, prompting the user to verify that all objects located in the OU should be deleted.

How to Change OU Properties

1. Open the Active Directory Users and Computers console
2. In the console tree, locate and expand the domain, right-click the OU that properties will be configured for, and click Properties from the shortcut menu.
3. Change the OU properties on the General tab, Managed By tab, and Group Policy tab.
4. Users can also change the GPO that is linked to the OU or the existing GPO’s settings from the Group Policy tab.

How to Rename an OU

1. Open the Active Directory Users and Computers console.
2. In the console tree, locate and expand the domain, then right-click the OU to be renamed, and click Rename from the shortcut menu.
3. Enter the OU’s new name.

How to Move an OU to a New Location

1. Open the Active Directory Users and Computers console
2. In the console tree, locate and expand the domain that contains the OU to be moved to a different location.
3. Click the OU and drag it to its new location.
4. Drop the OU in the new location.

How to Move Active Directory Objects between OUs with Drag and Drop

1. Open the Active Directory Users and Computers console
2. In the console tree, locate and expand the domain that contains the OU that holds the object to be moved to a different OU.
3. Expand the OU.
4. Click the object to be moved and drag the object to the other OU.
5. Drop the object in the new OU location.

How to Move Active Directory Objects between OUs with ADUC Move Option

1. Open the Active Directory Users and Computers console.
2. In the console tree, locate and expand the domain that contains the OU that holds the object to be moved to a different OU.
3. Expand the OU, right-click the object, then click Move on the shortcut menu.
4. When the Move dialog box opens, choose the new OU location for the object.
5. Click OK.

How to Move Active Directory Objects between OUs with the Dsmove Command-line Tool

Use the Dsmove command-line tool to move Active Directory objects between OUs and to rename an Active Directory object.

To use the Dsmove command-line tool to move Active Directory objects from one OU location to a different OU location:

1. Click Start and Command Prompt.
2. Enter dsmove with the proper parameters at the command prompt.

The command’s syntax is:

dsmove ObjectDN [-newname NewName] [-newparent ParentDN] [{-s Server | -d Domain}]

[-u UserName] [-p {Password|*}] [-q] {-uc | -uco | -uci}

• ObjectDN – the name of the Active Directory object to be moved to a different U.
• -newname NewName – to rename the Active Directory object
• -newparent ParentDN – for setting the new location to which the Active Directory object will be moved.
• {-s Server | -d Domain} – for connecting to a remote server or domain.
• -u UserName – the user name that the user utilizes to access the remote server.
• [-p {Password|*} - the password of the above specified user name.
• -q – sets output to quiet mode.
• -uc, uco, -uci – for setting the unicode format

How to Delegate Administrative Control of an OU

1. Open the Active Directory Users and Computers console.
2. In the console tree, locate and right-click the OU and choose Delegate Control from the shortcut menu.
3. The Delegation Of Control Wizard launches.
4. Click Next on the Welcome To The Delegation Of Control Wizard page.
5. Click Add on the Users Or Groups page.
6. When the Select Users, Computers, Or Groups dialog box opens, in the Enter The Object Names To Select list box, enter the user/group to which control will be delegated. Click OK then Next.
7. When the Tasks To Delegate page opens, do one of the following:
• Select the Delegate The Following Common Tasks option, then choose the tasks to be delegated. Click Next. The Completing The Delegation Of Control Wizard page will be displayed. The tasks typically delegated are listed below:
• Create, Delete, and Manage user accounts
• Reset Passwords on User Accounts
• Read All User Information
• Create, Delete, and Manage Groups
• Modify the Membership of a Group
• Manage Group Policy Links
• Select the Create A Custom Task To Delegate option and click Next.
8. When the Active Directory Object Type page opens, perform one of the actions listed below:
• Select the This Folder, Existing Objects In This Folder, And Creation Of New Objects In This Folder option to delegate administrative control for the OU, including all current objects in the OU, and to delegate administrative control for all new objects that will be created in the OU.
• Select the Only The Following Objects In The Folder option to delegate control for certain objects in the OU. Choose these objects.
9. Limit the user/group to creating the selected objects in the OU by enabling the Create Selected Objects In This Folder checkbox.
10. Also, limit the user/group to deleting the selected objects in the OU by enabling the Delete Selected Objects In This Folder checkbox. Click Next.
11. When the Permissions page opens, enable one of the following checkboxes to display information in the Permissions: box:
• General – to list general permissions in the Permissions: box
• Property-Specific – to list property specific permissions in the Permissions: box
• Creation/Deletion Of Specific Child Objects – to list all permission that apply to the object in the Permissions: box
12. After populating the Permissions: box, set the permissions for the user/group for the OU in the Permissions: box. Click Next.
13. Verify that the correct settings were selected on the Completing The Delegation Of Control Wizard page.
14. Click Finish.

Troubleshooting an OU Structure

The common problems that occur with OU structures are noted below:

• When users that should not be allowed to perform administrative tasks on OUs perform administrative tasks, verify that administrative control for the OU was delegated to the correct user or group. Verify the user or group specified for administrative control for each OU within the domain.
• If an OU contains objects that have a set of permissions applied when none was defined for the particular OU, verify that the OU is not inheriting permission settings from a parent OU. The default configuration is that a child OU and any objects that the child OU contains automatically inherits Group policy and other permission settings from its associated parent OU.

Understanding the Operations Master Roles

Understanding the Operations Master Roles

FSMO ( Flexible Single Master Operations)
Five Operations Masters Roles

1. Schema Master Role
2. Domain Naming Master Role
3. RID(Relative Identifier) Master Role
4. PDC (Primary Domain Controller) Emulator Master Role
5. Infrastructure Master Role

Active Directory operates in a multi-master replication manner. What this means is that each domain controller in the domain holds a readable, writable replica of the Active Directory data store. In multi-master replication, any domain controller is able to change objects within Active Directory. Multi-master replication is ideal for the majority of information located in Active Directory. However, certain Active Directory functions or operations are not managed in a multi-master manner because they cannot be shared without causing some data uniformity issues. These functions are called Flexible Single Master Operations (FSMOs).

There are five Operations Master (OM) roles which are automatically installed when you install the first domain controller. These five OMs are installed on the domain controller. Two of these OM roles apply to the entire Active Directory forest. The roles that apply to the forest are the Schema Master role and the Domain Naming Master role. The other three OM roles apply to each domain. The roles that apply to a domain are the Relative identifier (RID)/relative ID Master role, the Primary Domain Controller (PDC) Emulator role, and the Infrastructure Master role. When a domain controller is assigned a FSMO, that domain controller becomes a role master. The particular domain controller that is assigned these roles performs single-master replication within the Active Directory environment.

Because domain controllers generally contain the same Active Directory information, when one domain controller is unavailable, the remainder of the domain controllers are able to provide access to Active Directory objects. However, if the domain controller that is lost has one of these OM roles installed, you could find that no new objects can be added to the domain.

Forest-Wide Operations Master Roles

Each Forest-wide OM role can exist on only one domain controller in the entire forest. What this means is that these roles have to be unique in the entire forest. The two forest-wide OM roles are:

• Schema Master role: Because the objects that exist in the in the schema directory partition define the Active Directory structure for a forest, great control is placed on who can add objects to this partition. Since each domain controller in an Active Directory environment have a common schema, the information in the schema has to be consistent on each domain controller. It is the domain controller that is assigned the Schema Master role that controls which objects are added, changed, or removed from the schema. The domain controller with the Schema Master role is the only domain controller in the entire Active Directory forest that can perform any changes to the schema. You can use the Active Directory Schema MMC snap-in to make changes to the schema, and only if you are a member of the Schema Admins group. Any changes made to the schema would affect each domain controller within the Active Directory forest. You can transfer the Schema Master role to a different domain controller within the forest. You can also seize the role if the existing domain controller holding the role had a failure and cannot be recovered.
• Domain Naming Master role: As is the case with the Schema Master role, only one Domain Naming Master role is allowed in the entire forest. The domain controller that is assigned the Domain Naming Master role is responsible for tracking all the domains within the entire Active Directory forest to ensure that duplicate domain names are not created. The domain controller with the Domain Naming Master role is accessed when new domains are created for a tree or forest. This ensures that domains are not simultaneously created within the forest. The default configuration is that the first domain controller promoted in a forest, is assigned this role. You can however transfer the Domain Naming Master role to a different domain controller within te forest.

Domain-Wide Operations Master Roles

The three domain-wide OM roles have to unique in each domain within a forest. What this means is that there should be one of each of these roles in each domain. The three domain-wide OM roles are:

• Relative identifier (RID) Master role: When a security object is created within Active Directory, it is allocated a security ID. The security ID is made up of the domain security ID and a relative ID. The domain security ID is exactly the same for each security ID created in the particular domain. The relative ID on the other hand is unique to each security ID created within the domain. Because each relative ID has to be unique, the domain controller that is assigned the RID Master role is responsible for tracking and for assigning unique relative IDs to domain controllers whenever new objects are created. To ensure efficiency when assigning relative IDs to domain controllers, the domain controller assigned the RID Master role actually generates a set of 500 relative IDs to allocate to domain controllers. As the number of available relative IDs decreases, the RID Master generates more relative IDs to maintain the number of relative IDs available as 500. The default configuration is that the RID Master role and PDC Emulator role is assigned to the identical domain controller. You can however transfer the RID Master role to a different domain controller within the domain.
• PDC Emulator role: In domains that contain Windows NT Backup Domain Controllers (BDCs), the domain controller which is assigned the PDC Emulator role functions as the Windows NT Primary Domain Controller (PDC). The PDC Emulator role has importance when it comes to replication – BDCs only replicate from a Primary Domain Controller! Objects that are security principles can only be created and replicated by the PDC Emulator. Security principles are Users, Computers, and Groups. It is therefore the PDC Emulator that enables down-level operating systems to co-exist in Windows 2000 and Windows Server 2003 Active Directory environments. After the domain is operating in the Windows Server 2003 functional level, the domain controller assigned the PDC Emulator role continues to perform other operations for the domain.
  These additional functions include the following:
• All password changes and account lockout requests are forwarded to the PDC Emulator. A domain controller within a domain checks first with the PDC Emulator to verify whether a bad password provided by a user was a recently changed password, and is therefore a valid password.
• Group policies consist of a Group Policy Container (GPC) in Active Directory, and a Group Policy Template (GPT) in the SYSVOL folder. Because these two items can become out of sync due to multi-master replication, the Group Policy Editor is by default set to the PDC Emulator. This prevents group policy changes from being made on all domain controllers within the domain.
• Infrastructure Master role: The domain controller assigned the Infrastructure Master role has the following functions within the domain:
• Updates the group-to-user references when the members of groups are changed. These updates are sent by the Infrastructure Master to the remainder of the domain controllers within the domain via multi-master replication.
• Deletes any stale or invalid group-to-user references within the domain. To do this, the Infrastructure Master role checks with the Global Catalog for stale group-to-user references.

Planning the Placement of the FSMOs

A mentioned previously, all the OM roles are by default automatically assigned to the first domain controller created for the first domain in a new Active directory forest. Then, when you create either a root domain of a new tree in a forest, or a new child domain, the three domain specific OM roles are assigned to the first domain controller in that domain. In cases where a doain has only one domain controller, each domain specific OM role has to exist on that single domain controller. The two forest specific OM roles stay on the initial domain controller for the first domain created within the forest.

OM roles are usually transferred to other domain controllers when you need to perform maintenance activities, or load balance the existing load of the domain controllers, or simply move the particular OM role to a better equipped domain controller.

In instances where multiple domain controllers exist for a particular domain, consider the following recommendations when placing your Operations Master roles within the domain:

• Where you have two domain controllers that are direct replication partners and are well-connected, assign the RID Master role, PDC Emulator role and Infrastructure Master role to one domain controller. This particular domain controller would become the OM domain controller for the domain. The remaining domain controller would become the designated standby OM domain controller.
• It is generally recommended to assign the PDC Emulator and RID Master roles to the same domain controller.
• However, if the domain which you are placing FSMO roles for is large in size, consider locating the RID Master role and PDC Emulator role on two different domain controllers. Each of these domain controllers should be well-connected to the domain controller designated as the standby OM domain controller for these two roles. This strategy is usually implemented to reduce the load on the domain controller assigned the PDC Emulator.
• You should place the Schema Master role and the Domain Naming Master role on the same domain controller.
• You should refrain from assigning the Infrastructure Master role to a domain controller that contains the Global Catalog. The domain controller assigned the Infrastructure Master role should be well-connected to the Global Catalog server. The Infrastructure Master would not operate correctly if the Global Catalog is hosted on the identical domain controller.

Managing Operations Master Roles

Since only one or a few domain controllers are assigned the Operations Master roles, it is important that these specific domain controllers remain functioning in the Active Directory environment. There are essentially two processes involved in the management of FSMOs. These management tasks are outlined below:

• Because the FSMOs are automatically created when the first domain controller is installed, you might need to transfer OM roles to a more robust server. You would also need to transfer OM roles to a different server before demoting the domain controller hosting them.
• When a lost domain controller cannot be recovered, you would to need any seize OM roles assigned to the particular domain controller.

Transferring an Operations Master role, involves moving it from one server to a different server. To transfer the Schema Master role, you need to have Schema Admins rights, and to transfer the Domain Naming Master role, you need to have Enterprise Admin rights.

You can use an Active Directory console or a command-line utility to transfer OM roles. The Active Directory MMC consoles that can be utilized to transfer the different FSMOs are outlined below:

• Active Directory Schema MMC snap-in: For transferring the Schema Master role
• Active Directory Domains and Trusts console: For transferring the Domain Naming Master role
• Active Directory Users and Computers console: For transferring the RID Master role, PDC Emulator role, and Infrastructure Master role.

When you seize an OM role, you do it without the cooperation of the existing domain controller that is assigned with the particular OM role. When an OM role is seized, it is basically reassigned to a different domain controller. Before you attempt to seize any OM roles, first try to determine what the reason is for the filure of the existing domain controller which is assigned with the particular OM role. Certain network issues which are likely to be corrected in short time fames are well worth enduring through. Before you seize OM roles, first ensure that the domain controller you are planning to shift these roles to; is indeed powerful enough to uphold these roles. In summary, you should only really seize an OM role if the existing OM cannot be recovered again. You would need to use the Ntdsutil tool command-line tool to seize OM roles.

The Consequences of FSMOs Failing

The following section looks at what actually happens when each FSMO role fails:

• A Schema Master failure is basically only evident when an Administrator attempts to change the Active Directory schema. What this means is that a Schema Master failure is invisible to your standard network users. You should only seize this role to the domain controller designated as the standby schema master if the existing Schema Master can in fact never be recovered.
• As is the case with a Schema Master failure, Domain Naming Master failure is only evident if an Administrator is attempting to add a domain to the forest, or remove a domain from the forest. A Domain Naming Master failure can generally not be perceived by your standard network users. You should only seize this role to the domain controller designated as its standby when the existing Domain Naming Master would never be operational again.
• A RID Master failure is only evident to Administrators if they are attempting to add new Active Directory objects in the particular domain where the RID Master failed. When this happens, the RID Master is unable to allocate relative IDs to the domain controllers on which the new Active Directory objects are being created. A RID Master failure cannot be detected by your conventional network users. You should also generally only seize this OM role when the existing domain controller assigned with the RID Master role would never recover from the failure.
• An Infrastructure Master failure is also not visible to your standard network users. The failure only impacts Administrators that are attempting to move user accounts, or rename them. Consider moving the role to the designated standby domain controller if the existing domain controller assigned with the Infrastructure Master is to be unavailable for a reasonably extended period of time, and the changes that need to be made are pertinent.
• Unlike the OM role failures previously described that are not evident to your standard network users, a PDC Emulator failure does impact network users. It is important to immediately seize this role to its designated standby domain controller if the domain contains any Windows NT backup domain controllers. You can always return this role to its previous domain controller when it is recovered and online again.

How to view the existing Schema Master role assignment

1. Open a command prompt, and enter regsvr32 schmmgmt.dll to register the schmmgmt.dll on the computer.
2. Click Start, Run, and enter mmc in the Run dialog box. Click OK.
3. From the File menu, select Add/Remove Snap-in and then select Add.
4. In the list of available snap-ins, double-click Active Directory Schema.
5. Click Close. Click OK.
6. Open the Active Directory Schema snap-in.
7. In the console tree, right-click Active Directory Schema and select Operations Masters from the shortcut menu.
8. The Change Schema Master dialog box opens.
9. You can view the name of the existing Schema Master in the Current Schema Master (Online) box.
10. Click Close.

How to view the existing Domain Naming Master role assignment

1. Open the Active Directory Domains And Trusts console from the Administrative Tools menu.
2. In the console tree, right-click Active Directory Domains And Trusts and select Operations Masters from the shortcut menu.
3. The Change Operations Master dialog box opens.
4. You can view the name of the existing Domain Naming Master in the Domain Naming Operations Master box.
5. Click Close.

How to view the existing RID Master role, PDC Emulator, and Infrastructure Master role assignments

1. Open the Active Directory Users And Computers console from the Administrative Tools menu.
2. In the console tree, right-click Active Directory Users And Computers and click All Tasks, and then Operations Masters from the shortcut menu.
3. The Operations Masters dialog box contains the following tabs:
• RID tab: The name of the existing RID Master is displayed in the Operations Master box of this tab.
• PDC tab: In the Operations Master box of the PDC tab, you can view the name of the existing PDC Emulator.
• Infrastructure tab: The existing Infrastructure Master's name is displayed in the Operations Master box.
4. Click Close.

How to transfer the Schema Master role to another domain controller

Before you can transfer the Schema Master role to another domain controller, ensure that you have the required Schema Admins rights, and that both domain controllers you are planning to work with are available. Before you can use the Active Directory Schema MMC snap-in, you first have to add it to a MMC.

To add the Active Directory Schema snap-in to a MMC,

1. Open a command prompt, and enter regsvr32 schmmgmt.dll to register the schmmgmt.dll on the computer.
2. Click Start, Run, and enter mmc in the Run dialog box. Click OK.
3. From the File menu, select Add/Remove Snap-in and then select Add.
4. In the list of available snap-ins, double-click Active Directory Schema.
5. Click Close. Click OK

To transfer the Schema Master role,

1. Open the Active Directory Schema snap-in.
2. Right-click Active Directory Schema in the console tree, and select Change Domain Controller from the shortcut menu.
3. The options available when the Change Domain Controller dialog box opens are
• Any DC: If this option is selected, Active Directory will select a new domain controller for the Schema Master role.
• Specify Name: If this option is enabled, you have to enter the name of the new location for the Schema Master Role.
4. Click OK
5. Right-click Active Directory Schema in the console tree again, and choose Operations Master from the shortcut menu.
6. When the Change Schema Master dialog box opens, click Change.
7. Click OK when a message appears prompting for verification of the OM role transfer you want to perform.
8. Click OK to exit the Change Schema Master dialog box.

How to transfer the Domain Naming Master role to another domain controller

You have to be a member of the Enterprise Admin group to transfer the Domain Naming Master role to another domain controller.

1. Open the Active Directory Domains And Trusts console from the Administrative Tools menu.
2. In the console tree, right-click Active Directory Domains And Trusts and select Connect To Domain Controller from the shortcut menu.
3. The Connect To Domain Controller dialog box opens. This is where you specify the name of the new domain controller that should be assigned the Domain Naming Master role.
4. Click OK
5. In the console tree, right-click Active Directory Domains And Trusts and select Operations Masters from the shortcut menu.
6. When the Change Operations Master dialog box opens, click Change
7. Click Close

How to transfer the RID Master role, PDC Emulator role, or Infrastructure Master role to another domain controller

1. Open the Active Directory Users And Computers console from the Administrative Tools menu.
2. In the console tree, right-click Active Directory Users And Computers and click Connect To Doman from the shortcut menu.
3. When the Connect To Domain dialog box opens, enter the domain name that you want to work with.
4. Click OK
5. In the console tree, right-click Active Directory Users And Computers and click Connect To Domain Controller from the shortcut menu.
6. When the Connect To Domain Controller dialog box opens, specify the new domain controller for the OM role that you are transferring.
7. Click OK
8. In the console tree, right-click Active Directory Users And Computers and click All Tasks, and then click Operations Masters from the shortcut menu.
9. The Operations Masters dialog box opens. On one of the following tabs,
• RID tab: Click Change to change the location of the RID Master
• PDC tab: Click Change to change the location of the PDC Emulator
• Infrastructure tab: Click Change to change the location of the Infrastructure Master.
10. Click Yes to verify that you want to transfer the particular OM role to a different domain controller.
11. Click OK. Click Close.

How to seize an Operations Master role

When you seize an OM role, you need to perform the following tasks:

• Verify that the new domain controller for the role is completely updated with changes performed on the existing domain controller of the particular role. You can use the Replication Diagnostics command-line utility for this verification. Repadmin.exe is included with the Windows Support Tools on the Windows Server 2003 CD-ROM.
• You would not use the Ntdsutil tool to seize the particular OM role. The Ntdsutil tool first attempts to transfer the role before it actually proceeds to seize the role.

However, if you need to seize the PDC Emulator or Infrastructure FSMOs, you can use the Active Directory Users and Computers console. The Ntdsutil tool has to though be used to seize the other FSMOs – Schema Master role, Domain Naming Master role, and RID Master role. You can however also use the Ntdsutil tool to seize the PDC Emulator role or Infrastructure Master role.

To seize the PDC Emulator or Infrastructure FSMOs using the Active Directory Users and Computers console,

1. Open the Active Directory Users and Computers console
2. In the console tree, right-click the domain object, and choose Connect to Domain Controller from the shortcut menu.
3. Enter the name of the other domain controller. Click OK
4. To perform the seizure of the role, right-click the domain object and choose Operations Masters from the shortcut menu.
5. Click either the PDC tab, or the Infrastructure tab
6. You will notice that the particular OM role is indicated as being offline.
7. Click Change.
8. Click OK to verify that you want to transfer the OM role.
9. Click Yes when prompted to verify that you want to perform a forced transfer.

To seize any OM roles using the Ntdsutil tool,

1. Click Start, Command Prompt.
2. Enter the following at the command prompt: ntdsutil. Press Enter
3. Enter the following at the ntdsutil prompt: roles. Press Enter
4. Enter the following at the fsmo maintenance prompt: connections. Press Enter
5. Enter the following at the server connections prompt: connect to server, and the fully qualified domain name (FQDN). Press Enter
6. Enter the following at the server connections prompt: quit. Press Enter.
7. Enter one of the following at the fsmo maintenance prompt:
• seize schema master. Press Enter
• seize domain naming master. Press Enter
• seize RID master. Press Enter
• seize PDC. Press Enter
• seize infrastructure master. Press Enter
8. Enter quit at the fsmo maintenance prompt. Press Enter
9. Enter quit at the ntdsutil prompt.

How to perorm a metadata cleanup

The class objects and attribute objects of the schema are referred to as metadata. A metadata cleanup is usually performed when you are unable to restore a failed domain controller. The cleanup removes any references to the failed domain controller in Active Directory.

To perform the metadata cleanup,

1. From the command prompt, enter ntdsutil and press Enter.
2. Enter the following at the ntdsutil prompt: metadata cleanup. Press Enter
3. Enter the following at the metadata cleanup prompt: connections. Press Enter
4. Enter the following at the server connections prompt: connect to server, followed by the server name. Press Enter
5. Enter quit, and press Enter
6. Enter the following at the metadata cleanup prompt: select operation target. Press Enter
7. Enter list domains. Press Enter
8. Enter select domain, followed by the number of the domain that holds the server that you want to remove. Press Enter
9. Enter list sites. Press Enter
10. Enter select site, followed by the number of the site that holds the server that you want to remove. Press Enter
11. Enter list servers in site. Press Enter
12. Enter select server, followed by the number of the server that you want to remove. Press Enter.
13. Enter quit and press Enter to return to the metadata cleanup prompt.
14. Enter remove selected server, and press Enter.
15. When a message box appears prompting you to verify whether the server should be removed, click Yes
16. Quit from Ntdsutil.