Another Successful In-Place Upgrade – Why Not Change How You Think?

by | Last updated 2022.10.29 | Published on 2021.10.28 | Blog, Guides, WSUS

I’ve successfully in-place upgraded a WSUS/PDQ Deploy/PDQ Inventory server from Server 2012 > Server 2012R2 > Server 2019 > Server 2022. It is a VM that is appropriately sized for the 3 roles that it has.

Caveats with WSUS:

  • After the in-place upgrades, you must launch the Post-Install tasks – you can do that easily from Server Manager or from the commandline [See Step 4 on the Reinstallation of WSUS]
  • SSL has been changed back to HTTP – you will need to re-modify the IIS Bindings and re-apply the wsusutil configuressl command [See Part 7 of my blog series, PowerShell steps 5 and 6 of the self-signed conversion method to get you back working! Don’t worry, these are common commands even if you have an internal CA certificate being used.]

In-Place Upgrades vs the Traditional Method of Build New and Migrate

Most IT people to this day recommend the “Build New and Migrate” vs the “In-Place Upgrade” method. The big question is Why? One answer is because “this is always how it has been done” or “this is the best way” or “you get less problems with a migration vs an in-place upgrade”. While 2 of the above actually do answer a “why” question, they don’t answer it well.

Think Differently!

If you have a good, working, and error free server, WHY would you want to spend more time migrating the applications and services to a new server on the latest OS? Do you wipe and reload or re-image Windows 10 each time a Windows 10 Upgrade happens (or every other/few depending on how you upgrade?)? Why? Do your home systems get wiped and re-loaded too?

If you have a server that OCCASIONALLY has errors or issues, then yes, re-think an in-place upgrade and opt for the migration path as this may help alleviate any issues in the future that you may have with the new server throwing the same errors.

Many systems also don’t ‘support’ in-place upgrades – like Exchange, AD, etc. Why? Because it’s usually the way ‘it always has been’. Does it WORK? – HECK YEA! (I’ve upgraded Active Directory Domain Controllers, Exchange 2013, Root CA’s, Subordinate CA’s, Application Servers, and many more). So why don’t they change their method of thinking? Because it’s easier not to.

Whenever you in-place upgrade a system, ALWAYS TEST the applications on them. I’ve had services that didn’t re-add (Unifi) that once added via the correct way (in this case, a java command to install the service) there’s no issue. I’ve had it where you have to re-install the application over-top of itself or ‘repair’ it from Add/Remove Programs (sometimes you have to go into the Registry and set the NoRepair or NoModify option from 1 to 0 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\<application> and re-open Add/Remove Programs).

Have a WORKING, RESTORABLE, Backup Before You Start

You should always have a backup before you work on an in-place upgrade – because things DO happen! I in-place upgraded 6 servers successfully in-place from 2019 to 2022 in succession and then 1 failed, and failed again. Having the ability to revert to a backup, or in my case, a snapshot of the VM AND a restorable backup from my 3rd party solution means that I have ZERO worry that if I can’t get it upgraded in my downtime window, I can always restore back to what it was just before, and take a crack at it another time.

 

If Your In-Place Upgrade Fails: DON’T PANIC!

Remember, you have that safety net of a restorable backup! So instead, let’s try to WORK THROUGH the errors.

Always first try and let Windows Self-Heal – run:

sfc /scannow
DISM.exe /online /cleanup-image /restorehealth

and in some cases where DISM fails, you may need the current server version media and specify it:

DISM.exe /Online /Cleanup-Image /RestoreHealth /Source:wim:E:\Sources\Install.wim:1 /limitaccess

And then run SFC again for good measure and it should say everything is now in good working order with no errors.

sfc /scannow

If there were issues that have now been fixed, then try your upgrade again.

You can use this bit of PowerShell code to grab the related log information:

$DesktopPath = [Environment]::GetFolderPath("Desktop")
findstr /c:"[SR]" $env:windir\logs\cbs\cbs.log > "$DesktopPath\SFCDetails.txt"
findstr /c:"CONX" c:\`$windows.~bt\sources\panther\setupact.log >"$DesktopPath\SetupDetails.txt"
Copy-Item $env:windir\logs\cbs\cbs.log "$DesktopPath\cbs.txt"

If you still are having trouble, download SetupDiag from Microsoft. While it was originally meant to help troubleshoot Windows 10 Upgrades, Windows Server upgrades follow the same upgrade method and this tool will help you figure out what is causing the issues.