- Install K3s, a lightweight, production-grade Kubernetes distro - Mon, Mar 20 2023
- VMware NSX Advanced Load Balancer: Installation and configuration - Fri, Mar 10 2023
- NetCrunch 13: Real-time network monitoring, traffic analysis, alerts, and performance reporting - Tue, Mar 7 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>
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.
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.
Subscribe to 4sysops newsletter!
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.
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.
I was having trouble with memory errors when running WSMT (2016 -> 2022).
I came across this page looking for a solution.
I followed the instructions given and found the solution immediately.
Thank you very much.
From Tokyo,Japan.