- 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>
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.
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.
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:
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
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.