Windows Server Migration Tools

Comment | Print | RSS

• Login to Rate

The adage "If it ain't broke, don't fix it" seems to be the primary operating principle for many IT shops. But there are advantages to moving to Windows Server 2012, not the least of which is Microsoft support.

Windows Server 2012 includes built-in migration support as an installable role. If you happen to still use Windows Server 2003, you still have a few more years of official Microsoft support. Microsoft has traditionally provided support of an operating system for ten years, although they officially announced support for Windows Server 2003 until July 2015. The release of Windows Server 2012 provides a great opportunity to migrate those old systems and be done with it.

To install the Windows Server Migration Tools, simply launch Server Manager and then Add Roles and Features from Manage menu. Click through the wizard screens until you get to the Select Features screen. Scroll down the page and find the Windows Server Migration Tools entry and check the adjacent box. From there, click on the Install button and the wizard will execute the appropriate PowerShell command to install the tools. You can also accomplish the same steps with a single line of PowerShell as follows:

Install -- WindowsFeature Migration -- ComputerName

The main idea behind using the migration tools is to simplify moving existing roles and services from older versions of the operating system to either a physical or virtual version of Windows Server 2012. Microsoft has created a number of migration guides for moving a specific set of roles and services including Active Directory Federation Services, Health Registration Authority, Hyper-V, IP Configuration, Network Policy Server, Print and Document Services, Remote Access, and Windows Server Update Services.

For servers running multiple roles, it's recommended that you create a custom migration plan based on the steps outlined in the plans they provide. Some services, like the Remote Access service, can contain a significant amount of configuration or profile information. It's this information that the migration tools attempt to move for you to avoid the problem of recreating the service from scratch.

Some pieces of configuration for the Remote Access service are not automatically migrated. If the existing Remote Access service depends on a Network Policy Server, that role must be migrated separately prior to performing the Remote Access migration. In addition, you may find some situations where certificates are not automatically migrated. It's also important to keep in mind that you'll lose remote connectivity when performing migration on a production server.

Many migration permutations might not fit exactly into the cookie cutter process provided by Microsoft. It will pay great dividends to have a good understanding of the existing and target environments before you undertake any migration project. You'll also want to check out the Microsoft TechNet page for a full rundown on migrating a wide range of roles, services, and features to Windows Server 2012.