Hyper-V Server 2019 is now available

Hyper-V Server 2019 Installation

Hyper-V Server 2019 is now (finally) available for download, installation and activation.


How to get it

The x86-64 ISO for Hyper-V Server 2019 is available for free at the Microsoft Evaluation Center.

It is available in Chinese (Simplified), Chinese (Traditional), English, French, German, Italian, Japanese, Korean, Portuguese (Brazil), Russian and Spanish.

Upon installation you will be prompted to activate. A product key is not required.


About Hyper-V Server

Microsoft’s Hyper-V Server is a free version and further optimized Server Core edition of Windows Server 2019, that delivers virtualization.

Companying Windows Server 2008 with its preview of Hyper-V, Hyper-V Server 2008 marked the birth of Hyper-V Server. It also came with HvConfig; a command-line tool to manage Hyper-V Server installations. HvConfig could also be copied to Server Core and Full Installations of Windows Server. Later, Microsoft adopted this process and included SConfig with all Server Core installations.

The Windows hypervisor technology in Microsoft Hyper-V Server 2019 is the same as what’s in the Microsoft Hyper-V role on Windows Server 2019. It is a stand-alone product that contains only the Windows hypervisor, a Windows Server driver model, and virtualization components. It provides a simple and reliable virtualization solution. However, containers are not supported in Hyper-V server 2019.


The Windows Server 2019 disaster

During the Microsoft Ignite event in Orlando in September 2018, Microsoft announced Windows Server 2019. It was released for two short days, until reported problems lead to the conclusion at Microsoft that the quality of the Operating Systems was sub-par. Several upgrades led to data loss. Windows Server 2019 was recalled. It took Microsoft roughly a month to investigate and remediate the problem, then go through the regular validation and release processes. Windows Server 2019 was successfully re-released on November 13, 2018.

Hyper-V Server took a while longer, through. An additional problem was reported: Remote Desktop wasn’t working, non-bootable installation media, etc. These issues have been addressed in the new release. If admins installed the ‘October release’ of Windows Server 2019, a Remote Desktop fix was available with KB4482887 since mid-March.

After the validation and release processes, Hyper-V Server is now also available. Six months behind Windows Server 2019. Eight months behind the original schedule.

More information:


What’s New

Microsoft Hyper-V Server 2019 provides new and enhanced features. However, when looking at the new features for Windows Server 2019, and Windows Server 2019 Pricing, it becomes obvious that many of the improvements in Hyper-V are related to features only available in Windows Server 2019 Datacenter Edition:

  • Software-defined Networking
  • Shielded Virtual Machines
  • Storage Spaces Direct

However, you might benefit from Windows Admin Center.


Tell us!

Are you transferring to Hyper-V Server 2019 for other compelling reasons? Let us know in the comments.


Add Task Scheduler and Hyper-V Manager to Server Core installations

Microsoft recommends using the Server Core installation option when using Windows Server, Semi-Annual Channel in production. However, Server Core by default omits a number of useful management tools. You can add many of the most commonly used tools by installing the App Compatibility feature, but there have still been some missing tools.

Based on customer feedback, Microsoft added two more tools to the App Compatibility feature in Windows Server, version 1903:

  1. Task Scheduler (taskschd.msc)
  2. Hyper-V Manager (virtmgmt.msc)


About the App Compatibility feature

The App Compatibility feature in Server Core installations of Windows is a Feature on Demand. It is an optional feature package that can be added to Windows Server 2019 Server Core installations, or Windows Server Semi-Annual Channel, at any time.

For more information, see last year’s blogpost on New in Windows Server 2019: Server Core app compatibility feature on demand.

Print commands are no longer installed by default

When migrating or transitioning a Server Core-based Print Server from Windows Server 2016 to Windows Server 2019, you might be in for a surprise.


Managing Printers in Server Core

A couple of years ago, I wrote a series of articles on 4Sysops, detailing how to configure a Server Core Print Server.

In that article, I detailed three ways to configure printers:

  1. Use the (old) Printing Admin scripts.
  2. Use the Print Server-related PowerShell cmdlets.
  3. Use the Graphical User Interface (GUI) with printui.exe /il.


What has been going on?

In the following Windows Server versions, the Printing Admin scripts were made available after installing the Print Server role:

  • Windows Server 2008
  • Windows Server 2008 R2
  • Windows Server 2012
  • Windows Server 2012 R2

