While Windows 10 Redstone 4 is still in a sort of limbo, Redstone 5 development is well underway. Microsoft today released a new RS5 build of Windows Server, bringing the build number to 17650, which aligns with the latest Windows 10 client Insider Preview.
The main areas that Microsoft wants feedback on are still In-place OS Upgrades and application compatibility. In-place OS Upgrades are from either Windows Server 2012 R2 or Windows Server 2016.
That's not new to this build though, as Windows Server 2019 build 17650 contains the following new features:
Failover Clustering: File Share Witness
One of the witness options available for failover clustering, File Share Witness, has two new enhancements.
The first enhancement blocks the use of a Distributed File System (DFS) share as a location. Adding a File Share Witness (FSW) to a DFS share can cause stability issues for your cluster, and this configuration has never been supported. So, we added logic to detect if a share uses DFS, and if DFS is detected, Failover Cluster Manager blocks the creation of the witness and displays an error message about not being supported.
The second enhancement enables the use of an FSW for several scenarios that were previously not supported:
- Absent or extremely poor Internet access because of a remote location, preventing the use of a cloud witness.
- Lack of shared drives for a disk witness. This could be a Storage Spaces Direct hyperconverged configuration, a SQL Server Always On Availability Groups (AG), or an Exchange Database Availability Group (DAG), none of which use shared disks.
- Lack of a domain controller connection due to the cluster being behind a DMZ.
- A workgroup or cross-domain cluster for which there is no Active Directory cluster name object (CNO). Find out more about these enhancements in the following posts in Server & Management Blogs: Failover Cluster File Share Witness and DFS New File Share Witness Feature in Windows Server 2019
Failover clustering: Moving Clusters between domains
Moving a cluster from one domain to another has always been a daunting task because you must destroy the cluster to move it. Depending on the roles in the cluster, that role must also be removed and recreated. The following are two common scenarios:
- Company A purchases Company B and must move all servers to Company A’s domain
- Main office builds a cluster and ships it to another location
We have added two new PowerShell commandlets to quickly take you from one domain to another without the need to destroy it. For more information about this new capability, see How to Switch a Failover Cluster to a New Domain in Server & Management blogs.
Storage Replica (SR) was first released as a technology for Windows Server 2016 Datacenter Edition. SR enables synchronous and asynchronous block replication of volumes between servers or clusters for disaster recovery. SR also enables you to create stretch failover clusters that span two sites, with all nodes staying in sync.
Beginning with Windows Server 2019, responding to customer requests, we’ve added the following improvement to SR:
- Storage Replica Standard. SR is available on Windows Server 2019 Standard Edition, not just on Datacenter Edition. When installed on servers running Standard Edition, SR has the following limitations:
– SR replicates a single volume instead of an unlimited number of volumes.
– Volumes can have one partnership instead of an unlimited number of partners.
– Volumes can have a size of up to 2 TB instead of an unlimited size.
We will continue to listen to your feedback and evaluate these settings through our telemetry during Insider previews of Windows Server 2019. These limitations may change several times during the preview phase and at RTM.
There are also some known issues to be aware of:
In‑place OS upgrade: Domain Controllers. During an in-place OS upgrade, Active Directory (AD) Domain Controllers (DC) might not be upgraded correctly. So, back up any AD DCs before performing an in-place OS upgrade.
Editing or creating policies for AppLocker can cause the MMC snap-in to crash when generated rules for a packaged app.
After upgrading the operating system, the AppX database may have corrupted entries, which causes problems for components that use those entries.
As usual, the build expires on July 2, although you certainly shouldn't expect Windows Server 2019 to be finalized before then. It should be released sometime this fall, possibly at Microsoft's Ignite 2018 conference.
To download the latest build of Windows Server 2019, you can find it here.