Export (0) Print
Expand All

Examining Operations Master Technical Details

Use the following list to obtain more complete technical explanations concerning the management of operations masters:

  • Why must the RID master be available when creating a large number of security principal objects?
    When a domain controller creates a security principal object, it attaches a unique Windows NT Security ID (SID) to the object. A SID consists of a domain SID that is the same for all SIDs created in a domain, and a relative ID (RID) that is different for each SID created in a domain.
    Each Windows 2000 domain controller in a domain has a pool of RIDs it is allowed to assign to security principals it creates. In addition, the domain has a pool of RIDs that have never been assigned to a domain controller. When the number of RIDs in a domain controller's RID pool falls below a threshold, that domain controller submits background requests for additional RIDs from the domain's RID master. The domain's RID master removes RIDs from the domain's RID pool and assigns these RIDs to the pool of the requesting domain controller.

  • Why must cross-domain object moves originate on the RID master?
    In Active Directory, you can move an object from one domain to another. You can only move an object out of its domain on the domain's RID master. This prevents Active Directory from creating two objects in different domains with the same unique identifier. (This scenario could happen if an object were simultaneously moved from two domain controllers to two different domains.)

  • Why must the infrastructure master not be a Global Catalog server?
    When an object on one domain controller references an object that is not on that domain controller, it represents that reference as a record containing the GUID, the SID (for references to security principals), and the distinguished name of the object being referenced. If the referenced object moves, its GUID does not change, its SID changes if the move is cross-domain, and its distinguished name always changes.
    The infrastructure master for a domain periodically examines the references, within its replica of the directory data, to objects not held on that domain controller. It queries a Global Catalog server for current information about the distinguished name and SID of each referenced object. If this information has changed, the infrastructure master makes the change in its local replica and also replicates the new values to other domain controllers within the domain.
    If the infrastructure master runs on a Global Catalog server it will never update anything, because it does not contain any references to objects that it does not hold. That is because a Global Catalog server holds a partial replica of every object in the forest.

  • Why must the domain naming master also be a Global Catalog server?
    When the domain naming master creates an object representing a new domain, it must make sure that no other object — domain object or otherwise — has the same name. The domain naming master achieves this by running on a Global Catalog server, which contains a partial replica of every object in the forest.

  • What are the special considerations for role placement in mixed-mode domains?
    In mixed-mode domains that contain backup domain controllers, the "Standby operations master domain controller" should be in the same site as the primary domain controller emulator. By keeping both domain controllers in the same site, the system can avoid performing a full synchronization with the backup domain controllers in case you seize the PDC emulator role to the standby operations master domain controller.

  • What do you do if a role transfer is not completed?
    When a role transfer takes place, it updates the current role owner before it updates the desired new role owner. If the desired new role owner fails before making its update, it does not yet hold the role. The desired new role owner can gain ownership of the role in the following ways:

    • Typically, you would repeat the role transfer attempt.

    • Allow replication to update the desired new role owner with the change made at the current role owner. (This does not require any action on your part, but it does take more time than repeating the role transfer attempt.)

  • What happens to operations master roles during backup and restore procedures?
    When you back up a domain controller, you back up the roles it owns.
    So, when you restore a domain controller from backup media, you restore the roles it owns.

  • What happens to operations master roles during the demotion process?
    When you remove Active Directory from the domain controller that owns the operations master roles, the domain controller attempts to "abandon" its roles. For each role the domain controller holds, it locates another available domain controller for the role and transfers the role to it. If another domain controller is not available during the demotion, the demotion process will not succeed.
    Do not rely on the transfer feature when removing Active Directory from a domain controller. Instead, transfer any roles before you begin the removal process so that role placements are as they should be.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft