Understanding the Windows Server Semi-Annual Channel

Understanding the Windows Server Semi-Annual Channel

Microsoft has made major changes to the way that they build and release their operating systems. The new Windows Server “Semi-Annual Channel” (SAC) marks a substantial departure from the familiar release pattern that Microsoft has established. The change has pleased some people, upset many, and confused even more. With all the flash of new features, it’s easy to miss the finer points — specifically, how you, your organization, and your issues fit into the new model.

The Traditional Microsoft OS Release Model

Traditionally, Microsoft would work on pre-release builds internally and with a small group of customers, partners, and other interested stakeholders (such as MVPs). Then, they would finesse the builds with open betas (usually called “Release Candidates”). Then, there would be an RTM (release-to-manufacturing) event followed by GA (general availability). The release would then be considered “current”. It would enjoy regular updates including service packs and feature upgrades for a few years, then it would go into “extended support” where it would only get stability and security updates. While customers purchased and worked with the “current” version, work on the next version would begin in parallel.

Not every version followed this model exactly, but all of them were similar. The most recent Windows Server operating system to employ this model is Windows Server 2016.

Changes to the Model with Windows 10/Server 2016

The “Windows Insider Program” was the first major change to Microsoft’s OS build and release model. Initially, it was most similar to the “release candidate” phase of earlier versions. Anyone could get in and gain access to Windows 10 builds before Windows 10 could even be purchased. However, it deviated from the RC program in two major ways:

  • The Windows Insider Program includes an entire community.
  • The Windows Insider Program continues to provide builds after Windows 10 GA

The Windows Insider Community

Most of us probably began our journey to Windows Insider by clicking an option in the Windows 10 update interface. However, you can also sign up using the dedicated Windows Insider web page. You get access to a dedicated forum. And, of course, you’ll get e-mail notifications from the program team. You can tell Microsoft what you think about your build using the Feedback Hub. That applet is not exclusive to Insiders, but they’ll know if you’re talking about an Insider build or a GA build.

Ongoing Windows Insider Builds

I expect that most Insiders prize access to new builds of Windows 10 above the other perks of the program. The Windows 10 Insider Program allows you to join one of multiple “rings” (one per joined Windows 10 installation). The ring that an installation belongs to dictates how close it will be to the “cutting edge”. You can read up on these rings and what they mean on the Insider site.

The most important thing about Windows Insider builds — and the reason that I brought them up at all in this article — is that they are not considered production-ready. The fast ring builds will definitely have problems. The preview release builds will likely have problems. You’re not going to get help for those problems outside of the Insider community, and any fix will almost certainly include the term “wait for the next build” (or the next… or the one after… or some indeterminate future build). I suspect that most software vendors will be… reluctant… to officially support any of their products on an Insider build.

Windows Server Insider Program

The Windows Server Insider Program serves essentially the same purpose as the Windows 10 Insider Program, but for the server operating system. The sign-up process is a bit different, as it goes through the Windows Insider Program for Business site. The major difference is the absence of any “rings”. Only one current Windows Server Insider build exists at any given time.

Introducing the Windows Server Semi-Annual Channel

I have no idea what you’ve already read, so I’m going to assume that you haven’t read anything. But, I want to start off with some very important points that I think others gloss over or miss entirely:

  • Releases in the Windows Server Semi-Annual Channel are not Windows Server 2016! Windows Server 2016 belongs to the Long-Term Servicing Channel (LTSC). The current SAC is simply titled “Windows Server, version 1709”.
  • You cannot upgrade from Windows Server 2016 to the Semi-Annual Channel. For all I know, that might change at some point. Today, you can only switch between LTSC and SAC via a complete wipe-and-reinstall.
  • On-premises Semi-Annual Channel builds require Software Assurance (I’d like to take this opportunity to point out: so does Nano). I haven’t been in the reseller business for a while so I don’t know the current status, but I was never able to get Software Assurance added to an existing license. It was always necessary to purchase it at the same time as its base volume Windows Server license. I don’t know of any way to get Software Assurance with an OEM build. All of these things may have changed. Talk to your reseller. Ask questions. Do your research. Do not blindly assume that you are eligible to use an SAC build.
  • The license for Windows Server is interchangeable between LTSC and SAC. Meaning that, if you are a Software Assurance customer, you’ll be able to download/use either product per license count (but not both; 1 license count = 1 license for LTSC or 1 license for SAC).
  • The keys for Windows Server are not interchangeable between LTSC and SAC. I’m not yet sure how this will work out for Automatic Virtual Machine Activation. I did try adding the WS2016 AVMA key to a WS1709 guest and it did not like that one bit.
  • SAC does not offer the Desktop Experience. Meaning, there is no GUI. There is no way to install a GUI. You don’t get a GUI. You get only Core.
  • Any given SAC build might or might not have the same available roles and features as the previous SAC build. Case in point: Windows Server, version 1709 does not support Storage Spaces Direct.
  • SAC builds are available in Azure.
  • SAC builds are supported for production workloads. SAC follows the Windows Server Insider builds, but SAC is not an Insider build.
  • SAC builds will only be supported for 18 months. You can continue using a specific SAC build after that period, but you can’t get support for it.
  • SAC builds should release roughly every six months.
  • SAC builds will be numbered for their build month. Ex: 1709 = “2017 September (09)”.
  • SAC ships in Standard and Datacenter flavors only.

what is the windows server semi-annual channel

The Semi-Annual Channel is Not for Everyone

Lots of people have lots of complaints about the Windows Server Semi-annual Channel. I won’t judge the reasonableness or validity of any of them. However, I think that many of these complaints are based on a misconception. People have become accustomed to a particular release behavior, so they expected SAC to serve as vNext of Windows Server 2016. Looking at Microsoft’s various messages on the topic. I don’t feel like they did a very good job explaining the divergence. So, if that’s how you look at it, then it’s completely understandable that you’d feel like WS1709 slapped you in the face.

However, it looks different when you realize that WS1709 is not intended as a linear continuation. vNext of Windows Server 2016 will be another release in the LTSC cycle. It will presumably arrive sometime late next year or early the following year, and it will presumably be named Windows Server 2018 or Windows Server 2019. Unless there are other big changes in our future, it will have the Desktop Experience and at least the non-deprecated roles and features that you currently have available in WS2016. Basically, if you just follow the traditional release model, you can ignore the existence of the SAC releases.

Some feature updates in SAC will also appear in LTSC updates. As an example, both WS1709 and concurrent WS2016 patches introduce the ability for containers to use persistent data volumes on Cluster Shared Volumes.

Who Benefits from the Semi-Annual Channel?

If SAC is not meant for everyone, then who should use it? Let’s get one thing out of the way: no organization will use SAC for everything. The LTSC will always have a place. Do not feel like you’re going to be left behind if you stick with the LTSC.

I’ll start by simplifying some of Microsoft’s marketing-speak about targeted users:

  • Organizations with cloud-style deployments
  • Systems developers

Basically, you need to have something akin to a mission-critical level of interest in one or more of these topics:

  • Containers and related technologies (Docker, Kubernetes, etc.)
  • Software-defined networking
  • High-performance networking. I’m not talking about the “my test file copy only goes 45Mbps” flavor of “high performance” networking, but the “processing TCP packets between the real-time interface and its OLTP database causes discernible delays for my 150,000 users” flavor.
  • Multiple large Hyper-V clusters

Read the “What’s New” article for yourself. If you can’t find any must-have-yesterdays in that list, then don’t worry that you might have to wait twelve to eighteen months for vNext of LTSC to get them.

Who Benefits from the Long-Term Servicing Channel?

As I said, the LTSC isn’t going anywhere. Not only that, we will all continue to use more LTSC deployments than SAC deployments.

Choose LTSC for:

  • Stability. Even though SAC will be production-ready, the lead time between initial conception and first deployment will be much shorter. The wheel for new SAC features will be blocky.
  • Predictability: The absence of S2D in WS1709 caught almost everyone by surprise. That sort of thing won’t happen with LTSC. They’ll deprecate features first to give you at least one version’s worth of fair warning. (Note: S2D will return; it’s not going away).
  • Third-party applications: We all have vendors that are still unsure about WS2008. They’re certainly not going to sign off on SAC builds.
  • Line-of-business applications: Whether third-party or Microsoft, the big app server that holds your organization up doesn’t need to be upgraded twice each year.
  • The GUI.

What Does SAC Mean for Hyper-V?

The above deals with Windows Server Semi-Annual Channel in a general sense. Since this is a Hyper-V blog, I can’t leave without talking about what SAC means for Hyper-V.

For one thing, SAC does not have a Hyper-V Server distribution. I haven’t heard of any long-term plans, so the safest bet is to assume that future releases of Hyper-V Server will coincide with LTSC releases.

As far the Hyper-V role, it perfectly fits almost everything that SAC targets. Just look at the new Hyper-V-related features in 1709:

  • Enhanced VM load-balancing
  • Storage of VMs in storage-class memory (non-volatile RAM)
  • vPMEM
  • Splitting of “guest state” information out of the .vmrs file into its own .vmgs file
  • Support for running the host guardian service as a virtual machine
  • Support for Shielded Linux VMs
  • Virtual network encryption

Looking at that list, “Shielded Linux VMs” seems to have the most appeal to a small- or medium-sized organization. As I understand it, that’s not a feature so much as a support statement. Either way, I can shield a Linux VM on my fully-patched Windows Server 2016 build 1607 (LTSC) system.

As for the rest of the features, they will find the widest adoption in larger, more involved Hyper-V installations. I obviously can’t speak for everyone, but it seems to me that anyone that needs those features today won’t have any problems accepting the terms that go along with the switch to SAC.

For the rest of us, Hyper-V in LTSC has plenty to offer.

What to Watch Out For

Even though I don’t see any serious problems that will result from sticking with the LTSC, I don’t think this SKU split will be entirely painless.

For one thing, the general confusion over “Windows Server 2016” vs. “Windows Server, version 1709” includes a lot of technology authors. I see a great many articles with titles that include “Windows Server 2016 build 1709”. So, when you’re looking for help, you’re going to need to be on your toes. I think the limited appeal of the new features will help to mitigate that somewhat. Still, if you’re going to be writing, please keep the distinction in mind.

For another, a lot of technology writers (including those responsible for documentation) work only with the newest, hottest tech. They might not even think to point out that one feature or another belongs only to SAC. I think that the smaller target audience for the new features will keep this problem under control, as well.

The Future of LTSC/SAC

All things change. Microsoft might rethink one or both of these release models. Personally, I think they’ve made a good decision with these changes. Larger customers will be able to sit out on the bleeding edge and absorb all the problems that come with early adoption. By the time these features roll into LTSC, they’ll have undergone solid vetting cycles on someone else’s production systems. Customers in LTSC will benefit from the pain of others. That might even entice them to adopt newer releases earlier.

Most importantly, effectively nothing changes for anyone that sticks with the traditional regular release cycle. Windows Server Semi-Annual Channel offers an alternative option, not a required replacement.

Hyper-V 2016 Host Mode: GUI vs Core

Hyper-V 2016 Host Mode: GUI vs Core

Choice is a good thing, right? Well… usually. Sometimes, choice is just confusing. With most hypervisors, you get what you get. With Hyper-V, you can install in three different ways, and that’s just for the server hypervisor. In this article, we’ll balance the pros and cons of your options with the 2016 SKUs.

Server Deployment Options for Hyper-V

As of today, you can deploy Hyper-V in one of four packages.

Nano Server

When 2016 initially released, it brought a completely new install mode called “Nano”. Nano is little more than the Windows Server kernel with a tiny handful of interface bits attached. You then plug in the roles and features that you need to get to the server deployment that you want. I was not ever particularly fond of the idea of Hyper-V on Nano for several reasons, but none of them matter now. Nano Server is no longer supported as a Hyper-V host. It currently works, but that capability will be removed in the next iteration. Part of the fine print about Nano that no one reads includes the requirement that you keep within a few updates of current. So, you will be able to run Hyper-V on Nano for a while, but not forever.

