I would never clone a DC. Build a new VM and promote it to a DC and then demote the original.

I would transfer the PDCe FSMO role first in your scenario you described.

If you have only one domain, the infrastructure master and domain naming master FSMO roles do nothing.

Thanks

I have cloned a DC 2008 R2 from VMWare to Hyper-V and I have to demote it first then promote as a DC.
The only FSMO role that this DC has is the PDC and the rest of them we have them are running from our AWS DC.
Before I proceed with the demote and then promote I would like to have some advice from a professional like you.
What are the risks and steps that I should be more concerned ?

Thank you.
Arden.

You can’t migrate from Windows Server 2003 to Server 2016.
You can’t bring up a 2016 domain controller if there is a 2003 domain controller in AD.

Webster

a) Name Resolution/Network Connectivity to the current domain controller.
b) File Replication Service Latency (a file created on another domain controller
has not replicated to the current domain controller).
c) The Distributed File System (DFS) client has been disabled.
To diagnose the failure, review the event log or run GPRESULT /H GPReport.html f
rom the command line to access information about Group Policy results.

In this regard i need your help /suggestion what can i do now. If possible reply as soon as possible

When a DC crashes or is lost in any way, the FSMO roles are still tied to that server. Look up “FSMO Role seizure” to see the process for forcing the FSMO roles to be given to another DC. Once you have seized the FSMO roles, the original DC should NEVER be brought back on the network or the domain.

Webster

Sure. Change the IP, and either restart the netlogon service or restart the server. Personally, I prefer to restart the server for a “just to make sure of all things” good feeling.

Webster

I hope you get this but I have a few questions.

I’ve been writing up a document to transfer our FSMO roles from windows 2003 to another server we’ve revived with server 2012 R2.

Our current IP set on what we’ll call server A (has a ip of .2. THe dns has .3 (backup DC we’ll call server B) the second DNS is the loopback IP address.

IP: 192.168.1.2
DNS: 192.168.1.3 (from Backup DC Server)
DNS2: 127.0.0.1

My manager wanted to know if we can keep the same IP on the new server and if this was possible. I also wanted to know if this needs to be done after we transfer the FSMO roles over.

The IP of the server running server 2012 would be a .6. All workstation in the office has their DNS set to 192.168.1.2 and 192.168.1.3. Rather than having to reconfigure their DNS IP, can we set the new server up with the same .2 ip address as the old server and change the iP of the old to a different IP?

This would save us a lot of time if this was possible.

Thanks.

https://support.microsoft.com/en-us/kb/255504

Explains the process with the very important note:

A domain controller whose FSMO roles have been seized should not be permitted to communicate with existing domain controllers in the forest. In this scenario, you should either format the hard disk and reinstall the operating system on such domain controllers or forcibly demote such domain controllers on a private network and then remove their metadata on a surviving domain controller in the forest by using the ntdsutil /metadata cleanup command. The risk of introducing a former FSMO role holder whose role has been seized into the forest is that the original role holder may continue to operate as before until it inbound-replicates knowledge of the role seizure. Known risks of two domain controllers owning the same FSMO roles include creating security principals that have overlapping RID pools, and other problems.

How it is done:

https://support.microsoft.com/en-us/kb/223787

When the administrator seizes an FSMO role from an existing computer, the “fsmoRoleOwner” attribute is modified on the object that represents the root of the data directly bypassing synchronization of the data and graceful transfer of the role. The “fsmoRoleOwner” attribute of each of the following objects is written with the Distinguished Name (DN) of the NTDS Settings object (the data in the Active Directory that defines a computer as a domain controller) of the domain controller that is taking ownership of that role. As replication of this change starts to spread, other domain controllers learn of the FSMO role change.

Hope this helps.

Webster

FSMO is the term used since the beginning of AD.
It is best to manually transfer roles that way you decide what domain controller has the role and not a randomly picked DC.

Webster

Is FSMO a term no longer used in 2012? Is it now Operations Masters?
Why “It is really best to transfer any FSMO roles before demoting a DC.”?

Thanks,

Thank you very much for your response !
Olivier

If a DC crashes, FSMO roles are not automatically transferred. If the crashed DC holds the PDCe role, you will be in for some headaches if that DC is down for a few days.

Webster

Thank you for this article. I’m asking FSMO role comportement in another situation : I have 4 DCs and they are working properly. If 1 DCs hosting FSMO role crashed for few days, does FMSO role will be automaticaly transfered to another DC or does the FSMO role will be unavailable until I transfert the role ?
I’m working on Windows 2012R2.

Thank you,

Regards,

Olivier

I would have no fear in seizing the roles. A FSMO role holder is not the only domain controller that stores accounts and permissions. FSMO role are just roles that perform specific domain and or forest level functions. Read this article:

https://technet.microsoft.com/en-us/library/cc780487(WS.10).aspx

There have obviously been no schema changes or domains added to the forest during this time.

I would be digging into the event logs on all your DCs.

If you need help, I am available for hire to help you out. 🙂

Thanks

Webster

I’ve started work at a company where it looks like the FSMO roles are on a server that crashed several months ago. Running “netdom query fsmo” shows all roles on as living on the crashed server…but authentication is continuing to work as well as new account creation, etc…

Something doesn’t seem right, but I believe 4 months is long enough for lack of any active FSMO roles to have bitten them…but it hasn’t yet…I’m sure it is a matter of time, but after this long, is there any fear in seizing these roles from an active server? If the FSMO server is not online, where are these accounts and permissions being stored? Will seizing the roles unravel this unnatural (but functioning) environment?

FSMO roles are never automatically transferred in a crash. For a crash scenario where the crashed DC will not or cannot be brought back online, then you will have to seize the FSMO roles the crashed DC held.

Thanks

Webster