The most complete list of all PDC Emulator roles available.
In every Active Directory domain one single Domain Controller is the so called PDC Emulator. The PDC Emulator supports a surprisingly large number of important functions. In this article we will see all the responsibilities that lays on this single DC, which are very different from the somewhat misleading text above (from Windows 2008 R2).
The concept of Flexible Single Master Operations (FSMO) roles has been around since the introduction of Active Directory in Windows 2000 and most of the five FSMO roles are quite well understood. However, due to the large number of very different functions that the PDC Emulator handles it also the role that needs most attention and it is easy to not be entirely aware of what it does.
It is also important to know the impact if the PDC Emulator Domain Controller is unavailable both short and long term. Unfortunately I have not yet found any Microsoft Technet article or blog post who describes all of PDC Emulator functions. The goal of this article is to list every role, which are at least 16.
The original PDC, meaning Primary Domain Controller, was the only writable domain controller in a Windows NT domain, while all normal AD domain controllers are fully writable (multi master). However, a certain amount of operations are still single master and Microsoft has designed most of them to be concentrated on the domain controller holding the PDC Emulator FSMO role.
So here they are: (in no order of importance.)
1. The actual name “PDC Emulator” implies a function that was used a long time ago when migrating Windows NT domains into Active Directory. After the original NT 4.0 PDC was upgraded it became an AD Domain Controller with the PDC Emulator role, and “emulated” the older SAM replication technique against NT4 BDCs. This is only supported up to Windows 2003 R2 and is of no use after the last NT4 domain controller is removed. However, many other functions remain on the PDC Emulator.
2. The PDC Emulator also controls the time in the domain. Other domain controller polls the time from the PDC Emulator (PDCE) and transfers this to all other domain members (servers and workstations). It is crucial to maintain correct time on the PDCE.
3. All writes from the Group Policy Editor tool is by default done to the PDC Emulator, to lower the risk of conflicting writes if multiple administrators are editing the same Group Policy Object.
5. Every write against an user password done at any other domain controller is always also transferred directly to the PDCE. This makes the PDC Emulator an authorative source for the current state of all passwords in the domain.
6. All domain controllers which receives an incorrect authentication request will poll the PDC Emulator as a “second opinion” before rejecting the user. Since the PDCE always knows the most recently modified passwords it can grant access even if the change has not yet been replicated to the authenticating DC.
7. When setting up external trusts against other domains the PDC Emulator much be online or the trust cannot be created. This mimics how trusts was handled at Windows NT domains. Notice the information above from the Domain and Trusts tool.
8. All domain based DFS-Namespace changes is always written against the PDCE. Without the PDCE available no DFS-Namespaces could be created and existing namespaces cannot be modified in any way. This includes new folders, targets and any other DFS-N change.
9. If having any legacy Windows NT Servers still in production (although unsupported for several years) all machine and user password changes from these is targeted against the PDCE.
10. When changing the default location for new computer accounts. It is very recommended to redirect this from the default Computers container to a more suitable real Organizational Unit using the redircmp command line utility. The redirection action must be commited against the PDCE.
11. The PDCE holds the Domain Master Browser function, which means it is the master collector of “browse lists”. This is used less these days, but was important earlier. Remember the Network Neighborhood?
12. If using DFS-N in default mode of “Optimize for consistency” all DFS-N servers polls the PDC Emulator every hour to find updates. This could be changed to “Optimize for scalability” which uses the closest domain controller in the site.
13. Without the PDCE online it is impossible to change the Password Policy of the domain. All changes to the domain common password policy must be committed by the PDC Emulator. If using Group Policy Editor pointing to any other online DC the Password and Audit Policy settings are not even visible inside the Default Domain Policy, even if you select another DC as target from the Group Policy tool.
14. Any account lockout is immediately sent as a notification to the PDC Emulator.
15. Certain important groups have an added amount of protection for incorrectly changed Access Control Lists. Each hour the PDCE domain controller looks through the ACLs for the most important builtin groups and resets the permissions if anything has been altered. The process is called “AdminSDholder” and is only done by the PDC Emulator.
16. When using the command line tool dfsrmig.exe to migrate your SYSVOL replication from FRS to DFS-R the PDC Emulator must be online or else the tool will not work.
Are you aware of any other PDC Emulator role or have any questions? Please leave a comment below.