- 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
WSMT has been around for quite a while. It is a Windows feature that provides access to specialized PowerShell cmdlets, allowing automated migration of certain roles between a legacy server and a newer Windows Server operating system.
The Windows Server Migration Tools can migrate specific settings, including the following:
- Roles
- Features
- Shares
- Operating system configurations
The process of using WSMT is generally as follows:
- Install WSMT on the destination server (the server that is the target of the roles, features, etc.).
- Copy the WSMT files to the source server.
- Export the roles, features, etc., from the source server to a destination folder.
- Import the roles, features, etc., to the destination server.
Limitations of WSMT
While, in concept, the Windows Server Migration Tools provides great functionality, in practice, it is limited in the scope of roles, features, settings, and other data that can be migrated from a legacy server to a destination. Note the following compatible roles, features, settings, and data:
Roles
- Active Directory Domain Services
- DNS
- DHCP server
- File services
- Print services
Features
- BranchCache
Settings and data
- Data and shares
- IP configuration
- Local users and groups
Additionally, if you look at the documentation for WSMT, it is quite dated. It details scenarios of migrating roles and services up to Windows Server 2012 R2, which is now end-of-life. However, if you look at Windows Server 2022, the WSMT feature is still available for installation.
The /OS switch, which allows copying over the migration tools to a specific OS, does have a switch that includes Windows Server 2016, so it is reasonable to assume that it supports operating systems up to Windows Server 2016 as a source.
Windows Server Migration Tools is still valid for specific roles, services, data, and configurations, and can be a path to migrate the specific roles and services listed above. Just be aware of the potential for unsupported scenarios and buggy behavior that can be seen between different OS versions.
In-place upgrade vs. Windows Server Migration Tools
As mentioned at the outset, running an in-place upgrade is another common way to bring legacy servers up to current Windows Server versions. However, there can also be challenges with in-place upgrades. These can include:
- Hardware compatibility issues—The hardware may not be compatible with the latest Windows Server versions.
- Driver issues—Tying in closely with hardware compatibility, drivers can create issues during in-place upgrades.
- Unsupported software—Legacy software that cannot be migrated to newer operating systems can prevent an in-place upgrade.
- Multiple steps to arrive at the target Windows Server version—The further back the source Windows Server OS is, the likelier it will be that you will have to take multiple steps to get to the latest version. For instance, you cannot go directly from Windows Server 2008 R2 to Windows Server 2022. You have to go from Windows Server 2008 R2 to Windows Server 2012 R2 and then from Windows Server 2012 R2 to Windows Server 2022.
- Time and maintenance windows—The in-place upgrade could take a significant amount of time. Moving individual services and roles off a server can be more timely and, in many cases, work better.
Conclusion
This comparison certainly offers different answers for different businesses depending on many factors. These factors include the roles and services needing to be migrated, the difference in Windows Server versions between the source and destination servers (how many versions are between), and compatibility.
Subscribe to 4sysops newsletter!
Windows Server Migration ToolsWSMT may work out well for some who need to migrate the specific supported roles and features. However, using modern Windows Server tooling may be better, such as the new Storage Migration Service that can migrate an entire legacy file server from Windows Server 2003 and grab permissions, users, and shares, and assume identity.
HI Brandon
Interesting post as always
I would like to add other challenges not mentioned :
– The source server doesn’t respect the Best-Practices. It would be a shame to reproduce this on the new one.
– the source server has hidden “pans” (sorry if it’s not the correct word for a misconfiguration), it would be a shame to reproduce them on the new one.
to summarize : in a lot of cases, it could be easier, faster, less effort to audit the source server first, then choose using WSMT or build a full new server using scripts or other methods.
Regards