Since the introduction of Windows Server 2003, administrators have had the option to migrate roles and features to newer Windows Server versions using the Windows Server Migration Tools (WSMT). Despite not receiving recent updates from Microsoft, WSMT remains a viable choice for migrating Windows Server, even though there are alternative methods available based on the specific role being transferred. For instance, Windows Server 2019 brought about the Storage Migration Service for file servers. When it comes to updating domain controllers, administrators often opt to install a new server, allowing for the replication of the Active Directory database and SYSVOL. However, it’s important to note that using WSMT may exhibit some bugs when employed with Server 2022.
However migrating windows server using WSMT remains valuable for tasks like transferring roles like DHCP, along with local settings including users and groups. These guides may be of interest to you: Installing and configuring Hyper-V Cluster On Windows Server via PowerShell and Server Manager, What is ADK, MDT, Microsoft Endpoint Configuration Manager (SCCM), Intune, Autopilot, and WSUS, how to Deploy MVC Application to AWS EC2 Using RDP Connection and Web Deploy, Network File System: How to install NFS Server on Windows Server and how to install and Configure Hyper-V on Windows Server on Windows Server 2019, and 2022 via the Server Manager, PowerShell or DISM.
Installing and Running WSMT
Install the Windows Server Migration Tools on the destination server using the Server Manager GUI. Installing the tools with PowerShell is also possible, as shown below:
Install-WindowsFeature Migration –ComputerName <computer_name>
After installing the WSMT on the destination server, the workflow allows you to deploy these tools to the source server. In this case, I’m using a UNC path, which is supported.
After executing the above command, the SMT_ws16_amd64 directory is automatically created on the source server.
Frequent Mistakes in Migrating Windows Server Using WSMT
Migrating a windows server using WSMT can often display a number of buggy behaviors during testing on newer servers. After you’ve deployed the tools to the source server, you should run the
SmigDeploy.exe command to automatically register the PowerShell cmdlets. Several errors might occur during this process. Such errors include:
- .NET errors indicate that.NET was not installed, even when it was.
- When registering the cmdlets, PowerShell crashes.
- Errors relating to access denied and memory corruption
PS C:\SMIG\SMT_ws16_amd64>dir path to the
SmigDeploy.exe file directory published to the source server from the destination server, you will be able to see the contents of the
SmigDeploy.exe file. Running this file registers the PowerShell cmdlets on the source server.
Workarounds for the WSMT Bugs
The solution is to simply install WSMT on the source server instead of using the published WSMT from the destination server. After installing the Windows feature on the source server, you will need to manually register the snap-in using the following cmdlet:
Then, you can run the Export-SmigServerSetting cmdlet to export roles and features. The export cmdlet below will do this for you:
Export-SmigServerSetting -featureID <your FeatureID> -User All -Group -path c:\SMIG -Verbose
Once the feature ID is exported, you can then import the features on the destination server using the import cmdlet.
Import-SmigServerSetting -FeatureID <your FeatureID> -Path <path to the source export> -Verbose
In summary, for several years, Microsoft has not enhanced the WSMT. As a result, you’ll almost certainly run into some frustrating bugs while using them with Windows Server 2022. Nonetheless, they’re still valuable in situations where you don’t have access to newer tools or if an in-place update isn’t possible.