Complex IFM deployment issue

  • Last Post 22 August 2019
davyp posted this 22 August 2019

Hi gentlepeople,
One of my customers has a very complex issue deploying Domain Controllers with IFM.Even the Micosoft Premier Support guys that I am working with on the case can't seem to get their head around this pickle.I am not going to explain the entire case here, but there is one component of the issue that I can't seemt to get my head around and I would appreciate it if someone here could share some insight. I want to deploy a Domain Controller in a remote site.
I prepare a physical W2K16 server, name it "FUTUREDC1" and join it into the AD.I take an IFM backup on another W2K16 DC and copy the data structure to "FUTUREDC".My project gets pushed forward a week because of a new round of "urgent patching".
During this week FUTUREDC decides to change its computer account password. (assumption)Now the computer account password inside the IFM backup no longer matches the one stored in the server itself.
I change the server IP, shut it down, put it in a box, ship it to the remote site.
They plug it, power it up, everything looks good.
I rename FUTUREDC to NEWDCNow promote it to a DC based on the IFM data it has on board.It loads the ntds.dit file from the IFM which contains the old computer password for itself.
Promotion completes, it reboots, I can log in fine and additional DB updates get replicated in from the DCs in the dataceter.
After a while it becomes a running DC, shares its sysvol share restarts netlogon and so on.
A little while later I restart the Domain Controller but when I log on I get an error saying the trust relationship between this Computer and the domain is broken.
I am assuming this is because the new Domain Controller is advertising a version of the domain with the original computer account passwords and actually tries to log on to itself.This fails and the Domain Controller computer account is now unable to authenticate to itself and is stuck.
When we saw this we shut down the DC, unplugged it from the network and restared it in DSRM to debug.
My question now is:If I just replug everything, boot it normally and let it continue to (try to) replicate in aditional changes, will this problem solve itself?If not, is there a way to recover from this situation without starting over (using something like netdom to reset domain controller computer password).
Keep in mind that I can only log on to the Domain Controller if its in DSRM.
Gratefull for any insights anyone might have!
Best regards,DavyP

Order By: Standard | Newest | Votes
Smita posted this 22 August 2019

From what I understand, AD stores the older version of the password, so the computer should be able to authenticate.

(This is why when you do a restore of a DC, you have to reset the password twice).


So I’m thinking there is some other issue going on. I’d start with looking at DNS.


Smita Carneiro GCWN, CISSP

Consultant – Active Directory


Eli Lilly and Company

Email: Carneiro_smita@xxxxxxxxxxxxxxxx|Web :




Anthony.Vandenbossche posted this 22 August 2019

Hi DavyP,


Is the WAN bandwidth that bad to not just let the DC replicate changes on the fly. In other words, ship the server to where it needs

to be, Domain Join in then and promote it to a DC. In most cases I would think that even a 1Mbit line would do the trick so to speak.









barkills posted this 22 August 2019

DC replication of a large DIT can take a long time. The last time I did it here (3+ years ago) it took ~11-14 hours over a combo of 100Mb & 1Gb lines, and for this reason we now purposely pick a DC in the same datacenter when promoting

a new DC. It makes me shudder to imagine doing that over a 1Mb line.