deviceTRUST macOS Client 19.4.200 is now available. See the release notes for more information.

Best Practices

Consuming the deviceTRUST context

deviceTRUST is designed to allow the context to be consumed by your existing management solution such as:

  • Traditional logon script.
  • Microsoft Group Policy (GPO) scripts.
  • Microsoft Group Policy Preferences (GPP).
  • User Environment Management (UEM) products (Ivanti User Workspace Management, RES ONE Workspace, VMware User Environment Manager, Citrix Workspace Environment Management (WEM) etc.).

For easy consumption of this deviceTRUST context, all properties are made available within the users’ session as registry values under HKCU and / or user specific environment variables.

Registry and Environment
Registry and Environment

Step 1: Ensure your management solution can access the deviceTRUST information

To consume the context provided by deviceTRUST within an existing management solution, deviceTRUST must be configured to persist the context information to the Windows Registry before the management solution processes the user logon. Within the deviceTRUST configuration under COMPUTER CONFIGURATION\ADMINISTRATIVE TEMPLATES\DEVICETRUST\SHELL ACCESS, the METHOD USED TO BLOCK LOGON WHILST PROPERTIES ARE READ FROM THE CONNECTED DEVICE defines this behavior and must be set to BLOCKING:

  • The default behavior of deviceTRUST ensures that your management solutions can access the latest context information at Logon and Reconnect. There is no need to change this setting to support your management solutions.

Step 2: Configure persistence of context information within the users’ session

Within the deviceTRUST configuration under COMPUTER CONFIGURATION\ADMINISTRATIVE TEMPLATES\DEVICETRUST you can define the persistence of those context information for the users’ registry, environment variables and through the deviceTRUST Command Processor. Those settings are:

  • Persist properties to the users’ registry.
  • Persist properties to user environment variables.
  • Allow deviceTRUST triggers to get properties of the user and Define who can get properties of the user.

The context information deviceTRUST delivers into the users’ session will be persisted as registry values or environment variables when these settings are set to DEFAULT or ENABLED.

  • At least one of these settings must be enabled for existing management solutions to consume the context.
  • You can disable both settings at the same time, but your existing management solution will not have access to the context within the users’ session. In this scenario, only actions triggered by the deviceTRUST triggers have access to the context information as environment variables.
  • Choose between the persistence of registry values and environment variables based on the best practice of your management solution.

Step 3: Check if a deviceTRUST Client is installed on the remote device (EUC)

Depending on your configuration for ‘Untrusted Devices’, you should check first if client-based context information’s are available within the users’ virtual session. This can be achieved by checking the value of the HOST_DEVICETRUST_CONNECTED property:

Property Value Range Description
HOST_DEVICETRUST_CONNECTED false There is no deviceTRUST Client installed on the remote device and therefore only the HOST_* properties are available within the users’ virtual session.
  true There is a deviceTRUST Client installed on the remote device and therefore the HOST_* and DEVICE_* properties are available within the users’ virtual session.

Step 4: Using deviceTRUST Triggers with your management solution

Depending on the management solution you are using, deviceTRUST triggers can bring additional value to your management solution. For example, traditional logon scripts (triggered by NETLOGON share or from within a Microsoft Group Policy) can consume the deviceTRUST context information. However, they are unable to react to a reconnection, or to a change to one of the existing properties.

With deviceTRUST triggers, you can now also execute scripts or executables when a user reconnects to an existing session, or when the value of the properties changes. In this scenario, you can leave your logon script within the NETLOGON share or Microsoft Group Policy but call it again if a user reconnects or a property change occurs. This will enhance your ability to act with your scripts on logon, reconnect and on a property change which you can’t do with your traditional logon script.

If a more advanced User Environment Management solution is used, the built-in triggers of that solution also enable you to act on a Reconnect event. deviceTRUST ensures that the context information delivered into the users’ virtual session can be consumed by those UEM solutions on Logon and Reconnect. In this scenario, the deviceTRUST Property Change trigger can be used to trigger the UEM solutions to act on mid-session property changes of the remote device and user.

  • It is also possible to use any deviceTRUST trigger in conjunction with the management solution you are using. There is no technical limitation why you shouldn’t use the deviceTRUST triggers together with the triggers your management solution offers.
  • deviceTRUST RECONNECT triggers are only applicable to End-User Computing (EUC) installations.

Step 5: Notify your management solution during session runtime

Some management solutions are able to track a start of a process and can apply their own policies at that time to the users’ session. To be able to notify any capable management solution about a context change during the runtime of the users’ session, deviceTRUST has introduced a new application called DTNOTIFY.EXE which will be installed as part of the deviceTRUST Host.

DTNOTIFY.EXE is installed within the deviceTRUST Host folder under %PROGRAMFILES%\DEVICETRUST\HOST\BIN and can be triggered through the deviceTRUST triggers to notify your management solution about a context change. An argument can be supplied on the command line to differentiate between context changes.


With the following command you could very easily notify e.g. Ivanti User Environment Manager about a security context change to trigger Ivanti User Environment Manager to re-apply their policy set during session runtime.

dtnotify.exe “Security”

The following screen shows the Ivanti User Environment Manager management interface, which demonstrate how the PROCESS STARTED condition was defined to catch security context changes provided by deviceTRUST:

Environment Manager
Environment Manager

Customize properties

Out-of-the-box most of the available deviceTRUST properties are enabled and create a PROPERTY CHANGE event every time a DYNAMIC or DYNAMIC (REAL-TIME) property changes. Please consult the Property Matrix for detailed information about DYNAMIC or DYNAMIC (REAL-TIME) properties. It is recommended to consider the following steps to make your deviceTRUST configuration effective: