Citrix Published Apps

Citrix Published Apps, also known as Hosted Apps, are apps that are available by themselves on Storefront’s and Web Interface’s logon portal. These applications can be run on their own without the need of a Published Desktop.

This document will outline the requirements and the procedure for setting up a LoginVSI test for Published Apps for a XenApp 7.X environment. XenApp 6.5 and older versions are not supported

StoreFront store page with published apps

Video: Testing Citrix XenApp Published Applications with Login VSI

Terminology

• Windows Session: When a Published Application is launched by a user the application process is started in a user session on one of the XenApp Session Host servers.

User session view on Session Host

Outlook 2013 Published App running

Internet Explorer Published App running

• VSI Session: With a VSI session we are referring to a specific user and all the Windows Sessions the user is running. So for each VSI session, or user, there could be one or multiple Windows Sessions. The VSI Session count is the value that is checked against your VSI user license count.

• Session Sharing: Session Sharing is a feature available on most Server-Based-Computing (SBC) platforms, such as XenApp, and allows a user to run multiple published applications from a single Windows Session (instead of running a Windows Session for each application). One of several requirements for Session Sharing is that all the applications in question are available on the specific XenApp Session Host server, where the initial Windows Session was running.

• Application Silo: For larger environments, certain applications will be isolated on dedicated Session Host servers for security, resource optimization or compatibility reasons. An application silo refers to this group of dedicated Session Host servers. A consequence of using application silos is that Session Sharing cannot occur for Published Apps from different Application Silos. For a Login VSI user running applications from multiple silos, the user will have multiple Windows sessions running.

Published Apps Referenced in Official Workloads

Below is a list of published apps that are expected to be published in the Citrix environment for each workload. The names in parentheses are the default names (assumed by LoginVSI) of the Published Apps that the users see. When starting a test later on, you will see how you can change these.

See the Setting Up guide further down for more info regarding LoginVSIStartApp.

Workload Name	Application Names
KnowledgeWorker_PublishedApps	Launcher (“LoginVSIStartApp”) Outlook (“Outlook 2013”) IE (“Internet Explorer”) Word (“Word 2013”) PowerPoint (“Powerpoint 2013”) Excel (“Excel 2013”) Freemind (“Freemind”)
OfficeWorker_PublishedApps	Launcher (“LoginVSIStartApp”) Outlook (“Outlook 2013”) IE (“Internet Explorer”) Word (“Word 2013”) PowerPoint (“Powerpoint 2013”) Excel (“Excel 2013”)
ProfileCreate_PublishedApps (used if “Enable profile create mode” is checked)	Launcher (“LoginVSIStartApp”) OutlookPrepare (“Outlook 2013”) WordPrepare (“Word 2013”) ExcelPrepare (“Excel 2013”) PowerPointPrepare (“Powerpoint 2013”) FreemindPrepare (“Freemind”) IEPrepare (“Internet Explorer”)
TaskWorker_PublishedApps	Launcher (“LoginVSIStartApp”) Outlook (“Outlook 2013”) Excel (“Excel 2013”)

Setting up Login VSI for Published Application Test

1. Default Login VSI Setup: Follow the default Login VSI installation steps outlined on our website, [see this link].

2. Active Directory Users: Follow the guide on our website for setting up Login VSI with Active Directory, [see this link]. Generate a Powershell script according to the link and execute it on one of your Domain Controllers. This script will also create Login VSI Organization Units (you specify the base location when generating the script file) and link GPOs to them.

3. GPOs: Either move your Target and Launcher machines to the newly-created LoginVSI OUs so the LoginVSI GPOs are applied, or move LoginVSI GPOs to the OUs where your Target and Launcher machines reside. Ensure that LoginVSI GPOs have highest the priority in the OUs. See below pictures. If you did not use the script file in step 2, then you will need to create the two GPOs manually and use the import functionality in Group Policy Management Console to import the settings from the GPOs located at \\{server}\{VSIShare}\_VSI_Binaries\AD Setup\{GPO Folder}\

Note: Applying the Target GPO to Target Machines is necessary for this Published App LoginVSI solution to work. If you wish to get more info regarding on the settings in this GPO, contact us at support@loginvsi.com

Default setup example: In this scenario we will need to move our Computer objects of our Target machines and Launcher machines to the newly created OUs, so the LoginVSI GPOs will be applied.	Alternative GPO setup: Here we instead applied the LoginVSI-Target-V4 GPO to our XenApp production OU, where our XenApp computer objects already resided. We let the LoginVSI-Launcher-V4 GPO remain at the default location, LoginVSI\Launchers, and instead moved our Launcher computer objects to that OU. Showing this example since some admins prefer to move Computer Objects around while others would prefer to move the GPOs around.	Ensure that the LoginVSI-Target-V4 GPO has highest priority in the OU you link it to (if you are not using the default Login VSI OU)

4. RAM Disk Install: If you plan on running Login VSI tests with more than 500 users, we recommend that you setup RAM disk on your VSI share to minimize IO impact generated by log files during VSI test. Below are instructions for how to do that:

• On your Login VSI File Server, run the script called install_IMDisk.vbs, which can be found in folder \\{server}\{VSIShare}\_VSI_Binaries\RAMDisk, in an admin-elevated cmd prompt. This script will create a 512 MB RAM disk partition on localhost (so run this from your Login VSI file share server). After running the script, verify that a new drive letter partition was automatically created.
• This script will create three scheduled tasks on your VSI file server that will always execute upon server boot. The tasks will recreate the RAM disk (1) and set the share (2) and NTFS permissions (3) correctly.
  • Note: Rebooting your Login VSI file server will result in any data on your RAM disk being deleted. All files saved by Login VSI software on the RAM disk are used only for the execution of tests and for troubleshooting, so they can deleted without worry. Do not store any important files on the RAM disk.

5. RAM Disk Configure: Go to Options in Login VSI Management Console and enter the share path to the RAM disk we created above. The setting name is called “Published Apps log file share” and the value should be \\{FileServer}\PublishedAppsLogsVSI (use the actual name of your file server).

6. Segment Behavior: In the Settings tab in the Login VSI Management Console, change the setting “Segment Behavior” to “Fixed”. This will ensure all users start from segment one, which is the expected start behavior for the default published applications workloads.

7. Published Apps Names in Environment versus Workload: Look at the [Changes old and new workloads] site to see the difference between the existing Login VSI Workloads. You should choose the workload that best represents your user base.

8. Publish LoginVSIStartApp: Publish \\{server}\{VSIShare}\_VSI_Binaries\Target\Lib\LoginVSIStartApp.exe as an app from one of the Delivery/Worker Groups you will use in the test, and name it “LoginVSIStartApp” (you can choose another name but then you will need to adjust your workload accordingly). You should publish it in the Delivery Group which hosts the majority of the Workload applications.

Ensure that LoginVSI test users have access to this app and all other apps specified in the workload file. See below pictures taken from Citrix Studio:

Application Identification

Application path

Limit Visibility

9. Publish Freemind: Publish \\{Server}\{VSIShare}\_VSI_Binaries\Target\Lib\FreeMind\Freemind.exe as an app from one of the Delivery/Worker Groups you will use in the test, and name it “Freemind” (you can choose another name but then you will need to adjust your workload accordingly).

Ensure that LoginVSI test users have access to this app. See below pictures taken from Citrix Studio:

"(for user)"

Limit Visibility

10. Specify User Amount and Workload: Go to the Scenario tab in Login VSI Management Console and select the Workload you edited, and specify the amount of VSI Sessions you would like to run in your test.

11. Setup Connection Type: Go to the Connection tab in Login VSI Management Console, click “start connection wizard” and select either “Citrix Storefront” or “Citrix Web Interface – Published Apps” as the connection type (depending on what your Citrix environment uses) and complete the remainder of the wizard. Note: If you use the Citrix Web Interface Connection type, there are additional mandatory requirements that must be met for a Login VSI test to work correctly. See Citrix Web Interface Connection Type for more info.

12. Start Test: Go to tab “Start Test”, click on the start test button, and launch your test!

