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>
Install the Windows Server Migration Tools

Install the Windows Server Migration Tools

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

Deploy the server migration tools from the destination server to the source server

Deploy the server migration tools from the destination server to the source server

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

Directory is created on the source server

Directory is created on the source server

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.

Viewing the SMIGdeploy.exe command

Viewing the SMIGdeploy.exe command

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.

NET errors even though .NET is installed on the source server

NET errors even though .NET is installed on the source server

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
Exporting compatible roles and features from the source server

Exporting compatible roles and features from the source server

Once the feature ID is exported, you can then import the features on the destination server using the import cmdlet.

Subscribe to 4sysops newsletter!

Import-SmigServerSetting -FeatureID <your FeatureID> -Path <path to the source export> -Verbose
Importing features using the WSMT import cmdlet

Importing features using the WSMT import cmdlet

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.

+2
avatar
1 Comment
  1. Eslam Soliman 3 weeks ago

    Didn't like how this topic was written.
    What does this means:
    "" Once you install the WSMT on the destination server, the workflow has you then deploy these tools to the source server. ""

    Review before publishing.

    0

Leave a reply

Please enclose code in pre tags

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2021

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account