If you currently use Nano for Hyper-V, I would start plotting a migration strategy now. If you are considering Nano for Hyper-V, stop.

Hyper-V Server

Hyper-V Server is the product name given to the free distribution vehicle for Hyper-V. You’ll commonly hear it referred to as “Hyper-V Core”, although that designation is both confusing and incorrect. You can download Hyper-V Server as a so-called “evaluation”, but it never expires.

A word of advice: Hyper-V Server includes a legally-binding license agreement. Violation of that licensing agreement subjects you to the same legal penalties that you would face for violating the license agreement of a paid operating system. Hyper-V Server’s license clearly dictates that it can only be used to host and maintain virtual machines. You cannot use it as a file server or a web server or anything else. Something that I need to make extremely clear: the license agreement does not provide special allowances for a test environment. I know of a couple of blog articles that guide you to doing things under the guise of “test environment”. That’s not OK. If it’s not legal in a production environment, it doesn’t magically become legal in a test environment.

Windows Server Core

When you boot to the Windows Server install media, the first listed option includes “Core” in the name. That’s not an accident; Microsoft wants you to use Core mode by default. Windows Server Core excludes the primary Windows graphical interface and explorer.exe. Some people erroneously believe that means that no graphical applications can be run at all. Applications that use the Explorer rendering engine will not function (such as MMC), but the base Windows Forms libraries and mechanisms exist.

Windows Server with GUI

I doubt that the GUI mode of Windows Server needs much explanation. You have the same basic graphical interface as Windows 10 with some modifications that make it more appropriate for a server environment. When you install from 2016 media, you will see this listed as (Desktop Experience).

The Pros and Cons of the Command-line and Graphical Modes for Hyper-V

I know that things would be easier if I would just tell you what to do. If I knew you and knew your environment, I might do that. I prefer giving you the tools and knowledge to make decisions like this on your own, though. So, we’ll complement our discussion with a pros and cons list of each option. After the lists, I’ll cover some additional guidelines and points to consider.

Hyper-V Server Pros and Cons

If you skipped the preamble, remember that “Hyper-V Server” refers to the completely free SKU that you can download at any time.

Pros of Hyper-V Server:

  • Never requires a licensing fee
  • Never requires activation
  • Smallest deployment
  • Smallest “surface area” for attacks
  • Least memory usage by the management operating system
  • Fewest patch needs
  • Includes all essential features for running Hyper-V (present, not necessarily enabled by default):
    • Hyper-V hypervisor
    • Hyper-V PowerShell interface
    • Cluster membership
    • Domain membership
    • Hyper-V Replica membership
    • Remote Desktop Virtual Host role for VDI deployments
    • RemoteFx (automatic with RDVH role)

Cons of Hyper-V Server:

  • Cannot provide Automatic Virtual Machine Activation
  • Cannot provide deduplication features
  • Impossible to enable the Windows Server GUI
  • Software manufacturers may refuse to support their software on it
  • Third-party support operations, such as independent consulting firms, may not have any experience with it
  • Switching to Windows Server requires a complete reinstall
  • Difficult to manage hardware

Hyper-V in Windows Server Core Pros and Cons

If you’ve seen the term “Hyper-V Core”, that probably means “Hyper-V Server”. This section covers the authentic Windows Server product installed in Core mode.

Pros of Windows Server Core for Hyper-V:

  • Microsoft recommends Windows Server Core for Hyper-V
  • Receives feature updates on the quickest schedule (look toward the bottom of the link in the preceding bullet)
  • Comparable deployment size to Hyper-V Server
  • Comparable surface area to Hyper-V Server
  • Comparable memory usage to Hyper-V Server
  • Comparable patch requirements to Hyper-V Server
  • Allows almost all roles and features of Windows Server
  • Can provide Automatic Activation for Windows Server in VMs (Datacenter Edition only)

Cons of Windows Server Core for Hyper-V:

  • Impossible to enable the Windows Server GUI
  • Must be licensed and activated
  • Upgrading to the next version requires paying for that version’s license, even if you will wait to deploy newer guests
  • Software manufacturers may refuse to support their software on it
  • Third-party support operations, such as independent consulting firms, may not have any experience with it
  • Difficult to manage hardware

Hyper-V in Windows Server GUI Pros and Cons

We saved what many consider the “default” option for last.

Pros of Windows Server with GUI for Hyper-V:

  • Familiar Windows GUI
  • More tools available, both native and third party
  • Widest support from software manufacturers and consultants
  • Easiest hardware management
  • Valid environment for all Windows Server roles, features, and software
  • Can provide Automatic Activation for Windows Server in VMs (Datacenter Edition only)

Cons of Windows Server with GUI for Hyper-V:

  • Familiarity breeds contempt
  • Slowest feature roll-out cycle (see the bottom of this article)
  • Largest attack surface, especially with explorer.exe
  • Largest deployment size
  • Largest memory usage
  • Largest patch requirements
  • Must be licensed and activated
  • Upgrading to the next version requires paying for that version’s license, even if you will wait to deploy newer guests

Side-by-Side Comparison of Server Modes for Hyper-V

Two items appear in every discussion of this topic: disk space and memory usage. I thought that it might be enlightening to see the real numbers. So, I built three virtual machines running Hyper-V in nested mode. The first contains Hyper-V Server, the second contains Windows Server Datacenter Edition in Core mode, and the third contains Windows Server Datacenter Edition in GUI mode. I have enabled Hyper-V in each of the Windows Server systems and included all management tools and subfeatures ( Add-WindowsFeature -Name Hyper-V -IncludeAllSubFeature -IncludeManagementTools). All came from the latest MSDN ISOs. None are patched. None are on the network.

Disk Usage Comparison of the Three Modes

I used the following PowerShell command to determine the used space: '{0:N0}' -f (Get-WmiObject -Class Win32_LogicalDisk | ? DeviceId -eq 'C:' | % {$_.Size - $_.FreeSpace}).

Deployment Mode Used Disk Space (bytes)
Hyper-V Server 2016 6,044,270,592
Windows Server 2016 Datacenter Edition in Core mode 7,355,858,944
Windows Server 2016 Datacenter Edition in GUI mode 10,766,614,528

For shock value, the full GUI mode of Windows Server adds 78% space utilization above Hyper-V Server 2016 and 46% space utilization above Core mode. That additional space amounts to less than 5 gigabytes. If 5 gigabytes will make or break your deployment, you’ve got other issues.

Memory Usage Comparison of the Three Modes

We’ll start with Task Manager while logged on:


These show what we expect: Hyper-V Server uses the least amount of memory, Windows Server Core uses a bit more, and Windows Server with GUI uses a few ticks above both. However, I need to point out that these charts show a more dramatic difference than you should encounter in reality. Since I’m using nested VMs to host my sample systems, I only gave them 2 GB total memory apiece. The consumed memory distance between Hyper-V Server and Windows Server with GUI weighs in at a whopping .3 gigabytes. If that number means a lot to you in your production systems, then you’re going to have other problems.

But that’s not the whole story.

Those numbers were taken from Task Manager while logged on to the systems. Good administrators log off of servers as soon as possible. What happens, then, when we log off? To test that, I had to connect each VM to the network and join the domain. I then ran: Get-WmiObject Win32_OperatingSystem | select FreePhysicalMemory with the ComputerName switch against each of the hosts. Check out the results:

Deployment Mode Free Memory (MB)
Hyper-V Server 2016 1,621,148
Windows Server 2016 Datacenter Edition in Core mode 1,643,060
Windows Server 2016 Datacenter Edition in GUI mode 1,558,744

Those differences aren’t so dramatic, are they? Windows Server Core even has a fair bit more free memory than Hyper-V Server… at that exact moment in time. If you don’t have much background in memory management, especially in terms of operating systems, then keep in mind that memory allocation and usage can seem very strange.

The takeaway: memory usage between all three modes is comparable when they are logged off.

Hyper-V and the “Surface Area” Argument

Look at the difference in consumed disk sizes between the three modes. Those extra bits represent additional available functionality. Within them, you’ll find things such as Active Directory Domain Services and IIS. So, when we talk about choosing between these modes, we commonly point out that all of these things add to the “attack surface”. We try to draw the conclusion that using a GUI-less system increases security.

First part: Let’s say that a chunk of malware injects itself into one of the ADDS DLLs sitting on your Windows Server host running Hyper-V. What happens if you never enable ADDS on that system? Well, it’s infected, to be sure. But, in order for any piece of malware to cause any harm, something eventually needs to bring it into memory and execute it. But, you know that you’re not supposed to run ADDS on a Hyper-V host. Philosophical question: if malware attacks a file and no one ever loads it, is the system still infected? Hopefully, you’ve got a decent antimalware system that will eventually catch and clean it, so you should be perfectly fine.

On one hand, I don’t want to downplay malware. I would never be comfortable with any level of infection on any system. On the other hand, I think common sense host management drastically mitigates any concerns. I don’t believe this is enough of a problem to carry a meaningful amount of weight in your decision.

Second part: Windows Server runs explorer.exe as its shell and includes Internet Explorer. Attackers love those targets. You can minimize your exposure by, you know, not browsing the Internet from a server, but you can’t realistically avoid using explorer.exe on a GUI system. However, as an infrastructure system, you should be able to safely instruct your antimalware system to keep a very close eye on Explorer’s behavior and practice solid defensive techniques to prevent malware from reaching the system.

Overall takeway from this section: Explorer presents the greatest risk. Choose the defense-in-depth approach of using Hyper-V Server or Windows Server Core, or choose to depend on antimalware and safe operating techniques with the Windows Server GUI.

Hyper-V and the Patch Frequency Non-Issue

Another thing that we always try to bring into these discussions is the effect of monthly patch cycles. Windows Server has more going on than Hyper-V Server, so it gets more patches. From there, we often make the argument that more patches equals more reboots.

A little problem, though. Let’s say that Microsoft releases twelve patches for Windows Server and only two apply to Hyper-V Server. One of those two patches requires a reboot. In that case, both servers will reboot. One time. So, if we get hung up on downtime over patches, then we gain nothing. I believe that, in previous versions, the downtime math did favor Hyper-V Server a few times. However, patches are now delivered in only a few omnibus packages instead of smaller targeted patches. So, I suspect that we will no longer be able to even talk about reboot frequency.

One part of the patching argument remains: with less to patch, fewer things can go wrong from a bad patch. However, this argument faces the same problem as the “surface area” non-issue. What are you using on your Windows Server system that you wouldn’t also use on a Hyper-V Server system? If you’re using your Windows Server deployment correctly, then your patch risks should be roughly identical.

Most small businesses will patch their Hyper-V systems via automated processes that occur when no one is around. Larger businesses will cluster Hyper-V hosts and allow Cluster Aware Updating to prevent downtime.

Overall takeaway from this section: patching does not make a convincing argument in any direction.

Discussions: Choosing Between Core and GUI for Hyper-V

Now you’ve seen the facts. You’ve seen a few generic arguments for the impact level of two of those facts. If you still don’t know what to do, that’s OK. Let’s look at some situational points.

A Clear Case for Hyper-V on Windows Server Full GUI

If you’re in a small environment with only a single physical server, go ahead and use the full GUI.

Why? Some reasons:

  • It is not feasible to manage Hyper-V without any GUI at all. I advocate for PowerShell usage as strongly as anyone else, but sometimes the GUI is a better choice. In a multi-server environment, you can easily make a GUI-less system work because you have at least one GUI-based management system somewhere. Without that, GUI-less demands too much.
  • The world has a shortage of Windows Server administrators that are willing and able to manage a GUI-less system. You will have difficulty hiring competent help at a palatable price.
  • Such a small shop will not face the density problems that justify the few extra resources saved by the GUI-less modes.
  • The other issues that I mentioned are typically easier to manage in a small environment than in a large environment.
  • A GUI system will lag behind Core in features, but Hyper-V is quite feature-complete for smaller businesses. You probably won’t miss anything that really matters to you.
  • If you try Hyper-V Server or Windows Server Core and decide that you made a mistake, you have no choice but to reinstall. If you install the GUI and don’t want to use it, then don’t use it — switch to remote management practices. You won’t miss out on anything besides the faster feature release cycle.

We can make some very good arguments for a GUI-less system, but none are strong enough to cause crippling pain for a small business. When the GUI fits, use it.

A Clear Case for Hyper-V Server

Let’s switch gears completely. Let’s say that:

  • You’re a PowerShell whiz
  • You’re a cmd whiz
  • You run a lot of Linux servers
  • Your Windows Servers (if any) are all temporary testing systems

Hyper-V Server will suit you quite well.

Everyone Else

If you’re somewhere in the middle of the above two cases, I think that Microsoft’s recommendation of Windows Server Core with Hyper-V fits perfectly. The parts that stand out to me:

  • Flexibility: Deduplication has done such wonders for me in VDI that I’m anxious to see how I can apply it to server loads. In 2012 R2, server guests were specifically excluded; VDI only. Server 2016 maintains the same wording in the feature setup, but I can’t find a comparable statement saying that server usage is verboten in 2016. I could also see a case for building a nice VM management system in ASP.Net and hosting it locally with IIS — you can’t do that in Hyper-V Server.
  • Automatic Virtual Machine Activation. Who loves activation? Nobody loves activation! Let the system deal with that.
  • Security by terror: Not all server admins are created equally. I find that the really incompetent ones won’t even log on to a Server Core/Hyper-V Server system. That means that they won’t put them at risk.
  • Remote management should be the default behavior. If you don’t currently practice remote management, there’s no time like the present! You can dramatically reduce the security risk to any system by never logging on to its console, even by RDP.

You can manage Hyper-V systems from a Windows 10 desktop with RSAT. It’s not entirely without pain, though:

  • Drivers! Ouch! Microsoft could help us out by providing a good way to use Device Manager remotely. We should not let driver manufacturers off the hook easily, though. Note: Honolulu is coming to reduce some of that pain.
  • Not everyone that requires the GUI is an idiot. Some of them just haven’t yet learned. Some have learned their way around PowerShell but don’t know how to use it for Hyper-V. You like taking vacations sometimes, don’t you?
  • Crisis mode when you don’t know what’s wrong can be a challenge. It’s one thing to keep the top spinning; it’s another to get it going when you can’t see what’s holding it down. However, these problems have solutions. It’s a pain, but a manageable one.

I’m not here to make the decision for you. You now have enough information to make an informed decision.

Nano Server No Longer Supported for Infrastructure Workloads

Nano Server No Longer Supported for Infrastructure Workloads


When Windows Server 2016 was released last year, one of the features that I myself, and much of the community were excited about was the new installation option called Nano Server. The way I’ve always described Nano Server is that it’s like Windows Server Core, but on steroids. It is a completely gutted, only-what-you-need installation option, and it’s an installation option that really talked to my Linux and open-source roots. I loved the idea of having only what was absolutely necessary installed on a server, not just because of the attack surface reduction, but because of the reduction in software to maintain on the system as well. I remember running Gentoo Linux on some systems simply because it was a “compile from source” type of distribution and I loved the idea of again, only installing the needed bits, and with Nano Server I felt like we had arrived at something resembling that in the Microsoft world as well.

When Nano Server was released, it was stated that it would be the recommended installation path for containers and for core infrastructure workloads as well. This included things like Hyper-V, Storage Spaces Direct, DNS, IIS… and there was talk of more supported roles coming at some point. This was a lot to get excited about for sure! Hyper-V hosts running with a TINY OS image. It was amazing, it was awesome…  and ultimately, not meant to be.

Nano Server Gets Gutted for Infrastructure Workloads

Last week the Windows Server team hit us with THIS bombshell. Here are the key takeaways from the announcement as far as Nano Server is concerned

  • Going forward, Nano Server will be used primarily as a container image.
  • Support for Infrastructure Workloads and Bare-Metal will be removed from Nano Server. (This includes the removal of support for Hyper-V and Storage Spaces Direct)
  • Windows Server Core will now be the recommended deployment mechanism for Infrastructure roles/features
  • Server Core will also be able to be used as a container image for deployment of traditional applications via container services

You could see some of this coming if you read between the lines in Microsoft’s marketing and what not. The messaging behind Nano never really went further towards infrastructure workloads other than saying its a great installation option for those roles. Installation was difficult, documentation was spread out over several pages, with different UI image builders, and scripted deployment options. It was being used for too many things to be able to keep it as it was, and if I’m really honest with myself, I can understand why this happened.

The concept of something like Nano Server dictates that it be very CLEARLY defined as to what it’s going to be and what it’s going to do. By continuing to add more role and feature support to it, Microsoft was essentially creating another Server Core. Jeff Woolsey from the Hyper-V Product group said it best in that IT Pros using Nano Server for infrastructure wanted more roles/features and more drivers. Devs wanted a smaller footprint for their applications. There was no way to reconcile both of those complaints.

I think Microsoft listened to customer feedback, reviewed telemetry data, and made a decision, that they were not going to continue using Nano Server for infrastructure any longer, and instead they were going to make it the best container image on the market. While it bums me out for my infrastructure stuff, it makes me feel better that it has a VERY specific goal now, and with that, I think Microsoft will succeed in that goal.

So what is the Recommended Installation Option Now?

That leaves us with Server Core as the recommended installation option for infrastructure workloads. I’ve been using Windows Server Core for Hyper-V since the 2008 R2 days and I’ve always found it to fit my needs. Additionally, Microsoft has made a TON of improvements and changes since then like including Server Core in their new Semi-Annual Release Cadence, also announced last week.

If you hadn’t heard, Microsoft will now be bringing core feature updates to Windows Server twice a year, in the spring and fall. This update branch applies to customers that have ALL of the following:

  • Windows Server 2016 Standard or Datacenter
  • Running with the Nano Server or Server Core Deployment Option
  • Active Software Assurance

Also below is a chart from Microsoft detailing the different installation options and their associated channels

Services Branches

Long-Term Servicing Channel

Now I understand that this quicker release cadence isn’t for everyone, and Microsoft gets that too. That’s why they are still providing what they call the Long-term Servicing Channel (LTSC). LTSC is what you’ve been used to using all these years. You install your Windows Server and another big release comes out in a couple of years. In the mean time you get 10 years of support (from the OS release date) on that installed operating system if you don’t decide to upgrade it. This is the best option for those organization that don’t need the latest and greatest features, and perhaps need the most stable branch of server software possible.

What if I already deployed Hyper-V on Nano in Production?

You have support on Nano Server (the Fall 2016 version) until Spring of 2018. You’ll want to migrate those workloads to a Windows Server Core option. Following something similar to the rolling cluster upgrade procedure should help with this process. We actually happen to have a how-to article on that HERE.


While it’s a let down to some, I feel better in that the lines are more clearly defined now. We have Server Core for infrastructure and we have Nano for Containers and both of them will get the attention they deserve moving forward.

As always if you have any follow-up questions and/or comments, be sure to leave a comment below!

Thanks for reading!

Choosing a Management OS for Hyper-V: Hyper-V Server

Choosing a Management OS for Hyper-V: Hyper-V Server

For the server edition of Hyper-V, you have a choice in management operating systems. You can use the free, no-GUI Hyper-V Server or you can use the full-fledged Windows Server. This will be the first of two articles in which I will argue both sides of the debate. In this installment, I’ll take the position that you should use Hyper-V Server.

A Clear Explanation of What Hyper-V Server Is

There’s a lot of confusion around all the various terms for Microsoft’s hypervisor. Microsoft takes no small part of the blame for that, as they use overlapping product names and terms. Some of it is just a natural consequence of the delivery methods. Some of the blame lies with the community, though, as many writers don’t do a great job using non-arbitrary product descriptors. I always cringe when I read an otherwise great article that refers to “Hyper-V Core”. There have been more than a few that I’ve wanted to link to, but I’ve chosen not to as I don’t want to contribute to the confusion.

So, we’re going to start this post off with a chart that clearly indicates what is what:

Term Meaning
Hyper-V “Hyper-V” is Microsoft’s hypervisor technology. There is no way to get Hyper-V all by itself. You must choose one of three possible delivery methods. When using the term “Hyper-V”, you are referring specifically to the hypervisor.
Hyper-V Server “Hyper-V Server” is a standalone product available as a direct download from Microsoft. Despite the awkward placement of the download, it is not an evaluation product download. This is one of the three delivery methods for Hyper-V. It is based on Windows Server, but has almost no roles or features except those that would be useful in a hypervisor management operating system.
Core “Core” is a mode for Windows Server that does not activate any of Explorer’s GUI components. It has no special relevance to Hyper-V as just about every Windows Server component and most non-WPF and non-Explorer-based applications can run on it.
Windows Server with Hyper-V In the 2008 product series, this was actually one way you could buy Windows Server. Naturally, there was also a SKU that didn’t have Hyper-V. Nowadays, this phrase is just used to indicate that the management operating system is Windows Server and that it has the Hyper-V role enabled. This is another of the three delivery methods for Hyper-V.
Client Hyper-V This is the trimmed-down edition of Hyper-V that ships with the desktop editions of Windows. These desktop editions represent the third delivery method for Hyper-V.
Hyper-V Core This term is nonsense. Please stop using it. It leads to a great deal of confusion in which we have people asking things like, “How do I install the full GUI on Hyper-V Core?” and people who are trying to help wasting a bunch of cycles trying to figure out what product is actually being used.It would help if Microsoft would stop using “HYPERSERVERCORE” and things like that in the text strings related to Hyper-V Server. <wink wink nudge nudge>


Reasons to Use Hyper-V Server as the Management Operating System

So, now that we’ve hopefully arrived at an understanding that this post is about the free product, let’s move on to the reason that you should use it as your management operating system choice.

  • It’s free! Who doesn’t like free? I know that there’s a huge push out there among some people to split hairs over the definition of “free”, but most of the English-speaking world takes the default position that when the adjective “free” is applied to a non-living corporate product, that means “doesn’t cost me anything”. That’s probably why Pepsi Free was fairly short-lived as a product name. Hyper-V is free in the default usage. Go download it and use it and (unless you find a way around the license agreement) you’ll never have to give a penny for it. This is especially useful for permanent test labs, now that Microsoft has killed TechNet subscriptions.
  • It’s lean. Hyper-V Server has a very small disk footprint compared to the other delivery methods. Much of a Windows distribution is there “just in case”. All those extra bits are why, with the exception of a few things, such as .Net Framework 3.x, you can enable just about every Windows role or feature without digging out the media. I’ve read at least one source that claims that Windows Server in Core mode is just as small as Hyper-V Server, but this isn’t true. Server Core is smaller than the full Windows Server if the binaries and resources for the GUI have never been added, but it is always larger than Hyper-V Server.
  • It’s more secure and stable. There’s less to attack and fewer things available to go wrong, so it will survive assaults and bugs that would take a full Windows Server down. A great many exploits target the Explorer binaries; Hyper-V Server can’t even install those binaries, so Hyper-V administrators can shrug off a lot of the security bulletins that keep the other admins up at night.
  • It doesn’t need as much patching. Patching is a real pain. You have to schedule it, you might need to notify your users of potential downtime, and you have to worry about whether or not Microsoft performed sufficient testing before releasing them. Well, with less content in the management operating system, Hyper-V doesn’t need nearly as many of them. As a bonus side effect, it’s less likely to need to be rebooted.
  • You never have to worry about activation. A lot of experts advise against using any form of antimalware in the management operating system. Since I’ve been able to use it on mine without any trouble, I personally make no recommendations either way. If you’re going to skip this software, then you need to be extra careful to keep Hyper-V hosts locked away from anything that might harm them. One common way to do that is with network isolation; it’s not really necessary for the management operating system to ever communicate with the Internet or even other internal hosts, so you can completely wall it off if you like. Unless it’s Windows Server. Then, it’s going to really want to talk to a licensing server periodically. Sure, there are ways around that. The best of them is to use Hyper-V Server instead.
  • It’s cheaper if you only want to virtualize desktop and/or Linux operating systems. Windows Server gives you some guest virtualization privileges, but they only apply to Windows Server operating systems. You can install Hyper-V Server and set up a highly-available VDI farm and only need to buy the desktop licenses. If even one of those desktops is running the same operating system generation as your hosts, you can install RSAT in it and completely manage your Hyper-V Server cluster from it without ever buying a single Windows Server license.
  • Upgrades are free! So, you didn’t spring for Software Assurance and here comes the new release of Windows and Hyper-V. What to do? Well, if you’re on Hyper-V Server, you can just upgrade to the next version of Hyper-V Server whenever it suits your schedule. No need for licensing negotiations or true-ups or anything else.

Responding to the Reasons Against Using Hyper-V Server

There are reasons not to use Hyper-V Server. Some of them of them aren’t that good, and some make no sense at all. We’ll start with those that are most valid and work our way down.

  • There’s no GUI available. Your only choices for working at the console of Hyper-V Server are the command line and PowerShell. That’s daunting for a lot of Windows administrators, to be sure. But, you can’t really avoid PowerShell unless you are completely satisfied with the basics. PowerShell is required for a number of advanced features and even some intermediate ones. Even if it’s not simple, it’s not as difficult as many people make it out to be. I, and many others, constantly write guides and books to make the processes as clear as possible. You can use things like Desired State Configuration to get the system set up quickly and easily. From there, you shouldn’t be using the console directly anyway. All the GUI tools will connect remotely. PowerShell will connect remotely. This is something you can do.
  • You can do more with Windows Server than you can with Hyper-V. From a technical standpoint, this is absolutely true. Windows Server has a stack of features that Hyper-V Server does not; just running Get-WindowsFeature on both will show you that. The problem is, it’s not supported to run very many of those roles and features with Hyper-V. Some of them will cause problems. All of them will steal resources from your guests, provided that the guests don’t steal resources from them first. Worse, if you install any role or feature that even has the capability to provide services to any external user or computer, you forfeit one of your Windows Server guest virtualization privileges. It’s much better to place those roles inside guest virtual machines. Then, it won’t matter what your management operating system is, because the guests are doing all the work.
  • Using Windows Server makes better use of the licenses you paid for. This is a myth I see used a lot: that the choice between Windows Server and Hyper-V Server is related to licensing. There is one, and exactly one, situation in which this is almost true. Automatic Virtual Machine Activation is a feature that requires you to install the Datacenter edition of Windows Server 2012 R2. But, it doesn’t quite make the myth truth because it only works for Windows Server 2012 R2 guests and even if you don’t install Datacenter, all that you forfeit is the AVMA feature; you still get all of Datacenter’s guest privileges. So, we need to continue repeating that it is a myth that using Windows Server as the management operating system grants any particular license benefits over using Hyper-V Server. If you run even one Windows Server guest, then the host needs a corresponding license. This is always true, and it does not matter one bit what operating system you choose to run as the management operating system. One Windows Server 2012 R2 Standard guest requires one Windows Server 2012 R2 Standard license for the host whether you are running Hyper-V Server or Windows Server in the management operating system. Five Windows Server 2012 R2 Standard guests require three Windows Server 2012 R2 Standard licenses for the host whether you are running Hyper-V Server or Windows Server in the management operating system. Thirty-six Windows Server 2012 R2 Standard guests require eighteen Windows Server 2012 R2 Standard licenses or one Windows Server 2012 R2 Datacenter license for the host whether you are running Hyper-V Server or Windows Server in the management operating system. If you have questions about this, you can start with our previous article on the subject. As always, I recommend that you contact Microsoft directly or speak with a credentialed licensing expert at an authorized reseller. They’ll tell you: licensing for your guests has no impact on and is not impacted by your choice of management operating system.


So, there’s my case for using Hyper-V Server as the management operating system.

Stay tuned for my next article, in which I’ll make the argument for using Windows Server instead of Hyper-V Server.

Oh, and in case you’re wondering which of the two that I actually prefer, well, a guy’s got to have a few secrets.


4 Reasons Your Hyper-V Host Should Only Run the Hyper-V Role

4 Reasons Your Hyper-V Host Should Only Run the Hyper-V Role

As IT Pros we’re often told to “Be flexible” and to “Do more with less”. Nothing is more true than when we’re talking about hardware, software licensing and the placement of network-critical services.

While I agree with the above phrases, and Hyper-V allows us to do both with relative ease, there are still some guidelines that need to be followed to keep us from shooting ourselves in the proverbial foot. (more…)

10 Free Hyper-V Downloads

10 Free Hyper-V Downloads

Even though Hyper-V R2 is a fantastic hypervisor, it’s not easy to manage if you haven’t got the proper tools. Fortunately, there are plenty of downloads available if you know where to look. Here are our top 10 favorite free Hyper-V downloads.

1) Microsoft’s Remote Server Administration Tool
If you didn’t install Hyper-V as a role inside Windows Server, or if you used a Core installation of Windows, you won’t have any management tools at all to start with. Even if you’re running a full Server GUI to manage Hyper-V, it’s still a good idea to manage the hypervisor remotely to lower resource contention and add a little convenience. Download and install Microsoft’s Remote Server Administration Tools to your computer running Windows 7 and manage your Hyper-V and Failover Cluster (as well as a number of non-Hyper-V roles on your other Windows Servers) from the comfort of your own desktop.

Remote Server Administration Tool

[optin-monster-shortcode id=”ddym7ivqq8pxouv7″]

2) Sysinternals Suite
If you don’t own a copy of System Center Virtual Machine Manager, it can be difficult to convert your physical machines into Hyper-V virtual machines. Fortunately, there’s a tool available that can do the hardest part: convert a physical drive into a VHD file. This nifty tool is called “Disk2VHD” and is provided by Sysinternals (now a part of Microsoft). It is available as a standalone item or as part of the incredibly useful Sysinternals Suite.

3) PowerShell Management Library for Hyper-V
For all the convenience that GUIs provide, raw power is found at the command prompt — or the PowerShell prompt. Gain quick control over your Hyper-V deployment using the PowerShell Management Library for Hyper-V.

4) Microsoft’s SQLIOSim tool
How do you know if your Hyper-V deployment can handle (another) SQL Server? Hard drive I/O is probably the most limiting factor for database and other high-performance applications, and the last thing you want is to find out that your system is overloaded after you’ve gone through the trouble of deployment. It never hurts to check your system periodically, just to ensure its operating as expected. While not specifically designed for Hyper-V, Microsoft’s SQLIOSim tool is thorough, highly configurable, and available at an unbeatable price: free.

5) Core Configurator 2.0
If you put Hyper-V right on the hardware, you may struggle a bit with some management tasks, such as configuring network cards or setting up Windows Updates. Instead of giving up and putting in a full Windows installation, take a look at Core Configurator 2.0 for Windows Server 2008 R2 and Corefig for Windows Server 2012 Core and Hyper-V Server 2012. As its name implies, this package was designed for Server Core, but it runs just fine on Hyper-V as well and even has a section for power management of virtual machines. Take some of the stress out of management and configuration with this excellent tool.

Core Configurator 2.0

6) VHD Resizer
Expanding a VHD is easy. You shut down the virtual machine, access its properties in Hyper-V Manager, and set the VHD to the larger size. But what if you made the VHD too large and now want to shrink it? Fortunately, there’s a VHD Resizer for that.

7) Microsoft Assessment and Planning tool
The most common difference between a smooth deployment and a frustrating one is planning. Get a good look ahead at how well your shiny new hardware will handle the virtualization of your current physical hardware with the Microsoft Assessment and Planning tool.

8 ) ManageEngine’s configuration tool
Wouldn’t it be great if Hyper-V had a nice dashboard so you could keep an eye on its performance? Maybe someday. Until then, ManageEngine’s configuration tool helps to fill the gap. As a bonus, it can configure some settings on individual virtual machines.

ManageEngine's configuration tool

9) VHD Attach
Two years after the release of Windows 7 and Server 2008 R2, a lot of administrators don’t realize that they can directly mount VHD files. That’s probably because the only way provided by Microsoft is from within Disk Management. Get right-click options for VHD files in Windows Explorer using VHD Attach. This small tool can save a surprising amount of time if you find yourself with a virtual machine that won’t start and you need to operate directly on files within the VHD.

10) Hyper-V Guest Console
When performing complicated tasks involving virtual machines and their Hyper-V host, it’s sometimes necessary to switch between a remote session to the host’s console and your GUI installation for management. Hyper-V Guest Console can reduce the switching by providing an interface comparable to Hyper-V Manager within Hyper-V’s console. Usage of this product was featured in an earlier blog on this site.

Honorable Mentions

Free Hyper-V Backup

Since this site is run by Altaro, it might have been somewhat unseemly to include their products in the top ten list. Even so, there’s no reason not to mention that Altaro provides a pair of excellent and free products that address one of the most critical aspects of Hyper-V management: backup. The first is the free edition of Hyper-V backup, which lets you protect two virtual machines.

PowerShell – Hyper-V Export

The second is a PowerShell script that leverages Hyper-V’s export function as an alternative to a full backup solution.

Virtual Machine Servicing Tool

Another outstanding utility is Microsoft’s Virtual Machine Servicing Tool. It’s free, so it almost fits in the above list, but it requires System Center Virtual Machine Manager 2008 or 2008 R2. If you’ve built gold master images as templates or have some virtual machines that you keep offline (like a root certificate authority), VMST can be used to keep them up-to-date on patches exactly as they sit without the need to turn them on.

Looking for more Hyper-V downloads & resources?

Have a look at this list: 101 Free Hyper-V Downloads, Tools, Scripts and Resources


How to install Microsoft hotfixes / patches on server core & native Hyper-V

How to install Microsoft hotfixes / patches on server core & native Hyper-V

As with all infrastructure software, it is critical to stay abreast of updates applicable to Hyper-V. If you’ve got a particular Hyper-V issue and want to know if there’s a hotfix, or if you like to know the intricate details of each and every patch prior to deploying on your system, you’re in luck: Microsoft maintains a complete list of all updates to Hyper-V. The list can be automatically synchronized to your computer via the “Subscribe to Article (RSS)” link on the right side. If you’re on R1, there is a hyperlink in the first “Note” paragraph that will take you to that list. (more…)

Choosing a Hyper-V Installation Option – Native or as a Role in Windows Server Core or Full

Choosing a Hyper-V Installation Option – Native or as a Role in Windows Server Core or Full

One of Hyper-V’s unique attributes is that it has dramatically different deployment options. You can install it natively directly to host hardware, or you can install a copy of Windows Server and enable Hyper-V as a role. Within the Server option are two more choices: Full or Core. There are perfectly valid reasons to choose any of these three deployment options.  The decision is fairly permanent, though, so take the time to make an educated decision prior to deployment. (more…)

Enabling Hyper-V Guest Console in Server Core

Enabling Hyper-V Guest Console in Server Core

In Server Core, no Hyper-V Guest console is provided and you need to use the remote server Hyper-V Manager snap-in or VMM Console to manage a Virtual machine. I just found a free tool to execute the Hyper-V Guest Console in Server Core. Let see how you can enable the Hyper-V Guest Console in Server Core itself.