Start Test Wizard - Mapped applications

Start Test Wizard - Mapped application Process Names

Start Test Wizard - Mapped application titles

Management Console discovery phase

Published Apps discovery phase launcher

Published Apps Discovery Phase Launcher Silo Confirmation

LoginVSIStartApp start engine

LoginVSIStartApp running

Outlook 2013 Published App running

Internet Explorer Published App running

Known issues

Log off bug: If a session fails to become Active during a test, the logoff sequence will not be generated automatically. If so, you can click Abort and check ‘Log off active sessions’ to manually cause logoffs to occur. Do not do this until Launched Sessions count has reached max.

Notes and Requirements

General

• If you have multiple application silos then that is not a problem and fully supported. The Login VSI engine will run in each windows session created by a particular Login VSI test user, and the engines will synchronize with each other during the test.

• The Login VSI engine will go through a phase called Discovery Phase prior to starting the test, and during this phase it will identify the application silos and session sharing opportunities that exists in the Citrix environment. These results will then be used by the Login VSI engines during the test.

• It is a requirement that the Login VSI test users are not local admins on your session host servers, in order for the test to work correctly. This is due to the VSI engine, which is started with the Login VSI test user credentials, will be looking at and terminating running processes. If they are local admin they will see processes of other users, which could cause issues.

Workload

• [This link] will take you to our documentation web site where you can get more details regarding the available Workload functions and their parameters.

• You should not add calls to VSI_Timer() inside any workloads used for Published Apps testing. The Login VSI engine will take care of that automatically. This is why these function calls are removed from the official Published Apps workloads. The Setting Timer interval (see further below) controls how often timers are run. However, a Timer will always run immediately after Prepare phase and at logoff, regardless of the interval setting.

• In the workload, all functions have a LogName parameter. This value is used by the VSI engine(s) to determine if the function should be executed by this particular VSI engine. In some cases, a function will have multiple dependencies. In this case, use a semicolon as a delimiter in order to specify multiple LogName. These functions will only execute if all LogName are enabled for this particular VSI engine.
  Example:
  VSI_RandomFunction(“Word;Adobe”, Param2, Param3..)

• A requirement for any function to execute in the workload is that there exist either a function VSI_LaunchPublishedApp(“LogName”…) with the same LogName, or that you have specified VSI_ AddAppToEnabledList(“LogName). If both functions exist for the same LogName value, then AddAppToEnabledList takes precedence and any functions using the particular LogName will be executed in all Application Silos.

• If you wish to make an application execute locally on all Session Host servers (disregarding silo allocation), then add VSI_AddAppToEnabledList("LogName") to the top of your workload. Also ensure there are no calls to function VSI_LaunchPublishedApp(“LogName, PublishedAppName”, “ProcessName”) with the same LogName.
  You will need to associate new or existing function calls in the workload to the LogName you specified. Do this by using the same LogName' in these functions as you specified in VSI_AddAppToEnabledList().

• The official workloads include a few default calls to VSI_AddAppToEnabledList(), namely for Adobe, Photoviewer, Idle and Workload commands. If you wish to isolate the execution of, for example, Adobe Reader to a particular silo or Session Host (or if you do not have Adobe Reader installed on all XenApp servers) then you will need to publish Adobe Reader as an app, remove VSI_AddAppToEnabledList("Adobe") from the workload and add VSI_LaunchPublishedApp(“Adobe”, “AdobePublishedAppName”, “AcroRd32.exe”, “Adobe”) at the appropriate place in the workload.

• If you wish to include any custom Published Apps in your Login VSI test, you will need to edit the workload and add a call to function VSI_LaunchPublishedApp(“LogName”, “PublishedAppName”, “ProcessName”, “WindowTitle”), and you also need to add actions (functions) to run against the particular app. Use the same LogName as you used in the launch function above to associate the functions with each other.

