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 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.




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

Occasional Visitor

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 [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.


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).

Occasional 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:





Could you please advise?


Thank You!



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


Can you run the log collector from 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.

Occasional Contributor

Thank you buddy, much appreciated!


I will do and send you the ZIP file.

Occasional Visitor
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.
New 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?


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): 

New 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.


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. 

Frequent Visitor

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,,)



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]


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. 

Frequent Visitor

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 '' on source computer the gateway is '' [d:\os\src\base\dms\proxy\cutover\cutoverproxy\NetworkInterfaceMapper.cs::AddStaticIPsFromSource::1112]

05/12/2020-16:04:43.876 [Info] Creating IP '', prefixLength '16', gateway '' 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]


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. :\