Windows Server 2019: Session Host is dead! Multi-user Win10 instead?

Imagine if RDSH was based on a client OS instead of a server OS. Fantastic, right?

Update, April 25, 2018: After weeks of back and forth, Microsoft stated on April 17th that RDSH would be coming to Server 2019, and it was only missing because of a bug. RDSH returned in the Insider Preview Build 17650. We're leaving Brian's original article here, unaltered, for the historical record.

Original article:

Note from Jack: Apparently, Brian (the person, not the website) can’t stay away from desktop virtualization! Last week he noticed this interesting news and asked me if he could write about it, so today I’m happy to publish his post as a part of our freelance contributor program.

Microsoft released a preview build of Windows Server 2019 a few days ago, and amongst all the new features, one notable feature is missing: the Remote Desktop Session Host (RDSH) role.

I first learned about this via a tweet from Claudio Rodrigues. I googled to find more details, but all I found were a few random anonymous comments from people who said they couldn’t install the RDSH role on 2019.

So yesterday I downloaded the Windows Server 2019 LTSB preview / 1803 / 17623 build to see for myself.

For some context, the trend from Microsoft is they’re trying to move people off running a GUI on Windows Server. This makes the images smaller and simpler for containerization and virtualization, and, perhaps more importantly, it increases security by lowering the attack surface. Moving forward, if you even want an *option* for the GUI, you’ll need to use the Long Term Servicing Branch (LTSB). If you choose one of the other Server 2019 releases, like the Semi-Annual Channel (SAC), installing a GUI is not even an option.

Anyway, I installed the “Windows Server Standard (Desktop Experience)” from the Server 2019 LTSB ISO. Right off the bat I noticed that the installation notes explain that this option only exists for legacy applications that require a GUI. It says nothing about remote users or RDSH.

Next, I added the Active Directory Domain Services role (and everything it needed) to set up a new domain.

Then, using the Add Roles and Features Wizard, I chose the “Remote Desktop Services” installation type which says, “Install required role services for Virtual Desktop Infrastructure (VDI) to create a virtual machine-based or session-based desktop deployment.” This option should automatically install the RD Connection Broker, RD Web Access, and RD Session Host.

So far, so good.

The first two roles installed no problem, but the RD Session Host failed with an error about RDSH not existing. Other errors in the log stated that “The role, roles service, or feature name is not valid: ‘rds-rd-server’.”

I know in the past there were sometimes issues installing Session Host on the same machine that also ran the connection broker, so I spun up another Server 2019 VM, added it to the domain, and tried to install just the Session Host role while using the Connection Broker and Web Access from the first server. This install failed in the same way.

Finally, I tried to install RDSH from the “Server Roles” wizard instead of the “Installation Type” wizard. I checked “Remote Desktop Services” box, but then on the next screen I only saw the following sub-options:

  • Remote Desktop Connection Broker
  • Remote Desktop Gateway
  • Remote Desktop Licensing
  • Remote Desktop Virtualization Host
  • Remote Desktop Web Access

No Remote Desktop Session Host.

Based on this, I feel confident making the statement that RDSH is not part of Windows Server 2019. My guess is they just didn’t remove this option from the Server Manager wizard yet, since it looks like the 2016 version that was lifted into 2019.

So no RDSH? Now what?

If Microsoft removes RDSH from Windows Server, what does that mean for the RDS world? What about XenApp? What about multiwin? What about… everything?

The companion rumor to Microsoft removing RDSH from Server is that they will be *adding* a multi-user, multiwin-based option to Windows 10. (Claudio and a few other people mentioned this on Twitter, and I heard about it a few months ago on my own too.)

In other words, Microsoft is taking Terminal Server out of Windows Server and moving into Windows 10.

If true, this is fantastic.

The only reason that Terminal Server / Session Host was ever based on a server OS was that it was created in the 1990s when Windows Server was needed to support the multiple processors, huge memory, and server-specific hardware (SCSI, etc.) that was needed to support multiple simultaneous users.

The biggest change of the past twenty years is virtualization. IN 2018, most RDSH / XenApp servers are VMs anyway, and Windows 10 and Windows Server both work equally well as a VM.

One of the downsides of using a server as a desktop is the almost-but-not-quite application compatibility. Most everyone would agree that if there was a product like Terminal Server / RDSH that was magically based on Windows client, (and fully supported by Microsoft), that would be great.

The other reason Microsoft had to stick with RDSH on Server for so long was their ridiculous client licensing restrictions dictating Windows client usage, ownership, hardware, RDS CALs, SPLA for Windows client, etc. (I won’t re-rant on that, but readers know I’ve been pretty clear about my thoughts on how Microsoft licenses Windows clients for remote GUI usage.)

In the past year, Microsoft has started to relax some of these restrictions, and the tea leaves are suggesting that this trend will continue.

So in 2018/2019, the following are true:

  • Microsoft is trying to remove / minimize the GUI on Server.
  • Windows Server in a VM runs just like Windows client in a VM.
  • Windows desktop apps “prefer” a client OS versus a server OS.
  • Licensing restrictions that spawned creative “server as a desktop” usage models are going away.

In this world, it seems like a no-brainer to pull RDSH from Windows Server. (Just the Session Host role, of course. It makes sense to keep the other Remote Desktop roles in server, like the connection broker and web access, as those are “real” server roles that don’t require a GUI.)

Do we really need multi-user Windows 10?

The only remaining question I have is whether a multi-user Windows 10 is really needed. If everything in a datacenter in 2018 is a VM, then what’s the difference between a single physical host with a hundred Windows 10 VMs (1 user per VM) versus that same host with ten multi-user Windows 10 VMs (10 users per VM)?

Some of the traditional “RDSH versus VDI” arguments still do apply here, like maybe that multi-user VMs are more efficient, while single-user VMs provide more flexibility (per-user suspend, resume, live migration, resizing, etc.).

The only other thing I can think of right now is for single app publishing / RemoteApp. In a use case where the users are just using a single Windows app, without a whole remote Windows desktop, then maybe it is more efficient to have multi-user VMs that can spin up sessions per user instead of full VMs per user?

But for rank-and-file remote desktop users, I feel I’d want “real” Windows 10, single-user desktop VMs (e.g. VDI) rather than multi-user ones (e.g. Windows 10 sessions).

The bottom line

If all this turns out to be true, then I can safely predict that 2019 will be the year of VDI. :)

It also means that an earlier prediction, that my 2015 presentation of “RDSH versus VDI” would be the last time I ever gave that presentation, will turn out to be true as well.

Dig Deeper on Windows 10

SearchVirtualDesktop
SearchWindowsServer
Close