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.

Yes!

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.

Preview

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) *

Concluding

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?