Skip to main content
  • EN

I want to share my experience of an Active directory migration through the VB Replication software related to an Active directory environment 2012 R2 - forest and domain functional level 2012 R2.

The customer asked me to migrate 3 Domain controllers from an old  VMware 5.5 to the new VMware 6.5 infrastructure for a technological refresh.

Given that the best solution from Microsoft is to create new VMs and promote them Domain Controllers and transfer FSMO roles.

That said, there are scenarios like mine, where this type of approach was not possible as it was mandatory to maintain the same FQDN and IP address due to application configuration problems.

Microsoft advised against demoting and promoting a DC with a different OS but with the same FQDN and IP, even if my environment was relatively small 3 DC one forest \ domain and not complex it could be done with the metadata cleanup procedure but the customer did not give the approval. So I have adopted the solution of VM replica.

 

Scenario --------- > Virtual Environment:

vCenter Win:   Vmware 5.5.0 - build 2646482

VMware ESXi:  5.5.0 - build 3029944

New VCSA :       VCSA 6.7.0 - build 15129973

VMware ESXi 6.5.0 - build 15256549

 

Active Directory Enviroment:

- Remember that from the Windows 2012 R2 version it is possible to clone a DC through the official MS procedure.

https://social.technet.microsoft.com/wiki/contents/articles/23859.windows-2012r2-domain-controller-cloning-step-by-step-guide.aspx

https://www.interfacett.com/videos/clone-windows-server-2012-2012-r2-domain-controller/

 

AD Single Forest\Domain: functional level 2012 R2:

- If you have distributed FSMO roles on different DCs move them on a single DC before migration and carry out the preparatory checks post moving FSMO roles.

  • DC01 all FSMO roles- Primary DNS - Sync time Externa NTP

Forest Role:

    Master scheme

    Domain name master

Domain role:

    RID Master

    PDC emulator

    Master Infrastructure

  • DC02 - Secondary DNS
  • DC03 - Tertiary DNS

 

Veeam backup Enviroment: 9.5 U4 Virtual appliance (Hot add)

If possible, before proceeding with production, it is recommended to test everything in a laboratory and / or pre-production environment

  • Step by step check & migration:
  1. First of all check the UUID of the 3 DCs:

wmic csproduct get "uuid"

IMPORTANT** Never change UUID to a Domain Controller. The GUID is the means for AD to identify a DC for replication. It is important that it remains unchanged, above all, unique for each DC).

  1. VM migration  export and import generates new vHw device UUIDs, the new UUIDs for devices such as NICs tends to trigger   re-activation windows license of the VM.
  2. wmic csproduct get "uuid" ( if UUID changes the windows license it will be reset and could also corrupt the active direcory db and \ or have replication problems etc).
  3. Save the UUIDs of each DC.
  4. Set up a replication job (Application aware enable & Domain Admin user, from Active directory it is possible to give granular permissions to a single users) for each single DC starting from the DCs without FSMO role.

 

  1. Assigning the backup service user " svc_veeam@domain.local" (preferred UPN format) "Domain Admin" and deny "interactive logon" and other restricition Deny "Logon as a Batch" 'or' "Deny Logon as a service" etc depends on your needs.

    https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/implementing-least-privilege-administrative-models
  • TASK 1

Check FSMO roles & Global Catalog:

From dos:  netdom query fsmo

  1. From PS:  Get-ADForest "domain.local" | ft DomainNamingMaster, SchemaMaster Get-ADDomain "domain.local" | ft InfrastructureMaster, PDCEmulator, RIDMaster
  • Disable the DC3 node from the virtual service of the netscaler load balancer. (optional)
  • Full backup Active Directory (system state) of 3 DC (VM Online).
  • Precautionary reboot
  • Shutdown DC3 Windows 2012 R2.
  • Incremental Backup (VM Power Off).
  • Lunch Veeam Replica (VM Power Off)
  • Veeam Failover Now ---> start up VM DC03_Replica on new DC VMware.
  • Check & compare UUID on replicated DC3_Replica --> wmic csproduct get "UUID"
  • Check functionality of new DC3_replica + check replication and check health AD status.

                               nltest /dclist:domain.local

                                dsquery server -domain "domain.local" | dsget server -isgc -dnsname

                               DsQuery Server -o rdn -Forest

                               netdom query fsmo

