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.
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:
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!