Driving the Citrix Receiver Self-Service Plug-in Programmatically

This article is intended for Citrix administrators and technical teams only.



Non-admin users must contact their company’s Help Desk/IT support team and can refer to CTX297149 for more information.

The Self-Service Plugin (SSP) is the component within Receiver 4.0 onwards that is responsible for managing resources (desktops and applications). It communicates with the aggregation tier (StoreFront or Web Interface services) to obtain details about what resources are available for the user, and it can facilitate launching those resources. The actual HDX sessions are then provided by a separate component within Receiver (the ICA Client).

By default, SSP activities are driven by user interaction. However, SSP exposes sufficient information for its activities to be scripted. The advantage of this approach is that it allows SSP to do most of the difficult operations and in particular handle authentication. This provides support for all the authentication methods without having to interact programmatically with the aggregation tier. SSP also coordinates the session launch process.

This article outlines the scripting process and provides a list of parameters for reference.

Method

Assuming the system is set up to communicate with the same provider or store for all users, the SSP model is to:

1. Start up.

2. Authenticate to the store.

3. Enumerate the resources the user is entitled to access.

4. Create shortcuts for the resources the user has subscribed to or that the administrator has auto-subscribed them to. The store may be set as mandatory, in which case all resources are subscribed. If Receiver is communicating with a Web Interface Services site then all resources are automatically subscribed.

Store interaction

By default, there is a delay of about two minutes before the store is contacted. You can override this by setting the following registry keys and adjusting for Wow6432Node as appropriate:

Key	Notes
REG_SZ HKLMSOFTWARECitrixDazzleInitialRefreshMinMs	Set to 1. Setting is in milliseconds. 0 returns to the default.
REG_SZ HKLMSOFTWARECitrixDazzleInitialRefreshMaxMs	Set to 1.

Shortcuts

For any subscribed application, SSP builds a Start menu shortcut that launches an HDX session for that application when the user selects it. These shortcuts persist after the user logs off from the aggregation tier. If the user selects the shortcut without being logged on, they are prompted for credentials before the application launches. There is an exception to this: if the published application is tagged with a prefer keyword that has a value matching an existing local shortcut, no hosted shortcut is created. This is to save the overhead of a hosted launch where a local one might suffice. For further details, see http://support.citrix.com/proddocs/topic/receiver-windows-40/receiver-windows-config-app-delivery.html

SSP mimics a local install by building an .exe file that causes the application to start remotely when the file is run. Shortcuts are created for the application and an Add/Remove Software entry is also built. When SSP builds a shortcut, it builds it to a small stub application in a file %appdata%CitrixSelfServiceapp-name-with-spaces-removed.exe for each resource. These files allow SSP to create a fake ‘install’ record for Add/Remove Software. Running these .exe files causes the application to launch. This may be the simplest launch option for scripting: look for the relevant .exe file under the user’s profile area and execute it.

If you want to drive SSP directly for launch instead of through an .exe stub, look at the keys under HKCUSoftwareMicrosoftWindowsCurrentVersionUninstall. There will be keys in there named farm-name@@server-farm-name.app-friendly-name. In these keys you’ll find a LaunchString value that shows the relevant parameters. These parameters are user-independent and can therefore be cloned from a reference user to a general case.

These launchstrings will be of the form

​​"-launch" "-s" "store-63501976" "-CitrixID" "store-63501976@@Farm1.Test" "-ica" "https://Servername/Citrix/Store/resources/v2/RmFybTEuREcgVGVzdCBTY2htaXRCRTMi0z/launch/ica" "-cmdline"

You can copy and reuse these parameters without interpretation. This may be off-putting if the aim is to try and build a control for these independently. It is not necessary though to understand resources at this abstract level if more control is required.

Additional command-line arguments can follow the above format or be passed to the .exe stubs.

For both the stub and the direct launch methods, SSP will take care of authentication and interaction with the Web Interface or StoreFront.

Alternatively to -launch, -qlaunch, which has a simpler syntax, can be used. Please see below for details.

Cache file for resource details

A cache file is created per provider when SSP exits. This file records the last enumeration details and allows SSP to start up quickly. The name of the cache file is decorated with the internal store name.

Running the command selfservice.exe –init –ipoll –exit starts SSP, performs a refresh (interactive poll) from the current provider, and forces a clean exit. The cache file is then created in the %LOCALAPPDATA%citrixselfservice directory.

The cache file contains information about each resource, including all the information needed for a launch.

The launch command line contains:

SelfService.exe –launch –s <STOREID> -CitrixID <STOREID>@@<RESOURCEID> -ica <ICALAUNCHURL> -cmdline

If you look in a cache file (an example name might be storeservi-ee876897_cache.xml) you will see that it has a <resource> entry per application or desktop.

To construct a launch command line from this file, use the following details:

STOREID	The name of the file (do not include _cache.xml)
RESOURCEID	Contents of <internalName>
ICALAUNCHURL	Contents of <icaLaunchUrl>

The cache file will contain some LaunchCommandLine entries, but only for subscribed or prelaunch resources.

There is also a dump.xml file in the same location with similar content. This file is intended for external consumption (unlike the cache file). It contains some but not all LaunchCommandLines.

Other useful SSP parameters

Note that where multiple parameters are supplied, SelfService.exe executes them in order.

***SelfService parameters are case sensive***

Parameter	Description and notes
SelfService.exe –logoff	Log off current user.
SelfService.exe –rmPrograms	Clean up shortcuts and stub programs for current user.
SelfService.exe –reconnectapps	Reconnect to any existing sessions the user has. By default happens at launch time and app refresh time.
SelfService.exe –disconnectapps	Disconnect any current HDX sessions.
SelfService.exe –createproviderStoreName StoreURL	Create a provider. For example: SelfService.exe –init –createprovider Go https://testserver.net/Citrix/MyStore/discovery
SelfService.exe –deleteproviderbyname StoreName	Remove a provider.
SelfService.exe –deleteproviderandlocalappsbyname StoreName	Remove a provider.
SelfService.exe –poll	Contact the server to refresh application details.
SelfService.exe –ipoll	Contact the server to refresh application details as in –poll, but if no authentication context is available, prompt the user for credentials.
SelfService.exe –deletePasswords	Remove any stored passwords.
SelfService.exe –exit	Exit from SelfService.exe.
SelfService.exe –qlaunch “appname” See Note 1.	Launch applications. Note: This parameter can be customized with <appname> <argument>. Publish the application with “%*” in command line parameter. Example: To launch published application named “IE11” opening http://www.citrix.com, use: selfservice.exe -qlaunch IE11 http://www.citrix.com
SelfService.exe –qlogon See Note 1.	Reconnect any existing apps for current user.
SelfService.exe –fastterminate See Note 1.	Log off the current user and leaves their applications connected.
SelfService.exe –terminate See Note 1.	Disconnect applications for all users on endpoint.
SelfService.exe –terminateuser “user_name” See Note 1.	Disconnect applications for a specific user.
SelfService.exe –logoffSessions	Log off all the active sessions for the current user Note: This flag is available only in Receiver for Windows 4.12 and later versions.

Note 1: These parameters are available only in Receiver 4.2 and later versions.