• If you have Published Apps that have identical process names, such as Java applications that will all run as javaw.exe, then you will need to ensure that the 4th parameter, WindowTitle, of the function call VSI_LaunchPublishedApp() is unique for the particular application. This is necessary as otherwise Login VSI engine will not be able to distinguish between the javaw.exe processes.
  Example:
  VSI_LaunchPublishedApp_PA("Freemind", "Freemind", "javaw.exe", "Map1* - FreeMind - MindMap Mode")

• The function VSI_SetVSITestStartApp_PA("Launcher", "LoginVSIStartApp", "LoginVSIStartApp.exe") should be specified in the beginning of Prepare Phase in a workload file. This function will designate which application that should be used to initiate the Login VSI test. LoginVSIStartApp.exe itself does not do anything and it is a super lightweight application, which is its purpose.
  By using this app instead of something else, such as Notepad or omitting VSI_SetVSITestStartApp_PA(), we ensure that the start-up moment of our test does not use extra CPU or memory, which in turn will give a more accurate VSImax value.

Management Console

• Login VSI Engine startup mode will always use Chained instead of Shell for Published App test. Chained means VSI engine will start at user logon, while Shell will start when RunOnce keys are executed. However, RunOnce keys are only executed when Explorer.exe runs, which it does not do when you launch Published Applications.

• The Login VSI setting "SBC timer detection" is ignored in a Published App test. The frequency of timer execution in a published app test will be solely determined by the setting “Timer interval (sec)”. By using the default value of 360 seconds; however, your workloads will execute roughly the equal amount of timers as if "SBC timer" was enabled, and 360 is what we recommend.

• For Login VSI Published Apps tests we recommend that you run tests with the Login VSI "Segment Start Behavior" setting set to Fixed. This setting means that each user that logs on will start from Segment 1 in the workload, and not from a later or random segment. You can use Calculated and/or Random, but then you have to ensure that any segment in the workload does not contain functions that rely on the execution of a VSI_LaunchPublishedApp() that occurs in a previous segment.
  Example:
  Segment 2 contains VSI_LaunchPublishedApp(“Word”, “Word 2013”, “word.exe”, “Word”) and segment 3 contains App_Focus(“Word”, “UserEdit1”). If we use Calculated and the engine starts execution in segment 3, the App_Focus will fail since Word has not launched and thus does not exist in this scenario. So all functions related to Word will need to be concentrated into a specific segment to avoid this issue, if you wish to use the Calculated or Random settings.

• There are seven settings in the Options tab in the Login VSI Management Console that relate specifically to Published Apps tests.
  
  
  Published Apps options in the Login VSI Management Console - Options page

Below is an explanation of what they do:

• “App launch poll rate (sec)”:
  Application launches in a workload, done through VSI_LaunchPublishedApp_PA(), will deliver a request to one of the running Launchers to launch application X. This value dictates how often a launcher instance will check if there are any queued requests. Lowering the value will increase IO read amount from your launcher machines to your Login VSI share. We recommend a value of 5 (seconds) here.
• “Engine index poll rate (sec)”:
  This controls how often multiple running Login VSI engines will synchronize with each other in terms of workload execution. Lowering the value will increase IO read amount from your session hosts servers to your Login VSI share. We recommend a value of 5 (seconds).
• “Engine process poll rate (sec)”:
  This specifies how often a Login VSI engine will check if a requested application has been launched and started inside the Windows session. Lowering the value will increase the CPU usage of the particular Login VSI engine. We recommend a value of 5 (seconds).
• “Timer interval (sec)”:
  Specifies the minimum interval that must transpire between executions of two Login VSI Timer functions. The Timer functions will generate load on the session hosts and they will also gather data of the performance of the environment. VSImax value is based on this data.
  Running the Timer thread too often will cause too much load and thus not be representative of a real user, and too rarely will not cause enough load and insufficient amount data will be captured. For SBC environments, which is almost always the environment on which you host published Apps, we recommend a value of 360 seconds. If you host published apps from VDI machines, we recommend a value of 180 seconds.
• "Published Apps log file share":
  See RAM Disk Install and Configure in Setting up Login VSI for Published Application Test
