Windows Server Summit 2024
Mar 26 2024 08:00 AM - Mar 28 2024 04:30 PM (PDT)
Microsoft Tech Community
LIVE
Storage Migration Service August Update
Published Aug 23 2019 11:34 AM 11.1K Views
Microsoft

Heya folks, Ned here again. We've released our first set of new features for the Windows Server 2019 Storage Migration Service, as part of cumulative update KB4512534. No need to run a SAC release - this update applies to the RTM version of Server 2019 for one and all. Let's take a look at what the 8C update can do for you and your collection of legacy servers whose time is running out.

 

What's new

Installing KB4512534 on your SMS orchestrator and any WS2019 destination servers gives you:

 

  • Support for source and destination Windows Failover Clusters
  • Support for Samba Linux servers as source devices migrating to Windows Servers
  • Ability to migrate between networks
  • Ability to migrate local groups and users
  • Various bug fixes

Let's dig a little deeper.

 

Cluster Support

With support for Windows Server failover clusters, you can migrate existing clusters to new clusters. The new cluster must exist with a File Server resource installed in either File Server for General Use or Scale-out File Server mode, and migration from a legacy clustered file server to SOFS is supported.

 

You can also migrate from a standalone server into a new clustered file server resource. Migrating to a cluster has many benefits:

 

  • Your file workloads gain resiliency, availability, and upgradeability. Let's face it: your organization runs on files, and standalone servers without clustering are single points whose failure can cost you a ton of money in your effort to save money. Clusters allow you to reach zero downtime; when everyone else is rebooting for Patch Tuesday, Cluster-aware Updating keeps your workloads online. With cluster rolling upgrades, you might not even need SMS next time.
  • The SMS cutover process is considerably faster, especially for physical machines, as the destination will no longer requires reboots.

You can also migrate to Scale-out File Server from older clusters and standalone servers, but you'll probably choose general use file servers for most end-user workloads, for performance and file services compatibility reasons

 

The migration process in Windows Admin Center for standalone or failover cluster servers is nearly identical, you don't need to change your process. Simply use the default option, and when you get to the cutover, provide domain join credentials for the cluster resource.

 

choose cluster2.PNG

 

Samba on Linux

You can now migrate from Samba running on Linux to Windows Server; this is useful for organizations who built or bought legacy servers years ago that are running very old Samba versions as appliances and don't have upgrade paths; no more SMB1! ;D

 

The Linux and Samba versions we've tested are:

 

  • Debian GNU/Linux 8 
  • SUSE Linux Enterprise Server 11 SP4
  • Ubuntu 16.04 LTS 
  • Ubuntu 12.04.5 LTS
  • CentOS Linux 7 (Core)
  • Red Hat 7.6 (Maipo)
  • Samba 4.2, 4.3, 4.7, 4.8 
  • Samba 3.6

As you can see, we used the most popular distros as a guide; there are far too many variants to comprehensively test them all. And despite all being Linux, we found huge variations in the tools and behaviors between distros that forced us to do a lot of per-distro special casing. 

 

The only difference in migrating from Samba/Linux instead of Windows Server isa new authentication page in Windows Admin Center where you can provide the various credential options for SSH, plus the Samba credentials for emulated Windows.

 

choose linux.PNG

 

linux creds.PNG

 

Once you select a Samba Linux migration and enter in your SSH credentials or certificates then run inventory, you'll see all the SMB shares and storage as you would normally

 

linux volumes.PNG

 

linux config.PNG

 

linux share details.PNG

 

Newer variants and forks of these distros will likely work as well. Some older distros are more problematic, as we found they often lacked management tools; you will have to test and let us know at smsfeed@microsoft.com. The same goes for Samba: from a Windows file server emulation perspective, the API surface should be quite similar between both old and new Samba versions, and the main difference will be protocols (remember, you may need to turn SMB1 back on in Windows Server 2019 in order to migrate!). Because we have no control over Samba or the Linux distros, our support model is "best effort." We will gladly entertain bug fixes here if you find them, though - we want you to succeed.

 

Local User and Group Migration

This is an SMS feature we're especially proud of: SMS will now inventory all local users and groups, then recreate them on the destination during the migration, finding and replacing the SIDs in every transferred file and folder's ACL. When you manually migrate using tools like Robocopy, all of this security is lost - any file or share permission that came from a local security principal is gone, because that SID won't exist on the new destination server. This makes non-domain joined machine migrations particularly problematic, but affects Active Directory users too: we surveyed customers last year and found that even with domain-joined computers, 39% of customers said they used at least one local group or user to access data on their servers. 

 