However, in Windows Server 2016, the Printing Admin scripts were available, by default, as part of Server Core installations.

For Server Core installations of Windows Server 2019, Microsoft returned to the previous model: The Printing Admin scripts are no longer installed, by default.



There are a couple of consequences for organizations migrating and/or transitioning from Windows Server 2016 to Windows Server 2019:

  • By default, there is no C:\Windows\System32\Printing_Admin_Scripts folder.
  • By default, scripts and admin actions using the following commands will fail:
    • Prncnfg.vbs
    • Prndrvr.vbs
    • Prnjobs.vbs
    • Prnmngr.vbs
    • Prnport.vbs
    • Prnqctl.vbs
    • Pubprn.vbs


How to resolve these issues

To get the Printing Admin scripts, and the Print Server features, install the Print Server Role.

Use the following lines of Windows PowerShell to accomplish this goal:

Import-Module ServerManager

Install-WindowsFeature Print-Server


Further reading

Install and manage a Print Server in Server Core
Features removed or planned for replacement starting Windows Server 2019
What’s new in Windows Server 2019
Pricing and licensing for Windows Server 2019
Windows Server 2019 System Requirements

ServerCore.Net in 2018

Goodbye 2018.

Throughout 2018, ServerCore.Net saw 299.722 pageviews. This is a new record for this little blog.

You liked the content. So here’s our Top 5 for 2018:

  1. How to disable the Windows Firewall on Server Core installations of Windows Server 2012 and Hyper-V Server 2012 (14816 views)
  2. How to disable Password complexity on Server Core installations (6399 views)
  3. How to install a Server Core R2 Domain Controller (2644 views)
  4. Windows Server 2016 no longer offers to add or remove GUI Layers (2338 views)
  5. How is Nano Server different from Server Core? (1610 views)

I’d like to thank you, my readers, for appreciating the content, for your visits, replies, helpful comments and your likes and retweets on Twitter.

I wish you all the best and a good start into 2019.

Thank you.

New in Windows Server 2019: Server Core app compatibility feature on demand

Microsoft has released Windows Server 2019, so it’s time to look at Microsoft’s latest and greatest.
One of the most exciting features Microsoft added to Windows Server 2019 is the ability to add additional app compatibility to Server Core installations.


About App Compatibility on Server Core

One of the biggest challenges with embracing Server Core as an administrator is that not many software vendors have specifically written their products for Server Core installations of Windows Server, or have tested their products on Server Core installations of Windows Server. As you might expect, just like desktop software, these products are tested on Windows Server installations with the Desktop Experience (formerly known as Full Installations), with administrative privileges.
Unfortunately, the challenge isn’t limited to software packages or agents. In the past, this resulted in cases where Server Core wasn’t installed on HP-branded servers, simply because the tools to team the built-in networking adapters was only available as graphical tools. They couldn’t be used…

Windows Server’s ability to temporarily run with the Desktop Experience to install and configure parts of the Operating System, software packages and agents, has eased the process of embracing Server Core. In the end, though, the conclusion from many admins was that it was not worth their time to go this route, because when they removed the GUI layers, eventually things still broke.


App Compatibility on Windows Server 2019

In Windows Server 2019, GUI layers can’t be removed. You could do this in Server Core installations of Windows Server 2012 and Windows Server 2012 R2. However, since Windows Server 2016 you can no longer do this. It is expected to remain this way for long-term servicing branch/channel (LTSB/LTSC) versions of Windows Server. The choice between Server Core installation and Windows Server with the Desktop Experience is to be made during installation and will remain this way until reinstallation of Windows Server or decommissioning of the server.

App Compatibility Feature on Demand (FoD)

To ease this pain, and to improve the adoption of Server Core installations on Windows Server for good reasons, Microsoft introduces the Server Core App Compatibility feature on demand feature in Windows Server 2019. This feature significantly improves the app compatibility of Windows Server Core installations, by including a subset of binaries and components from Windows Server with the Desktop Experience, without adding the Windows Server Desktop Experience graphical user interface (GUI) itself.

Specifically, the App Compatibility feature adds:

  • Microsoft Management Console (mmc.exe)
  • Event Viewer (Eventvwr.msc)
  • Performance Monitor (PerfMon.exe)
  • Resource Monitor (Resmon.exe)
  • Device Manager (Devmgmt.msc)
  • File Explorer (Explorer.exe)
  • Windows PowerShell (Powershell_ISE.exe)
  • Failover Cluster Manager (CluAdmin.msc)


