Skip to content

Custom Windows based Thin Client (for Citrix environments)

3. July 2019

If you have a look at the Endpoint used in VDI / SBC environments, you often see Thin Clients. There are several Thin Client vendors around. Most companies see them as a Hardware and Software delivery – although some of them now position as a software solution.

Beside that most of them rely on a customized Linux system where they integrate the Client Version from the VDI / SBC vendors – e.g. the Citrix Workspace App (formerly Receiver). Unfortunately, this leads to two issues:

  1. Linux Clients have often less features compared to the windows version
  2. The vendor of the actual VDI / SBC Client software does not support the (custom) implementation of the Thin Client vendor. Thus, you must install a native Linux on a hardware an reproduce the issue on this device with the official client software.

On the other hand, the Thin Client vendors also often offer a Windows based version of their devices. But they are often limited in performance and manageability. Beside that it would mean to implement another device type in your environment (which of course require a separate configuration).

During my previous job we had some issues with Linux based Thin Clients that could not be fixed. As we also didn’t like the limitations of the Windows Thin Clients we thought: Why aren’t we creating our own Windows based Thin Client – based on a small form factor device. These devices often already have a Windows license included. This means that you sometimes need less / cheaper licenses from Microsoft for connecting to your VDI / SBC environment – I can’t tell you details about this as I am no licensing expert (and honestly, I don’t try to get one). Furthermore, these devices are often quite powerful that they can easily handle H.264 decoding and even H.265. In some remoting scenarios this is important for a smooth user experience.

The requirements to full fill had been assessable:

  • User has no access to the local system itself (e.g. Desktop etc.)
  • Automatic logon to the local device
  • Browser with StoreFront Website is automatically started
  • Peripheral devices can automatically be redirected to the Citrix Session (e.g. 3DConnexion Devices)
  • Installation must be possible with current Software Deployment Tool
  • Central Configuration
  • Automatic start of Desktop when only one Desktop is assigned
  • Desktop starts in Full screen mode

Some of you might now think: There are solutions on the market available that solve these issues like:

  • ThinKiosk
  • Citrix Desktop Lock
  • Citrix WEM Transformer Mode

But these solutions have some points we didn’t like in our Scenario: They are either quite limited – e.g. Desktop Lock always starts the first available Desktop for the user. He can’t choose which Desktop is started when he has assigned multiple Desktops. The other solutions on the other side meant it would be necessary to implement / maintain / configure another software. Yes, these software solutions have their advantages – but the idea was to just use the available tools!

My first idea was to use the Windows 10 function Assigned Access. Unfortunately, it was only possible to publish modern apps with this solution and not classical ones like Internet Explorer. In the documentation (and if you google for it) you see that there are commands / script available to also publish classical apps – but that didn’t work for me.

So, I decided to look at other ways. I remembered that it was possible to assign a Custom User Interface with a GPO to Windows. My idea was to automatically logon the endpoint, start the Internet Explorer in Full Screen mode and open the StoreFront Website.

The first step was to create a new Group Policy named Windows Thin Client and assign it to the OU containing my test device. Inside the policy I configured the following setting to automatically launch the Internet Explorer instead of the Windows Explorer after Logon:

User Configuration => Policies => Administrative Templates => System => Custom User Interface

Interface File name
"c:\Program Files\Internet Explorer\iexplore.exe" -k

This starts the Internet Explorer and opens the StoreWeb page.


The next step is to enable the automatic user logon. Microsoft has documented the necessary registry keys here. You need to create the following registry keys:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Name Type Data
DefaultPassword REG_SZ PASSWORD
DefaultDomain REG_SZ DOMAIN
AutoAdminLogon REG_SZ


I added them to the same policy:

Time to power up the test-machine and look how it works so far. Test-System was Windows 10 LTSC (to keep the necessary upgrades low), an Anti-Virus-Tool and a current Citrix Receiver (Workspace App).

The system booted – user was automatically logged in – Internet Explorer was started – but also the Setup Internet Explorer Dialog popped up:

Ok – back to the GPO to disable the Wizard:


After closing the First Run Wizard Internet Explorer asked if I really want to run the Citrix Receiver Active X Plugin:

It is possible to automatically allow an Active X Plugin with a GPO setting – but therefore we need the Class ID of the addon. To find that you need to open Manage Add-ons from the Internet Explorer Settings Menu on the top right. Now select the Citrix ICA Client Add-On and press More information on the bottom left to show the details.

Inside the details view you get information’s like Name, Publisher, etc. and also the Class ID. Use Copy to copy the details (including the class ID) to the clipboard.

Open Notepad and insert the content. We now just need to copy the Class ID. After copying the Class ID to the clipboard switch back to your GPO. The Class ID for the Citrix ICA Client is:


You now need to open the following setting:

Computer => Administrative Templates => Windows Components => Internet Explorer => Security Features => Add-on Management => Add-On List

Here you can now configure Add-ons as allowed. Press Show….

… to open the Add-on configuration. As the Value name paste the copied Class ID. For the Value enter “1”. (1 enables the Add-on and this cannot be changed by the user.)

Now it was time to logon to the StoreFront Website and launch a Desktop. But before the Desktop was started another message appeared:

Ok. Back to the GPO (again) and assign the StoreFront Website to the correct Security Zone. You need to open the following setting:

