The Windows Server Migration Tools (WSMT) have shipped with Windows Server since version 2003. Admins can use them to transfer roles and features to a newer version of the operating system. Since Microsoft hasn’t updated these tools for quite some time, they show some bugs when used with Server 2022. Nevertheless, the WSMT are still a viable option when upgrading Windows Server.

Depending on the role you want to migrate, there are alternatives to WSMT. For file servers, Microsoft has introduced the Storage Migration Service with Windows Server 2019. When updating domain controllers, admins usually install a new server and replicate the Active Directory database and SYSVOL to the new machine. However, WSMT are still useful when migrating roles such as DHCP and several local settings such as users and groups.

Installing and running WSMT ^

On the destination server, install the Windows Server Migration Tools using the Server Manager GUI. You can also use PowerShell to install the tools using the following command:

Install-WindowsFeature Migration –ComputerName <computer_name>

Once you install the WSMT on the destination server, the workflow has you then deploy these tools to the source server. Here, I am using a UNC path, which is supported.

Note that the directory is created on the source server, as specified in the command run above.

Weird issues ^

In my testing with newer servers, I ran into multiple buggy behaviors with WSMT. After deploying the tools to the source server, you are supposed to run the SMIGDeploy.exe command on the source server and automatically register the PowerShell cmdlets. I ran into several oddities during this process, including:

• .NET errors stating that .NET was not installed, even when it was installed
• PowerShell crashes when registering the cmdlets
• Access denied errors and memory corruption errors

Below, you can see the SMIGDeploy.exe file in the directory published to the source server from the destination server. Running this file registers the PowerShell cmdlets on the source server.

Even though the .NET feature was installed on the source server, I saw issues with the server not seeing the .NET components installed. Similar problems have been reported across various message boards, including TechNet. See here.

Workarounds ^

The workaround in my case was simply installing WSMT on the source server instead of using the published WSMT from the destination. After installing the Windows feature on the source server, I manually registered the snap-in using the cmdlet:

Add-PSSnapin Microsoft.Windows.ServerManager.Migration

Then, you can run the Export-SmigServerSetting cmdlet to export roles and features. The example below shows exporting the BranchCache feature to a target folder.

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

Conclusion ^

Microsoft hasn’t improved the WSMT for several years. So when using them with Windows Server 2022, you will probably run into some annoying bugs. Nevertheless, they’re still useful for certain scenarios where you don’t have newer tools or an in-place update isn’t an option.