In the following step-by-step demonstration, we will take a look at migrating file shares from server to server using Storage Migration Service.
Storage Migration Service (SMS) is a Windows Server feature that enables the migration of unstructured data, such as files and folders, from an older file server to a newer one with minimal downtime and disruption to users. SMS automates the process of moving data, shares, and permissions, allowing you to migrate file servers with little to no manual intervention.
The migration process is performed in stages, allowing you to verify each stage before proceeding to the next one. SMS also includes a comprehensive set of tools for monitoring and troubleshooting the migration process, ensuring that everything goes smoothly.
In this article, we will show you step-by-step how to migrate a file server from Windows Server 2016 to Windows Server 2019. This also can apply to different and newer versions of Windows Server.
Table of Contents
Storage Migration Service
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, and 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, Windows Admin Center (WAC) leverages PowerShell under the covers.
Prerequisites
The requirements are very simple, to use Storage Migration Service, you need the following:
1) A source server (Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019, or Windows Server 2022).
2) A destination server (Windows Server 2012 R2, Windows Server 2016, Windows Server 2019, or Windows Server 2022). Destination servers running Windows Server 2022 or Windows Server 2019 have double the transfer performance of earlier versions of Windows Server. This performance boost is due to the inclusion of a built-in Storage Migration Service (SMS) Proxy service.
3) An orchestrator server (Windows Server 2019/2022 Standard or Datacenter). You need at least one Windows Server 2019/2022 to act as an orchestrator, but you don’t have to make your destination server 2019 or 2022, however, if your destination server is Windows Server 2019 or Windows Server 2022, 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 that was introduced in Windows Server 2019 and later.
4) At the time of this writing, the source and the destination server must reside in the same domain and same forest.
5) A PC or Server running Windows Admin Center (WAC) with minimum version 2103. Check my previous article on how to install Windows Admin Center.
6) Last but not least, make sure you have installed the extension Windows Server Storage Migration Service (msft.sme.storage-migration) in Windows Admin Center. At the time of this writing, we are running Version 2.6.1 of the Storage Migration Service extension.
As a side note, if you are installing the Storage Migration Service (SMS) Proxy service in a DMZ, you must open and allow the following 4 inbound firewall rules (File and Printer Sharing (SMB-In), Netlogon Service (NP-In), Windows Management Instrumentation (DCOM-In), and Windows Management Instrumentation (WMI-In).
Please note that installing the Storage Migration Service Proxy service on a Windows Server 2019 or Windows Server 2022 computer automatically opens the necessary firewall ports on that computer. To do so, connect to the destination server in Windows Admin Center and then go to Server Manager (in Windows Admin Center) > Roles and features, select Storage Migration Service Proxy, and then click Install as shown in the figure below.
How to do it…
Launch the 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 or Windows Server 2022), 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 consolidate (more on this 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 data on the source server. This step may take some time depending 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, and 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) On the Adjust transfer settings page, you can set the Validation method (checksum), Max duration, and Retries, as well as whether to migrate local users and groups on the source servers. This is useful in case you have several local accounts on the Source server that you need to migrate. This lets you recreate any local users and groups on the destination servers so that file or share permissions set to local users and groups aren’t lost. Click on Next to continue.
> Please note that migrated user accounts are disabled on the destination server and assigned a 127-character password that’s both complex and random, so you’ll have to enable them and assign a new password when you’re finished to keep using them. This helps ensure any old accounts with forgotten and weak passwords on the source don’t continue to be a security problem on the destination.
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) On the Start transfer page, click Start transfer. The transfer will kick in and take some time depending 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 a CSV file and open it in Excel. This is so interesting because it will help you to cross-check that all files are migrated in case any user complains 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 using 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 map the network on the destination server, rename the source server, and change its 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.
Related: How to Migrate Servers and Workloads.
How it works…
The Storage Migration Service has 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), and 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, and you can also set retry flags, reservations, and checksum. Then you validate the transfer settings to see if it’s going to work, and 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 cut over.
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 addresses, 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
Storage Migration Service (SMS) makes it easier to migrate your older Windows Server File Servers (2003 & later) to Windows Server 2016 and Windows Server 2019. SMS provides an elegant graphical UI (via Windows Admin Center) that inventory data on servers and then transfers the data and configuration to newer servers—all without apps or users having to change anything. This is a great feature!
SMS is designed to help by doing the following:
1) Inventory multiple servers and their data.
2) Rapidly transfer files, file shares, and security configuration from the source servers.
3) Optionally take over the identity of the source servers (also known as cutting over) so that users and apps don’t have to change anything to access existing data.
4) Manage one or multiple migrations from the Windows Admin Center user interface.
At the time of this writing, Storage Migration Service is in the second release, Microsoft is working on adding additional features shortly such as:
- Full discovery option instead of typing source computer names.
- The Storage Migration Service supports migrating from and to clusters after installation of cumulative update KB4513534 or subsequent updates on Windows Server 2019 and with Windows Server 2022 out of the box.
- Add support for NFS (Linux/Unix), Block, and NDMP protocol.
- Add support for Samba, NAS, and SAN devices.
- If you have Azure File Sync set up, you can sync this storage directly to Azure as well. The Storage Migration Services does support migration to a Windows Server or cluster running Azure File Sync with cloud tiering when using the latest version of Windows Admin Center and Windows Server 2022, or Windows Server 2019 with the latest cumulative update.
- 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 having an agent installed on the source server.
Overall, SMS provides a streamlined and efficient way to migrate file servers, while minimizing the impact on users and the risk of data loss.
__
Thank you for reading my blog.
If you have any questions or feedback, please leave a comment.
-Charbel Nemnom-
Our Existing file share has a local C:\ Drive for the OS and all of the actual file shares are NetApp-connected ISCSI LUNs.
We also use the NetApp “Snap Drive agent for Windows installed on the C drive for taking nightly automated snapshots using PowerShell scripts.
Does this process address all of these complexities? I didn’t see any mention of external storage.
Hello Mike, thanks for the comment!
Microsoft has tested NetApp FAS external arrays hosting NetApp CIFS server, running NetApp ONTAP 9.
You should be able to inventory data on Windows, Linux, and NetApp CIFS servers and then transfers the data to newer servers or to Azure virtual machines.
I would say give it a try and see how it works in your environment. It’s safe.
Check this article for more information.
Hope it helps!
Thank you for the detailed post, when you initiate a transfer will it happen over ethernet or FC (considering it is an FC configuration)?
Hello Pateel, thanks for the comment!
The transfer will happen over the Ethernet.
Hope it helps.
Is it possible to skip the Cutover phase? I am moving a DFS 2012 R2 to a 2022. I don’t want to give it the same IP and name as I am moving this to a different site with a different subnet and naming scheme.
Once the file transfer completes, I planned on adding a target in DFS and disabling the target to the old source server.
Once I verify the DFS shares are working from the new server, I would remove the old targets.
Hello James, thanks for the comment!
Yes, you can safely skip the Cutover phase and move with your plan as you described.
Hope it helps!
Hello,
Thanks for a great article! Would you have an idea how to solve the following?
I have an issue with SMS where files with non-standard permissions are not copied and job fails with “access denied”.
I have of course followed the guideline, migration user is a member of local admins, and patch mentioned there does not apply to WS2022.
Exactly as the issue described here: https://learn.microsoft.com/en-us/windows-server/storage/storage-migration-service/known-issues#certain-files-dont-inventory-or-transfer-error-5-access-is-denied
Thanks!
Michael
Hello Michael, thanks for the comment and feedback!
It seems you’ve already taken the necessary steps by ensuring the migration user has the appropriate permissions.
Yes, the patch mentioned in Microsoft documentation doesn’t apply to your Windows Server 2022 environment and if you’re encountering a similar issue as described in the known issues section, it might be beneficial to explore alternative approaches or workarounds:
1) Check Permissions: Double-check the permissions on those files to ensure that the migration user has the necessary access. Sometimes, certain files might have specific access restrictions.
2) Log Analysis: Review the logs generated during the migration process for more specific details on which files are encountering the “access denied” error. This might offer more insight into the issue.
3) Workaround Solutions: Consider temporarily modifying permissions or copying the problematic files manually to a different location, if feasible. Then, attempt the migration again after ensuring appropriate access permissions.
4) Update or Alternative Solution: Since the issue seems to be related to a known problem in SMS, reaching out to Microsoft support provide you with more targeted assistance or possible workarounds specific to your scenario with Windows Server 2022.
Hope it helps!