Can someone double check my DC migration check list please :-)

[TwistedHelixis]

I need to migrate our one and only DC from Server 2012 to Server 2019. They are both VMs on a 2019 Hyper-V host.

 

Its been a long long time since I last did this.

Hopefully someone can look over my migration check list and let me know if it looks OK or not.

 

 

Set static IP on new server

 

Set time services

 

Check if old server is FRS or DFRS - Needs to be DFRS

 

Join the new server to existing Active Directory domain

 

Install Active Directory Domain Services role

 

Promote the new server to a domain controller

 

Point the old DC servers DNS IP setting to the new DC

 

Check the new server has netlogon and sysvol folders

 

Move FSMO roles to new server

 

Check FSMO roles on new server

 

Update DHCP with new DNS server info

 

Demote old domain controller

 

Move DHCP from old server to new server

 

Raise the domain and forest functional levels on new server

Edited October 14, 2022 by TwistedHelixis

[XiJ]

I generally prefer a clean install - but would an in place upgrade not work here ?

[MatthewL]

Create new server, promote it up and check its replicating.

 

Move DNS & DHCP and let things settle and remove roles off old one. Remember to update anything that uses DNS statically and update DHCP scope with relevant DNS enteries and things like firewall, switches etc.

 

Then after a week or so demote the old one after ensuring all roles such as GC are transfered over.

[TwistedHelixis]

but would an in place upgrade not work here ?

I did think about that, but have decided to migrate. I read a post where the upgrade seemed to work for a few weeks and then crashed out. Reading that put me off. If somethings going go wrong with the switch over, I would rather it went wrong while I was actually doing the switch, not x time later.

 

Move DNS

Silly question, but doesn't that move when I promote the new server?

 

Does my list above look OK?

[Davit2005]

Personally I've always kept the same IP addresses but used different names.

 

2 DCs migrate one at a time, give the new DC a temp IP address then change the old DC to a different temp IP address once DNS, DHCP is setup. If you keep different IP address for new DCs you'd need to potentially update everything that has manual DNS IP settings. I always leave a day before demoting and run DC Diag before start, during i.e. promoting a server to DC and when finished too.

 

DNS wise, I always have setup Active Directory integrated zones, so whilst you still need to install the DNS role it is quite straight forward.

Edited October 17, 2022 by Davit2005

[TwistedHelixis]

Personally I've always kept the same IP addresses but used different names.

So at which point in my list would you change the old DC's IP address to something else and then use that IP on the new server? I assume just before demoting the old server, but wanted to check.

[chaplic]

I'd take a copy of your VMs first, standup on an isolated PC and test it all first.

[TwistedHelixis]

I'd take a copy of your VMs first, standup on an isolated PC and test it all first.

That will give me something to do over the half-term :-)

[dmj]

Comms.

 

You should communicate with your users when a major change is going to happen, that no downtime is expected but there is a rollback plan (you should add that to your Techincal Implementation Plan).

 

It gives them confidence and helps them understand changes are afoot and that you're not sitting around all day picking your nose.

[Boredguy]

Comms.

 

You should communicate with your users when a major change is going to happen, that no downtime is expected but there is a rollback plan (you should add that to your Techincal Implementation Plan).

 

It gives them confidence and helps them understand changes are afoot and that you're not sitting around all day picking your nose.

 

Well if the network already has 2 DC's in place, not really a need to let users know, as adding a new DC doesn't impact them, and migrating DHCP between servers is reasonably painless as well these days and stations will only worry about that when they need to contact it again.

If there was just a single DC.. yep letting them know there may be downtime is fine... but adding and moving FMSO roles etc should be simple.

 

DNS these days can be AD Linked so adding a new DC with DNS role automatically picks up the zones and conditional forwarders without needing to do anything extra.

[dmj]

Well if the network already has 2 DC's in place, not really a need to let users know, as adding a new DC doesn't impact them, and migrating DHCP between servers is reasonably painless as well these days and stations will only worry about that when they need to contact it again.

If there was just a single DC.. yep letting them know there may be downtime is fine... but adding and moving FMSO roles etc should be simple.

 

DNS these days can be AD Linked so adding a new DC with DNS role automatically picks up the zones and conditional forwarders without needing to do anything extra.

Even if downtime isn't expected it's good to let people know if services are at risk. I've always informed users about changes to a production environment, it's good for relations. We keep griping about how NM's don't get enough recognition for the work we do and decent comms on changes is one way of helping to let users know of (security/performance/etc) improvements.

[TwistedHelixis]

You should communicate with your users when a major change is going to happen

Always do :-)

 

By the way this is not my first DC migration, I have done about 25 over the years, but they were all pre server 2012 R2, so its been a while, hence wanting my (hastily put together) check list double checked.

[TwistedHelixis]

The only bit I have never done is use the same IP address as the old server, so I'll need to do some testing on where that should get done in my list

[TwistedHelixis]

Thinking about it, we only have a couple of devices that might have fixed IP settings, so I might just promote the server, leave it running alongside the other DC for a while, turn off the old dc and see if anything stops working, if all good turn it back on and demote it.

 

If I do decide to set the new DC IP to the old server, what is the sweet spot in my list to do this?

 

Promote the new server to a domain controller

Point the old DC servers DNS IP setting to the new DC

Check the new server has netlogon and sysvol folders

Move FSMO roles to new server

Check FSMO roles on new server

Update DHCP on old server with new DNS server info, so clients get new DC info

Demote old domain controller

Move DHCP from old server to new server

Raise the domain and forest functional levels on new server

Edited October 17, 2022 by TwistedHelixis

[Davit2005]

How many DCs would you normally have?

 

I'd prob say once you have the DHCP migrated over. I've always gone down the route of having a split scope and never used windows DHCP failover.

[Boredguy]

The only bit I have never done is use the same IP address as the old server, so I'll need to do some testing on where that should get done in my list

Its sometimes handy to switch the IP back to an existing one when the DNS role has been removed, especially if you've lots of devices with static IPs pointing to that DNS box, but it's nothing too major.

[mrstrong]

Hi @TwistedHelixis , how did it go ? I'm in an almost identical situation:

 

Only one DC (Server 2012r2 hyper-v VM) and I have created a new Server 2019 hyper-v VM on a new physical hyper-v host

ready to become the DC.

 

Don't suppose you could share your "final" todo / check list as I've never done this before

[TwistedHelixis]

Hi @TwistedHelixis , how did it go ? I'm in an almost identical situation:

 

Only one DC (Server 2012r2 hyper-v VM) and I have created a new Server 2019 hyper-v VM on a new physical hyper-v host

ready to become the DC.

 

Don't suppose you could share your "final" todo / check list as I've never done this before

Yep, sure. Busy now but will share later [emoji4]

[Davit2005]

Its sometimes handy to switch the IP back to an existing one when the DNS role has been removed, especially if you've lots of devices with static IPs pointing to that DNS box, but it's nothing too major.

 

Yep defo vouch for this if you have any services/servers using DNS. I've done loads of DCs this way temp IP for new server, then before change over, use different temp ip for original server then change new server to original IP. I also run dcdiag at each stage.

[mrstrong]

I was using this web article https://lazyadmin.nl/it/add-domain-controller-to-existing-domain/

but he doesn't cover any of the extra stuff like DNS / DHCP migration. Glad I found this thread !

[Koldov]

Have you made your "new Server 2019 hyper-v VM" a DC at all yet?

 

Someone will correct me if I'm wrong, but I would personally promote it to a DC and get it all replicating nicely for a while, then you can transfer all the roles to it and make it FMSO/PDC, then after another grace period, demote the old one. IIRC once DNS is installed (as creating a DC it will replicate from the original to all DCs) nothing needs to be done to 'transfer it'. I don't think there's much more to it, so it should be relatively straight forward and pain-free.

 

It's been a while since I've done it (and sorry I don't have a list since I basically winged it), the only trouble I had was actually DNS (for the static clients), I couldn't use the previous DC's I.P. address as the new VM DC was on the host which was the original DC (and it was still in service with other roles - I mean I somehow probably could have, but I didn't need extra stress/hassle of an extra thing)!!

[TwistedHelixis]

on't suppose you could share your "final" todo / check list as I've never done this before

 

 

These are the basic steps I completed.

 

I am away for the next week, but if you need more info about any of the steps, let me know and ill help you late next week.

 

Set static IP on new DC

Set external time service

Check if old server is FRS or DFRS - Needs to be DFS-R.

Run DCDIAG on old DC

Join the new server to your domain

Install the Active Directory Domain Services role

Promote the new server to a domain controller

Check DNS forwards and scavenging settings

Update NIC settings on both DCs. Primary DNS = pointing to other DC, secondary = itself 127.0.0.1

Add new server to DHCP server options

Update devices with fixed IP addresses with new DNS info

Move Flexible Single Master Operation (FSMO) roles to new server

Move DHCP from old server to new server

De-authorise the old DHCP Server

At this point I tuneded of the old server to see if clients couls still log in. Whan all good I turned the old DC back on.

Remove old DC server from new servers DHCP scopes

Demote your old domain controller

Raise the domain and forest functional levels on new DC

[mrstrong]

well my todo list is getting quite long and with only two weeks to go (part time / term time only)

I'm tempted to leave this till after hols as just checked and 2012r2 not EOL until October 10, 2023.

I may take your approach koldov e.g. just promote it before the summer break and leave DNS / DHCP

Not sure I want to take a brave pill right now

[mrstrong]

managed to do the promotion ok I think (so now have two DCs replicating ).

 

Only thing I noticed is a dcdiag gives me scary warning :

Starting test: SystemLog
        A warning event occurred.  EventID: 0x80040020
           ...
           Event String: The driver detected that the device \Device\Harddisk0\DR0 has its write cache enabled. [b]Data corruption may occur.[/b]

 

Is this anything to worry about ?

 

This DC is a server 2019 VM with one disk. Host is server 2022 with one disk (dell raid 10)

 

The VM's disk properties-policies has "enable write caching" ticked and "device does not allow write-caching setting to be changed"

So it must be managed by hyper-v or raid controller ?

Edited July 19, 2023 by mrstrong

[TwistedHelixis]

If you have recently rebooted the server I would probably ignore any errors for a few days.

 

I think that error is related to the VM disk. All my servers display that error and have done for 12 years.

 

I'll keep my eyes open for others posting back, just in case its something I also need to look at.