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.
Installing KB4512534 on your SMS orchestrator and any WS2019 destination servers gives you:
Let's dig a little deeper.
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:
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.
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:
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 firstname.lastname@example.org. 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.
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.
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 ™.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.