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.
4. When the Domain Functional Level is raised (e.g. from Windows 2008 to 2008 R2) the PDC Emulator DC must be available as these changes are always committed at the PDCE.
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.
This article is amazing and quite relevant. Folks out there do not understand these nuances. I came across a handful in this post based on experience using troubleshooting tools in AD and seeing constant communication with the PDCe only on certain operations. Thanks for posting!
Very useful article 🙂
I updated my personal notes with few of these points.
Thanks for posting!
Can PDCE be on a virtual machine (VMware) while NTP is configured for time sync?
As long as the virtual machine could reach the correct NTP server it will work fine. Also make sure to not have the VMtools time sync set up for this virtual machine.
I am planning to move PDC emulator role to a different Windows 2008 R2 DC, their are existing trust relationships with couple of Win NT 4 domains. Will these trust relationships have any impact if PDC emulator role is moved from existing DC to another ?
Thanks in Advance
Hello Smeeta,
do the other domain controllers already run Windows 2008 R2? If so, it should be fine, just if there is no routing and firewall issues between the Windows NT domains and the new DC holding the PDC emulator role.
Also make sure that the NT domains can resolve the NETBIOS name of your domain with the <1B> suffix, which is how they identify the PDC. Typically this is through WINS, so verify that the new DC has WINS client pointers to a WINS server that the NT servers use.
You are most likely very aware of this, but it should be noted that Windows NT is unsupported since many years and Microsoft does not guarantee anything works from newer operating systems together with NT. 🙂
Regards, Rickard
I am planning to move the PDC-role from a Windows 2003 DC to a new virtual Windows 2008R2 DC. We have several One-Way-Trust to our Domain (it is a DMZ). Does this move has any infuence on the trusts?
Thanks in advance
Hello Frank,
The trusts themeselves will be remained as they are part of the Active Directory database. You must however make sure that the new Windows 2008 R2 domain controller has the same routing/firewall rules/access to every other domain. Also make sure that the other domains are correctly configured with new IP addresses if you use DNS conditional forwarding for example, as you will likely remove the old 2003 DC.
Regards, Rickard
This is a very relevant article to understand the PDCEmulator. I learned a lot about these roles.
Thanks Rickard
Hi,
Thanks a lot for such a detailed post on PDC. However If I am asking which is the most important responsibility of a PDCE other than time sync, pwd change mgmt, account lockout processing, GPO update processing and OU redirection?
Help me please.
Regards
Suraj
Hello Suraj,
do I understand you that you seek the most important function of the PDC Emulator other than the ones you mention?
It might not be easy to name one specific function. From a practical point of view the Time, GPO and password managment is the most critical to be without, and many of the other function are needed when certain specific tasks should be made, such as creating a new external trust, however only needed at the moment.
Could you give some more information regarding what you seek?
Great article and thanks for taking the time to put it all together.
Thanks a ton buddy..your efforts are really helpful and few of my doubts cleared for PDCE
Hello!
Thank you for the awesome article! I definitely learned a few things from the long list you were able to find information on! In return, I would like to add some info that I gathered over my admin life. Specifically on #6 and #14. Also wanted to add some more info on #14.
#6: Where you said all incorrect authentication requests are forward to the PDC, this is not entirely true. So far I’ve only found RPC and NRPC calls have the ability to forward incorrect authentication requests to the PDC by default. In other words, only Kerberos and NTLM requests are forwarded to the PDC. Also custom built applications that leverage Kerberos or NTLM, there is a specific flag that needs to be enabled to forward failed authentication requests to the PDC. If the flag is not enabled in the programming design, the authentication request will not be forwarded to the PDC and fail at the first DC.
#14: Each bad password count and time is logged on the respective DC that the failed attempt was made on, and at the PDC. If you log into another DC, you will not see that failed attempt for that user in the user’s badpassword attributes in ADUC. The badpassword attributes are updated individually on each DC, and the PDC is responsible for the total count and determines if the user gets locked. Also the badpassword count is not replicated during the rep interval. So if I try 1 time each on 5 DCs, all 5 will have 1 entry only, and the PDC will know about all 5.
Also to add to #14. Server 2003 SP1 implemented a feature called Password History N-2. If you have Enforce Password History enabled in your GPO, which most people do, and change your password. That old password history (up to 2) is saved at the PDC. If you reset your password and any device or application has an old password saved that continuously tries with one of the two passwords in the password history, the attempt is still logged but badpassword count and time is never incremented, so the user will never get locked out. But if a user types in anything other than the 2, it will increment the count properly.
Limitations and drawbacks of the password history N-2 feature:
Forest functional level needs to be 2003 or up. All DCs must be at least 2003 SP1 or up. It only supports Kerberos and NTLM, so other protocols like RADIUS will not work. PEAP or PEAP-CHAP is certificate based and does not forward to PDC. MS-CHAPv2, although uses your NT hash, it also combines it with the challenge/response and repackages it all into an SHA hash and sent over. If this authentication request fails, this does not get forward to the PDC neither. So users with WiFi on RADIUS, this feature won’t work. Lockouts left and right!. Also Exchange Servers are a bit tricky here too. On-prem will leverage Kerberos and NTLM by default so this will work. HTTPAuth, OAuth both support NTLM so we’re good there. MAPI supports Kerberos over HTTP, so I think we’re good there too, but not 100% sure. Hosted Exchange and Outlook Anywhere can be tricky with ActiveSync depending on how it’s setup.
The final thing about this feature is, if you have a 90 day password expiry period like most environments and 2 password histories, you might not find out about devices trying for 6 months. 6 months and 3 passwords later, the user will never remember where he has that password saved. Phones with ActiveSync will try whenever you use it, but if left alone, it only tries once every few hours. But if you leave Outlook open with the old password, it will try every minute. Enough of these can basically simulate an unintentional DoS attack on your most important PDC. Also this feature is enabled by default if you have the enforce password history. I’m not sure what happens if you set it to 1, but you have no choice but to use it. I like the feature but it leaves massive amounts of logs and I haven’t found a way to filter these as they come in as standard 4771 failures.
Hope that helps some people!
Ricky
I apologize, I made a mistake in the above post. It looks like MS-CHAPv2 from a Microsoft NPS server will indeed forward the request to PDC and not increment the bad password if one of the two passwords in the history is used. Bogus password did increment the count. Old password did not.
Also I just tested this on an iPhone with a Microsoft NPS server running 2012 R2 with PEAP and the user was able to login successfully via RADIUS using one of his old passwords. He was actually able to accept the certificate and get onto the WiFi with the previous password. A bogus password did indeed increment the count, but a previous password let him in. This is very odd behavior. I’ll need to look into this deeper.
The RADIUS scenario mentioned in the previous post was with a Cisco VPN RADIUS and that one did not work with the Password History N-2.
My apologies!
Ricky
**Update**
Just tried the same thing again with the iPhone on PEAP and the user was not able to logon to the WiFi with the old password, but the failed attempt did not increment the badpassword count. I conducted the test too early after I changed the password for the user on the PDC. The NPS server checked DC2 first which didn’t have the updated password yet. But Microsoft NPS server with PEAP and MS-CHAPv2 is compatible with the Password History N-2 feature. This is confirmed with tests from both Android and iPhone. The NPS servers first option is set to use PEAP, and MS-CHAPv2 as secondary. I don’t have a choice on Android (Galaxy S6) to use PEAP, I can only use MS-CHAPv2 on Android. iPhone which can’t use MS-CHAPv2 will use PEAP and request the phone to accept the certificate.
One last thing is that I have my DCs set to accept NTLMv2 only. The failed attempts from both android and iPhone are left in the logs as MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 on both DC2 as the first attempt, and DC1 as the PDC check. iPhone, Android, and other 3rd party devices that don’t support NTLMv2 can still authenticate using NTLM.
According to this, http://deployingradius.com/documents/protocols/compatibility.html PEAP, CHAPv2, and CHAP all still contain the NT hash in the payload of the authentication package. When the authentication request reaches the NPS server, the logs showed that it checked against DC2, then forwarded it to the PDC for invalid attempts. If it’s able to do this already, I wonder why the NPS server can’t construct the NTLMv2 hash if it already has the NT hash for the user. Can’t find any documentation on this one.
Thank you and sorry for the wrong information in the above threads.
Ricky
If PDC is down what happen with the badpwdcount?
Is connectivity between PDCs required only for creating an external domain trust, or also for functioning trust? If it is long time required, what will happen if connectivity between PDCs will be unavailable for e.g. several weeks?
Can I setup more than one PDC role inside a single forest or domain? (ex. two domain controller that has PDC role?)
Hello Felix,
you can have several PDC emulator role owners inside a forest, but only one PDC-emulator for each domain.
This means that the PDCE is something of a single-point-of-failure domain-wide, even if most of the features it provides does not get an instant impact.
Best regards, Rickard
If there could be 2 PDCe in a domain then it is not a F”S”MO role anymore. Each domain in the Forest will have a PDCe of its own.
Hi Rick,
I have total 3 DCs. first one is win 2003 DC and other 2 are win2012 r2. i want to decomm old DC. I have moved all FSMO roles except PDC to new server. but when i move PDC to new server, My all user’s outlook clients keep on asking credentials and they are failing to connect even giving correct cred. however, all users can connect with office 365 portal.
S1 – Old server – Win2003 R2 SP2 – 205.x.x.x
N1- New Server 1 WIN 2012 R2- 10.62.x.x
N2 – New server 2 Win 2012 R2 – 10.62.x.x
What do you think is the issue with PDC role migration?
Hello KP and thank you for your comment.
It is unfortunately quite hard to give any real advice since I do not know very little of your environment, for example internal routing, Exchange version, firewalls, DNS pointers and more. I do not work much myself with Exchange, but I am not aware of any feature in Exchange having a specific dependancy to the PDC emulator role, however such need might exist.
I hope you will be able to find the solution, and if possible, please post your findings here.
Regards, Rickard
Hi Rickard,
This is amazing article, learnt a lot. We are in middle of redesigning our domain. We have 9 Domain controllers (too Many of us), now it is time to retire about 5 of those domain controllers, unfortunately, one of them is PDC Emulator. We have two of the following options:-
What do we need to watch out for, if we decommission PDC Emulator? (Option 1)
What do we need to watch out for, if we change the IP Address of the PDC (Option 2)
I am just researching just now to find out what is the impact of both of those options, If the impact could be severe or it is highly not recommended to decommission the PDC Emulator than we will look into the option 2.
Hi Rickard,
Very good explanation about the importance of PDC , Thank you very much for sharing the article
Regards,
Swaminathan Shanmugam