When you reach the Transfer phase, you'll now see this new set of options:

 

local wac.PNG

 

By default, SMS will migrate all local users and groups on the source server. If it finds matching-named custom groups on the destination, it will rename them unless you opt to merge their members. If it finds matching named users, it will rename the existing one on the destination unless you opt to re-use the account. In either case, the ACLs will be updated on files, folders, and shares to match the security that was on the source computer. Local built-in groups or users (like "Administrators" and "Administrator") will never be renamed. You can opt out of all of this by selecting "Don't transfer users and groups." This is also important if you are using SMS to pre-seed data for DFSR, which will create hash mismatches between servers (DFSR does not support local groups and users). 

 

Here you can see my old 2012 R2 server, where I've ACL'ed a share and NTFS with a custom local group.

 

local perm.PNG

 

local ntfs.PNG

 

I made a special user for the IT staff that has access to a high-privilege share, and it's an administrator for break-glass scenarios. 

 

local user source.PNG

 

local user source groups.PNG

 

After my data transfer completes and SMS recreates all the shares on the destination, my local user and group have been created on the new Windows Server 2019 destination and all the ACLs set, along with all the existing built-in group security set everywhere so that no access was lost.

 

local user perm migrated.PNG

 

As you can see, my local user is disabled - this is intentional. We do not copy passwords, and instead assign a new random Unicode wide 127-character password. The account is disabled so that admins can intentionally set the password to something new and enable it. Any accidental stale local accounts with forgotten weak passwords that travel won't continue to be security problems. You should go setup LAPS when you're done, because you're diligent and hard-working.

 

local user dest.PNG

 

local user dest 2.PNG

 

We also added the popular CSV logs to the transfer details section for local users and groups, just like you've had for files and shares. Press a button and you get an audit trail.

 

{FCB2777B-2BCD-4379-A59C-EDFC97A81C79}.png

 

Network Move

Finally, we've added the ability control your network migrations. By default, we migrate IP addresses for each source network interface to the destination. You map them in the cutover phase, so that users and applications that were accessing your old servers by their IP address instead of DNS name or (shudder) WINS name will not be broken by the migration. For most customers, you'll get to this screen, map the new interfaces to the old interfaces, set DHCP or a new static IP on the old interface, and never touch anything else. 

 

cutover 1.PNG

 

For customers wanting to migrate to a new network though - such as an Azure network, hint hint - and who aren't worried about old IP addresses changing, we now let you skip mapping some or all destination interfaces. Whatever IP they have will still be there when cutover is done. You'll still need to change the IP or set DHCP on the source computers of course; otherwise, we didn't really do a cutover - your users and apps may still talk to the old server by IP address, which is Very Bad ™. 

 

cutover 3.PNG

 

cutover 2.PNG

Sum up

We've got updates coming to the SMS documentation to cover all this; I know how your boss wants the "official" answer (even though I wrote that article as well :D ).

 

The KB4512534 cumulative update is available on the Microsoft Catalog for download, and will automatically install via Windows Update in the September patch Tuesday release. I hope these new features help you leave Windows Server 2008 behind - there isn't much time!

 

- Ned "I told you I'd do it!" Pyle

15 Comments
Copper Contributor

Got an error, for Samba Storage Migration:

 

08.29.2019-13:09:20.931 [Crit] Encountered exception System.NullReferenceException: Object reference not set to an instance of an object.

at Microsoft.StorageMigration.Common.LinuxNetworkingutils.IsStaticIPConfigured(ISmsEventProvider logger, String deviceName, SSHCredentials sshCredentials, String iface, String& networkConfigType, Boolean isCutoverSourceIPSettingFlow)

at Microsoft.StorageMigration.Proxy.Service.Discovery.DiscoveryUtils.GetLinuxNetworkInfo(ISmsEventProvider logger, String deviceName, String userName, String password, Char[] privateKey, Char[] passPhrase, String hostFingerPrint) while getting OSInfo with SSH connection on device 192.168.0.40 [d:\os\src\base\dms\proxy\discovery\discoveryproxy\utils\DiscoveryUtils.cs::GetLinuxNetworkInfo::916]

 

I guess it's the network, but storage migration did read the network config before.

Microsoft

Sorry for the delay, I got this while I was on vacation. Can you tell me more about the repro (Linux kernel ver, exact distro). We'll need to be able to reproduce here unless it's something specific to your environment (in which case it will mean you need to open a Support case).

Brass Contributor

Hello Ned,

 

