Sneak peek: Windows Server 2019 Insider Preview Build 17666

Do you want to know more about what to expect in Windows Server 2019 when it fully launches later this year?

Microsoft recently posted a new Insider’s build of the forthcoming Windows Server 2019 release – preview build 17666. You can read their details and sign up to be an Insider, if you haven’t already. If you have spare hardware or enough capacity to run an additional virtual machine, I strongly encourage you to take a look for yourself. I’m going to cover the focal points of this specific build.

Ongoing Testing Request

If you will continue to follow the Insider’s builds through to final release, then Microsoft would like you to test two things at each build:

• In-place upgrade from WS2012R2 and/or WS2016
• Compatibility with applications

I have not yet attempted this myself. I intend to export/import a functioning test system and use a checkpoint to hold it at a point immediately prior to an upgrade. At each build, I will revert to the creation point of that checkpoint and install the new build. If you take the effort to do the same, don’t forget to report your findings! To do so you can use the Feedback Application on your Windows 10 desktop, select the server category and then choose the applicable sub-category for your feedback.

Build 17666 Feature 1: Improved Performance History for Storage Spaces Direct

Unfortunately, I do not have a functioning Storage Spaces Direct (S2D) build to test, so I can’t give you any screenshots.

WS2019 will introduce automatic gathering of performance history data for S2D clusters. Windows Admin Center (formerly Project Honolulu) displays that data graphically. You can also use PowerShell to gather the information. You can use that to build your own charts, store it in a database, or whatever else you’ve got in mind. The nice thing here being you can see how your S2D performance is changing over time, and potentially time major changes with certain milestones for the cluster, such as patching, the addition of a new workload….etc…etc.

Build 17666 Feature 2: Changes to the Storage Spaces Direct PowerShell Cmdlets

In 17666, the Windows Server team improved the PowerShell module for S2D performance history. They made the output more compatible with several of PowerShell’s native object group manipulation cmdlets (Sort-Object, Where-Object, and Measure-Object). A page dedicated to this feature shows a number of examples. A few new metrics were added: read cache hits, write cache hits, and CSV cache hits.

Be aware that some of the object names have changed, which could cause some scripts written against a prior build to produce some empty fields. As of this writing, Windows Admin Center has not yet been updated to reflect the new names either, so it will have a few empty charts.

A New Cmdlet for S2D Volumes to Manually Delimit Allocation

The update contains a new cmdlet to make management of manually delimited volumes a bit easier: Get-StorageScaleUnit. This cmdlet will display any volumes that you’ve manually configured and their delimitation parameters. It can accept input from and send output to Get-VirtualDisk. For more information, see the related docs page.

Commentary on Windows Server 2019 Build 17666

Nothing in this build comes as a shock, especially if you’ve been involved in any of the Semi-Annual Channel and/or Insider program for long. Storage Spaces Direct continues to ride high as the hot new “killer feature”, so it gets lots of attention. If you have no interest in S2D, then you won’t have anything special to test in this build. Of course, other things always change in every release, so I advise against skipping the release. If you skip it and encounter a bug in a later release, you won’t know for certain which build introduced it.

I always like expansions to PowerShell capabilities, so I welcome those improvements. Hopefully, no one had become overly attached to the object names that changed. Using pre-release software inherently carries dangers, and such a minor thing should barely register for most. On the other side of things, I expect the S2D community will gladly accept the new cache metrics.

I cannot make any reasonable predictions about the changes to manually delimited allocation (note: the feature was introduced in build 17093; build 17666 simply adds the Get-StorageScaleUnit cmdlet). I feel that in order for S2D to gain widespread acceptance, it needs to use up a minimum of administrative time. Windows administrators already have full plates; adding “manage your own storage” to the list won’t make many of us happy. If you choose to delimit S2D allocation yourself, you accept a great deal of responsibility and you must outsmart the system to make it worth your time. Of course, Microsoft would not have put forth the effort to build out this level of control if no one wanted it. This cmdlet will help, of course, but you’re still taking on a consequential management chore.

How about you? What are your thoughts on this build? Are you excited about the focus on S2D or are you clambering for other enhancements and features? Let us know in the comments section below!