- How to use VMware vSAN ReadyNode Configurator - Fri, Dec 17 2021
- VMware Tanzu Kubernetes Toolkit version 1.3 new features - Fri, Dec 10 2021
- Disaster recovery strategies for vCenter Server appliance VM - Fri, Nov 26 2021
Usually, Active Directory is replicated among several members to enable redundancy. However, I've often seen small IT shops running a single copy of AD with almost no backup or other protections. If you want to migrate Microsoft AD on a single server, you can choose between an in-place upgrade and a clean installation of Windows Server 2019, with reinstallation of all your existing applications.
In-place upgrade vs. new install
There is no single way to approach these issues; it always depends on your situation. In addition, there is always an unknown variable which could mean your applications won't work after an upgrade.
Note: You could ask the relevant vendor if a particular application has been tested under Windows Server 2019, or you can test whether it is working simply by installing a clean copy of Windows Server 2019 as a virtual machine and then test your critical applications.
Microsoft published a detailed guide to an in-place upgrade for systems running Windows Server 2008 R2, however you should always check whether the in-place upgrade will actually works at the end. For example, you could check with your hardware manufacturer if your old server supports WS 2019.
It is not possible to do a direct, in-place upgrade of Windows Server 2008 R2 to Windows Server 2019. If you want to do an in-place upgrade, the process would require three steps:
- First step – Upgrade from Windows Server 2008 to 2012 or 2012 R2.
- Second step – Upgrade from Windows Server 2012 to Windows Server 2016.
- Third step – Upgrade Windows Server 2016 to Windows Server 2019.
That's quite a lot of upgrades. In addition, as being said, the hardware on which your old Windows Server 2008 R2 is installed would have to support Windows Server 2019.
There is another option from Microsoft which basically extends the support for Windows Server 2008 R2 with security patches and updates. However, you would have to migrate your servers to Azure for three years. This might be an option for customers not willing to invest money in new hardware.
Active Directory 2008 R2 upgrade to 2019 checklist
We'll try to provide a detailed checklist, but as I said earlier, the upgrade scenario always depends on your specific situation, the application set you're running, and support for those applications on Windows Server 2019. This checklist is by no means intended to be a detailed, step-by-step guide; rather, it only gives you an overview of the issues you should consider.
Let's assume we're doing a single server update and that we do not have any other server with a copy of AD. I also assume you have bought new hardware so your physical server has the latest drivers and firmware to run Windows Server 2019.
- Your Microsoft AD is working – Ensure your AD is working properly and that nothing is broken before you start the upgrade process. Many command line options and GUI tools are provided by Microsoft.
- Backup – It is highly recommended to create a backup of your Windows Server 2008 R2. You can use many free backup tools. Just be sure to stop any enterprise application that might be running (MS SQL Server, Exchange, and any other database servers). This helps to make your backup application consistent. Ensure your backup tool also backs up the system's state as well as Active Directory.
- Update AD schema – Every new operating system introduces changes to your AD schema to allow for new functionality and features. Therefore, you have to update your AD schema before the upgrade to Windows Server 2019. This happens when you promote the 2019 server as an additional domain controller. There is no automatic rollback scenario for a schema update. If it goes wrong or if you applied it by mistake, you'll have to go back and restore your domain controller. You can find a detailed guide how-to update AD schema here.
- Install and configure Windows Server 2019 – This is perhaps the easiest part. Ensure your disk size and partition layout suits your needs and that your IP addressing scheme suits your environment. Make sure you create static DNS records (forward and reverse) on your DNS server.
- Promote Windows Server 2019 to DC – You will need to promote this newly installed system to be an additional domain controller within your domain. This is a common scenario of adding an additional domain controller to the domain. Then restart the system and check whether everything works as expected.
- Migrate resources – If any shares are defined on the old server, you'll need to migrate your shares and files to the new Windows Server 2019. I recommend using the Storage Migration Service, which allows you to migrate and transfer all files and configuration settings (shares, NTFS permissions, and ownerships) from older Windows Servers to new operating systems.
- Wait – Observe the behavior of your AD for at least a week. More than once, I've seen strange behavior occur after a day or two. Waiting allows you to detect any anomalies and gives you the chance to fix them before you decommission the old server.
- Move FSMO roles – The next step is to move Flexible Single Master Operation Roles (FSMO) to the new Windows Server 2019. There are many guides available on how to do this.
- Demote Windows Server 2008 R2 – Here, Microsoft AD is properly uninstalled from Windows Server 2008 R2. Microsoft has step-by-step guides on how to do this here. If errors occur and the assistant fails, use the force switch; however, only do this as a last resort because you'll have to manually "clean" AD of orphaned objects. It's possible and not that difficult, but it must be done with precision. Once this step is done, leave the server as a member server for a couple of days and observe it to ensure everything is working.
- Decommission Windows 2008 R2 – You can now disjoin the server from your domain. It's not recommended to keep it in your network once it cannot be no longer patched and protected against malware or hackers. Keeping this server on your network makes your network more vulnerable.
This was, in essence, a small guide for migrating a Windows Server 2008 R2 single host with Active Directory to Windows Server 2019. These instructions only apply to situations where you do not want to do an in-place upgrade. Personally, I prefer doing it this way as you can easily manage downtime (if any). If you do an in-place upgrade and something goes wrong (firmware/drivers) and your server won't reboot, you'll have to initiate a bare metal restore, which might take quite a while depending on how much data was stored on that server.
Subscribe to 4sysops newsletter!
If you do a side-by-side migration, you also have redundancy; you'll have time to observe your systems, and if something does not work, you can roll back the changes and start again.
Want to write for 4sysops? We are looking for new authors.
nice post there. I noticed two points:
– it seems there is unfinished sentence at Update AD schema "You can find a detailed guide how-to update AD schema"
– actually, when you promote Windows Server 2019 to DC, it will do the schema update automatically for you, there is no need to do it in advance.
Hi Leos, thanks for pointing this out. True, the schema has to be updated before the promotion of the WS 2019.
Actually I was doing this today morning, just few minutes before the article poped up. All went smooth, the process is quite simple. Two more to do until end of the year.
I also prefer the clean install way, never do in-place upgrade.
Hello all, I don't know if it is a common issue but when I updated in-place a bunch of servers from Windows server 2008R2 to Windows Server 2012R2 there was an issue on Network Adapters with assigned static IP address changed to dhcp. It was the only issue that I discovered in the Windows Server upgrade in-place process.
I saw this kind of strange behavior several times, what usually helped was to remove all ghost adapters in Device Manager and then reset all IP configuration with commands
Hi Leos, I will try next time with your suggestion.
PS: I guess you know this, but just to make the info totally complete – this command has to be executed before starting the device manager, otherwise it will not show the ghost stuff
and then I usually start it with devmgmt.msc from the same command line.
If you're coming from 2008R2 there's a good chance that FRS is still being used for replication. 2016/2019 don't support that and the conversion process to DFS-R needs to be performed prior to upgrading.
Today morning I have installed clean VM with 2008R2 and setup brand new domain. Second VM was clean W2019 and I had totally no issues with the process. No special steps were required. 🙂
Totally agree. Sometimes you just have an AD which is not working as it should. The upgrade process depends on that! Make sure to verify all possible logs and find out what's wrong before the upgrade. It saves tons of time.
Anyone please help, I am getting following error while upgrading Additional Domain Controller, from Windows Server 2008 R2 to Windows Server 2012 using In-place upgrade method.
"Setup cannot continue. Your computer will now restart, and your previous version of Windows will be restored."
There are several different problem with this error., you should have a log with more information about this error.
Maybe can help this article: Upgrading to Windows Server 2012 – Part 3
hi … i got 6 servers.. different site(site A: 2, sitb:2 sitec:2)
One server is already done clean install 2019 n sysvol migrated.( this is in site A)
FSmo is still controlled by old 2008r2 at site B.
.. i want to clean install on same hardware from windows 2008r2 to 2019. One of my DC already 2019 (sysvol dfrs). fsmo is still on old server2008r2. How do i move forward?
Replication is going through all Domain controllers.
Do i have to export dhcp scope for each DC and Roles then import it again?
you just need to transfer the FSMO roles to the 2019 controller and then you can decommission and replace the other controllers. You can use this document to see how to transfer the FSMO roles or google it up.
For DHCP I assume you have different subnet on each site and both DCs on each site have also DHCP installed? You could use following Powershell commands:
Hope that helps.
How many hours should it take to migrate active directory from 2008 to 2019? I'm trying determine how much a reasonable charge would be for a 3rd party to do this.
That greatly depends on your setup. How many DCs you have, how many locations, etc.
If I take a single DC customer, deploy new DC 2019 and do all the transfer it might take like 3-4 hours of real work? Then of course you should follow all the guidelines to wait if all works well, etc. before you decomission the old DC.
I am doing a 2008 to 2019, is that possible?
i saw a site indicating that it should be done with a middle step, ie. 2008 to 2012 r2 and then to 2019, is that correct?
I tried upgrading to 2016 in a sandboxed copy, but after all objects were synced, and I promoted the 2016 as master of all roles, the old 2008 kept replying to ping domain.local, and when logging on the clients kept using it.
The 2008 server, without FSMO roles, can no longer authenticate users. After double checking that all FSMO roles were successfully migrated, you should decommission this server from the network.
We ran netdom query fsmo that confirmed that all roles were on DC2016.
Then the following day, we demoted the 2008 server, and shut it down, whereafter all clients could not log on…
When we tried to ping domain.local from a client it wanted answer from the old server. I tried flush dns from that client, but still insisted on an answer from the old DC.
The clients already logged on in the morning with all FSMO roles on the 2016 server, indicated that they had used the 2008 server as logon server anyways…
Seems you have DNS issue there. What do you mean by client wanted asnwer from old server for the ping? Client pings what DNS gives.
Sorry, that was a typing error. When we ping domain.local, it is the old server replying, not the new master.
So I then powered the old server off, and then noone could login, and ping domain.local was still resolving to old DC.
We rolled back everything, and have started over, so I do not have the issue right now, I was looking for knowledge in case we run into the same error again.
Then you have a DNS issue. Your DNS server is giving the client back IP of the old server, instead of new one. Do you have the new DNS configured on client computers? If your DNS server is also your new DC and client queries it, it should first answer with its own IP, rather than other DC.
I would recommend to start nslookup on the client and see what DNS server replies and what are the replies.
Are you performing in-place upgrade of the 2008 DC? I would not do that, unless you have a very specific reason. Deploy clean W2019, add it to the domain, promote it to DC and then start decomissioning the old one. Not clear from your text.
Why would server without FSMO roles be unable to authenticate users? Its normal to have multiple DCs, only one is holding the roles and others normally authenticate users 🙂
True, don't know what I smoked when writing the reply lol… Perhaps I thought it was already a member server only? Go figure. Thanks Leos….
Haha nice one 😀
I think the DHCP server scopes had the old 2k8 server listed at the DNS server. Removing 2k8 DC and adding the new DC should resolve the issue.