repadmin /syncall or manual force replication from AD site & services

                               repadmin.exe /showrepl

repadmin.exe /replsum

                               repadmin.exe /replsum %computername%

                               dcdiag

                               netdiag.exe

 

DCDiag (part of WS03 SP1 Support tools) displays all information about Domain Controller information.

                dcdiag.exe /V /C /D /E /s:#DomainControllerName# > c:\dcdiag.log

NetDiag provides information about specific network configuration for the local machine.

                netdiag.exe /v > c:\netdiag.log

RepAdmin helps diagnose AD replication issues with WS03 and WS08 DC’s.

                repadmin.exe /showrepl dc* /verbose /all /intersite > c:\repl.txt

DNSLint is a Microsoft Windows utility that helps you to diagnose common DNS name resolution issues.

                dnslint /ad /s #IPAddressOfServer#

  • If you encounter problems from Veeam --->"Undo Failover" and turn on the old DC previously off.
  • Check event viewer for AD service related.
  • No problems found -->  Veeam --> "Permanent Failover"
  • Reactivation of the Netscaler DC3 side balancing node (optional)

Task 2:

  • DC2 - no FSMO only secondary DNS - perform the previous steps of DC3
  • Disable the DC2 node from the virtual service of the netscaler load balancer (optional)


Task 3:
DC01 all FSMO roles:


Moving FSMO role from DC1 to DC2 from PS Active Direcotry:

Move-ADDirectoryServerOperationMasterRole -Identity "dc2.domain.local" -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster
  • Waiting for replication check, check time domain etc.
  • Disable the DC1 node from the virtual service of the netscaler load balancer. (optional)
  • Full backup Active Directory (system state)dei 3 DC (VM Online).
  • Precautionary reboot
  • Shutdown DC1 Windows 2012 R2.
  • Incr backup (VM power Off).
  • Lunch Veeam Replica (VM power Off)
  • Veeam Failover Now ---> start up VM DC01_Replica on new DC Vmware.
  • Check & compare UUID on replicated DC1_Replica --> wmic csproduct get "UUID"
  • Check functionality of new DC1_replica + check replication and check health AD status.

nltest /dclist:doamin.local
dsquery server -domain "domain.local" | dsget server -isgc -dnsname
DsQuery Server -o rdn -Forest
netdom query fsmo
repadmin /syncall or manual force replication from AD site & services
repadmin.exe /showrepl
repadmin.exe /replsum
repadmin.exe /replsum %computername%
dcdiag
netdiag.exe
DCDiag (part of WS03 SP1 Support tools) displays all information about Domain Controller information.
dcdiag.exe /V /C /D /E /s:#DomainControllerName# > c:\dcdiag.log
NetDiag provides information about specific network configuration for the local machine.
netdiag.exe /v > c:\netdiag.log
RepAdmin helps diagnise AD replication issues with WS03 and WS08 DC’s.
repadmin.exe /showrepl dc* /verbose /all /intersite > c:\repl.txt
DNSLint is a Microsoft Windows utility that helps you to diagnose common DNS name resolution issues.
dnslint /ad /s #IPAddressOfServer#

  • If you encounter problems from Veeam --->"Undo Failover" and turn on the old DC previously off.
  • No problems found --> Veeam --> "Permanent Failover"
  • Check event viewer for AD service.
  • Reactivation of the Netscaler DC1 side balancing node. (optional)
  • Moving FSMO role da DC2 to DC1 + wait active directory replication or force it & check preparatory post fsmo roles move:

nltest /dclist:doamin.local
nltest /dclist:doamin.local
dsquery server -domain "domain.local" | dsget server -isgc -dnsname
DsQuery Server -o rdn -Forest
netdom query fsmo
repadmin /syncall or manual force replication from AD site & services
repadmin.exe /showrepl
repadmin.exe /replsum
repadmin.exe /replsum %computername%
dcdiag
netdiag.exe

  • Moving FSMO roles from DC2 a DC1 + wait Active Directory replication or force it & check AD status health post FSMO roles move.
