Why use Storage Migration Service (SMS)

So you currently are using an old outdated Windows File Cluster, say Server 2008 R2.

You want to upgrade it to the latest OS, either 2019 or even 2022 as 2008 is out of support.

How do you get the files off multiple servers in a quick and easy way.

The answer could be……… Storage Migration Service, so how does it work then and is it easy to setup?

Yes it is, let me explain a bit more about it.

How to set it up?

To use SMS you need the following:

A source server or failover cluster that you want to migrate the files and data from.

A destination server, or servers should you want them to be your new failover cluster, running either Windows Server 2019 or 2022.

An Orchestrator server, again running either 2019 or 2022, this is used to manage (or Orchestrate) the migration.

Finally, a PC or server running the latest Windows Admin Center, this is used to run the Storage Migration Server user interface. You also need the latest SMS tool(or extension), available from the feed. It must also be at least version 2103.

Also, bear in mind that the destination and orchestrator servers must have at least 2 CPU’s and at least 2GB RAM.

So what credentials and firewall rules must you have to use this service –

A migration account that is administrator on the source, destination and orchestrator servers, this can be a domain or local account, unless it is not domain joined in which case it must be a local user.

The orchestrator server must have File and Printer Sharing (SMB-In) firewall rule enabled inbound, as well as Netlogon Service (NP-In), Windows Management Instrumentation (DCOM-In and WMI-In)

If the servers belong to an Active Directory Domain Services domain then they should all belong to the same forest.

How does it work?

The migration is a three-step process:-

  1. Inventory servers – to gather information about their files and configuration.
  2. Transfer data – from the source to destination servers.
  3. Cut over to the new servers – Once the migration is complete the destination server assumes the source server identity so that apps and users don’t have to change anything and see no visible difference to before.

Obviously a lot of companies are putting their data in Azure, but some companies still prefer to use legacy on-premises storage, because of legacy application dependencies.

About the author