Windows Server uses a multi-master format for domain controllers but there are some network tasks that can only be performed on single, designated computers. These are called Flexible Single Master Operations (FSMOs). These single computers are Domain Controllers called Operations Masters, and they are the only ones which will accept changes, even though these changes are replicated throughout Active Directory.
Use the buttons below to navigate through the lesson
Introduction to Operations Masters
- Relative ID Master
- PDC Emulator
- Infrastructure Master
- Schema Master
- Domain Naming Master
Because of their particular function, Global Catalog servers are included in the following discussion even though this is not a single master role.
Global Catalog Servers
A Global catalog is a database that contains a reduced set of attributes for every object within the forest. Their function is to allow searches of the entire forest to be resolved at the local site to reduce network traffic.
Global Catalog servers are also accessed to discover the location of domain controllers during logon. Therefore if no Global Catalog is present at a remote site, clients attempting logon will access a remote Global Catalog to discover the location of the local Domain Controller. Hence, there should be at least one global catalog server at every site.
A Domain Administrator may change the contents of the Global Catalog using the “Active Directory Schema” snap-in. To use this, the “Adminpak.msi” file (located in the c:\windows\system32\ directory) must first be installed.
To modify the contents of the Global Catalog, open a new MMC and add the “Active Directory Schema” snap-in.
Here the Active Directory Schema snap-in has already been installed. Double click it to open. Double click Attributes. Double click the property to be modified. If you index the attribute, searches on it will be faster. However, indexing too many attributes will cause the whole directory to slow down. You can also replicate the attribute to the Global Catalogs, which will prevent searches on this attribute from using the WAN. However, it will also increase replication traffic.
The infrastructure master maintains consistency of User to Group mappings and ensures all Domain Controllers receive Group membership changes. ACLs depend largely upon group membership so this role is vital in ensuring correct user access to network resources. There should be one Infrastructure Master on each domain in your forest. The first Domain Controller within the domain is by default the Infrastructure master. If other Domain Controllers are available, place the Infrastructure Master and Global Catalog on different Domain Controllers. If the infrastructure master and global catalog are on the same domain controller it will never find data that is out of date, so will never replicate any changes to the other controllers in the domain.
Relative ID Master
The object “Fred” could be a user, printer, computer, or Organisational Unit within this list. Human beings can be (and frequently are) confused by objects which have similar names. Active Directory doesn’t have this problem because every object has a SID – a Security ID number. There are two parts to each SID: a number which identifies the Domain in which the object is created, and a Unique ID which only that object has.
A Domain Controller creates and names new objects in the directory. It will give out the same Domain ID to every object, secure in the knowledge that every other Domain Controller will give out that Domain ID to the objects they create.
The unique part of the SID is a different matter. Each Domain Controller is given a range of sequential numbers (about 10,000) different from any other DC. It is the job of the Relative ID (RID) Master to furnish busy Domain Controllers with these numbers.
There are two principal consequences of the foregoing:
- There should only ever be one RID Master per domain, otherwise there is the possibility of duplicate sequences being generated.
- A RID master might fail but its loss might not be noticed until a Domain Controller’s list of Unique IDs is used up.
Note the following:
- When using the “Movetree” command to move objects between domains the operation must be performed on the Domain Controller that is acting as the RID master for the domain the object is currently in.
- If the RID master role has been seized in the event of a failed server, the failed server must not be brought back on line without reformatting the drives and reinstalling Windows.
Active Directory is really only a glorified list – a very big one. Because a computer is basically a well-meaning idiot, this list has to be carefully and precisely specified for it to find anything in the directory at all. The schema is the specification for how each thing in the list should be described. Deviate from this specification even by the smallest point and you’ll confuse the idiot utterly.
Consider this soldier’s kit-list:
- Boots (2)
This list is a Schema for his kit – and the soldier must follow orders exactly. If the schema is unchanged then his performance of his duties is unimpeded.
Change ONE thing however……and every soldier has to conform.
At a stroke you’ve rendered your country defenceless. The same thing applies to the Schema. Changing a seemingly unimportant detail can have drastic effects!
The Schema Master is responsible for maintaining a consistent Schema throughout the forest. Any changes to the schema must be performed on the Schema Master which then propagates the change to all Domain Controllers in the forest. Only manual changes need be made on the Schema Master. Installing software may alter the schema automatically.
Domain Naming Master
The Domain Naming Master is responsible for logging the addition and deletion of domains within the forest, thus it is a forest-wide role. The DNM ensures the uniqueness of each domain name and ensures that it fits within the naming structure of the forest. When a forest is dismantled the DNM must be the last DC within the forest otherwise domains will not be removed! The failure of the Domain Naming Master will not be noticed until an attempt is made to add or remove a domain from the tree. If the Domain naming master role has been seized in the event of a failed server, the failed server must not be brought back on line without reformatting the drives and reinstalling Windows.
The PDC Emulator
NT 4.0 networks did not use Active Directory. They relied upon a Primary Domain Controller (PDC) and Backup Domain Controllers. Clients which do not use Active Directory are termed “down-level”. Down-level clients joined to a modern Windows 2003 network expect to be served by a PDC. For this reason, one server in each Windows 2003 domain acts as a PDC emulator. The Primary Domain Controller Emulator allows down-level clients to log on to the network and receive security information. It also replicates the directory structure to any Backup Domain Controllers remaining on the network, which is useful during migration from NT4 to Windows 2000.
The PDC Emulator receives preferential password updates, even when the network is running in native mode. This means if a password change has not been replicated to the Domain Controller you are attempting to log on to, it will forward the request to the PDC Emulator which should have the latest information. If the Primary Domain Controller Emulator fails, the Backup Domain Controllers will not be able to process logons, thus you should transfer the PDC Emulator role to another server as soon as possible.
While there is no PDC Emulator functioning on the network, no down-level clients will be able to log on! For a company that is migrating at the time, this can cause a lot of hassle, money and wasted time!