When 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)

When 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.

In a verbose log you’ll see the following line

MSI (s) (B0:04) [13:54:53:463]: MSI_LUA: Elevation required to install product, will prompt for credentials

followed by the following lines after the user confirmed.

MSI (s) (B0:04) [13:54:55:865]: MSI_LUA: Credential Request return = 0x0
MSI (s) (B0:04) [13:54:55:865]: MSI_LUA: Elevated credential consent provided. Install will run elevated

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.

In a verbose log you’ll see the following line

MSI (s) (B0:04) [13:55:04:446]: Executing op: ActionStart(Name=res.exe,,)
MSI (s) (B0:04) [13:55:04:446]: Executing op: CustomActionSchedule(Action=res.exe,ActionType=1618,Source=C:\Program Files\RES Software\Workspace Manager\svc\res.exe,Target=/msiparms=3||{18E874CB-DCEE-49F9-9EE4-D9133C58927D}||********||||NO||SAHPSXD6554;SAHPSXD6555;SAHPSXD6854;SAHPSXD6855||||YES||Hosted Private Machines||no||||||||||||||||||||,)

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).

To prove this theory I added two Custom Actions that call whoami to read the users privileges.

1. WhoAmI_default with type 1058
   • 34 [EXE file having a path referencing a directory] +
   • 1024 [msidbCustomActionTypeInScript]
2. WhoAmI_noimpersonate with type 3106
   • 34 [EXE file having a path referencing a directory] +
   • 1024 [msidbCustomActionTypeInScript] +
   • 2048 [msidbCustomActionTypeNoImpersonate]

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

WhoAmI_default

Privilege Name                Description                          State   
============================= ==================================== ========
SeShutdownPrivilege           Shut down the system                 Enabled 
SeChangeNotifyPrivilege       Bypass traverse checking             Enabled 
SeUndockPrivilege             Remove computer from docking station Disabled
SeIncreaseWorkingSetPrivilege Increase a process working set       Disabled
SeTimeZonePrivilege           Change the time zone                 Disabled

WhoAmI_noimpersonate

Privilege Name                  Description                               State   
=============================== ========================================= ========
SeAssignPrimaryTokenPrivilege   Replace a process level token             Disabled
SeLockMemoryPrivilege           Lock pages in memory                      Enabled 
SeIncreaseQuotaPrivilege        Adjust memory quotas for a process        Disabled
SeTcbPrivilege                  Act as part of the operating system       Enabled 
SeSecurityPrivilege             Manage auditing and security log          Enabled 
SeTakeOwnershipPrivilege        Take ownership of files or other objects  Disabled
SeLoadDriverPrivilege           Load and unload device drivers            Disabled
SeProfileSingleProcessPrivilege Profile single process                    Enabled 
SeIncreaseBasePriorityPrivilege Increase scheduling priority              Enabled 
SeCreatePagefilePrivilege       Create a pagefile                         Enabled 
SeCreatePermanentPrivilege      Create permanent shared objects           Enabled 
SeRestorePrivilege              Restore files and directories             Disabled
SeShutdownPrivilege             Shut down the system                      Disabled
SeAuditPrivilege                Generate security audits                  Enabled 
SeChangeNotifyPrivilege         Bypass traverse checking                  Enabled 
SeImpersonatePrivilege          Impersonate a client after authentication Enabled 
SeCreateGlobalPrivilege         Create global objects                     Enabled

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.

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:

%ProgramFiles%\RES Software\Workspace Manager\svc\res.exe /config

.