Recently I was asked how to leverage the Citrix Workspace app SelfService.exe programmatically 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.

Contributors: CTP Carl Stalhood and Rudolf Schachinger

Table of Contents Using the SelfService.exe on the command line How to launch a published application with multiple parameters using the SelfService.exe? How to launch a published application with complex multiple parameters using the SelfService.exe?

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 user 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 programmatically.

The following command launches the published application Notepad:

“C:\Program Files (x86)\Citrix\ICA Client\SelfServicePlugin\SelfService.exe” -qlaunch Notepad

Note: 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)\Citrix\ICA Client\wfica32.exe) to establish the session.

The published application is presented.

Note: There was an issue with Citrix Workspace app 1810 to 1812 whereby only the first SelfService.exe call 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:\Windows\System32\mstsc.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 mandatory.

  In case the store is set to self service, although not strictly necessary, I recommend adding 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 then please see the Citrix article Driving 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)\Citrix\ICA Client\SelfServicePlugin\SelfService.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:

1. 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)\Citrix\ICA Client\SelfServicePlugin\SelfService.exe” -qlaunch MyTestApp “Apple Pear Ground Cherry“

   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.

2. 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 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:\Temp\SelfService.ps1” %*

Note: 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:\Temp\SelfService.ps1” %*

The SelfService.exe is executed like this:

“C:\Program Files (x86)\Citrix\ICA Client\SelfServicePlugin\SelfService.exe” -qlaunch SelfServiceTestApp “2,Ward 16,66b,”

Or this:

“C:\Program Files (x86)\Citrix\ICA Client\SelfServicePlugin\SelfService.exe” -qlaunch SelfServiceTestApp “2,Ward 16,66b,a”

All parameters should be between quotes and each 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:

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 programmatically. In case you still have questions please leave a reply at the bottom of this page. Cheers!