+49 (0)261 – 9 27 36 – 0 info@sul.de
[ivory-search id="214639" title="DIVI Header Search Form"]
As a Citrix/RDS/VDI admin you (hopefully) know FSLogix by now, probably primarily the profile container. Especially the Citrix guys should also know Citrix Workspace Environment Manager (WEM)right 😉? But do you already know FSLogix AppMasking and deviceTRUST? No? Then you missed something, but that can be changed. These three tools operate perfectly together, and I want to give you an example for that.  Many of you know the following problem. You install software on your RDS host which requires a device licensing model, a good example is always MS Office (not Office 365 J). So, you have to somehow ensure, that certain devices (not users!) CANNOT run Office, but you also want to maintain as few images as possible. Some say it is enough to create an AppMasking Rule with FSLogix to hide MS Office and use the computer or an environment variable (clientname) as an assignment. Audits have shown that this isn’t enough, so you better make sure that you have a valid solution. We had some discussions about that topic on Twitter 😉 a while ago  So, I will show you how to do it the safe way:   First, you install your software on the RDS host, e.g. MS Office and create a new AppMasking rule using the FSLogix Apps RuleEditor. If you use PVS or MCS, you should put the rules in a central share and use the Base Image Script Framework (BIS-F) to have the rules copied locally when starting your VDA hosts. Here is an good documentation how to create these rules. At this point we need to make sure that the application is not hidden for any user. We’ll come to that later … 
You will realize, that the FSLogix rule is going to hide the application shortcuts from the common start menu and common desktop folder amongst other things, so that after the rule applies a user isn’t able to see the app shortcuts. That’s a good idea, but many of you hide these folders by default, so these rules are more or less useless. So, if you don’t redirect the user desktop or start menu you can simply add the following rules to hide the shortcuts:



C:\Users\*\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Outlook.lnk


Unfortunately, FSLogix isn’t able to hide application shortcuts that are located on redirected folders, so in case of folder redirection you can use WEM to manage the shortcut creation.


WEM is able to control the applications shortcuts which are created on the user desktop and/or start menu. First add an application, then assign this application to your users or better AD group. In this case it doesn’t matter if the folders are redirected or not.

Now deviceTRUST (dT) comes into play: “deviceTRUST delivers more than 200 hardware, software, network, security, performance and location contextual properties into the virtual and physical workspaces. deviceTRUST can easily integrate with any existing workspace management solution and requires no additional infrastructure. The context is always up-to-date and any change triggers a definable action.” Source: https://devicetrust.com/ With these properties we can create a context. For example, we can specify that the device should be a member of our domain or, in the case of Igel thin clients, they must be managed by a YOUR UMS server to be recognized as a licensed corporate device. Context changes are able to trigger actions, e.g. execute a FSLogix AppMasking task.   dT is easy to install and manage, you don’t need a big infrastructure. First, we have to install the dT Host on our VDA/RDS servers (or golden master) and a dT console on a server with GPMC installed.  
The dT client has to be installed on the devices. There are clients available for Windows, MacOS, iOS, Igel and eLux Thin Clients. For Igel and eLux you have to enable dT for the Thin Client in the newer firmware releases. deviceTRUST is also able to get client properties from Dell Thin Clients, although there is no client available yet.   You have to configure dT with group policies. dT has ADMX templates and a nice console that integrates in GPMC. Here is a nice getting started guide. You can configure black and white lists, e.g. if dT should not be used for your Administrators. Best practice is, to only enable the device and host properties you really need, so that there is no overhead to provide the necessary information.  

You should configure at least the following settings:

Computer Configuration – Administrative Templates – deviceTRUST

  • Enable deviceTRUST (and supply a license, there are EVAL licenses available)
  • Blacklist of users not controlled by deviceTRUST
  • Whitelist of users not controlled by deviceTRUST
  • All the Device properties you want to check and use for your context

Here you can find all the policy settings.


Let’s assume you want to check the device MAC address and the domain membership to make sure this is a “known” device for which you have a valid license.

You have to configure the following device filters to get this information:

deviceTRUST/Properties/Device Filter 

  • Filter device DOMAIN, name, dns, sid, etc: DEVICE_DOMAIN_SID – Enabled
  • device NETWORK ip, mac, dns, wifi, etc: DEVICE_NETWORK_X_MAC

Let’ see what information we get after a logon with a “deviceTRUST enabled” device which is a member of our domain. The content depends on what you have configured in the GPO:

Eventlog of VDA: (Applications and Services Logs\deviceTRUST\Admin):


















The same information is present in the following registry key of the VDA: HKEY_USERS\S-1-5-21-SID-OF-USER\SOFTWARE\deviceTRUST\Properties.

You can also get this information as environment variables.


Now we can use this information to create a “context” with deviceTRUST, to create a context you have to use the deviceTRUST Console which is integrated in GMPC. Open your deviceTRUST GPO and select deviceTRUST Console:

Select Context and create a new context:


  1. Give your context a unique name
  2. Enter a description
  3. The Default value is “Not licensed”
  4. Check the domain SID (Windows) the MAC address and Igel UMS for example
  5. If it matches set the value to “Licensed”
Save your settings and go back to select actions, create a new action:

  1. Give your action a unique name
  2. Enter a description
  3. Add a new trigger (context changed) and select the previously configured context with the value “Not licensed”
  4. Click next and select the filter “Logon”, click OK
  5. Now you can add tasks like “Audit event”, “FSLogix AppMasking”, “Popup message”, etc.
  6. The last task should be “FSLogix AppMasking” to hide Office, cause the device is not licensed. It’s very simple, just enter the path of your AppMasking rule and select “Automatically revert to previous values on ‘Disconnect or Logoff’
  • Since we only want to take care of devices that are “Not licensed” we only have to create triggers for that condition.
  • If you want to inform the user that the device is not licensed for MS Office you can show a Popup message, but keep in mind that this requires a new trigger “On Logon Shell Ready” to make sure the shell is already loaded.
  • If a user disconnects from a HDX session with a licensed corporate device and reconnects at home with a BYO device (which is not licensed) you have to use the “Reconnect” trigger and hide MS Office again with AppMasking. You can also terminate Office applications that the user left open while disconnecting
  • Again, if you want to inform the user that the device is not licensed for MS Office you can show a Popup message, but keep in mind that this time you requires the trigger “On Reconnect Shell Ready” to make sure the shell is already loaded.


As already mentioned, if you use folder redirection for your user desktops you will realize that AppMasking isn’t able to hide the shortcuts on the desktop. Remember, we used WEM to create the shortcuts, so we have to change some configurations to deal with the creation and deletion of the shortcuts.


To tell WEM, that the app shortcut is only created when the device is licensed, we can use a filter. So, let’s create a condition to check a registry value from deviceTRUST and reassign the applications with WEM.


The context information for that is available in the registry under the key HKEY_CURRENT_USER\SOFTWARE\deviceTRUST\Contexts

So, we are ready to test our configuration. In the end the deviceTRUST action should look similar to this:
This is how it looks like on a corporate device

Corporate device connecting to VDA, deviceTRUST determines the context:



User DOMAIN.DE\DMohrmann logged in.







My customized BGInfo (Download here) reads this information from the registry:

WEM creates the application shortcuts and I can execute MS Office apps

This is how it looks like on a noncorporate device

Noncorporate device connecting to VDA, deviceTRUST determines the context:

deviceTRUST triggers FSLogix to apply the AppMasking rule User gets message after logon (optional):


User DOMAIN.DE\DMohrmann logged in.





Successfully updated App Masking rule assignment ‚C:\Program Files\FSLogix\Apps\Rules\Office.fxa‘ for user DOMAIN.DE\DMohrmann with operation ApplyUser.


My customized BGInfo (Download here) reads this information from the registry:

WEM doesn’t create the application shortcuts and I can’t execute MS Office apps     User disconnects from a corporate device and reconnects from a noncorporate device Noncorporate device connecting to VDA, deviceTRUST determines the context:
  1. User gets message after reconnecting (optional):

An event was generated for user DOMAIN.DE\dmohrmann.

Message: Microsoft Office isn’t licensed for user ‚dmohrmann‘ with the dem device ‚PC-02‘ (Context changed)

Successfully updated App Masking rule assignment ‚C:\Program Files\FSLogix\Apps\Rules\Office.fxa‘ for user DOMAIN.DE\dmohrmann with operation ApplyUser.

deviceTRUST triggers WEM agent to stop and restart, so that the shortcuts will be removed, otherwise they will become invalid

Office apps that are already open will be closed after a given time

So, basically that’s it! With FSLogix, WEM and deviceTRUST you are able to control your device licenses in a proper way and this is only one single use case of many others you can cover with deviceTRUST, FSLogix and WEM