Computer => Administrative Templates => Windows Components => Internet Explorer => Internet Control Panel => Security Page => Site to Zone Assignment List

Again, press Show

… to open the Configuration. Value Name is the URL (starting with https://) of your StoreFront Website. The Value is 2 (Trusted Sites).

Time to reboot the test client, delete the user profile and logon again as a user to see how it now behaves. After logging in the Internet Explorer was started and the StoreFront Website was opened – but also the following Dialog appeared:

The user can disable the message with Do not show this window automatically at logon, but it would be a manual step on every new client. In theory there is a Citrix Receiver Policy setting available that disables this message – it did not work on my test client. I looked for another way. In CTX135438 there are several options described to disable the message. Next to the GPO it is also possible to install the Receiver with a Parameter to disable the message. I changed the software deployment to install the receiver with the following parameter:

CitrixReceiver.exe /ALLOWADDSTORE=N

After a reinstallation of the system the message was gone. Time for some more tests. After logging in a user to StoreFront a Desktop was automatically launched when only one was assigned – as expected but it was not launched in full screen mode. When switching to full screen, logging of the desktop and connecting it again the desktop was launched in full screen. The only thing is that this would require a user interaction – the user had been used that the desktop automatically starts in full screen. I found several methods that describe how to force full screen mode for started desktops. They did not work. After some more searching I stumbled across this discussion. Inside this discussion the following registry key was mentioned:





As this is a user setting I first enabled the loopback mode as the GPO was assigned to the Computer object and not the user:   

Then I added this entry to the GPO:15_win_thin_client

Deleting the user profile and another test – yes worked as expected. User was automatically logged on to the client, StoreFront Website was opened, user can login, published Desktop is started in full screen. I did some more tests and everything worked fine. Then I locked the client – but not the remote session itself was locked – the local client was locked. That means that the user would need to know the password of the user that automatically logged in to the client. It means that every user could unlock every other client. Not a good idea. Beside that I started to think about it. When the remote session was locked another user would be able to disconnect the session. If the automatic logout of the StoreFront website did not already happen he would be able to restart the user session without knowing his password. Not a good way. I had to change the idea of automatically logon the client. The user needs to login to the client and instead an automatic login to StoreFront was required. I removed the following registry settings from the GPO to disable the automatic client login:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Name Type Data
DefaultPassword REG_SZ Password
DefaultDomain REG_SZ DOMAIN
AutoAdminLogon REG_SZ


The next step was to create a new StoreFront Website that allows automatic user logons. So, I opened the StoreFront console, selected my store and switched to the Receiver for Web site area to add another one (Manage Receiver for Web Sites => Add).

The first step is to enter the name / path of the web site.

After that it was necessary to configure Domain pass-through as the Authentication Method:

The web site was created. 

As the user should only be able to launch a desktop and not an application I opened the settings of the new web site. Under Client Interface Settings I changed the Select View to Show Desktops view only.

After changing the URL in the GPO to the new web site I logged in with a user to the client. The new website was opened and the following error message appeared:

Cannot complete your request


On the StoreFront server I found the following Event.

Source: Citrix Receiver for Web
Event ID: 17
Level: Error

Failed to run discovery

Exception Status: TrustFailure


As there was a domain certificate assigned to the StoreFront ISS website with the domain name it was not surprising that the connection to the local IP address fails with a Trust error.

To fix this I went back to the settings of the new create StoreFront Website. Under Advanced Settings I changed the Enable loopback communication to OnUsingHttp.

After that the error was gone – but the user was prompted to login:

To fix this I had to adjust the zone assignment of the StoreFront Website to Intranet Zone instead to Trusted Sites. Another solution would have been to enable the setting Automatic logon with current username and password for the zone Trusted Sites.

After this change the StoreFront Website was automatically logged on and I was able to start a published Desktop. But now the published desktop required a separate login instead of using the local username / password.

Time to add the Receiver ADM/ADMX Templates to our configured GPO. Inside the Receiver Settings (Computer Configuration => Citrix Components => Citrix Receiver => User Authentication) you find the following setting:

Local user name and password

Inside this you need to enable the following two settings thus the Receiver can automatically logon the user to the published desktop:

Enable pass-through authentication

Allow pass-through authentication for all ICA connections

(This requires you to configure XML Trusts on your delivery controller if you didn’t use that in the past – see CTX133982. Furthermore check if you installed the Receiver with the Single-Sign-On-Module – parameter /includeSSON during the installation. For Receiver Version 4.4 or higher this parameter should also be enough – thus you don’t need to enable the policy any longer – but haven’t tested that.)

That’s it – the user was now able to logon and start a published Desktop without any further logons required.

Honestly this is just the start – there are some other points you should have a look at before deploying the system to productive users:

  • Use the Receiver Policy to connect USB devices automatically to the Published Desktop (Generic USB Remoting)
  • Enable Kerberos Authentication for Receiver if required (Kerberos Authentication)
  • System Settings eg:
    • Anti-Virus
    • Disabling of Registry Editor
    • Disable the local Task Manager (to prevent the user to kill the Full screen Browser)
  • System Hardening

Hope it gives you an idea how you can create your “own” Windows based “Thin Client” with a GPO.

    Leave a Comment

    Leave a Reply

    Fill in your details below or click an icon to log in: Logo

    You are commenting using your account. Log Out /  Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out /  Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out /  Change )

    Connecting to %s

    %d bloggers like this: