As many of you know Microsoft integrated a special Enterprise edition in the Insider Preview 17713:
Windows 10 Enterprise for Remote Services

If you search for this, you only find a few blog posts about this version – most focus on Microsoft Windows Virtual Desktops (WVD). The actual content is mostly only showing multiple RDP session at the same time on a Windows 10 VM – like you know it from the Microsoft Remote Desktop Session Host (RDSH) (or to keep the old name: Terminal Server). Only Cláudio posted two post during the last days about this topic which lead to some interesting discussions. You can find them here and here.

When using Office 365 and other programs there are some limitations when running them on RDSH – often it’s even not supported. When now Windows 10 allows multiple users to connect to one VM they have the full Windows 10 experience and on the other side they are still sharing one VM (like with RDSH).

When booting an official Windows 10 1809 Iso I saw that there is still Windows 10 Enterprise for Virtual Desktops available. As I didn’t find any blog posts having a look at this version I decided to have a look myself.

[Update]
Christoph Kolbicz posted the following on Twitter – thus you can also use other ISOs of Windows 10:

If you installed Enterprise and want to get #WVD, you can also simply upgrade it with this key: CPWHC-NT2C7-VYW78-DHDB2-PG3GK – this is the KMS Client key for ServerRdsh (SKU for WVD). Works with jan_2019 ISO.

[/Update]

Disclaimer:
I am not a licensing expert and quite sure some of the following conflicts with license agreements. During the tests in my Lab I only wanted to figure out what’s possible and where the limitations are. Beside that some of the things described are not supported (and I bet will never be supported) – but I like to know what’s technical possible

Installing Windows 10 Enterprise for Virtual Desktops and logging in

Ok let’s get to the technical part. I connected an 1809 Iso, booted a VM and got the following Windows-Version selection. After selecting Windows 10 Enterprise for Virtual Desktops the normal Windows Installer questions followed.

After a reboot I was presented with this:
No question for domain join or user – just a login prompt. So, I started to search and only found one hint on twitter (about the Insiders Build) that the only options are to reset the password with a tool or add a new user. Before you are wondering: Yes it’s possible to create another Administrator Account for Windows without having login credentials. As I already tested that in the past (and didn’t want to test out which password reset tool fits) I decided to take that way.

[Update]

Jeremy Stroebel gave me the following hint on Twitter – this way you can skip the steps below to create a local Administrator-User and continue at Multiple RDP-Connections – Not Domain Joined.

Easier, boot to safe mode and it logs right in… then add your user.

[/Update]

Ok time to boot another time from the ISO and open the Command Prompt (press Shift + F10 when the setup shows up).

Now we need to replace the Utility Manager (from the normal Login-Screen) with the cmd.exe. The Utility Manager from the Login-Prompt is always started with Admin-Rights….
To replace the Utility Manager with a cmd enter the following commands:

move d:\windows\system32\utilman.exe d:\windows\system32\utilman.exe.bak

copy d:\windows\system32\cmd.exe d:\windows\system32\utilman.exe

That’s it. Time to boot Windows again. Now press the Utility Manager Icon on the bottom right side. Voila: A command prompt (with elevated rights):

The next step is to create an account and add this one to the local admin group. Therefore, you need to enter the following commands:

net user username /add

net localgroup administrators username /add

And voila – you can now login with your just created user (without a password):

Multiple RDP-Connections – Not Domain Joined

For my first tests I just wanted to connect multiple users to the machine without joining the VM to the AD to prevent impacts by policies or something else. I created three local users:

When I logged of my created Administrator all three had been available on the Welcome-Screen to Login:

A RDP connection was not possible at this time. So let’s check the System Properties => Remote Settings. As you can see Remote Desktop was not allowed:

I enabled Allow remote connections to this computer” and added the three created users to the allowed RDP Users:

Time for another RDP-Test. The first user logged on successfully – but the second received the message that already two users are logged on and one must disconnect:

That was not the behavior I expected. After searching a little bit around and finding no solution I tried the old “Did you try a reboot yet?” method. And now something interesting happened. When shutting down this was shown:

And after booting Windows showed this:
All Windows Updates had been installed before and I added no other Windows features, functions or any programs. So what was installed now?

The Welcome-Screen after the reboot also looked different:

Before you could see the created users and select one for login – now you need to enter username and password. Looks quite familiar to an RDSH host after booting or?

So logging in with the local admin again and directly this message was displayed:

Time for another RDP-Test. And guess? This time I was able to connect multiple RDP-Sessions at the same time:
So it looks like the “RDSH”-Role is installed when RDP was enabled and Windows is rebooted. Time for the next tests.

Multiple RDP-Connections – Domain Joined

After everything worked fine I thought it’s time to test how everything behaves in a Domain. I reverted to a snapshot where I just had created the local Admin-User. I logged in and joined the machine to the domain:

After a reboot I logged in with a Domain Admin to Allow Remote Connections to this Computer.

Interestingly this was already enabled. Furthermore it was not possible to disable it any longer. There had been no policies applied to enable this setting – only the default Domain Policy was active.

So let’s go on and allow the Domain Users to connect.

Like before the logon of a third user was denied:

But as we already know a reboot is necessary to install the missing features. Like before magically some features are installed:

Now several domain users are able to connect to the Windows 10 VM at the same time using RDP.

Citrix Components

The next logical step for me was to try to install a Citrix Virtual Delivery Agent on the VM. So connect the Virtual Apps and Desktop 7 – 1811 iso and start the Component selection. But what’s that?

Next to the VDA it’s also possible to select all other roles – which are normally only available on a Server OS! (Just a quick reminder: None of the things I test here are designed or supported to work under such circumstances).

Delivery Controller

I couldn’t resist and selected Delivery Controller. After accepting the license agreement the Component selection appeared. I selected all available Components.

The first prerequisites are installed without issues – but the installation of the Microsoft Internet Information Service (IIS) failed. The error just showed something failed with DISM.

So I just installed the IIS with all available components manually.

But even after installing all available IIS components the Delivery Controller installation still failed at the point Microsoft Internet Information Service.

I decided to first have no deeper look into this issue and remove all components that require the ,IIS: Director and StoreFront.

The installation of the other components worked without any issues – as you can see all selected components are installed on Windows 10 Enterprise for Virtual Desktops.

The Citrix Studio opens and asks for a Site Configuration – as on every supported Server OS.

Time to create a Site on our Windows 10 Delivery Controller.

The Summary shows that the Site was successfully created.

And the Citrix Studio now shows the option to create Machine Catalog.

And a last check of the services: Everything is running fine.

Virtual Delivery Agent

Before we now can create a Machine Catalog we need a Master VDA. So let’s create another VM with Windows 10 Enterprise for Virtual Desktops. Repeat the steps from above (Domain-Join with two reboots) and connect the Citrix Virtual Apps and Desktops ISO. This time we select Virtual Delivery Agent for Windows 10 Enterprise for Virtual Desktops. To be able to create multiple VMs from this Master-VM using MCS select Create a master MCS image.

The next step is to select the Additional Components – like in every other VDA Installation.

Now I entered the name of the Windows 10 VM where I previously installed the Delivery Controller.

The summary shows the selected components and the Requirements.

The installation started….

….and finished without any errors.

The VDA was successfully installed on Windows 10 Enterprise for Virtual Desktops.

Machine Catalog

Time to deploy some VMs – so switch back to the Studio and start the Machine Catalog Configuration.

The first step is to select the Operation System. Normally this is easy: Server OS for Windows Server 2016 / 2019 – Desktop OS for Windows 10. But this time it’s tricky – we have a Desktop OS with Server OS functions. I first decided to take Desktop OS – although I thought Server OS might fit better.

Select the just created Master-VM and configure additional Settings like CPU, RAM, etc..

Finally enter a name for the Machine Catalog and let MCS deploy the configured VMs.

Delivery Group

As we have now a Machine Catalog with VMs it was time to create a Delivery Group – thus we can allow users to access the VM(s).

I selected the created Machine Catalog…

… and added a Desktop to the Delivery Group.

The Summary shows the configured settings.

Now we have everything ready on the Delivery Controller – just the user access is missing.

As the installation of StoreFront failed I added the Windows 10 Delivery Controller to my existing StoreFront Deployment.

After logging in the User can see the just published Desktop. Unfortunately, the user is not able to start the published Desktop.

So back to the Delivery Controller. Oh – the VDA is still unregistered with a “!” in front of the Status.

Let’s check the VDA-Event-Log:

The Citrix Desktop Service was reused a connection to the delivery controller ‘win10-multi-01.lab.jhmeier.com.

The registration was refused due to ‘SingleMultiSessionMismatch’.

Looks like my feeling was correct that the Machine Catalog should have the Operating System Server OS. I created another Machine Catalog and Delivery Group – this time with the type Server OS.

Let’s boot a VDA and check the Status: Registered.

Time to check the user connections. After logging on to StoreFront the user now sees the second published Desktop – Type Server OS.

And this time the connection is possible. As you can see we have now multiple users connected using ICA to the same Windows 10 VDA.

At this point I would like to sum up what worked and what didn’t work until now:

What worked:

• Multiple RDP connections to one Windows 10 VM – Domain-Joined and not Domain-Joined
• Multiple ICA connections to Domain-Joined Windows 10 VDA
• Delivery Controller on Windows 10 (including Studio and License Server)

What did not work:

• Installation of Citrix Components that require an IIS (StoreFront and Director)

If the last point can be fixed it would be possible to create an “all-in” Windows 10 Citrix VM. Thus you could run all Citrix Infrastructure Components on one VM – not supported of cause but nice for some testing. Beside that it’s really interesting to see that next to the VDA also a lot of the Delivery Controller Components just work out of the box on Windows 10 Enterprise for Virtual Desktops.

When we look at the behaviour of the Citrix Components it looks like all Server features (including RDSH) that the Citrix installer uses to detect if it is a Desktop- or Server-OS are integrated into Windows 10 Enterprise for Virtual Desktops.

That’s it for now – I have some other things I will test with this Windows 10 Edition – if I find something interesting another blog post will follow