Recently I was asked how to leverage the Citrix Workspace app SelfService.exe programatically with the added requirement to be able to parse more than one parameter. After some testing, it turns out that parsing multiple parameters is possible, but you have to be very precise in your syntax. One small mistake and you will be scratching your head wondering why the parameters are not being parsed to the published application. In this article, I provide a general overview of the SelfService.exe and I will demonstrate how you can handle the parsing of (multiple) parameters.
Citrix Workspace app can be used on domain and non-domain joined PCs, tablets, and thin clients. Provides high performance use of virtualized Skype for Business, line of business and HDX 3D Pro engineering apps, multimedia, local app access.
- HDX RealTime Optimization Pack supports the following Workspace app versions: Workspace app 1808-1811 for Windows, Workspace app 1808-1812 for Mac, Workspace app 1808-1812 for Linux, Workspace app 1809-1811 for Android. HDX RealTime Connector requirements: HDX RealTime Connector is supported on Windows 7, 8.1, 10 and Servers 2008 R2, 2012 R2.
- Citrix provides sample scripts that can be downloaded from one of the Workspace app or Receiver download pages (Workspace app version 2103.1 (Current Release), or Workspace app version 1912 CU3 (aka ) (LTSR), Receiver version 4.9.9002 (LTSR) by expanding Downloads for Admins (Deployment Tools).
Contributors: CTP Carl Stalhood and Rudolf Schachinger
Table of Contents
Using the SelfService.exe on the command line
The SelfService.exe is part of Citrix Workspace app. This executable aggregates (retrieves) a user's resources. With resources I refer to published applications and published desktops. The SelfService.exe connects to StoreFront, assists in the authentication process, retrieves the list of available resources for the current user and parses the launch command to the Citrix HDX engine (wfica32.exe).
Most applications (and desktops) are launched interactively by the user, meaning that the users clicks on an icon, either in a browser or in Citrix Workspace app. The user is presented with a list of applications and selects the one he or she wants to launch.
It is also possible to launch published applications from the command line using the SelfService.exe. The application is still launched in the user's security context, but the difference is that the user does not actively click an icon. Instead, the published application is launched programatically.
The following command launches the published application Notepad:
'C:Program Files (x86)CitrixICA ClientSelfServicePluginSelfService.exe' -qlaunch Notepad
I prefer to use the 'quick launch' option, -qlaunch, instead of the more complicated
-launch option. The option -qlaunch is available from Citrix Receiver 4.2. For more information about these two options please read the Citrix article Driving the Citrix Receiver Self-Service Plug-in Programmatically.
Leveraging the SelfService.exe on the command line allows Citrix administrators and application owners to launch published applications directly from a local application installed on the user's endpoint device (e.g. laptop/desktop) without requiring any user interaction.
In the example above, Citrix Workspace app on the user's endpoint device already has the correct store configured. Also, the user is authenticated to this store and the application Notepad is visible to the user in the aggregated list of applications. Launching an application using the command line works the same way as a user launching the application in Citrix Workspace app or from the browser.
Let's take a closer look at how this works.
The published applications of my test user are visible in Citrix Workspace app. I want to launch the application Notepad, but instead of clicking on the application in Citrix Workspace app, I use the SelfService.exe with the -qlaunch parameter in the command window.
The SelfService.exe passes the launch command to the Citrix HDX engine (C:Program Files (x86)CitrixICA Clientwfica32.exe) to establish the session.
And the published application is presented.
There was an issue with Citrix Workspace app 1810 to 1812 whereby only the first SelfService.exe call actually launched an application. Any other attempt to launch an application failed. This issue has long been fixed in newer versions of Citrix Workspace app. My recommendation is that you always use the latest LTSR or CR version of Citrix Workspace app.
How to launch a published application with multiple parameters using the SelfService.exe?
Sometimes you need to dynamically add parameters when launching a published application from the user's local endpoint. Let us use the Remote Desktop Client (mstsc.exe) as an example. Let's assume we want to execute the following command using a published application, but the section in green should be dynamic instead of static:
C:WindowsSystem32mstsc.exe /v:%ServerName% /f /multimon
To accomplish this we need to do the following:
- Citrix Studio:
Create a published application for the Remote Desktop Client and add%** in the command line arguments section, like this:The argument %** enables the published application to accept multiple parameters from the command line. Make sure NOT to use any quotes (e.g. '%**'), otherwise all of your parameters are interpreted as one single parameter.
- Citrix StoreFront:
The store used to connect the user to the published application can be set to either self service or to mandatory.
In case the store is set to self service, although not strictly necessary, I recommend to add the keyword auto or mandatory to the published application. This ensures that the published application is always present in the user's aggregated list of resources. For more information on how to use keywords, see the article Configuring application delivery on the Citrix Product Documentation website.
- The user's (Windows-based) local endpoint:
- Make sure that the StoreFront store has been configured in Citrix Workspace app. If this is not the case, it is possible to connect to the store programmatically using the following command: SelfService.exe –createprovider %StoreName% %StoreURL%. However, that adds unnecessary complexity to most environments since the store can easily be configured using Group Policies. If your environment requires the store to be connected dynamically than please see the Citrix articleDriving the Citrix Receiver Self-Service Plug-in Programmatically for more information. For detailed information on Citrix Workspace app, see the article Citrix Workspace app unattended installation with PowerShell on this website.
- When executing the SelfService.exe on the command line, make sure to add one quote before and one quote after the list of parameters. Also, the parameters themselves have to be separated by adding a space between each of them. In our example, we can launch the published application called MSTSC as follows:
'C:Program Files (x86)CitrixICA ClientSelfServicePluginSelfService.exe' -qlaunch MSTSC'/v:Server001 /f /multimon'
How to launch a published application with complex multiple parameters using the SelfService.exe?
In some cases the list of parameters may be more complex, for example:
- Some parameters may contain a space. In this case, the solution described in the previous section will not work. Take this command for example:
'C:Program Files (x86)CitrixICA ClientSelfServicePluginSelfService.exe' -qlaunch MyTestApp'Apple Pear Ground Cherry'Php echo.
In this case, four parameters are parsed to the published application instead of the intended three. The reason is that the parameter Ground Cherry contains a space.
- The number of parameters may differ depending on the situation. Suppose that a locally installed hospital application (installed on the local endpoint of the user) needs to launch a published application on the Citrix worker. Let's assume that in most cases the parameters consist of floor number, ward number and room number. But sometimes the parameter bed number may be required as well. This means that sometimes three parameters are parsed and sometimes four.
One way how to deal with both situations is to parse all parameters as one single parameter. This one 'master' parameter needs to be interpreted by the published application. This means that the published application will have to launch a custom script. Let me show you how this is done.
Most steps described in the previous section still apply, except for the command line argument in the published application. This should be %* instead of %**. The argument %* only accepts one argument which is all we need. In this example, we will use a PowerShell script to interpret the parameters parsed by the SelfService.exe. In the screenshow below you see the exact syntax that I used to call the PowerShell script.
- Path to executable file:powershell.exe
- Command line argument:-executionpolicy bypass -NoExit -file 'C:TempSelfService.ps1' %*
In case you do not want to see the PowerShell window you can always add the option -WindowStyle Hidden, like this:-executionpolicy bypass -WindowStyle Hidden -NoExit -file 'C:TempSelfService.ps1' %*
The SelfService.exe is executed like this:
'C:Program Files (x86)CitrixICA ClientSelfServicePluginSelfService.exe' -qlaunch SelfServiceTestApp '2,Ward 16,66b,'
'C:Program Files (x86)CitrixICA ClientSelfServicePluginSelfService.exe' -qlaunch SelfServiceTestApp '2,Ward 16,66b,a'
All parameters should be between quotes and each individual parameter is separated using a comma. This allows the PowerShell script to interpret the parameters as an array. The comma is what separates each argument. The added benefit of this approach is that a space within one parameter does not matter since the main separator is the comma and not the space.
In each of the two examples a total of four parameters are parsed. In the first example, the parameters are: '2,Ward 16,66b,'. No value is present after the last comma, which means that the value for bed number is undefined. So why do we need this comma? Because it tells the script that four parameters are being parsed with the last one simply being empty or undefined.
In the second command line the parameters '2,Ward 16,66b,a' are parsed. The last one, a, represents the bed number within the room.
The PowerShell script that has to do all the hard work will look something like this:
Citrix Workspace App For Mac 1812
# Split the 'master-parameter' to be able to create individual parameters
# Create individual parameters from the master parameter
# Show individual parameters
write-host'Bed number: $BedNumber'
Citrix Workspace App 1812 For Mac
The script splits the 'master' parameter based on the comma. Each comma-separated item is then stored in its own unique variable:
- Parameter 1 = $FloorNumber
- Parameter 2 = $WardNumber
- Parameter 3 = $RoomNumber
- Parameter 4 = $BedNumber
If a parameter does not contain a value, the corresponding variable is set to <unknown>.
From here on you can expand the script to whatever is required such as launching an application.
I hope that this article helps you to utilize the SelfService.exe programatically. In case you still have questions please leave a reply at the bottom of this page. Cheers!