• “Relaunch Apps on subsequent loops”:
  If your workload is short and you wish to run several loops, for instance, and you want to mimic user behavior to the largest extent possible, then you probably do not want to close applications at end of workload and then re-launch them again in a new loop. With this setting disabled, any VSI_LaunchPublishedApp() calls will be ignored on loop 2 or later. By default it is enabled since most Login VSI tests do not stretch beyond 1 loop.
  Note: If you disable this setting, ensure you remove any App_Close() or similar calls in your workload to ensure the application stays running between loops.
• “Enable workload index debugging”:
  Turning on this setting will cause log files to be generated in either the path you specified under “Published Apps log file share” setting, if used, or in the default path \\{server}\{VSIShare}\_VSI_LogFiles\{TestName}\Monitor\MultipleResourcesLogs. The log files will be named as “Username_##SiloNumber_##WorkloadIndexDebugFile.txt”. This file will contain info regarding what functions were executed or skipped by a particular VSI engine for a specific user. Only use this setting for troubleshooting and not during real tests.

Citrix/GPO

• Login VSI will always launch published apps with Seamless mode disabled. This is a requirement of the solution, and is handled automatically by Login VSI if you use the Storefront Published App Connector. If you use the Web Interface Published App Connector, you will need to manually disable Seamless mode on your Web Interface servers. See here for instructions.

• The Citrix User policy setting “Default Printer” needs to be set to “Do not Adjust”. This is handled by the Login VSI GPO “LoginVSI-Target-V4”. Otherwise the default printer could be changed when a new application is launched and session sharing occurs, since Citrix policies are applied at Reconnect (which is what a session sharing occurrence is treated as).

• If you have associated Citrix Receiver on your launcher machines with a Citrix WebInterface/Storefront store, then "Citrix Prelaunch" needs to be disabled. If you have applied the GPO “LoginVSI-Launcher-V4” to your Launcher machines, then Prelaunch will be disabled specifically on the Launcher machines.

• In the GPO “LoginVSI-Target-V4” there are settings defined for Internet Explorer proxy. These settings ensure that IE does not run into any issues when run in environments that do not have internet access (Login VSI workloads do not require any internet access to function). If you have edited your Workload to browse to web pages on the internet, you will need to remove these GPO settings. The two registry settings are called “ProxyServer” and “ProxyEnable”.

Citrix Web Interface Connection Type

Below requirements are specifically for Citrix Web Interface Connection type. If you are using Storefront Connection Type then none of the below is necessary.

• The Web Interface logon URL must be in Trusted Sites in Internet Explorer on your Launcher machines. There is a placeholder value for this in the GPO “LoginVSI-Launcher-V4” that you can replace with your own URL.

• "Workspace Control" on your Web Interface Site must be configured with the setting “Log off active sessions when users log off from the site” unchecked. If this setting is enabled, Login VSI Launchers will fail since they are dependent on logging on and off in IE continuously.

• "Seamless mode" must be disabled for the applications used in your Login VSI Workload. See this link for instructions on how to achieve this. By enabling "Citrix Desktop Toolbar" we disable Seamless mode for Published Applications. Note that changing [Application] settings in default.ica file will affect all applications and desktops that are accessed through that particular Web Interface server.
  Example of modified default.ica:
  Disable Seamless mode for all applications by adding Connectionbar=1 under [Application]
  

  [Application]:

  ConnectionBar=1

FAQ for Published App Testing

Q: Do I have to make any modifications in my environment to support Login VSI Published App testing?

A: You need to apply the two Login VSI GPOs, included in the installation, respectively to your XenApp Session Hosts and the Launcher machines that you will use in the test. Using the Management Console tab “Ad Setup” you can generate a Powershell script that will automatically create the Login VSI OUs for Launcher and Target Machines The script will also bind the two GPOs to these OUs. This is the highly recommended way of setting up AD users, OUs and GPOs.

Alternatively, you can manually import the GPOs – they are stored at \\{server}\{VSIShare}\_VSI_Binaries\AD Setup

Q: How many users can I run in a Published App test?

A: We have, so far, run published apps tests with 1000 users, but the solution should work for more users without issue. Please contact Login VSI for further info if you wish to run a test with 5000 or more users.

Q: How many launcher instances can I run per Launcher machine in a Published Apps test?

A: This depends on the amount of calls to VSI_LaunchPublishedApp() you have in your workload, how frequent those calls are, what logon period you use for your test (default is 2880 seconds) and the CPU/memory specification of your Launcher machines. The limiting factor here is the stability of Citrix Receiver. If your test generates too many ICA launches for Citrix Receiver in a short period of time, Citrix Receiver is likely to crash on your Launcher machines or fail to launch particular applications.

Our testing has shown that you can approximately run 3 times as many launcher instances as VSI_LaunchPublishedApp() requests, if using default logon period. So for the KnowledgeWorker_PublishedApps workload, it means roughly 20 instances per Launcher machine.

If using 2 vCPU/2 GB RAM Launcher machines, vCPU is going to be a bottleneck before memory. We suggest you experiment to find the amount of launcher instances that your Login VSI test and environment can support.

Q: Can I include custom applications in the test, such as our business application X?

A: Yes. Just keep in mind that you will need to add instructions in the workload for your specific application, so the virtual users will actually perform some action(s) inside the application.

If you wish to run a test with a single custom application in addition to the standard set of applications, then create your custom workload based on one of the existing official ones.

You can have a look at this [link] to see all the functions you can use in a workload. If you need assistance with creating custom workloads, or if you feel there are relevant functions missing from our workload library, the Login VSI team would be happy to help you. Please contact us at support@loginvsi.com if so.

Q: Can I run a test against published apps on RemoteApp or VMWare Horizon View?

A: This is currently not supported, but we are working on it.

Q: I have a Login VSI license for 2000 users – how will this work with published apps?

A: Exactly the same way. You will be able to run tests with up to 2000 users, irrespective of how you have siloed your applications or how many published applications you have.

Q: What difference in VSImax can I expect between an SBC environment with a Published Desktop and an SBC environment with purely Published Apps?

A: At Login VSI we have tested this by running tests against the Published Desktop, and then against the same applications but through Published Apps instead. In both tests the hardware and the particular XenApp servers were the same. With XenApp 7.6 we saw an increase in VSIMax of 10%.

The difference between Published App and VDI testing could be attributed to the lower impact that a published app session has on the XenApp compared to a published XenApp desktop session. There are several Windows processes that do not have to run with a published app (compared to a published Desktop), such as explorer.exe.

Q: What IOPS can I expect from a Published App test, and how much does a VDI test generate?

A: A Published App test with a single application silo will generate 5 times more IOPS against the Login VSI file share than a VDI test. This is the reason we use a RAMDisk, namely to mitigate the impact of these extra IOPS. The formulas for calculating the IOPS generated against a Login VSI file share during a 48 minute test:

 

• Published Apps test IOPS formula: 0.016y + x(1 + 0.06y) with x being amount of application silos and y being amount of users in test, and x>1
• VDI test IOPS formula: 0.016y, with y being amount of users in test

Q: What XenApp, Storefront/WebInterface and Citrix Receiver versions are supported?

A: Our validation testing was done on XenApp version 7.6, and using Receiver version 3.4.5 and 4.3.0 on the Launcher machines. Web Interface 5.4, Storefront 2.6 and Storefront 3.0 was used during validation. Other versions of Web Interface and Storefront should work, but we cannot guarantee it. XenApp 6.5 or older versions will not work, only 7.X is supported. We are working on adding support for XenApp 6.5 and older versions.

Q: We are in the process of setting up a Published App environment on XenApp, but we lack the expertise/do not know the Best Practices/are running into issues. Can Login VSI assist us?

A: Yes, we have multiple consultants in-house that are experts when it comes to Citrix. Feel free to contact us and we would be happy to assist you.

Q: I have questions that have not been answered here, or I need more specific info. Who can I contact at Login VSI for more information?

A: Send an email to support@loginvsi.com with any questions you have, and specify in your email that you are testing a published app scenario. I would also suggest you take a look at our regular FAQ on our website, [see this link], to see if your issue is already covered there.