Step By Step: Migrate Your File Servers With Storage Migration Service in Windows Server 2019

Introduction

In Windows Server 2019, Microsoft introduced a brand new feature called Storage Migration Service (SMS). With SMS, you can migrate unstructured data from any Windows Server version (even Windows Server 2003 if you still have them around) into physical, virtual machines, Azure IaaS, and Azure Files. It’s super fast, consistent, and scalable, it takes care of all the complexity such as permissions, share properties, encrypted, attributes, in-use files, network settings, names,  and Active Directory membership. The following diagram from Microsoft shows all the supported scenarios for Storage Migration Service in Windows Server 2019. SMS leverages the SMB protocol to migrate your data.

Storage Migration Service in Windows Server 2019 [image credit: Microsoft]

Storage Migration Service ships in Windows Server 2019 (Standard and Datacenter edition), and Windows Admin Center (WAC) is the primary management tool for Storage Migration Service, WAC actually leverages PowerShell under the covers.

In this article, I will show you step by step on how to migrate a file server from Windows Server 2016 build 14393 to Windows Server 2019 build 17763. This also can apply to different versions of Windows Server.

Prerequisites

The requirements are very simple, to use Storage Migration Service, you need the following:

  • A source server (Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, or Windows Server 2019).
  • A destination server (Windows Server 2012 R2, Windows Server 2016, or Windows Server 2019).
  • An orchestrator server (Windows Server 2019 Standard or Datacenter). You need at least one Windows Server 2019 to act as an orchestrator, but you don’t have to make your destination server 2019, however, if your destination server is Windows Server 2019, then the transfer speed will be double compared to Windows Server 2012 R2, and Windows Server 2016. This performance boost is due to the built-in Storage Migration Service proxy service in Windows Server 2019.
  • The source and the destination server must reside in the same domain and same forest as of today.
  • A PC or Server running Windows Admin Center (WAC) with minimum Version 1809. Check my previous article on how to install Windows Admin Center.
  • Make sure you have installed the extension msft.sme.storage-migration in Windows Admin Center. At the time of this writing, I am running Version 0.59.0 of the Storage Migration Service extension.

How to do it…

Launch Windows Admin Center portal and take the following steps, assuming you have already added the source and destination server:

  1. Choose the orchestrator server (Windows Server 2019), then select the Storage Migration Service from the left-hand-side, and then click Install to install the Storage Migration Service feature.
  2. A new window will pop-up describing the three easy steps that you will go through to migrate your file shares and configuration to new servers without affecting existing apps and users. Click Close.
  3. This is Phase 1, click +New job to create a new job, give it a name without any space (only alphanumeric), and then click OK.
  4. Enter the credentials for the source server that you want to migrate from, select if you want to include all admin shares, and then click Next.
  5. Click +Add a device, enter the source server, and then click OK. Please note that you can add more than one source server at a time. This is useful in the scenario where you want to migrate more than one file server to new Windows Servers, but not consolidating (more on that in the Summary section).
  6. Click Start scan to start the inventory, in this step, the Storage Migration Service will start looking at all the configuration, network settings and the data on the source server. This step may take some time depends on the amount of data you have on the source server.
  7. Once the scan is complete, you will see all the shares, their path, size, files, including the configuration, network adapters, and volumes on the source server. Click on Next to continue.
  8. Now we move to Phase 2, enter the credentials for the destination server that you want to migrate to, and then click Next.
  9. Add your destination server to map it against your source server, and then click Scan device. After a moment, you will see all the volumes on the destination server including their free space, you can change the destination volume if you wish to, and you can select which source share you want to include in the transfer. Make your selection and then click Next.
  10. In the Adjust transfer settings page, you can set the Validation method (checksum), Max duration and Retries. Click on Next to continue.
  11. Then you need to validate to check if the transfer is going to work, so you can make sure that everything will work before you start the migration. This is the best feature! Click Validate. In my example, the validation passed.
  12. If you click on the Pass link, you will see all the migration test results. Click Close and then click on Next to continue.
  13. In the Start transfer page, click Start transfer. The transfer will kick-in and take some time depends on the amount of data you are transferring. Get a cup of coffee and then come back 🙂
  14. If you switch back to the Storage Migration Service dashboard in Windows Admin Center, you will see the migration job in real time including the network throughput in a beautiful chart view. This is awesome!
  15. Once the transfer is completed, you will see the status is Succeeded. Click on the job name at the bottom.
  16. In the Start the transfer page, you will see transfer and error log details where you can download the logs as CSV file and open them in Excel. This is so interesting because it will help you to cross check that all files are migrated in case any user complaint that he/she cannot see their files! Click on Next to continue.
  17. Now we reach the final step, Phase 3, Cutover to the new servers. In this step, you can use the stored credentials or enter new ones in case they are changed on the destination server. Click on Next to continue.
  18. In the Configure cutover page, you will see the network adapter for the source server, you can map the network adapter on the destination server, you can set a new static IP address for the source server, or you can use DHCP. Last but not least, you can rename the source server by giving it a new name or use a random name. Click on Next to continue.
  19. In the Adjust cutover settings page, you can specify the cutover timeout in minutes, the default is 2880 minutes (48 hours).
  20. In the Validate source and destination devices page, click Validate. This step will validate that everything will work before you cut over and remove the old server. If you click on the Pass link, you will see all the migration test results. Click Close and then click on Next to continue.
  21. Finally, click Start cutover. Please note that this step requires downtime because it will reboot twice the source and the destination server, then mapping the network on the destination server, and renaming the source server and change it’s IP address, so make sure to schedule a maintenance window before you proceed.
  22. After the cutover process is succeeded. I was able to verify that the old server was renamed and the new server has the identity of the old server. Now if your destination server is Windows Server 2019, and is acting as an orchestrator as well as you are migrating to the same server as described in this example, then you need to connect to the old server name in Windows Admin Center because the name of the destination orchestrator server is changed to the source server name.

How it works…

The Storage Migration Service is basically three phases, inventory, transfer and cutover.

The inventory phase is passive, there is no agent to install on the source or the destination server. You create a job, you add a server(s), then you start scanning, the discovery phase will scan the configuration, network settings, volumes, and OS info on the source server(s). This also includes SMB information, file count, file sizes, and their share properties. Once the scan is complete, you are ready to transfer.

In the transfer phase, you will map the destination volumes based on the list of sources you have from the inventory phase, you can skip shares not to be included in the transfer phase, you can also set retry flags, reservation, and checksum. Then you validate the transfer settings to see if it’s going to work, you proceed with the transfer (you can repeat the transfer as many times as you want and only the delta will be copied), by the end of the transfer you will get a CSV report, and finally you are ready to cutover.

In the cutover phase, you will map the network adapter on the destination server, you can give your old file server a new set of IP address, and change its name if you want, you can specify the maximum duration of the cutover before it expires, then you validate the cutover settings to see if it’s going to work, and finally you do the cutover and wait for the job to be complete.

Summary

The Storage Migration Service makes your life easier to migrate your old servers to a newer version of Windows Server. It provides a graphical tool that inventories data on servers and then transfer the data and configuration to newer servers—all without applications or users having to change anything. This is a really great feature!

At the time of this writing, Storage Migration Service is in the first release, Microsoft is working to add additional features in the near future such as:

  • Full discovery option instead of typing source computer names.
  • Add cluster support.
  • Add support for NFS (Linux/Unix), Block, and NDMP protocol.
  • Add support for Samba, NAS, and SAN devices.
  • Azure File Sync integration. If you have Azure File Sync set up, you can sync this storage directly to Azure as well. This is awesome!
  • Add Azure Files support as a target (SMB/NFS).
  • Consolidation. This is great for scenarios when you have many file servers and you want to consolidate them into one file server.
  • Data analysis, reporting, and governance. This is interesting, but it will require to have an agent installed on the source server.

__
Thank you for reading my blog.

If you have any questions or feedback, please leave a comment.

-Charbel Nemnom-

Advertisements
About Charbel Nemnom 406 Articles
Charbel Nemnom is a Cloud Solutions Architect and Microsoft Most Valuable Professional (MVP), totally fan of the latest's IT platform solutions, accomplished hands-on technical professional with over 17 years of broad IT Infrastructure experience serving on and guiding technical teams to optimize performance of mission-critical enterprise systems. Excellent communicator adept at identifying business needs and bridging the gap between functional groups and technology to foster targeted and innovative IT project development. Well respected by peers through demonstrating passion for technology and performance improvement. Extensive practical knowledge of complex systems builds, network design and virtualization.

Be the first to comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.