This way, the functionality and compatibility of Server Core is increased, while keeping it as lean as possible.

As you can see, many of the tips and tricks that were provided on working with Server Core evolve around absent tools that can now (temporarily) be added.


Getting started with the App Compatibility Feature on Demand

This optional feature on demand is available on a separate ISO and can be added to Windows Server Core installations and images only, using DISM.exe.

Download the ISO

First, download the Windows Server 2019 Features on Demand ISO image file is available on the Microsoft Evaluation Center. For MSDN subscribers and current Microsoft volume licensing customers, the Features on Demand (FoD) image file is also available in their respective download centers.

This downloads is called en_windows_server_2019_features_on_demand_x64_dvd_c6194375.iso and weighs 335 MB.

Add the App Compatibility feature

Sign into the Server Core installation with local administrator rights, mount the ISO-file or insert is as removable media, and execute the following command:

dism.exe /Online /Add-Capability /CapabilityName: “ServerCore.AppCompatibility~~~~” /Source: E: /LimitAccess

After the command completes, restart the Server Core installation.

Exchange Server 2019 is coming to Server Core

Last week, the Microsoft Exchange Product Group announced the release of the Exchange Server 2019 public preview! They also lifted the veil on some of the new features/capabilities etc. of this new major build of Exchange Server. To say that I’m excited about this release is an understatement… I feel this Exchange Server version is groundbreaking due to one of its new features, touted by the team as making Exchange Server 2019 the safest Exchange Server yet.


Of course, you’ll think I drank too much of the Kool-Aid and simply bought the same line the team has been marketing for the last couple of years for many Microsoft products, including Windows. This time it’s different. This time, it’s not really an Exchange Server feature, but more a platform support feature:

Exchange Server 2019 is coming to Server Core.



It will be finally possible to install Exchange Server 2019 on Server Core installations of Windows Server 2016 and Windows Server 2019. The Product Group mentions that they consider this the best deployment option. It means there isn’t really a need for a desktop experience. However, it remains an option.


Exchange Server 2019 and Windows Server 2019 is still in preview, but you can download the Windows Server Insider Preview here (after signup) and the Exchange Server 2019 Preview here. As both versions are still in preview, anything in the above text might still change before either of these products reach Release to Manufacturers (RTM)…

Remote Desktop Connection Broker and Remote Desktop Virtualization Host will no longer be available on Server Core installations

Reading through the Features removed or planned for replacement starting with Windows Server, version 1803, something caught my eye:

Remote Desktop Connection Broker and Remote Desktop Virtualization Host in a Server Core installation

Most Remote Desktop Services deployments have these roles co-located with the Remote Desktop Session Host (RDSH), which requires Server with Desktop Experience; to be consistent with RDSH we’re changing these roles to also require Server with Desktop Experience. We’re no longer developing these RDS roles for use in a Server Core installation. If you need to deploy these roles as part of your Remote Desktop infrastructure, you can install them on Windows Server 2016 with Desktop Experience.


To be honest, I was dumbfondled by this message, but I guess Microsoft knows what they’re doing.


Remote Desktop Services Architecture

Looking at Microsoft’s Remote Desktop Services architecture, several roles exist:

  • Remote Desktop Gateway (RD Gateway, RDGW)
    The Remote Desktop Gateway (RD Gateway) component enables people on their client devices on the public Internet to securely access Windows desktops and applications.
  • Remote Desktop Web Access (RD Web)
    The Remote Desktop Web Access (RD Web Access) component allows the tenant’s employees to have a single website where they can authenticate and then access Windows desktops and applications.
  • Remote Desktop Connection Broker (RDCB)
    Remote Desktop Connection Broker (RD Connection Broker) manages incoming remote desktop connections to the servers in Remote Desktop Session Host (RD Session Host) server farms, known as collections.
  • Remote Desktop Licensing Server (RDLS)
    Each Remote Desktop Services environment includes an Remote Desktop Licensing server to allow users to connect to the Remote Desktop Session Host (RD Session Host) servers that host the desktops and applications. The licensing server may be configured in “per user” mode or in “per device”  mode.
  • Remote Desktop Session Host (RDSH)
    The Remote Desktop Session Host (RD Session Host) component provides people with session-based desktops and RemoteApp programs.
  • Remote Desktop Virtualization Host (RDVH)
    In contrast to a Remote Desktop Session Host, that offers session virtualization by allowing multiple people to log on interactively to a Windows Server installation, a Remote Desktop Virtualization host (RDVH) offers desktop virtualization where people log onto their own virtualized Windows instance, running on top of a hyper-virtualization platform. This platform is the Remote Desktop Virtualization Host.