Move-ADDirectoryServerOperationMasterRole -Identity "dc1.domain.local" -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster
  • Reconfigure NTP server on DC1

w32tm /config /manualpeerlist:"Ip your external time sync server" /syncfromflags:manual /reliable:yes /update
net stop w32time
net start w32time

  • Confirm that the server is configured correctly:

w32tm /monitor
w32tm /query /status

  • Run the command on two DCs that are not PDC DC02 and DC03.

w32tm /config /syncfromflags:domhier /update
w32tm /resync /nowait
net stop w32time
net start w32time
w32tm /query /configuration

  • Check that the configured time server is reachable from the PDC.

w32tm /stripchart /computer:"Ip your external time sync server" /samples:3 /dataonly

  • Check the correct domain time on the servers and clients.
  • Create a user, a group and verify that the objects are replicated on all DCs.
  • Create a file in the sysvol and verify the correct replication of the file on the sysvol of the DC partners.
  • Check Ip DNS forwarder.


Migration completed successfully .. cheers 😃

Wow, very detailled procedure.

I have to take some time to review (and understand :grin: ) all the steps.

Thank you.

Thanks @Link State for this very detailed post!

I confess MS AD is not my world any more. Did you migrate AD to a new OS version as well? I did not found this step in here? Did I miss it?

ohhh very good topic !!! very useful !!!

thank you !!

Excellent write-up! Worth binge sharing. Thanks for the efforts.

Thanks @Link State for this very detailed post!

I confess MS AD is not my world any more. Did you migrate AD to a new OS version as well? I did not found this step in here? Did I miss it?

No the Domain Controller migration was done "as is", no O.S or Forest \ domain functinal level upgrade was performed.
The entire Vmware infrastructure has been migrated to a new Vmware Datacenter. ;)

Thanks @Link State for this very detailed post!

I confess MS AD is not my world any more. Did you migrate AD to a new OS version as well? I did not found this step in here? Did I miss it?

No the Domain Controller migration was done "as is", no O.S or Forest \ domain functinal level upgrade was performed.
The entire Vmware infrastructure has been migrated to a new Vmware Datacenter. ;)

Please don't misunderstand my question: Why is this better than just move/migrate VMs to the new vSphere environment? This seems to be very complex. The only advantage I see is less downtime because of the replication. But for my understanding it should be no huge problem to shutdown a DC for a while (while migration for example).

… but as I said, I am not a AD-guy

Thanks @Link State for this very detailed post!

I confess MS AD is not my world any more. Did you migrate AD to a new OS version as well? I did not found this step in here? Did I miss it?

No the Domain Controller migration was done "as is", no O.S or Forest \ domain functinal level upgrade was performed.
The entire Vmware infrastructure has been migrated to a new Vmware Datacenter. ;)

Please don't misunderstand my question: Why is this better than just move/migrate VMs to the new vSphere environment? This seems to be very complex. The only advantage I see is less downtime because of the replication. But for my understanding it should be no huge problem to shutdown a DC for a while (while migration for example).

… but as I said, I am not a AD-guy

Given that the best solution from Microsoft is to create new VMs and promote them Domain Controllers and transfer FSMO roles.

That said, there are scenarios like mine, where this type of approach was not possible as it was mandatory to maintain the same FQDN and IP address due to application configuration problems.

Microsoft advised against demoting and promoting a DC with a different OS but with the same FQDN and IP, even if my environment was relatively small 3 DC one forest \ domain and not complex it could be done with the metadata cleanup procedure but the customer did not give the approval. So I have adopted the solution of VM replica.

 

it is a custom scenario dictated by the customer's needs. :wink:

Thanks @Link State for this very detailed post!

I confess MS AD is not my world any more. Did you migrate AD to a new OS version as well? I did not found this step in here? Did I miss it?

No the Domain Controller migration was done "as is", no O.S or Forest \ domain functinal level upgrade was performed.
The entire Vmware infrastructure has been migrated to a new Vmware Datacenter. ;)

Please don't misunderstand my question: Why is this better than just move/migrate VMs to the new vSphere environment? This seems to be very complex. The only advantage I see is less downtime because of the replication. But for my understanding it should be no huge problem to shutdown a DC for a while (while migration for example).

