I am looking for some advice...
We are implementing a new DR Datacenter, we are 100% virtualized (VMware server/desktop). Connectivity between both Datacenter is not an issue and we are connected via double ring of dark-fiber, etc.
We are VMware, Cisco, Netapp, EMC, Microsoft shop with MS Exchange 2016, Sharepoint 2013 on premise.
The goal is to be able to be flexible with where we run services, so we are not just active/passive or active/active and we are planning to be both per system/application.
That being said, I was wondering if you can provide some advice in how to approach Active Directory. Specifically looking for advice on how to place the FSMO roles on a two datacenter deployment, best practices to virtualize all the DCs with VMWare, any other advice or stuff to have in mind from previous deployments/experience?
Seeking for advice Active Directory across two Datacenter (DR site)
- 97 Views
- Last Post 14 March 2017
Luis, I have been retired for two years so its been a while since I did this sort of thing, and my views changed while implementing it. I started out retaining a Physical DC as Vcenter used AD for Authentication and so you could end up with a chicken and egg situation where you couldn’t start the Virtual Environment, but in the end we switched to all virtual and developing process so we could start a DC by connecting directly to the individual ESXi box. Remember that AD is inherently a distributed multi-master data base.. .. with the exception of the FSMO roles which are generally non-critical, with the perhaps the exception of the PDC emulator as password “master” which I guess brings us to the key question, one site or two? .. I personally would go for one site… its just simpler… Dave
Primary and Secondary at both sites. FSMO roles placement is really up to you. You might consider seizing your FSMO roles as part of your DR strategy for AD along with your backup or system state back Domain Controller strategy. However, you will have Authentication and possibly DNS (if you host your DNS on your Domain Controllers) available at your DR site. You should have no problem going Virtual on 2012 R2 Domain Controllers now with the better support from VMware.
If you want to have multiple sites but don't want to wait the 15 minute replication interval, set the change notification "options" flag on the site link to 1. This way, you get intra-site replication speed between two distinct sites. You probably still
want to keep a physical DC for FSMO available for the scenario Dave described. I worked at a company that had all virtualized DCs and when the power/backup power went out, we had to physically go to the datacenter to get the FSMO DC up (forest root and child
domains) before anything else would work.
You should size your DCs appropriately for the Exchange/application LDAP requirements. If nothing else, make sure that you have enough memory (physical or virtual) that your DIT can be loaded completely into memory with all of the other system processes. For
small domains, this shouldn't be an issue. If you're active/active and load-balancing applications, make sure that your DCs can handle the extra load should one data center go down.
There isn't anything special regarding which location for the PDCe, just know that's where password changes happen, and you definitely want that up at all times. If most of your apps/services run out of the "primary" datacenter, no reason not to leave your
PDCe/RID FSMO roles there.
Tony, The only issue with the PDC emulator is that if you:-
- Have two sites
- Have a user who changes their password in the site with the PDC.
This would always be the case, which is why enabling change notification
would speed up the normal replication process.
On using the new (changed) password on a DC that hasn't received the PW change replication via standard replication:
When the user logs on to a domain and is authenticated by a domain controller that does not have the updated password,
the domain controller refers to the PDC emulator to check the credentials of the user name and password rather than denying authentication based on an invalid password. Therefore, the user can log on successfully even when the authenticating domain controller
has not yet received the updated password.