Migrating roles and features to Windows Server 2022 using WSMT

• Author
• Recent Posts

Brandon Lee

Brandon Lee has been in the IT industry 15+ years and focuses on networking and virtualization. He contributes to the community through various blog posts and technical documentation primarily at Virtualizationhowto.com.

Latest posts by Brandon Lee (see all)

• What’s your ENow AppGov Score? Free Microsoft Entra ID app security assessment - Thu, Nov 30 2023
• Docker logs tail: Troubleshoot Docker containers with real-time logging - Wed, Sep 13 2023
• dsregcmd: Troubleshoot and manage Azure Active Directory (Microsoft Entra ID) joined devices - Thu, Aug 31 2023

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

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

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

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

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

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

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

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.