In this architecture, typically, multiple Remote Desktop Session Hosts perform the heavy lifting: actually running the applications and/or offering Windows desktops. One (virtual) machine runs the  Remote Desktop Connection Broker (RDCB) and Remote Desktop Licensing Server (RDLS), so people land on the right Remote Desktop Session Host (RDSH) when they are properly licensed. Another (virtual) machine running the Remote Desktop Gateway (RD Gateway, RDGW) and Remote Desktop Web Access (RD Web) roles offer outside connections to the infrastructure. All components can be made highly-available. The infrastructure requires Active Directory Domain Services or Azure AD Domain Services, as well as a Microsoft SQL Server or Azure SQL database (in highly-available scenarios).

Many variants of the above best practices architecture exist, but all of them avoid placing any of the RDS infrastructure role services (RD Gateway, RD Web, RD Connection Broker or RD Licensing) on Remote Desktop Session Hosts or Remote Desktop Virtualization Hosts.


… in the real life, though…

Now, when you read closely, Microsoft states that organizations are not following its guidance. Instead, they install the Remote Desktop Connection Broker (RDCB) on one or more of the Remote Desktop Session Hosts.

This has led to the decision to remove the two features from Server Core installations in the following Windows Server releases:

  1. Semi-Annual Channel (SAC) releases: Windows Server, version 1803, and beyond
  2. Long-term Servicing Channel (LTSC) releases: Windows Server 2019, and beyond

Looking at the list of available roles and features for Server Core installations, the Remote Desktop Licensing Server is the only Remote Desktop Services (RDS) role still viable to run on Server Core installations in the near future.


Install Windows Server with Desktop Experience

Starting with Windows Server, version 1803 and Windows Server 2019, when you want to run any of the below Remote Desktop Services role services, install a Windows Server with Desktop Experience, instead of a Server Core installation of Windows Server:

  • Remote Desktop Gateway (RD Gateway)
  • Remote Desktop Web Access (RD Web)
  • Remote Desktop Connection Broker (RDCB) *
  • Remote Desktop Session Host (RDSH)
  • Remote Desktop Virtualization Host (RDVH) *



Thanks to people not following Microsoft’s best practices architecture, we’re now getting screwed out of Server Core for two more RDS Infrastructure roles… or is there something else at play?


Windows Admin Center is here

Ever since the first incarnations of Server Core in Windows Server, people have looked at ways to manage ‘Windows Server without GUI’ with a GUI. Today, the newest method of managing Windows Server, dubbed ‘Windows Admin Center’ was released and it promises an entirely new way to manage Windows Server, both ‘Installations with a GUI’ and ‘Server Core installations’.

Let’s take a look!


Our strange obsession…

Quoting ‘Graphical is for women’ doesn’t even begin covering admins’ strange obsession with graphical management tools to manage all aspects of Windows Server. We’ve seen tools like CoreConfigurator pop up early on in the Server Core lifecycle, but being capitalized on by Smart-X. We also saw other tools, and I even provided instructions on how to run hvconfig on Server Core installations, before sconfig came to Server Core installations.

However, the industry has mostly moved on. Drivers and other tools no longer rely on having a GUI present to allow installation or configuration. Even Microsoft’s own Remote Server Administration Tools (RSAT) have moved on, although some notable exception apply, like AD FS Management and driver management.


Windows Admin Center

Microsoft now offers a brand new toolset, that has been available for the last year as private previews and public previews, codenamed Project Honolulu: the Windows Admin Center.

In contrast to other tools out there, Windows Admin Center offers its experience in full HTML5, so it’s usable in any of the popular browsers admins use today. Windows Admin Center is a locally deployed and can be used to manage servers, clusters, hyper-converged infrastructure, and Windows 10 PCs. It comes at no additional cost beyond Windows and is ready to use in production.

Download Windows Admin Center now.



While you could use any 3rd party tool to remotely manage your Server Core installations, but wouldn’t you rather use this free tool from Microsoft?

Windows Server 2016 no longer offers to add or remove GUI Layers

In a surprising move, Microsoft decided to remove a feature, that from a security point of view was perhaps the most useful feature in Windows Server.

Let’s look at the recent history of Windows Server:


Windows Server 2008 (R2)

Windows Server 2008 and Windows Server 2008 R2 were the first two versions of Windows Server that offered the ability to install the Operating System (OS) as Server Core installations. These optimized installations of Windows Server offered more security (due to a smaller attack surface), less resource use and more agility.

Even though, Windows Server 2008 Server Core headed for a dead end street in some scenarios, some organizations opted to install their Windows Servers as Server Core installs.


Windows Server 2012 (R2)

To allow even greater agility, but also to get the installation ‘just right’ using the Graphical User Interface (GUI), Microsoft offered to add and remove GUI layers in Windows Server 2012 and Windows Server 2012 R2. This way, system admins can switch from Full Installations (even with the Desktop Experience feature turned on) to Server Core Installations. We’ve discussed it here, roughly five years ago.

We saw an uptick in the adoption of Server Core due to this opportunity and believe it made the life of admins easier, even though they would not fully benefit as much as they would with a Server Core Installation from the get-go.


Windows Server 2016

Now, in Windows Server 2016, Microsoft no longer offers to add and remove GUI layers.

Admittedly, many of the Server Core benefits have become moot points with Windows Server 2016: The newly added security measures in Windows Server add a lot. This removes most of the urgency of removing the GUI, although you can’t install Internet Explorer from Windows Server 2016…

Also, many of the (graphical) tools we needed in Windows Servers to configure the Windows Server installation just right also have grown up and now offer command-line, if not PowerShell support. There’s less and less need to install Windows Server as a Full Installation to configure it.


I guess time will tell if Microsoft has made a wise decision by removing the ability to add and remove GUI layers…

Three things to consider when switching the GUI in Windows Server

Windows Server 2012 and Windows Server 2012 R2 allow to switch the Graphical User Interface (GUI) on and off. It’s easy, and already the topic of a previous blogpost.

The ability to switch GUIs in Windows Server has been removed in Windows Server 2016.

I’ve already showed you how to actually switch between these three GUI modes (with a choice between dism.exe and PowerShell), but what I haven’t pointed out yet, is the things you need to consider when you actually switch between GUI modes:


1. Only update in your desired GUI mode

One of the benefits of running a Server Core installation is a smaller attack surface, compared to a Full installation. The attack surface in a Full installation results in a higher amount of vulnerabilities and a higher frequency of updates for the Operating System.

Another benefit of Server Core is a smaller disk footprint, compared to a Full installation. This benefit becomes partly undone when we start installing updates for a Full installation, that we no longer need when we run the server as a Server Core installation most of the time. To this date, there is no way or tool to determine which updates are no longer needed or to actually uninstall these in a simple way.


2. Take notice of the support matrix of your agents and add-ons

Even the server running your easiest of tasks needs to adhere to your information security strategy. This results in the installation of many agents and add-ons. Backup, anti-malware and UPS all need their respective software. When your environment also features System Center, you will need software like the Server App-V agent and the System Center Configuration Manager agent.

Even though the Server Core team communicated a whole lot within Microsoft, it’s not plausible to assume every product team took notice of the ability for administrators to switch between GUIs. So, the problems with Microsoft software may already be big, but the bigger question is which software producers have also got the message? Did your anti-malware supplier get it?

Two ways to make sure you’ll be in the clear while switching GUIs, are:

  1. Consult the support matrix from the suppliers of your agents and add-ons
  2. Test your configuration

The best choice, however, remains to install agents and add-ons (remotely) with the Server installation in the desired GUI.


3. Take notice of the support matrix of your server applications

The SQL Server team has actively communicated SQL Server 2012 and up supports installation on Server Core. They are one of the product teams outside the Windows Server group to get onboard with Server Core. Other Microsoft Server products, like Exchange Server and Skype for Business Server have not communicated plans in that direction.

Even though the Server Core team communicated a whole lot within Microsoft, not every product displays a warning at installation, warning you not to switch the GUI after installing the product. Many non-Microsoft products also might not contain the warning, at least in the early period after their releases.