Powershell Script to launch one or more Published Applications from Citrix Storefront 2.x through 3.11

by Stan Czerno August 26, 2016 10:24 CST

I have a new script for Storefront 1912 CU1. Click here for the new script.

I have updated my script for testing Citrix Storefront or Netscaler and Storefront. The previous versions can be found here and here. I have modified the script so it handles errors better as well as added support for Storefront 3.11 and Netscaler 11.x. 

I have tested the script with Internet Explorer 11 and Citrix Receiver 14.2 - 14.4.1 on Windows 7 x64 and Windows 10 x64.

The script attempts to closely resemble what an actual user would do by:

  • Opening Internet Explorer.
  • Navigates to the Receiver for Web site or Netscaler Gateway portal.
  • Entering a Username and Password.
  • Clicking on the Log on button.
  • Clicking on the Published Application(s).
  • Logging off the StoreFront site.

You can use this script to confirm your most important Published Application(s) launch correctly and in a timely manner.

You can use this Script to verify that each of your servers is responding correctly, as well. To do this you will need to Publish an Application from each server. For example, you could publish Task Manager (taskmgr.exe), from each server, and name it something like "Server 1 Task Manager", "Server 2 Task Manager", etc, etc.

The script has the ability to send an email along with the log file when an error is encountered. The email body will contain the error message(s) and the log file which basically documents each step and where the error occurred.

Script Requirements:

  • Citrix Receiver installed in the default location.
  • Must be launched from an Elevated Administrator console of PowerShell x86. The 64 Bit Powershell will not work since the script is using Citrix Receiver, which is 32 bit, to verify a launch and logoff the session.
  • No other XenApp/XenDesktop sessions should be connected/running before running the script.
  • SiteURL should be part of the Intranet Zone (or Internet Zone at Medium-Low security) in order to be able to download AND launch the ICA file without interaction. This can be done through a GPO or locally.
  • Requires Citrix StoreFront, version 2.0 through 3.6 or NetScaler Gateway, version 9.3 through 11.1.
  • Requires autoLaunchDesktop to be set to false.
  • Requires the pluginAssistant to be set to false.
  • Currently works for desktops or already subscribed apps only.
  • You can auto subscribe users to apps by setting "KEYWORDS:Auto" in the published app's description or make sure the apps have been subscribed to manually.
  • In order for the script to interact with the ICO, the script modifies the required changes in the registry:
    • x64: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\CCM
      • AllowLiveMonitoring REG_DWORD 1
      • AllowSimulationAPI REG_DWORD 1

Create some Apps to use with the Script:

The first thing you should do is to publish the Application (or Desktop) and assign it to your test user.

If you want to test each server, then you need to publish an Application (or Desktop) from each server and assign it to your test user. What I mean by that is; if you have five servers, you will need to publish the App or Desktop five times, one for each server. In this scenario I am not testing load balancing, I am testing to make sure each server launches the application correctly and within an acceptable time frame.

I chose Task Manager for my testing, but it can be any Application, such as Command Prompt. The more lightweight the Application the better, you do not want to put extra strain on your servers.

You can also use a Published Desktop but Desktops are more resource intensive and take a little longer to launch since it initializes the Explorer shell. If you choose a Desktop you may need to extend the wait times, especially for the Log off command by adding -TimeToWaitForLogoff to the command line. By default this is set to 30 seconds and a Desktop may not logoff within 30 seconds. Overall, I have noticed that using a Desktop can be problematic. It is not so much an issue with the Server but with CDViewer on the client. So I recommend using Task Manager or Command Prompt for the test.

Subscribe to Apps:
The Apps need to be visible in order for the Script to launch them. You will need to log in to Storefront, as the Test User, manually and subscribed to the Apps. Alternatively, you can auto subscribe the Apps by setting "KEYWORDS:Auto" in the published app's description.

Schedule the Task:
My Scheduled Task's Action looks like this:


Add arguments:
-executionpolicy bypass -file c:\CitrixScript\SFLauncher36.ps1 -SiteURL "https://citrix.domain.com" -UserName "domain\TestUser" -Password "TestUserPassword" -smtpServer "smtp.server.domain" -emailFrom "XenAppMon@domain.com" -emailTo "email@domain.com" -LogFilePath C:\CitrixScript -LogFileName SFLauncher.log "App1" "App2"

Start in:

Security options:
The user account needs to be an administrator on the client so PowerShell can be elevated. This does not need to be the Test User used in the script to connect to XenApp/XenDesktop.
Use the option "Run whether user is logged on or not" and "Run with highest privileges".

Command Line Notes:
The Application(s) to be launched need to be at the end of the command line, separated by a space, like this: "App Server1" "App Server2"

Testing from a Command Prompt:
If you want to test before Scheduling, open a Command Prompt as an Administrator (right click and choose "Run as Administrator")
To test the script, here is a sample command line:
%SystemRoot%\syswow64\WindowsPowerShell\v1.0\powershell.exe -executionpolicy bypass -file c:\CitrixScript\SFLauncher36.ps1 -SiteURL "https://citrix.domain.com" -UserName "domaain\TestUser" -Password "TestUserPassword" -smtpServer "smtp.server.domain" -emailFrom "XenAppMon@domain.com" -emailTo "email@domain.com" -LogFilePath C:\CitrixScript -LogFileName SFLauncher.log "App Server1" "App Server2"

