How many Windows Server 2012 domain controllers do I need initially and where should I put them?

[BrandonWilson]

First published on TechNet on Sep 10, 2012

Following up on Greg Jaworski’s great post from last week where he talked about how to promote a domain controller in Windows Server 2012, today we will cover some thoughts around where to place your first Windows Server 2012 DCs and how many to plan on rolling out at once.  This blog post is meant to be used as high level guidance as every environment is different, so your mileage most likely will vary.  If you are interested in a more detailed recommendation specific to your environment, I encourage you to speak with your Microsoft account team contact(s) to get you hooked up with the right resources at Microsoft to assist.

1. Where you place your first 2012 DCs and how many you need greatly depends on two things:
2. What new 2012 features you plan on using right out of the gate. If you have multiple domains and/or multiple forests with trusts in place.

Let’s break these down a bit more with some specific examples.  For those of you who have not looked into the new Windows Server 2012 features Dynamic Access Control (DAC), Kerberos FAST (AKA armoring), and DC cloning, some of this content may be a bit confusing.  We plan on covering these topics in greater detail in future blog posts.  In the interim, I encourage you to review the following links on TechNet for a quick review before and/or after reading the next section.

Access Control and Authorization Overview (covers DAC)
http://technet.microsoft.com/en-us/library/jj134043.aspx

What’s New in Kerberos Authentication (covers DAC and Kerberos FAST)
http://technet.microsoft.com/en-us/library/hh831747.aspx

Introduction to Active Directory Domain Services (AD DS) Virtualization
http://technet.microsoft.com/en-us/library/hh831734.aspx

Dynamic Access Control (DAC) & Kerberos Flexible Authentication Secure Tunneling (FAST or AKA Kerberos armoring)

If you plan on using Dynamic Access Control with user or device claims, you will definitely want to implement more than one 2012 DC in each of the domains that contains user and computer accounts.  The reason for this is because when a Windows 8 client is enabled to support claims and FAST, it sends a flag for claims support in the PA-PAC-OPTIONS portion of the AS-REQ.  If a downlevel DC receives the AS-REQ, it sends back a TGT without claims which the Windows 8 client throws away and repeats the DC discovery until a TGT is sent back with the claim flag.  If a 2012 DC is unavailable, the claims population process in the Kerberos ticket will fail.  This could also happen if the DC is overloaded so it is important to stand up a sufficient number of DCs to support your DAC implementation.  What is the sufficient number?  This will vary on many factors however here is one way you can estimate:

• Capture the following Performance Monitor counters from your existing DCs:
• Windows Server 2003
• NTDSKDC AS Requests
• NTDSKDC TGS Requests
• Windows Server 2008 & R2
• Security System-Wide StatisticsKDC AS Requests
• Security System-Wide StatisticsKDC TGS Requests
• Implement 2 Windows Server 2012 DCs, enable claims and FAST support, and capture the following Performance Monitor counters:
• KDC AS Request with claims for domain controllers
• KDC AS Requests with FAST for domain controllers
• KDC TGS Requests with FAST for domain controllers
• With the data captured above, you should begin to see how many KDC requests are hitting the down level DCs and how many are hitting the 2012 DCs.  Theoretically the number of KDC requests will be higher on the 2012 DCs since they can support non-claims/FAST and claims/FAST KDC requests.  Use these numbers to scale appropriately.

Another item to keep in mind with DAC is that in environments with Forest trusts in place, you will need 2012 DCs in each domain in the forests where you plan on using DAC so that the claims can be handled appropriately.  With domains that have External trusts, claim information is stripped out of the Kerberos PAC so DAC will not function over an External trust. Virtualized Domain Controller Cloning

When you move the PDC emulator FSMO role to a Windows Server 2012 DC, it creates a special group named “Cloneable Domain Controllers”.  Membership in this group authorizes a Domain Controller to be cloneable.  You can read more about the virtualization safeguards as well as DC cloning in the following article: http://technet.microsoft.com/en-us/library/hh831734.aspx

If you want to use DC cloning and the virtualization safeguards built in to Windows Sever 2012, you will need to make your 2012 DC the PDCe in each domain where you plan to use the technology.  You should then leave the PDCe role on a 2012 DC going forward due to the fact that during the cloning process, an RPC call is made to the PDCe to authorize a DC to be cloned.  You can read more detailed info about the cloning process and how it works is in the following article: http://technet.microsoft.com/en-us/library/3ecd4dc9-2fc1-42a6-bd36-b38c9e607b01

PS.  Don’t forget to update your time settings on the new forest root PDCe and former forest root PDCe after you move the role!  If you don't know what I'm talking about, please see this article: http://technet.microsoft.com/en-us/library/cc786897(v=WS.10).aspx

Active Directory Web Services (ADWS)

If you are still on Windows Server 2003 or Windows Server 2008 (non-R2) you should also think about ADWS when placing your first 2012 DCs.  ADWS is used to support the remote PowerShell functionality in the Active Directory Domain Services role in Windows Server 2008 R2 and Windows Server 2012. With all the above considerations, you should also keep in mind your site topology and place 2012 DCs where appropriate to support local DC use (with the exception of the PDC emulator for cloning, which will happen over a site link if necessary).

I hope this gives you some ideas around how to plan for your first Windows Server 2012 DCs.  Have fun and don’t forget to test, test, and test!

-Jake Mowrer