Unattended RES WM2012 agent does not store Relay Server configuration with UAC enabled

Written by Ingmar Verheij on June 19th, 2013. Posted in Workpace Manager

RES Workspace Manager Agent - Configure connectionWhen RES Workspace Manger 2012 is installed unattended and configured to connect to a Relay Server, and User Account Control (UAC) is enabled, the configuration is not stored. As a result the agent is unmanaged.

After extensive testing I found the solution to solve this issue.

PS: This applies for both SR2 and SR3 (release notes).

User Account Control (UAC)

User Account Control SettingsWhen UAC is enabled (introduced since Windows Vista) a user has a token with only basic privileges, administrative privileges are filtered (removed). The administrative privileges are only available when a process is ran with elevated permissions. The user needs to confirm to run the process in elevated mode (and specify credentials)  in a UAC prompt.

In the environment where I’m setting up RES Workspace Manager UAC is enabled with the default policy (notify only when programs try to make changes to the computer).


Windows Installer

Windows Installer is used to install RES Workspace Manager Agent (.msi extension). The user interface that’s shown to the user (of hidden when running unattended) runs in the users context with a filtered token (without administrative privileges). Since the installation makes changes to the computer, elevation is required and the user is prompted by UAC.

UAC question

In a verbose log you’ll see the following line

followed by the following lines after the user confirmed.


Custom Actions

Custom Actions are used in Windows Installer to launch executables that are on the local machine or installed by the installation. A Custom Action named ‘res.exe’ is used to configure the RES service with the specified datastore connection.

RES-WM-2012-Agent-SR3 - Custom Actions

In a verbose log you’ll see the following line

In the example above a list of Relay Servers is specified including the GUID and encryption password (********). However, as said in the introduction the configuration is not applied to the RES Workspace Manager service.


Impersonating the invoking user

By default Custom Actions impersonate the invoking user (having a filtered token, without administrative privileges). As a result a machine-state changing task can fail, which indeed is the case for the datastore configuration. The default behavior of a Custom Action can be changed using value in the ‘Type’ field. When the msidbCustomActionTypeNoImpersonate option flag is set the user is not impersonated,  the action is executed by the user with elevated privileges (a non-filtered token).

RES-WM-2012-Agent-SR3 - InstallExecuteSequence - WhoAmITo prove this theory I added two Custom Actions that call whoami to read the users privileges.

  1. WhoAmI_default with type 1058
  2. RES-WM-2012-Agent-SR3 - Custom Actions - WhoAmIWhoAmI_noimpersonate with type 3106

The result of the two custom actions clearly show the difference in the privileges of the user:




Patch RES Workspace Manager installation file

In the installation file provided by RES Software the option flag set for the Custom Action ‘res.exe’ is set to 1618 decimal (or 0x652). To enable the NoImpersonate option flag we need to add 2048 (or 0x800) resulting in 3666.

RES-WM-2012-Agent-SR3 - Custom Actions - Patched

Now if the Custom Action ‘res.exe’ is executed (and UAC is enabled) the task is executed by the user with elevated permissions and changes can be made to the system.

Instead of changing the original MSI file you can also create a transform file (MST). You can download the transform file for the Workspace Manager 2012 SR3 agent here: RES-WM-2012-Agent-SR3.mst. Thanks to Remko Weijnen for the tip!

Configure Connection

After the MSI file was “patched” and executed the datastore configuration was applied successfully. The datastore configuration can be shown (and changed) by executing the following command line:


RES Workpsace Manager Agent - Configure connection




Ingmar Verheij

At the time Ingmar wrote this article he worked for PepperByte as a Senior Consultant (up to May 2014). His work consisted of designing, migrating and troubleshooting Microsoft and Citrix infrastructures. He was working with technologies like Microsoft RDS, user environment management and (performance) monitoring. Ingmar is User Group leader of the Dutch Citrix User Group (DuCUG). RES Software named Ingmar RES Software Valued Professional in 2014.

More Posts - Website

Follow Me:
TwitterLinkedInGoogle Plus

Tags: , , ,

Comments (3)

  • 21 June 2013 at 10:12 |

    A great article Ingmar, and thanks for bringing this to our attention!

    We will take a look, and see if we can’t do something about it. It’s not right that we should expect you guys to patch an installer to get it doing what you need it to do!

    Cheers, and keep up the good work. It is community contribution like this that make RES Software who we are!


    • Ingmar Verheij
      21 June 2013 at 15:12 |

      Thanks for the kind words Grant, keep up the good work at RES!

  • Ingmar Verheij
    19 August 2013 at 14:01 |

    I just got confirmed that this bug will be fixed in SR4 (expected to be released in Week 39/2013).

    If you can’t wait for this release, or need to deploy SR3, you can use the provided solution from this article.


Leave a comment



%d bloggers like this: