In Place Upgrade KB ID 0001895
Problem
An in-place upgrade of a Windows Server, where you update an existing server installation to a newer version without reinstalling from scratch, can be a powerful way to bring older infrastructure up to date without the lengthy process of rebuilding a system and restoring data. The allure of this method lies in its simplicity and time efficiency; theoretically, you can go from, say, Windows Server 2016 to Windows Server 2022 with much less downtime, keeping configurations, applications, and user data intact. This can be especially appealing in scenarios where budget or time constraints make a full migration impractical, or for environments where a server holds critical roles that are complex to reconfigure from scratch.
However, while in-place upgrades have their perks, they aren’t without pitfalls. For starters, there’s always a risk of compatibility issues, especially if the server runs legacy software that might not play nicely with the new OS version. Performance problems can also arise, as remnants of old files and configurations may lead to a less than optimised system, compared to a clean installation. Additionally, any existing issues on the server, such as misconfigurations, registry bloat, or malware, can carry over to the new version, potentially causing instability. Therefore, before deciding on an in-place upgrade, it’s essential to weigh these pros and cons carefully, considering both the potential gains and risks based on your environment and long-term plans.
As I’ve previously stated, I prefer to do in place upgrades, If you have less than 50 servers and an IT support team, you may want to plan a clean install and data migration, but there comes a point where that’s simply not practical. My firm looks after more than 10 thousand Windows servers, and when a ‘wave’ of them goes outside of supportability – We either stop supporting them or offer and in-place upgrade.
Windows Server In Place Upgrade Paths
| Current OS | Upgrade Path to Windows Server 2022 | Upgrade Path to Windows Server 2025 |
| Windows Server 2008 | Upgrade to Windows Server 2008 R2 → Upgrade to Windows Server 2012 R2 → Upgrade to Windows Server 2019 → Upgrade to Windows Server 2022 | Upgrade to Windows Server 2008 R2 → Upgrade to Windows Server 2012 R2 → Upgrade to Windows Server 2019 → Upgrade to Windows Server 2025 |
| Windows Server 2008 R2 | Upgrade to Windows Server 2012 R2 → Upgrade to Windows Server 2019 → Upgrade to Windows Server 2022 | Upgrade to Windows Server 2012 R2 → Upgrade to Windows Server 2019 → Upgrade to Windows Server 2025 |
| Windows Server 2012 | Upgrade to Windows Server 2012 R2 → Upgrade to Windows Server 2019 → Upgrade to Windows Server 2022 | Upgrade to Windows Server 2012 R2 → Upgrade to Windows Server 2019 → Upgrade to Windows Server 2025 |
| Windows Server 2012 R2 | Upgrade to Windows Server 2019 → Upgrade to Windows Server 2022 | Upgrade to Windows Server 2019 → Upgrade to Windows Server 2025 |
| Windows Server 2016 | Direct upgrade to Windows Server 2022 | Direct upgrade to Windows Server 2025 |
| Windows Server 2019 | Direct upgrade to Windows Server 2022 | Direct upgrade to Windows Server 2025 |
| Windows Server 2022 | NA | Direct upgrade to Windows Server 2025 |
Note: Server 2025 information is not official at time of writing, information was provided my Microsoft Copilot.
Solution : In Place Upgrade
In Place Upgrade Planning and Pre Upgrade Steps
As well as making sure you have the compute and storage requirements (of the OS that you are upgrading to), make sure your hardware and/or Hypervisor supports the target OS. Then you have things to consider.
- Roles And Features.
- Microsoft Applications.
- Third Party Applications.
Roles and Features: these are add-on components to the OS that you can enable (add) or disable (remove). Some common ones like DNS server or DHCP server, we just accept and don’t even worry about, but what about roles like certificate services? or a feature like NDES? What if the server is a domain controller? I’ll attempt to answer SOME of those questions below, but this is another reason why you should check, research, and test before upgrading
Show all Roles and Features With PowerShell
[box]
Get-WindowsFeature
[/box]
Microsoft Applications: Here I’m talking about things like Microsoft Exchange, Microsoft SQL, Microsoft Teams etc. Each one of those have their own dependancies OS requirements an upgrade paths that you may need to take into consideration. My personal preference is to migrate these applications onto new clean servers rather than in-place upgrade. I’ve done two in place upgrades of Exchange on the test bench and both of those were 100% successful, I’d be less happy doing them in production, and I’ve got a lot of articles showing you how to upgrade and migrate Exchange, I suggest you look there first!
Third Party Applications: This will vary from use case to use case, but consider your AV and security products, do they support the new OS? Does you backup and replication software support the new OS. That’s before you look at you line of business or back office applications like print management software, or the software that controls your building access for example.
Show all Installed Software With PowerShell
[box]
Get-WmiObject -Class Win32_Product
[/box]
In Place Upgrade ‘Pre-flight checks’
Most servers these days are virtualised, and time spent on reconnaissance is seldom wasted, If you are considering in place upgrading anything, I would urge you to clone those machines, sandbox them, and perform the in place upgrade in isolation, this will give you a change to do some functional (post upgrade) testing of both the server OS, its installed roles and any third pert applications.
As with all things infrastructure, you’re only as good as your last backup, before doing anything MAKE SURE you have a reliable (tested!) backup. Not just for the server you intend to upgrade but for any server that has a service or software dependency on the server you intend to upgrade.
Ensure the upgrade server is FULLY UPDATED before proceeding.
If the server is virtual, we also have the advantage, to take a snapshot prior to upgrade. (You can even clone a copy and keep it on standby) .
In Place Upgrade Process
Well it’s 95& preparation and 5% execution, the actual upgrade process is alarmingly simple. Present the installation media ISO to the source server, (or copy the files to the server and run setup.exe)
At the welcome screen > Next > At this point the system may take some down getting update’s > Enter the Windows activation code for the new server OS > Next > Select the version you want to install, remember if you want a server with a GUI interface, select the Desktop Experience option > Next.
At the EULA screen > Accept > Select “Keep files settings and apps” > Next > Install.
At this point the upgrade will take place, the server may reboot, but the upgrade process will continue.
When complete, you will be looking at a login screen, simply authenticate with the same credentials as before.
In Place Upgrade of Domain Controllers
Yes it’s possible, yes I’ve done it multiple times, if all the server is doing is performing Active Directory domain services and other common roles like DNS and DHCP, then I would not bother in place upgrading a domain controller, I’d simply build a fresh one, then decommission the old one (possibly needing to migrate FSMO roles)
But I’ve said its possible, just beware you may come across this error during the upgrade.
Active Directory on this domain controller does not contain Windows Server {version} ADPREP / FORESTPREP updates
This one is pretty much self-explanatory, and makes complete sense if you’ve spent any time deploying domains controllers! Well of course it doesn’t! Think about it if this is the first domain controller with the new OS in the domain, the schema has not been updated for that version of domain controller, which would happen if you were installing a DC from scratch. Here there’s only one server in the domain, and I’m on it. DON’T CLOSE THE UPGRADE WINDOW.
Open a administrative command window and change to the D:\Support\Adprep directory, run adprep.exe /forestprep and when prompted press C {Enter} to continue.
In Place Upgrade of Servers Running Certificate Services
Can you do this? Yes – Even if you have a multi-tier PKI deployment. see here I’ve personally done this twice (Server 2016 > Server 2022 and Server 2019 > Server 2022) and both were 100% successful. You can of course perform a traditional migration of Certificate Services to another server.
In Place Upgrade of Servers Running DHCP
I would not even worry about this, if you wanted to migrate a DHCP scope to another server it’s easy as peas. But in place upgrade of a DHCP server is not a concern. Even if they are performing DHCP HA
In Place Upgrade of Servers Running NPS (Network Policy Server)
I’ve done this successfully, if you wanted to migrate this role manually then simply see the following article Migrate NPS Server.
In Place Upgrade of Servers Running RDS (Remote Desktop Services)
Whilst supported be aware that if you upgrade you RDS licensing server, ensure you have CALs/Licenses (or SALS if you’re SPLA licensed) that support the new version of Windows. e.g. 2016 RDS CALs will work with Server 2019 but will not with Server 2022. If you have problems ‘post upgrade‘ delete the following folder “\windows\system32\lserver ” then relicense correctly with new CALs/SALs.
Invitation
If you’re reading this and considering an in place upgrade there may be a role or feature, or piece of software your server is running I’ve not covered. If so please bookmark this article, and return later, then post below what OS you upgraded from and to, and what Role/Feature/Software you were running. Was it a seamless procedure, or did you encounter a problem, error message, of complete failure? Please post your follow ups below to help the next person.