Here is a Screenshot of what the script looks like while it is running:



Link to file: SFLauncher36.ps1

Tags: , , , ,

Catergories: Citrix | Receiver | Storefront | XenApp | Powershell

Comments (12) -

Bill Rogge
November 29, 2016 08:44 CST

Paweł Serwan's took your original XenAppMonitor script and altered it to hit multiple servers for testing a Farm.

We currently have 5 different Farms that I have tweaked his script to work with.

With the change to StoreFront, would you have any tweaks to hit multiple Farms for the same app?

Stan Czerno
November 29, 2016 08:57 CST

I am not sure I understand the question. Are the apps in question named the same? Are they hosted from five different farms but consolidated in one Storefront Store?

Bill Roggr
November 30, 2016 02:20 CST

So, from your comment, I went back and read my question.  Sorry for the confusion.

I am trying to run the same App on 5 different servers at the same time to validate functionality.

The issue with StoreFront is that it sees an active connection to one server and wants to start subsequent executions against that server rather than going to another server.  I understand why, but we are trying to test functionality across the Farm to make sure it can handle the load that could be placed on it.

Yes, this is vastly different than what I had stated.

Eventually, the script will be run against the 5 different farms but testing different applications within those farms.

The reason I mentioned Paweł is because he took your original script (powershell-script-to-launch-a-published-application-from-one-or-more-xenapp-servers) and modified it close to what we were looking for.  I found your StoreFront script and was hoping to utilize it instead to get the multiple executions.  It may not be possible, but had to ask.

Stan Czerno
November 30, 2016 03:12 CST

What you describe is how it is supposed to work.

In order to test each server that hosts the application, using this script, you have to do that type of work with the Published Applications in whichever version of XenApp management you are using. This is very easy is XenApp 6.5, but gets complicated in XenApp 7.x and above.

If you have five servers per farm, then you need to publish the application from each server. So "TestApp" would be published five times, one for each server. I explained this in my post above under "Create some Apps to use with the Script".

So, if you have an App named "TestApp" that your users run and is published from five servers, you cannot test it to force it to run from each server since Load Balancing is supposed to give you the least busy server. To bypass Load Balancing you would create five more copies of the same app. You would configure them to only run from one server each.

Publish App: "TestApp on Server1 in Farm1" is only configured to run from only from Server1 in Farm 1 and only the TestUser has access.
Publish App: "TestApp on Server2 in Farm1" is only configured to run from only from Server2 in Farm1 and only the TestUser has access.
Publish App: "TestApp on Server3 in Farm1" is only configured to run from only from Server3 in Farm1 and only the TestUser has access.
Publish App: "TestApp on Server4 in Farm1" is only configured to run from only from Server4 in Farm1 and only the TestUser has access.
Publish App: "TestApp on Server5 in Farm1" is only configured to run from only from Server5 in Farm1 and only the TestUser has access.

If you just want to test that each Server will launch the application, my original script will work just fine without any modifications.

However, this does not test NetScaler/Storefront or Farm communication via IMA or FMA. If there is an issue with IMA or FMA my original script will still launch the test application, which creates a false positive test and a false sense of the farm being accessible.

This scripts more closely resembles how users connect to published applications as well as testing NetScaler/Storefront or Farm communication via IMA or FMA.

Bill Rogge
November 30, 2016 03:15 CST

Thanks.  I guess I'll have to stay with the original scripts.  Those had the ability to direct to a specific server (bypassing Load Balancing).

December 15, 2016 06:14 CST

Hi Stan, great script! I have tested it and it works really well. Thank you for making this available.

What are the possibilities of adding support for testing published apps that are located in a folder? In some cases we disable StoreFront subscriptions to have an experience more like Web Inetrface, thus all apps are organized into folders. Having this capability would allow us to use your script to test with existing applications that are in folders.
Just curious as this might be a helpful addition.

Thank you

Stan Czerno
December 15, 2016 10:49 CST

The script looks for the application in the HTML code, so the application has to be visible on the landing page. If you set the default view for Apps, you could always publish the Application for just the Test User outside of your folder structure. Other than that you would need to change the script to meet your needs by having it traverse your folder structure.

February 10, 2017 11:16 CST

Hi Stan,
Is there a maximum limit to the number of apps the script can check?

Stan Czerno
February 10, 2017 11:41 CST

The script has no limits set on the number of apps.

May 5, 2017 05:01 CST

Great Script !! Thanks for sharing this, it works perfectly for published apps, but I am getting an error in Published desktops, Could you pls help.

It repeatedly throws this error

"Session is Connected, looking for any active Windows.
Unable to confirm that a session launched for "AWS Project Team Desktop", but an active session was found.
Cannot find a Top Level Window, this could just be an ICO issue on the client and may not be a Server issue.
If this occurs again you may need to try manually launching "AWS Project Team Desktop".
Sleeping 5 seconds before logging off Storefront

Stan Czerno
May 5, 2017 05:53 CST

I presume this is because of Desktop Viewer. I made a change to the script, re-download and try it again.

May 8, 2017 04:58 CST

Thanks a lot it works like a charm. Would like to know what was the issue in the earlier script, thanks again!!

Comments are closed