… but as I said, I am not a AD-guy

Given that the best solution from Microsoft is to create new VMs and promote them Domain Controllers and transfer FSMO roles.

That said, there are scenarios like mine, where this type of approach was not possible as it was mandatory to maintain the same FQDN and IP address due to application configuration problems.

Microsoft advised against demoting and promoting a DC with a different OS but with the same FQDN and IP, even if my environment was relatively small 3 DC one forest \ domain and not complex it could be done with the metadata cleanup procedure but the customer did not give the approval. So I have adopted the solution of VM replica.

 

it is a custom scenario dictated by the customer's needs. :wink:

Thanks!

Woow!

Quite a challenge, isn't?

Congrats for this work @Link State!

@Link State  Amazing work and share, thank you! I’m not in charge of AD in my company but it’s really interesting for my personal curiosity :)

I am a bit curious here, was there anything preventing you from doing a simple vMotion of the domain controllers to the new hosts?

Thanks for the share. informative post.

I am a bit curious here, was there anything preventing you from doing a simple vMotion of the domain controllers to the new hosts?

Yes, VMware HCL, vCenter 6.7 can’t pilot 5.5 hosts. Cross-vCenter started with 6.5 but it is a pain to setup. Starting 6.7 requirements got easier and better, more scenarios (shared or non-shared storage) appeared also.

Regards,

Oli

While I appreciate very much your problem-solving skills and imagination, the operation the promote/demote approach is enough, even with a re-use of the original IP. 

 

When the old one is back as a member server, and optionally had its IP changed if not powered off. Go on the new DC, execute locally or even from another DC ‘ntltest /server:targetdc /dsderegdns. Change your IP, reboot your DC and voilà! Each time a DC is started, ADDS DNS records are refreshed or created.

 

Note: check your local DNS if you don’t have temporary IP left overs. 

 

While I appreciate very much your problem-solving skills and imagination, the operation the promote/demote approach is enough, even with a re-use of the original IP. 

 

When the old one is back as a member server, and optionally had its IP changed if not powered off. Go on the new DC, execute locally or even from another DC ‘ntltest /server:targetdc /dsderegdns. Change your IP, reboot your DC and voilà! Each time a DC is started, ADDS DNS records are refreshed or created.

 

Note: check your local DNS if you don’t have temporary IP left overs. 

 

Thanks, sure, the problem was that on the domain controllers was installed a custom app (chilling I know), and the client didn't know how to reinstall it, replicating the DCs solved the problem of reinstalling and reconfiguring this custom web app to the customer...

While I appreciate very much your problem-solving skills and imagination, the operation the promote/demote approach is enough, even with a re-use of the original IP. 

 

When the old one is back as a member server, and optionally had its IP changed if not powered off. Go on the new DC, execute locally or even from another DC ‘ntltest /server:targetdc /dsderegdns. Change your IP, reboot your DC and voilà! Each time a DC is started, ADDS DNS records are refreshed or created.

 

Note: check your local DNS if you don’t have temporary IP left overs. 

 

Thanks, sure, the problem was that on the domain controllers was installed a custom app (chilling I know), and the client didn't know how to reinstall it, replicating the DCs solved the problem of reinstalling and reconfiguring this custom web app to the customer...

 

Now the picture is complete! Thanks for sharing!

 

Oli

Thank you @Link State grate topic

Thanks @Link State for this very detailed post!

I confess MS AD is not my world any more. Did you migrate AD to a new OS version as well? I did not found this step in here? Did I miss it?

No the Domain Controller migration was done "as is", no O.S or Forest \ domain functinal level upgrade was performed.
The entire Vmware infrastructure has been migrated to a new Vmware Datacenter. ;)

Please don't misunderstand my question: Why is this better than just move/migrate VMs to the new vSphere environment? This seems to be very complex. The only advantage I see is less downtime because of the replication. But for my understanding it should be no huge problem to shutdown a DC for a while (while migration for example).

… but as I said, I am not a AD-guy

> Did you migrate AD to a new OS version as well?

I had this question as I read through this excellent piece. But here is the answer, thank you @Link State for the thorough writeup.

Comment


Terms & Conditions