RG004 – Workspace Manager commandline parameters

By Max Ranzau


The purpose of this technote is to provide a singular point of reference to all the commandline parameters which are available in RES Workspace Manager and related sub systems, such as the Workspace Manager management console, Desktop Sampler, Workspace Composer, VDX, etc. The technote was one of the very first articles written back in the beginning of 2009 and will continue to be expanded as new feature become available. The information below has been picked up from the release notes, online help, knowledgebase and similar sources. All the executables referenced below are unless otherwise indicated to be found in %programfiles%RES Workspace Manager, which is the default location. Use the jumplink index below:

Parameters for the Workspace Manager Management Console

Performing buildingblock import/delete actions

Add/remove Citrix servers to servergroups

Make the 2008 console skip loading AD info at startup

Dealing with a locked out console user

Add/remove computername to (Partial) Computername zone

Export Network Security log (WM2012 SR2)


Installation parameters

Workspace extender installation parameters

Workspace Manager unattended/silent installation

Desktop Sampler installation parameters

Reconfiguring agent connection parameters


Mixed bag o’ tricks

Start workspace composer in exclusive/specified workspace

Starting a defined Workspace Manager application during logon

Reference for PwrGate.exe command line options (separate article)

Workspace Manager Subscriber configuration

WM Relay Server Interactive configuration mode


Parameters for the Workspace Manager Management Console


Performing buildingblock import/delete actions

pwrtech.exe /add [/overwrite] <full-path-to-buildingblock.xml>

The commandline above imports a single building block. Example: “%programfiles%\res Workspace Manager\pwrtech.exe” /add f:\buildingblocks\appguard_authorizedfiles.xml

pwrtech.exe /add [/overwrite] <full-path\wildcard*.xml>

Imports multiple buildingblocks from a given path. Example: “%programfiles%\res Workspace Manager\pwrtech.exe” /add f:\buildingblocks\*.xml

pwrtech.exe /del <full-path-to-your-buildingblock.xml>

Deletes a given application in Workspace Manager. Example: “%programfiles%\res Workspace Manager\pwrtech.exe” /del f:\buildingblocks\startmenu_accessories_calculator.xml

Note1: In order for the applixation /del switch to work, the GUID’s in the datastore must match the one in the buildingblock, i.e you cannot use a buildingblock to delete an app just because it has the same display name.

Note2: When using the /add switch, you can optionally specify the /overwrite switch. This specifies that the imported settings should replace any existing settings in the same node. If you do not add this switch, all settings in the specified Building Block files will be merged with the current settings in the RES Workspace Manager Management Console. I guess this is important when importing global authorised files list in order to avoid a merge.

Note3: Up to Workspace Manager 2010 SR2 it’s not possible to do an commandline driven export of buildingblocks, which would be cool for automated backups. Nevertheless the feature has been requested so we’ll have to see when/if we get it.

Note4: Per Workspace Manager 2011 SR1, Update Pack 3 (, pwrtech.exe now gives exit codes (errorlevel) upon import. The exit codes are as follows:

0 = Success

1 = File not found

2 = Insufficient Permissions

4 = Import failed


Add/remove Citrix servers to servergroups

pwrtech.exe /serveradd=<servername> /group=<servergroup>

The above command will add a Citrix server to a group. Example: “%programfiles%\res Workspace Manager\pwrtech.exe” /serveradd=CTX10 /group=CTXServerGroup

pwrtech.exe /serverremove=<servername> /group=<servergroup>

Removes a Citix server from a specific group. Example: “%programfiles%\res Workspace Manager\pwrtech.exe” /serverremove=CTX10 /group=CTXServerGroup

pwrtech.exe /serverremove=<servername> /group=*

Removes specified server from ALL groups at once. Example: “%programfiles%\res Workspace Manager\pwrtech.exe” /serverremove=CTX10 /group=*

Using these 3 command line parameters, you can add or remove Citrix servers to server groups without using the Management Console. Note: The mentioned servergroups are NOT XenApp 6.5 servergroups. This functionality was in the Workspace Manager product since Metaframe XP. This feature was then typically used in an automated scenario where for example RES Automation Manager was used, to re-install a Citrix Server with new software and remove old software. First, RES Automation Manager would remove this server from any Server Group. Then the new software will be installed and the old software will be removed. As a final step, RES Automation Manager will add this server to the right Server Group. Below are some practical examples on usage; suppose you have two Citrix XenApp silos (an Office Silo and an SAP Silo) like this:

CTXSRV001 Office Silo CTXSRV006 SAP Silo

CTXSRV002 Office Silo CTXSRV007 SAP Silo

CTXSRV003 Office Silo CTXSRV008 SAP Silo

CTXSRV004 Office Silo CTXSRV009 SAP Silo

CTXSRV005 Office Silo CTXSRV010 SAP Silo

In the event that the SAP silo to the right above becomes overloaded, an imaging tool of your choice can be used to transform server CTXSRV004 and CTXSRV005 into SAP servers, resulting in these new silo configurations:

CTXSRV001 Office Silo CTXSRV006 SAP Silo

CTXSRV002 Office Silo CTXSRV007 SAP Silo

CTXSRV003 Office Silo CTXSRV008 SAP Silo



The practical problem in this scenario is, the XenApp farm would still thinks that CTXSRV004 and CTXSRV005 are servers on which Microsoft Office has been installed, and the farm will be load balancing Office users to CTXSRV004 and CTXSRV005. As a result, Office users would experience that Office will be unavailable (because it has not been installed) and SAP users will not be load balanced to these new servers. This is why the servers on which these applications are published need to be adjusted, by using the above described method. The RES Automation Manager Agent can be embedded in the image together with a RES Workspace Manager installation. When the image comes online, RES Automation Manager and RES Workspace Manager will automatically perform the necessary steps.



Make the PowerFuse 2008 management console skip loading AD info at startup

pwrtech.exe [/skipou] [/skipusers] [/skipgroups]

These options are only relevant for Workspace Manager 2008, as the way the console enumerates AD objects has completely been rewritten in Workspace Manager 2010 and newer. The options would respectively skip ou’s, users and groups. You can use them together or in combination. This allows you to start up the RES Workspace Manager Management Console much faster, which can be very beneficiary in very large environments. Start up the RES Workspace Manager Management Console. This will display the RES Workspace Manager splash screen. During the startup process, the Skip loading button will be displayed in the lower right corner of the RES Workspace Manager splash screen. When you click Skip loading, it will open up a new window, where you can select which elements should be skipped when loading information from the domain. If support for OUs has not been enabled in your environment, the option Organizational units cannot be selected. If OUs, users and/or groups have already been loaded, these options cannot be selected.


Dealing with a locked out console user

pwrtech.exe /lockedout

In Workspace Manager 2008 SR3 and newer, a parameter was added to the console to deal with a locked out situation due to misconfiguration of Administrative Roles. This can be solved by starting the Console using a command line with the parameter /lockedout (e.g. “%programfiles%RES Workspace Managerpwrtech.exe” /lockedout). If the user can provide the correct database credentials (dbuser and dbpassword), the current users Windows credentials are added to the Security Role “Technical manager”, so that the legitimate user can get access to the Workspace Manager Management Console again.

Notes: Use of the /lockedout method, including failed attempts, is logged in the Audit Trail.  The same feature is now also available in Automation Manager 2009; in this case use wmc.exe /lockedout


Add/Remove computername to (Partial) Computername zone

Valid from Workspace Manager 2012 ( The releasenotes states the following: At User Context > Locations and Devices, on the Rules tab of a zone based on (Partial) computer name, you can manually add the relevant computer names. Specifically for this type of zone, computer names can also be added to an existing zone using the command line. This can be used, for example, for scripting. The Administrator who runs this command must have access to the Console and to Zones. Syntax examples:

To add MACHINE002 to the zone “France > Paris > Building A > Floor 1”, use the following command line:
pwrtech.exe /clientadd=MACHINE002 /zone={7B8BF240-3682-41C5-881E-B14595593817}

Above, {7B8BF240-3682-41C5-881E-B14595593817} is the GUID of the zone “France > Paris > Building A > Floor 1”. Note: The GUID of a given zone can be found on the Properties tab of any given zone.

If the command is run without a value for the parameter /clientadd, the current computer on which the command is run will be added at the moment of execution:
pwrtech.exe /clientadd /zone={7B8BF240-3682-41C5-881E-B14595593817} If the command is run with a question mark as the value for the parameter /zone, a selection window opens to allow selection of the relevant Zone:

pwrtech.exe /clientadd /zone=?

To remove a Zone Rule for a particular client from a particular Zone, use this command:

pwrtech.exe /clientremove=MACHINE002 /zone={7B8BF240-3682-41C5-881E-B14595593817}

Finally, if the command is run with an asterisk (*) for the parameter /zone, all existing Zones are checked and any Rule where the (partial) computer name = MACHINE002 will be removed, like this:
pwrtech.exe /clientremove=MACHINE002 /zone=*


Export Network Security log (WM2012 SR2)

In Workspace Manager 2012 SR2, it is now possible to export the network security log file in the interchangeable .xml format via the following command line:

Pwrtech.exe /exportlog /type=network /output=output location /start=start date /end=end date
Example: Pwrtech.exe /exportlog /type=network /output=c:\networklogs.xml /start=20120101 /end=20120630

The values for output, start and end can be specified. The values for start and end need to be set in the YYYYMMDD (optionally YYYMMDDHHMMSS) format and are not mandatory. The Console administrator needs to have at least read permission on the Network Connections node (at Security > Network Connections) to export the log file successfully. If the command line is executed with insufficient access rights, the .xml export file will contain no data.


Installation Parameters

Workspace extender installation parameters

msiexec /i RES-Workspace Manager-XXXX-Workspace-Extender.msi [/AUTOEXTEND=1]

There’s currently only parameter for installing the workspace extender as most configuration is done post installation using .INI files for both the Extender and the Subscriber. The AUTOEXTEND attribute does the same thing as the AutoExtendWorkSpace registry setting. With this feature it’s possible to integrate locally running applications that have not been configured as a Workspace Extension into a RES Workspace Manager session. This can be done by editing the registry settings of the RES Workspace Manager Workspace Extender of all local clients that should use this functionality. To enable this functionality, change the value of the registry entry AutoExtendWorkspace to 1 or use the MSI property AUTOEXTEND=1 when installing the RES Workspace Manager Workspace Extender .msi file.


Workspace Manager unattended/silent installation

msiexec.exe /i res_Workspace Manager_nnnn.msi DBSERVER=SQLSERVER01[\Instance]
[AI_STARTMENU_SH=0] [ADDTOWORKSPACE=Workspace1|Workspace2|WorkspaceN]

The MSI public attributes above are what’s necessary to do a full installation of RES Workspace Manager. Note there are two installation modes. One, as shown above is to attach a new Workspace Manager installation to an existing datastore. This is the most common option. The other shown below is used to create a new datastore from scratch. An example with all bells and whistles enabled is shown, where we  create a new datastore, enable SQLserver protocol encryption (optional), import a license file (optional), import a given buildingblock (optional) and add the Workspace Manager instance to two workspace containers, which are then created at install (optional):

Msiexec.exe /i res_Workspace Manager_nnnn.msi DBSERVER=SQLSERVER01 DBNAME=RESWorkspace Manager DBUSER=PFUser DBPASSWORD=PFUserPassword DBTYPE=MSSQL DBPROTOCOLENCRYPTION=Yes
DBIMPORTLICENSE=c:\license.xml DBIMPORTBB=c:\buildingblock.xml
ADDTOWORKSPACE=Workspace1|Workspace2 /qn 

When the unattended installation of RES Workspace Manager has completed, the computer will automatically reboot. You can suppress this reboot by adding the parameter REBOOT=R to the command line. This is a parameter of MSIexec, not Workspace Manager. Besides this parameter, you can use all other parameters of the msiexec in the command line. Below is an alphabetic list of all known Workspace Manager MSI public attributes:

ADDTOWORKSPACE – Specifies the names of the workspaces that this computer should be a member of after finishing installation. Separate multiple workspace names using pipe characters “|” (optional).

ADDGROUPTOTECHMGRSpecify a group to add as technical manager in the installation. Must be in the form DOMAIN\groupname. FQDN is not supported at this time. The parameter is valid from Workspace Manager 2008 SR3. This parameter is optional.

ADDTOWORKSPACESpecifies the names of the workspaces that this computer should be a member of after finishing installation. Separate multiple workspace names with pipechar “|”. Specified workspace container names will be created if they do not exist already. This parameter is optional.

ADDUSERTOTECHMGRSpecify a user to add as technical manager in the installation. Must be in the form DOMAIN\username. FQDN is not supported at this time. The parameter is valid from Workspace Manager 2008 SR3. This parameter is optional.

AI_DESKTOP_SH – Valid from Workspace Manager 2010. If you set this parameter to 0 (zero) no icon for the Workspace Manager management console will be created in the Alluser’s desktop. This is very useful for StealthMode deployments. Default value is 1. This parameter is optional

AI_STARTMENU_SH – Valid from Workspace Manager 2010. Works the same way as AI_DESKTOP_SH, but only for all the Workspace Manager related icons that usually go into the RES Workspace Manager start menu folder. When this parameter is set to 0 (zero) nothing is created here. Also useful for StealthMode deployments. Default value is 1. This parameter is optional.

AUTORUNCOMPOSER – Valid from Workspace Manager 2010. This parameter allows you to automatically set Workspace Manager as the shell on the target computer. Set value to YES to make it happen. This is equivalent of later going to the Agents node in the console and change the shell. See this post for further info. Alternatively set it to NO to leave the current shell value (explorer.exe) shell unmodified. If not specified the default value is NO. Note: you cannot use this parameter when installing Workspace Manager on SBC servers, as you never change the shell here.

DBCREATESpecifies a new database should be created using the DBTYPE, DBUSER, DBPASSWORD parameters. Values are “yes” or “no” (default is “no“).

DBCREATEUSER – Specifies the database user name that should be used to create the new database, e.g. “sa”. Note you still need to specify DBUSER and DBPASSWORD, as the DBCREATEUSER will only be used during installation.

DBCREATEPASSWORDSpecifies the database user password that should be used to create the new database. Used together with DBCREATE and DBCREATEUSER. Used only during installation.

DBIMPORTBB – Specifies a Building Block file (including full path) to be imported after creating a new database with the DBCREATE parameter. This parameter is optional.

DBIMPORTLICENSE – Specifies a license file (including full path) to be imported after creating a new database (optional). Can only be used together with DBCREATE. This parameter is optional.

DBNAME – Specifies the database name that Workspace Manager should connect to. This parameter is mandatory.

DBPASSWORD – Specifies the database password that Workspace Manager should use to connect to the database. This parameter is mandatory.

DBPROTOCOLENCRYPTIONSpecifies whether protocol encryption should be used when connecting to Microsoft SQL Server. Values are “yes” or “no” (default is “no“). This is rarely used, but available from SQLserver 2005 and up I believe.

DBSERVER – Specifies the hostname of the database server that RES Workspace Manager should connect to. Note, if you are using instances, or SQLexpress, you need to specify the database name as HOSTNAME\SQLExpress or whatever your instance name is.

DBTYPE – Specifies the database type. This can be either MSSQL, DB2, ORACLE, MYSQL or MSSQLAZURE.

DBUSERSpecifies the database user name that RES Workspace Manager should use to connect to the database. This username will be used onwards. If used together with DBCREATE, this username will be created in the datastore.

CLAIMUSERLICENSE – RES Workspace Manager 2011 introduced the option to reserve named user licenses for specified users. Workspace Manager 2012 enhances the options for this licensing model with the possibility to claim a named user license during unattended setup.
By default, a newly installed Agent will not claim a license until a user starts a session on that Agent. Claiming a license requires the Agent to have connection to the Datastore or a Relay Server. If the first session on an Agent is offline (which may well be the case on a laptop), a license cannot be claimed and the license policy will apply unless a license was claimed and cached locally during the installation. During an unattended install, use the MSI parameter CLAIMUSERLICENSE=domain\username to claim and cache a named license for the specified user. When that user starts a session, a license is available and the session can proceed without restrictions.

From Workspace Manager 2012, the following parameters have been added to assist in configuring a RES Relay Server during an unaattended installation of a WM Agent. For more information on the Relay Server, see this article.

RSENVGUID – Specifies the GUID of the RES Relay Server Environment. This is necessary to specify in the event where there are multiple environments (WM databases) on the network, such as production and test. The RES Environment guid can be found in the WM 2012 console under Setup | Relay Servers | Settings.

RSPASSWORD – Specifies the environment password. This password can be changed in the same location as where the Environment GUID above is found. The purpose of the password is to provide extra security in regards to isolating different environments from each other, as well as provide security against spoofing.

RSDISCOVER – Valid values are YES or NO. This is eqivalent of switching on discovery in the WM console under Administration | Agents | <Properties> | Connection tab, when it’s been configured for using a Relay server

RSLIST – This is the list of Relay Servers to contact. Individual servers are specified as IP or FQDN, seperated by semicolon (;). Alternative portnumbers (other than TCP/1942) can be specified with a colon (:) after the host. Example is RSLIST=server1;server2;server3:666

RSRESOLVE – This parameter is equvalent of the DNS specified fallback server to be used, in case none of the servers specified by RSLIST can’t be reached. You can only specify one relay server by FQDN, like RSRESOLVE=relayserver.company.com

INHERITSETTINGS – This parameter must be set to NO in order for the above WM2012 parameters to remain in effect permanently. If INHERITSETTINGS is set to YES, the WM Agent will use the settings above first initially to get access to the environment, but the values specified with the settings above will then be overridden by any settings in the datastore as these are being inherited.

From Workspace Manager 2012 SR3 the following parameter(s) are available:

CONNECTFILE – This parameter allows you to specify a textfile containing encrypted datastore connection information. The format is CONNECTFILE=c:\temp\connectfile.txt. The contents of the file can be generated by going to the Workspace Manager Console’s Setup|Datastore and clicking as directed on the illustration below.


This is very useful in scenarios where you need somebody to perform an unattended installation of RES Workspace Manager, but you do not want to supply that person with your datastore credentials for security reasons.


Note1: It is recomended to use the ADDTOWORKSPACE parameter in conjuction with the above WM2012 specific parameters if there will be different Relay Server configurations on your network. That way the Agent will automatically belong to the workspace container which will govern it’s relay server configuration.

Note2: Upgrading Workspace Manager is not covered in this document, as it does not warrant special command line parameters. Just download the latest unattended ServicePack and run it on each Workspace Manager enabled computer. If you are upgrading from Workspace Manager 7.x to 20xx, you are actually doing a migration. It’s recommended you have a look at the upgrade presentation which is available here.

Note3: If you’re a security minded individual and not happy about specifying the SQLaccount password in clear text, you have multiple choices: Either a) use Automation Manager to deploy the package and hide the password in a Password module parameter b) install a copy of Workspace Manager manually and copy the registry settings (password is encrypted there), or c)  use DHCP options for obtaining the encrypted connection string



