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