I am trying to migrate a Clustered General Purpose File Server (WS2016 to WS2019), but the scan is failing in Windows Admin Center v1904 with the following message:

 

2019-09-12_22-18-42.png

DLL WAS NOT FOUND.

 

Could you please advise?

 

Thank You!

-Charbel

Microsoft

Well that's a new one on me, buddy :D.

 

Can you run the log collector from https://aka.ms/smslogs on the orchestrator and email me where I can grab the ZIP file? Since you're an MVP under NDA, I can look at your logs directly without a support case, unlike usual.

Brass Contributor

Thank you buddy, much appreciated!

 

I will do and send you the ZIP file.

Copper Contributor
I assume you are running the SMS on a SMS orchestration server? If so, my workaround for this problem was to install the Failover Cluster Management Tools and Failover Cluster Module for Windows PowerShell.
Copper Contributor

This should be so simple, but something isn't working for me.  I did exactly as you said, but the Source IP isn't migrating to the new Server.  This is a simple transfer from a 2008 R2 Machine to a 2019 Datacenter box.  What am I missing?

Microsoft

Is the cutover completing without the IP migrating, or is the cutover stuck at some % complete? If the latter, it's likely this bug (which we are releasing a patch for soon): https://docs.microsoft.com/en-us/windows-server/storage/storage-migration-service/known-issues#cutov... 

Copper Contributor

I have tried it several ways, but the result that I am looking for is that the Hostname and the IP address of the source computer migrate to the new server.  The process finishes normally.  I reach 100% and the cutover completes without errors.  But no matter how I try it, the hostname migrates, but the IP address stays the same as it originally was on the Destination server.  So as an example, the source computer is IP address x.x.x.115, and the destination is x.x.x.118.  I would expect that after the cutover, that the source would be DHCP and the destination would be x.x.x.115, but it still winds up x.x.x.118.

Microsoft

Oh, that's something we've never seen before. The cutover should actually be failing - it is required to set the new IP or fail out. Are you using any kind of non-standard networking here (teaming, 3rd party NIC management software, etc) that might be swallowing the attempt or the error? Perhaps it is changing then being set back - I was trying to find some reliable event logging for this in Windows and surprisingly could not, will keep digging.

 

We'd need to see your logs to get to the bottom of this. Because of GDPR policy, I cannot ask for these logs directly, you have to open a an MS Support case. They can engage me if they have questions after looking through the data. 

Copper Contributor

Same issue as @Jeffwb2u, migrating from 2008R2 and in our testing its successful and 100% however the IP address doesn't migrate. was a resolution ever found for that? 

 

I see a warning in logs about failing to determine OS on the new server during the setting ips on destination section, everything else appears ok in terms of the setting IP/DNS etc steps however the IP doesn't get changed

 

05/11/2020-17:00:12.913 [Info] Setting IPs on destination machine [d:\os\src\base\dms\proxy\cutover\cutoverproxy\NetworkInterfaceMapper.cs::MapDestinationInterfaces::1258]

 

05/11/2020-17:00:13.322 [Warn] Failed to determine OS version for new server. Error 0x5 [d:\os\src\base\dms\proxy\common\proxycommon\CimSessionHelper.cs::GetOsVersion::76]

 

 

05/11/2020-17:00:15.532 [Info] Mapping adapter 'Intel(R) PRO/1000 MT Network Connection' from 'old server' to adapter 'vmxnet3 Ethernet Adapter' on 'new server' [d:\os\src\base\dms\proxy\cutover\cutoverproxy\NetworkInterfaceMapper.cs::MapDestinationInterfacesStandalone::1347]

 

05/11/2020-17:00:15.533 [Info] Adapter 'vmxnet3 Ethernet Adapter' from 'xxxxxxx': interfaceIndex=1 [d:\os\src\base\dms\proxy\cutover\cutoverproxy\NetworkInterfaceMapper.cs::MapDestinationInterfacesStandalone::1361]

 

05/11/2020-17:00:15.533 [Info] Getting destination network adapter with index 1 [d:\os\src\base\dms\proxy\cutover\cutoverproxy\NetworkInterfaceMapper.cs::MapDestinationInterfacesStandalone::1365]

 

05/11/2020-17:00:15.606 [Info] Adapter 'vmxnet3 Ethernet Adapter' on 'xxxxxxxxxxxxxxxxx': EnableWINS(False,True,,)

[d:\os\src\base\dms\proxy\cutover\cutoverproxy\NetworkInterfaceMapper.cs::EnableWINS::950]

 

