Promote Additional Domain Controller to Primary Domain Controller

In an Active Directory forest, where you have several domain controllers, but one primary domain controller (PDC) - you may think that you must RESTORE or recover this PDC to salvage the domain. In other words, if the PDC fails - is all lost? Nope, not at all. Unless you do not have backup domain controllers. When you promote additional servers on your domain, and make them member DC's in the same forest, then your domain details are available to you - and you simply need to transfer the Operation Master role to another DC - but before doing that - there are the FSMO's - yea, something hardly anyone knows about: FSMO = Flexible Single Master Operation - something your PDC or master of operations - manages. If a PDC - and Global Catalog for that matter - goes offline, a backup DC will generally pickup and juggle traffic for the PDC. But what happens if the PDC crashes altogether, and you need to basically assign a member backup DC the PDC role? FSMO must be transferred to a backup DC before that DC can assume the Master of Operations role. This is done at the command-line level, and you must be careful before you make this call - ONLY do this if you are sure you cannot recover the original PDC because once you do this - you cannot laterr recover the PDC and bring it online. It cannot be added back into the forest at all. So, the FSMO roles and how we transfer these. In a word, you cannot simply transfer the FSMO roles because the PDC is off line and not available to authorize the transfer. However, you 'can' SEIZE the FSMO roles from the original PDC - even with the machine offl line. Caution: Using the Ntdsutil utility incorrectly may result in partial or complete loss of Active Directory functionality.

Open a CMD prompt on the backup DC you want to perform this on. At the command-line prompt, type Ntdsutil and press <Enter>.

C:\WINDOWS>ntdsutil ntdsutil: At this prompt, type roles and press <Enter>: ntdsutil: roles fsmo maintenance: Now type connections and press <Enter>: fsmo maintenance: connections server connections: Now type connect to servername <serverName> where <serverName> is the name of the backup DC you are working on, and press <Enter>: server connections: connect to servername hamddc02 Connected to hamdc02 using credentials of locally logged on user. server connections: At the server connections prompt type q and press <Enter>: server connections: q fsmo maintenance: Now we are going to SEIZE the FSMO roles we want. NOTE: Out of the 5 FSMO roles, we are NOT going to seize the Infrastructure Master. We do not want to put the Infrastructure Master (IM) role on the same domain controller as the Global Catalog server. If the Infrastructure Master runs on a GC server it will stop updating object information because it does not contain any references to objects that it does not hold. This is because a GC server holds a partial replica of every object in the forest. For now, we'll seize the following: Seize domain naming master Seize PDC Seize RID master Seize schema master We do this by typig the line shown above. For example, to seize the domain naming master, type seize domain naming master and press <Enter> You will receive a Windows dialog prompting to confirm this move - click <Yes> and then you'll see the attempt to safely transfer the FSMO role, a failure message, and then it will seize the role, assigning it to the backup DC you specified when you connected to the server above. Once you have completed this for the 4 roles, type Quit to exit the utility, then Exit to return to Windows. From the Start menu, select Run and enter dsa.msc and press <Enter>. On the domain that is displayed, right click and select Operations Masters. You should now see that this backup domain controller (HAMDC02 in this case) is not the Operations master. From here you simply re-create the failed domain controller, and promote it - joining it to this existing forest.   NOTE: some great tips found on net The seize command is a rather heavy handed route to undertake and only should happen as a last resort if the usual transfer is not possible. Don't be alarmed though if you need to go down this road. If the DC is limping till it gives up the ghost, try and transfer the roles without delay. In other words, if there is a chance to transfer then, do it otherwise fall back on seizing them. The issue of never returning the same DC back into the AD had concerened me the most especially as it's written everywhere yet with no good explanation as to why. The main reason for it is that the AD will be competing with the downed server for the handling of the RID pool in particular. If this was to occur, any newly created items within AD will not get unique identifiers and start to cause unknown complications when calling on these ID's leading up to an unstable and very confused AD. However, the above rule would only happen if the downed DC was not freshly rebuilt before returning to the domain. If the server _is_ the same one that left, then you can never bring it back into AD and promote it. However, if it's the same server physically yet was formatted and repartitioned with a fresh OS then its not technically the same server as the GUID of the new machine will be different. That's what is referred to when instructed never to bring it back - the GUID. So, when rebuilding you can even use the same netbios/dns name as the original since AD will hand it a new GUID on entry to the directory. This then means that when removing the server (or rebuilding it from a crash) there will still be remnants of it within AD. You will then need to do a metadata cleanup via ntdsutil. To ensure that all records of the original server have been removed from AD, use the DcDiag /v command. If you need to determine which servers are handling each of the 5 FSMO roles, use the "Netdom query FSMO /domain" command available from either the windows 2000 support tools or within the standard 2003 server.