Migrating file servers using Storage Migration Service

Need to move from Windows Server 2003 and up? The Storage Migration Service in the Windows Admin Center does most of the heavy lifting to make this procedure more routine rather than risky.

As the year 2020 approaches, so does the end of life for Windows Server 2008. Many in IT have to reckon with the migration of old file servers to Windows Server 2019.

Administrators tend to hold onto infrastructure such as Windows file shares until just before support ends for a few reasons. A file server migration can be a complex process that requires accounting for multiple scenarios, such as encrypted files or alternate data streams, network and security settings. If the move is short of seamless, it can disrupt users who need access to files to do their jobs.

To address this need, Microsoft created the Storage Migration Service. This feature in the Windows Admin Center reduces the difficulties associated with migrating Windows Server 2003 and upward -- and Samba file shares on Linux -- to a newer version of Windows Server on either a physical box or a virtual machine, or to Azure IaaS or Azure Files. Even though Windows Server 2003 is out of support, as long as you can connect to it from the orchestrator component of the Storage Migration Service, it will work. For older Windows Server operating systems, Storage Migration Service avoids any double-hop issues by handling authentication between the source and destination servers.

This tutorial explains how to migrate Windows Server 2008 file shares to Windows Server 2019, but the process is identical for most supported operating systems. You can also move to Windows Server 2012 R2 and Windows Server 2016 for the destination server.

What is Storage Migration Service?

The Storage Migration Service is a plug-in in the Windows Admin Center that orchestrates and administrates migrations of file servers. It performs a cutover migration to minimize downtime.

In short, the process works like this:

  • install an orchestrator for Storage Migration Service on a server;
  • create a migration job with one or several source servers and one destination server;
  • data transfers the source servers to orchestrator to destination server; and
  • the final cutover occurs when the source servers get a new IP address and name, and destination server gets both the source server's old IP and name.

Storage Migration Service eases this process in situations where you don't use Distributed File System or have odd applications that can only bind directly to the file shares.

Storage Migration Service requirements

To use Storage Migration Services, you will need the following:

  • An up-to-date installation of Windows Admin Center on a server, but it's fine to use on a PC.
  • A supported source server to migrate data from that runs Windows Server 2003-2019.
  • A destination server running Windows Server 2019 to migrate the data running on the same subnet as the source server.
  • A server to orchestrate the migration running Windows Server 2019. It's possible for this to be the destination server, but it's not recommended because it may cause some hiccups and slow down the cutover.
  • Open ports between destination, source and orchestrator servers for at least the following services: RPC, WSMAN, WMI and SMB.
  • A free IP address on the same subnet as the destination server.
  • An installation of Windows Admin Center that's not installed on a domain controller, source or destination server.
  • The account performing the migration needs the following permissions: local admin rights on source and destination servers, add computer to AD, write permission in Active Directory to the destination and source server computer accounts; write to DNS record for destination and source server.

For a transfer from Windows Server 2003 to Windows Server 2019, both the orchestrator and source server running Windows Server 2003 need SMB1 enabled if this function is turned off.

Once those requirements are in place, set up Storage Migration Service.

Prepare TTL on source server DNS record

While it's not mandatory, it's good to shorten down the Time-To-Live (TTL) on the DNS record for the source to shorten the downtime of the cut-over.

Open PowerShell on a domain controller or a computer with Remote Server Administration Tools installed and enter:

$Domain = ""
$SourceServerName = "vm-fs-2k8"
$DomainController = ""
# Get the DNS record for source server
$Record = Get-DnsServerResourceRecord -ZoneName $Domain -Name $SourceServerName -ComputerName $DomainController
$NewRecord = $Record
# Enter new TTL
$NewRecord.TimeToLive = New-TimeSpan -Minutes 2
Set-DnsServerResourceRecord -ZoneName $Domain -OldInputObject $Record -NewInputObject $NewRecord -ComputerName $DomainController

This will reduce the TTL to two minutes and will shorten the time the share is unreachable for clients.

Install Storage Migration Proxy on Destination server

On the Windows 2019 destination server, open PowerShell as an admin and enter:

Install-WindowsFeature SMS-Proxy

This will install the Storage Migration Proxy needed to communicate with the orchestrator.

Next, configure the Storage Migration Service on Windows Admin Center to set up the migration job.

Update and install Storage Migration Service on the orchestrator

It's time to update the Storage Migration Service plug-in and install it on the orchestrating server, which handles communication and data transfer between our source and destination server. Start out by browsing to Windows Admin Center Gateway and click on Settings.

Click on Extensions > Installed extensions and click on the plug-in.

Storage Migration Service plug-in update
Update the Storage Migration Service plug-in from the Extensions menu.

Click on the Update button and wait for the system to finish. After the update completes, install the Storage Migration Service on the orchestrator server by connecting to the orchestrator server through the Windows Admin Center, clicking on the Storage Migration Service in the left panel menu and pressing Install. Wait for the install to finish.

Create the storage migration job

Next, configure the migration job. This process takes a few minutes and allows us to start transferring data and do the cutover, which is optional.

In Storage Migration Service, press New Job.

start a new file server migration job
Begin the file server migration by selecting New Job in the Storage Migration Service.

Name the job and set the source device operating system -- Windows server and clusters, or Linux servers -- and press OK.

Scan the source

Enter credentials for an account that has local admin privileges on the source server and press Next.

file server credentials
Enter the credentials for the source file server.

Press on Add a device, enter the fully qualified domain name (FQDN) or name of the source server and press OK.

Press Start scan to create an inventory of source devices shares and files.

Wait for the scan to finish and press Next on the bottom of the page to start mapping the source disks to the destination server hard drive.

Map source server disks to the destination server

To scan the disk of the destination server for mapping purposes, enter the name or FQDN of your Destination Server and press Scan device.

Select where the contents of the disks containing shares on the source device should be mapped to on the destination server.

For example, the C disk on source should be copied to D disk on the destination server.

Press Next on the bottom of the page to continue when finished.

destination device mappings
Set up the mappings on the destination device.

If you use only domain accounts on the source server for accessing file shares, then the default values are fine; otherwise, adjust accordingly.

Press Next.

transfer settings
Adjust the transfer settings on the source server, including the number of retries.

Click Validate to confirm your settings.

When the validation checks pass, select Next to start the data transfer process.

Transfer the file share data

After all the configuration work, the Storage Migration Service can now transfer the data. You can stop the process and continue the transfer several times during the migration to minimize the time for the cutover migration.

You also can exit the Windows Admin Center during the transfer because the job runs on the orchestrator.

Press Start Transfer. This does not start the cutover.

When the file transfer completes, you can continue to the cutover phase by pressing Next. You can stop here if you want to avoid the cutover and just wanted to copy the files.

If errors occurred, then try the transfer again or check the logs to see which files did not make the move to decide if you need them.

Begin the cutover migration

Now it's time for the most critical step of the migration: the cutover. At this state, the Storage Migration Service will perform a differential transfer, then change the IP and name on the source server.

Start out by either entering new credentials for the source and destination servers or use the stored credentials. Click Next.

Enter a spare IP on the same subnet that the source server will switch to. Remember to select the correct network adapter.

cutover migration configuration
Configuring the cutover migration section in the Storage Migration Service.

Enter the new name or choose the option for a randomly generated name for the source device.

Enter the Active Directory credentials with permissions to join computers to Active Directory as well as create/write to the organizational units. The Storage Migration Service will use the stored credentials if new ones are not provided.

Click Validate and wait for the system to finish and press Next.

When you feel ready, press the Start cutover button to start the process.

Press the Events button for more information if any errors occur.

The cutover process will proceed and should take around 15 minutes to finish. During this time, clients will have connection issues because the servers will restart several times. After the job finishes, the storage migration should be complete.

Dig Deeper on Windows Server OS and management

Cloud Computing
Enterprise Desktop
Virtual Desktop