05/11/2020-17:00:15.653 [Info] Adapter 'vmxnet3 Ethernet Adapter' on 'xxxxxxxxxxxxx': EnableDNS([xxxxxxxxxxxxx]) [d:\os\src\base\dms\proxy\cutover\cutoverproxy\NetworkInterfaceMapper.cs::EnableDNS::1036]

Microsoft

The previous person never opened a case or provided logs AFAIK. Your error was earlier in these logs, you are just seeing the result of not being able to contact the server with that OS warning. I need you to open a support case to figure this out - if it's a bug the case will be free. 

Copper Contributor

Hi Ned,

 

Don't have $500 to gamble on the fact Microsoft may decide this is a bug or not i'm afraid.

 

We are just going to have to go with manually setting the IP address ourselves but In any case it definitely appears to not work between 2008r2 and 2019 I have tested a 2019 to 2019 migration and it works fine. With a different 2008r2 to a different 2019 server i also see the same issue (version 1.83.2 of the SMS service and 1910.2 of the admin centre)

 

Including below incase it helps you anyway.

 

for the 2019 - 2019 after the events setting DNS we then see 2 events about the gateway and creating the IP address on the destination server

 

05/12/2020-16:04:43.767 [Info] Adapter 'vmxnet3 Ethernet Adapter' on 'xxxxxxx': EnableWINS(False,True,,) [d:\os\src\base\dms\proxy\cutover\cutoverproxy\NetworkInterfaceMapper.cs::EnableWINS::950]

05/12/2020-16:04:43.782 [Info] Adapter 'vmxnet3 Ethernet Adapter' on 'xxxxxxxxx': EnableDNS([xxxxxx,xxxxx], [xxxxxxxxx]) [d:\os\src\base\dms\proxy\cutover\cutoverproxy\NetworkInterfaceMapper.cs::EnableDNS::1036]

05/12/2020-16:04:43.876 [Info] For IP '1.2.3.4' on source computer the gateway is '1.2.3.254' [d:\os\src\base\dms\proxy\cutover\cutoverproxy\NetworkInterfaceMapper.cs::AddStaticIPsFromSource::1112]

05/12/2020-16:04:43.876 [Info] Creating IP '1.2.3.4', prefixLength '16', gateway '1.2.3.245' on adapter 'vmxnet3 Ethernet Adapter' on 'xxxxxxxxx' (interface index 3) [d:\os\src\base\dms\proxy\cutover\cutoverproxy\NetworkInterfaceMapper.cs::AddStaticIPsFromSource::1113]

 

for the 2008r2 --> 2019 we see the events where it sets the wins/dns and then there are no no events logged regarding setting the ip address on the destination server.

 

05/12/2020-16:59:05.237 [Info] Adapter 'vmxnet3 Ethernet Adapter' on 'xxxxxxxxxxxxxx': EnableWINS(False,True,,) [d:\os\src\base\dms\proxy\cutover\cutoverproxy\NetworkInterfaceMapper.cs::EnableWINS::950]

05/12/2020-16:59:05.237 [Info] Adapter 'vmxnet3 Ethernet Adapter' on 'xxxxxxx': EnableDNS([xxxxx,xxxxx], [xxxxx]) [d:\os\src\base\dms\proxy\cutover\cutoverproxy\NetworkInterfaceMapper.cs::EnableDNS::1036]

05/12/2020-16:59:05.300 [Info] Start cutover operation async. [d:\os\src\base\dms\proxy\cutover\cutoverproxy\CutoverService.cs::StartOperation::55]

Microsoft

Fair enough. I can say that we have not heard of this issue outside of you two customers, and I'd highly suspect both an unusual network condition specific to your environments combined with a bug or design flaw in our cutover. A recent example of this was us finding customers who don't set subnet gateways on their server NICs, which was a case we weren't able to handle correctly and the cutover would get stuck at.

 

In this case we'd need to look directly to see what's going on. :\

Copper Contributor

@CHARBEL NEMNOM

 

This was the workaround for the DLL error on a 2012R2 SOFS.

Error "Dll was not found" when running inventory from a cluster node

When attempting to run inventory with the Storage Migration Service and targeting a Windows Server failover cluster general use file server source, you receive the following errors:

DLL not found
[Error] Failed device discovery stage VolumeInfo with error: (0x80131524) Unable to load DLL 'Microsoft.FailoverClusters.FrameworkSupport.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

To work around this issue, install the "Failover Cluster Management Tools" (RSAT-Clustering-Mgmt) on the server running the Storage Migration Service orchestrator.

Version history
Last update:
‎Nov 12 2020 05:16 PM
Updated by: