I just came across this and wanted to share it as I think it’s an interesting read here.
The Exchange Team’s Blog has an excellent blog posting about GC placement and AD design guidance in Ex2007 environments:
http://msexchangeteam.com/archive/2007/03/28/437313.aspx
…it also references a KB article for GC placement on Ex2000/2003 that I was (also) unaware of (which is also referenced in the blog posting above):
The guys over at the Directory Services team have a two part blog posting published that explains how to read the Userenv log file you can generate on bootup. Definitely worth a read not only for Group Policy admins:
This is a fictive conversation between two colleagues in an enterprise. One of the persons involved, a directory services engineer, answers questions of his colleague, a not-so-strong sysadmin. The sysadmin is about to replace a DC in a one-domain forest and already has a transition plan that details the steps need to be taken to replace the old hardware.
SysAdmin: We’ve been looking for the DC replacement the entire week. Could you have a look into our transition plan so that we can be sure we didn’t miss a thing? Replication and making sure core services like DNS and GC are activated on both DCs is on the list. It’s the plan we worked out for the DC replacement in the asia office.
DS engineer: The plan looks pretty straight forward – except that I can’t find any reference on how you’d go about the FSMO roles, have you thought about that, yet?
SA: FSMO? Didn’t know we had to migrate them too? I heard about them and that they are unique in a forest – and three of them in a domain. How would I go about backing them up and restoring them on the new DC?
DSE: First of all you make sure they are on the soon-to-be replaced DC. If so, you need to transfer those roles to the new DC. By “transfer”, I mean really having both DCs, the new and the old one running side by side and you transfer the roles using ntdsutil.
SA: Okay – what would I need to back up, then. I’m pretty sure the old DC has further knowledge about the roles that I need to somehow import on the new DC, right?
DSE: Nope – not at all. All information needed by the DC to perform the roles is stored in the directory and therefore replicated among all DCs. There’s nothing you’d have to fulfill further. From the five roles, the Schema Master and the Domain Naming Master are the forest wide roles – they are pretty much the masters of the two functionalities they host. Any DC in the forest (except RODCs) could fulfill what they do: make changes to the schema and the directory database. The serious thing about these two roles is that if any random DC did that, it could lead to a mess. So there simply needs to be a “master” assigned that has responsibility of those changes – and that can be queried for an authoritative answer on schema or naming questions.
The remaining three roles, they are domain-wide, meaning every domain has holders of those three roles. All of them, the RID Master, the PDC Emulator and the Infrastructure Master hold their configuration in the directory. Transferring the roles is nothing you need to be afraid of.
SA: Am I done then?
DSE: Further things that you need to consider when you’re replacing the hardware that might not be 100% obvious: The first thing is EFS. Is EFS in use in the domain? If so, be sure to export the certificate(s) as a safety procedure. If they get lost, all data that has been encrypted may not be restorable. Also, keep in mind that it’s best practice to run at least two DCs in every domain to ensure fault tolerance in case one of the DCs fails. Be sure to have a backup of both DCs and don’t just demote the old DC. Plug out its network cable (or take a equivalent measure) to see whether all services keep working before completely removing it.