Desktop Sampler installation parameters

msiexec.exe /i res-Workspace Manager-2010-desktop-sampler.msi
SAMPLEPATH=\\fileserver\sampleshare EXPIREDAYS=30 DELAY=120 /q

These are the 3 parameters you can use to do a silent deployment of the Workspace Manager 2010 Desktop Sampler. It’s almost overkill to use the MSI installer to deploy 3 files and 5 registry settings, but nevertheless it allows you to maintain a consistent deployment method. Below is an overview of the MSI public attributes for the desktop sampler

SAMPLEPATH – Local path or better yet, an UNC path to where the sampler should store it’s DTS files. This parameter is optional. If not specified, the sampler will store the DTS files in the same path where it is installed. Default is “%programfiles%\res Workspace Manager desktop sampler”.

EXPIREDAYS -How many days from the installation date the Desktop Sampler will uninstall itself. I believe it should be 30 days if not specified.

DELAY – How long after the Desktop Sampler has initialized, should it wait before doing a snapshot? This is per default 30 seconds. If you have a very long loginscript or a slow environment, consider bumping this up. I’ve had customers that set it up to 120 seconds to be sure.

Note: After Workspace Manager Service Release 1, it is now possible to specify /SAMPLEPATH as a runtime parameter to dtsampler.exe. This gives you the possibility of installing the destktop sampler’s 3 files (1 exe and 2 dll’s) into the NETLOGON folder of your DC’s. The advantage of this approach is that you then do not have to install the sampler on any target computers. Just ammend the loginscript with “dtsampler.exe /SAMPLEPATH=\\server\share” and you’re done!


Reconfiguring WM Agent connection parameters. (WM 2012)

With the introduction of the RES Relay Server in Workspace Manager 2012, it may often be necessary (at least in the beginning) to be able to reconfigure existing agents from using a direct datastore connection to instead pointing to a relay server. This is done easily with this parameter:

“%Program Files%\RES Software\Workspace Manager\svc\res.exe” /config

After upgrading to WM2012, run this command on every relevant machine. When you do, you’ll get the following dialog box where you can change and test the connection to a relay server:


Note: Depending on your DNS and discovery configuration, it may sometimes look like nothing is happening initially, when you run the command line above. Just give it a few moments and it will pop up eventually.


Mixed bag o’ tricks

Start workspace composer in exclusive/specified workspace

pfwsmgr.exe /ew "<name of workspace>"
pfwsmgr.exe /ew ?

Starting up the Workspace Composer (formerly known as the Workspace Manager ) in an exclusive workspace can be useful if you want to deliver only one specific workspace to a user, even when other workspaces are accessible to the user. If you configure the Workspace Composer to start up in an exclusive workspace, the RES Workspace Manager Workspace Composer will only process the specified Workspace for this session and ignore other workspaces accessible to the user. If the specified Workspace is not accessible, access to the session will be disallowed. This option is typically used when publishing desktops on a Terminal Server.

If you specify a questionmark as shown above in the second example, Workspace Manager will prompt the user to select what workspace he wants to use for this session. I have not tried this yet, but I suspect the behavior will be similar to what’s described in this article.

Example: An environment, has two workspaces, ApplicationSet1 and ApplicationSet2. Each workspace grants access to a different set of applications and settings. Both workspaces are accessible to the user, but are mutually exclusive (i.e. they are not allowed AT THE SAME TIME in one RES Workspace Manager session). You can force the Workspace Manager to either use ApplicationSet1 or ApplicationSet2 by using different command line parameters that each point to a different workspace.

Note: All actions will be logged in the Event log, even if the startup action fails. You can view the Event log when viewing your Workspace Analysis details.


Starting a defined Workspace Manager application during logon

Pwrgate.exe <appid>
Pwrgate.exe {GUID}

During logon, it may be necessary to start an application which has been defined in Workspace Manager. Just use one of the commandlines above, specifying the application ID or the GUID (yeah, the GUID was new to me too), which can be found in the Workspace Manager Management Console | Application Management | Application List. Both the AppID and the GUID of the application can be viewed on the Properties|General tab of an application when you edit it. This combines great with a External Task at logon. See also article RG024 – Secrets of PWRGATE.EXE.

Note1: Under normal circumstances, you would probably just create a managed application in the Workspace Manager console and mark it with the option on the Properties|Settings tab of the applicaiton, however you may need the above workaround in some cases.

Note2: There is a certain advantage to using GUID’s rather than AppID’s for launching apps. While the AppID may change when you export and import a buildingblock into a seperate environment, the GUID will remain the same if you specify this during buildingblock import.


Workspace Manager Subscriber configuration

subscriber.exe /config

This commandline will bring up the configuration console for the subscriber, which will enable you to configure menu’s, behavior, updating and much more. All settings configure here are stored in the subscriber.ini file located along with the executable in %programfiles%\RES Subscriber\


WM Relayserver, Interactive configuration mode

Path: "%PROGRAMFILES%\RES Software\Workspace Manager\Relay Server\
Command: relayserver.exe" /interactive

relay-server-interactive-modeThis command line will allow you to configure the RES Workspace Manager Relay Server interactively. This screen allows you to reconfigure the items you configured during the Relay Server installation. However it offers some additional stuff as well. In interactive mode you can start/stop the service, check on what port the Relay Server is listening (default TCP/1942), check connected clients and finally check and/or configure the connected Relay Server environments. Thanks to my buddies at RES Support for providing this info. There are some additional things in here (like Known Operations) that I’m not sure what does at the time of writing, but I know that a KB article is in the works. Stay tuned.


No Comments

No comments yet.

RSS feed for comments on this post.

Leave a comment

You must be logged in to post a comment.