Windows Server Upgrade - an overview

Windows Server 2025 is the most current server operating system. However, as every new system or software it still includes some bugs and introduces changes which may affect working deployment mechanisms.
With this article, I want to summarize some of the issues and changes I faced throughout my upgrade projects so that you hopefully do not have to scratch your head for long if you ever encounter one of these issues as well. 🤜🏼🤛🏼

Important: not all these topics are directly related to Windows Server 2025 (meaning WS2025 is not always the root cause), they may also happen in other upgrade projects.

Disk creation in automated setups

Windows operating systems can be deployed automatically in many ways. The basis for this is the so-called AutoUnattend.xml, in which the installation parameters are defined (e.g., number of partitions, server roles to be installed, specific settings, etc.).

Until now, it was possible to simply use the XML files from earlier versions for newer OS versions. However, this no longer works with Windows Server 2025—the installation gets stuck with an error message:

During testing, it became apparent that Windows Server 2025 apparently requires the creation of a recovery partition. In earlier versions, this was still optional. Unfortunately, attempts to create the recovery partition in the same way as the other partitions also failed.

The solution at the moment is a workaround: the partitions are no longer created as part of the XML code, but as a separate command line script using diskpart. It looks a little strange during installation (dozens of command line windows open and close quickly), but it works perfectly!

And the recovery partition is removed again after installation with another script (at least it's not needed in our case).

Windows Server 2025 ignores WSUS group policies

I came across this problem in a LinkedIn post. Companies that use WSUS to distribute updates typically use group policies to configure their systems. However, Windows Server 2025 appears to ignore the specified settings.

Curiously, Microsoft recently removed Windows Server 2025 from the list of “Applies to:” operating systems in the official article describing how to use group policies for Windows Update.

This could lead to the assumption that Windows Server 2025 will no longer support WSUS, especially since it was recently discontinued by Microsoft. However, this does not fit with the fact that WSUS also offers updates for Windows Server 2025 (referred to there as “Microsoft Server Operating System-24H2”).

The LinkedIn post links to an article (in German) that describes the reasons for this in detail. The article states that a few settings options specific to WSUS have recently been added. Of these, the following policy must be explicitly configured for Windows Server 2025:

Specify source service for specific classes of Windows Update

If this policy is enabled and all settings are set to “Windows Server Update Services,” Windows Server 2025 will adopt these and all other settings, such as the operating systems, as before. This therefore appears to be more of a bug than a silent departure from WSUS.

Inplace upgrade and ReFS disks

Recently, I upgraded a server which had an additional data disk for SQL Express and an application running on it. This data disk was formatted with ReFS as ReFS is more robust than NTFS. Obviously, upgrading such a server is a bad idea... The upgrade took unusually long (other servers took approx. 30-60 minutes, this server took 3 hours) and after the upgrade the application and SQL failed to start - "the file was not found".

I looked at the disk and at first glance everything seemed fine - all files were there. But when I tried to copy a file explorer threw the same error: "File not found". So, the upgrade obviously corrupted the disk. I did some research and found other articles stating that they experienced the same issue (also with former OS versions). The root cause seems to be incompatibilities between ReFS versions which result in file corruption.

So, if your server uses ReFS disks, DO NOT use an inplace upgrade. Instead, install a new server or move files to a new NTFS formatted disk, if possible (i.e., mount the disks on another server and copy everything to the new disk).

Networking issues, Part 1 - legacy network interface

In some environments, the customer used the E1000 Intel card for his VMware virtual machines. While is it generally recommended to use VMXNET3 (better performance, higher bandwidth, etc.), some admins may still rely on the old card.

In these environments I encountered a strange issue when demoting Domain Controllers. As part of the process, the virtual machine must be reboot. After the reboot, the virtual machine was not reachable anymore - no network connectivity at all, although nothing was changed in the networking configuration.

We did the usual - restarted network adapters, restarted the NLA service (known bug since Windows Server 2016), but to no avail. The only thing which helped was to replace the E1000 network adapter with a VMXNET3 adapter.

Important: we removed the old network adapter not only in VMware but also in the operating system by doing the following:

• Open a command line and enter the following commands:

set devmgr_show_nonpresent_devices=1
devmgmt.msc

• Enable "Show hidden devices" under "View"
• Remove the old network adapter from "Networking adapters"
• Reconfigure the new network adapter with the networking configuration from before

The server immediately gained network access again and we were able to continue the demote process.

Networking issues, Part II - the good old NLA bug

The Network Location Awareness (NLA) service is meant to recognize which network the server is currently located in so specific firewall rules can apply. On Domain Controllers this service has a bug which is known at least since Windows Server 2016 and is still not fixed in Windows Server 2025 (however, I did not experience this issue with 2025 yet).

After reboot, the NLA service recognizes a wrong network so the Domain Controller applies the wrong firewall rule set and is not reachable anymore. There are several ways to fix this manually:

• Disable and enable the network adapter (only if accessing the server via console and does not work very well)

PowerShell (good when accessing the server remotely):
Get-NetworkAdapter | Restart-NetworkAdapter -Confirm:$False

However, these fixes are only temporary as the next reboot may cause this issue again. These ideas can fix the issue completely (maybe in combination):

• Set the NLA service start to "Delayed"
• Add additional services dependencies to the NLA service like DNS
• Implement a local script which restarts the network adapter after every reboot

Networking issues, Part III - DFS replication issues for Active Directory

When upgrading the Domain Controllers (by installing new ones) I recently encountered a weird issue with DFS replication which led to the scenario that the old Domain Controllers could not be demoted as they were unable to locate a valid replication partner.

When looking at the DFS replication event log, the following error (Event 4012, DFSR) was presented:

The DFS Replication service stopped replication on the folder with the following local path: C:\Windows\SYSVOL\domain. This server has been disconnected from other partners for n days, which is longer than the time allowed by the MaxOfflineTimeInDays parameter (60). DFS Replication considers the data in this folder to be stale, and this server will not replicate the folder until this error is corrected.

There is a long and a short way to solve this issue:

• Long way: do a non-authoritative DFS restore
• Short way: add the mentioned registry key with a higher value than given in the error message and restart the DFS replication service

You should see additional entries in the event log stating that the server initiates the replication again. Depending on the site configuration and replication intervals the demoting should work again.

Of course, this also can indicate a larger issue in your environment. Before you implement this workaround be sure that your domain controllers are fine and replication is only affected on this single domain controller.

Upgrading NPS with Azure MFA extension resets the extension

Some customers use the NPS (Network Policy Server) server role to add Azure MFA for VPN and Wifi connections. To connect NPS to Entra ID, the Azure MFA NPS extension is used. The extension is configured via a PowerShell script.

Upgrading such a server runs smoothly. However, after the upgrade, the server no longer communicates with Entra ID. Therefore, the NPS extension must be reconfigured using the script.

Note 1: If the customer is still using an older version, it may still use the MSOnline PowerShell module instead of Microsoft Graph. In this case, the NPS extension should be updated BEFORE the upgrade, as installing the Microsoft Graph module takes some time.

Note 2: If the server is installed in German, the configuration script must be adjusted manually. The service principal “NETWORK SERVICE” is hard-coded in the script and must be replaced with “NETZWERKDIENST”. Otherwise, the script will not be able to perform an important configuration step.

Upgrading non-English ADFS servers with english language pack

Some customers use Active Directory Federation Services for connecting external systems and users to their Active Directory. While it is not recommended to use ADFS for Entra ID authentication anymore there are still other use cases for ADFS.

The issues I encountered are specific to customers which do not install their servers in English language (as recommended). In these cases, it is highly recommended to at least enable the english language pack for the ADFS servers as some strange issues may appear, if not (service intermittently fails to start, no real error message, connection to database fails, etc.).

However, after upgrading such a server, the operating system language gets reset to the original installation language (German). To quickly re-enable the English language pack again it is advised to keep a local copy of the language pack ISO. If the server has Internet access, the language pack can also be downloaded via the settings app.

Also check, if the service account inside SQL Server got reset to the installation language. I cannot tell how this could happen but in my case the account was also reset to German which caused the ADFS service to fail during startup.

And, do not forget to upgrade the ADFS farm itself:

Invoke-AdfsFarmBehaviorLevelRaise -Confirm:$false

Invoke-AdfsFarmBehaviorLevelRaise -Confirm:$false

Liked this article? Share it!

• Share on LinkedIn
• Share on Bluesky
• Share on Facebook
• Email this Page
• Share on Reddit