In-Depth
The Downside of Windows Server 2016 for Virtualization Admins
Not all the virtualization upgrades are improvements.
Microsoft has released Windows Server 2016, and it's replete with yummy virtualization goodness. While there is a lot of good packed in to the announcement, Server 2016 also marks the adoption of many controversial or simply bad practices that were pioneered with Windows 10.
They're Watching
On the controversial side is the inability to
turn off telemetry in Windows Server 2016. Privacy- or security-conscious administrators will have to either learn to love the all-seeing eye, or abandon the platform altogether. No middle ground is offered.
One important practical consideration is that systems not connected to the Internet, or which have limited connectivity, should set their telemetry level to "security" (the lowest level Microsoft allows), to limit the buildup of pending telemetry data in the queue. More about telemetry levels here.
Thankfully, the current release of Windows Server 2016 does not appear to install any aspect of Cortana by default, so having to cope with that particular security cluster migraine is delayed. It is worth bearing in mind, however, that with Windows 10, Microsoft has had no issues with making significant changes to the operating system with the various major releases, and it is unknown how they will treat Windows Server 2016 in this regard.
(Un)fortunately for virtualization administrators, network security is increasingly our responsibility. The tools to clamp down on telemetry (or Cortana, should she appear) are increasingly placed in our hands.
Cumulative Updates
This brings us to the simply bad choice: cumulative updates. Systems administrators whose job it is to simply build a new VM or server and then walk away love the idea. Application administrators have expressed notably less enthusiasm to me.
Microsoft envisions a world where all instances of Windows are fully patched, and the "fragmentation" caused by administrators rolling back patches that cause problems is eliminated. From Microsoft's point of view, this makes perfect sense: it's cheaper and easier to support homogenous install bases.
Of course, a server isn't a MacBook, and users tend to get a mite tetchy when some patch happens along that borks the printers for everyone. Independent Software Vendors (ISVs) also may not care overmuch that some Microsoft patch has broken their app. They may well be perfectly OK with you having to choose between applying the security updates that are part of the cumulative update and being able to use their application.
In my experience, ISVs know their software is the reason why organizations need IT, and thus operate at their own pace. I personally don't expect them to be bullied by Microsoft into a more responsive development model, nor do I expect Microsoft to care who is harmed or why.
For the virtualization administrator this is going to create immense pressure to automate patch testing. In the real world, very few organizations have the budget to keep a test lab identical to their production environment. This will make virtualization all the more important for it's ability to clone live workloads. Expect copy data management to rise in importance, especially when combined with configuration management and testing management solutions.
Expect also to have to defend some workloads that simply can't be patched. The standoff between Microsoft and ISVs is simply not going end, and virtually every organization will end up with workloads whose operating systems can't be patched beyond a given point, because there is no longer a way to avoid "only the one bad patch".
Protecting Yourself From Microsoft
This will probably mean increased investment in network virtualization and various levels of network security to isolate vulnerable workloads. If you are facing a Windows Server refresh, prepare to make the case for all of these tools now, so that you aren't caught unawares later. One way or another, virtualization admins, protecting your network from Microsoft's choices is going to rest on you.
About the Author
Trevor Pott is a full-time nerd from Edmonton, Alberta, Canada. He splits his time between systems administration, technology writing, and consulting. As a consultant he helps Silicon Valley startups better understand systems administrators and how to sell to them.