Citrix Logon Simulator’s – Part 2

/ /
in Blog

In my previous post I was looking at utilizing a Logon Simulator to setup some proactive monitoring of a Citrix environment.  I setup some goals for myself:

  1. Minimize the number of VM’s to run the robots
  2. As little resource consumption as possible
  3. Still provide operational alerts
  4. Operate on-premise

I want the footprint of these robots to be tiny.  This must done on Server Core.

I want to run multiple instances of the logon simulator concurrently.

I need to be able to test “Stores” that do not have “Receiver for Web” sites enabled.

I want it so if I reboot the robot he picks up and starts running.

The Choice.

In order to successfully hit these specified targets I opt’ed to use ControlUp’s Logon Simulator.  It can target the Store Service so it works with our “Receiver for Web”-less stores.  It also has the features to generate events that can be targeted to send out notifications of an application launch failure.

The Setup

In order to achieve my goals I need the following:

  • A Service Account that will be logging onto the Citrix servers
  • The robot (Windows 2019 Server Core)

I installed Server Core 2019 and added it to the domain.

Configure Autologon

I configured group policy preferences to setup AutoLogon for my service account.  This group policy object is set to the OU the robots reside in.

Group Policy Preferences settings to configure Autologon for our service account.

However, I did not include the required “DefaultPassword” registry with the password.  In order to embed the password in a more secure fashion, I had to manually use Sysinternals AutoLogons.  This keeps the password from being stored in plain text in the registry but this does need to be manually executed on each robot.

Configuring Autologon

The account MUST be a regular user and not a member of the “Administrators” group.  This is a requirement of the ControlUp Logon Simulator.

Prerequisites gotcha’s

Because I selected to use pure Server Core, there are some components that require fixing for full compatibility.  This can actually be alleviated immediately by installing the Feature On Demand (FoD) “Server App Compatibility”, but this would increase both memory utilization and consume more disk space for our robot.  However, if you prefer the easy way out, adding the FoD fixes everything and you can skip the “Fixes” section.  Or just run the Logon Simulator on a operating system with the desktop experience.  Otherwise, follow the steps in each of the solutions.


Unable to install Citrix Reciever/Workspace App

“TrolleyExpress.exe – System Error”
The code execution cannot proceed because oledlg.dll was not found.  Reinstalling the program may fix this problem.


Copy oledlg.dll from the SysWow64 in either the install.wim or another “Windows Server 2019 (Desktop Experience)” install and put it in the C:\Windows\SysWow64 folder of your robot.


ControlUp Logon Simlulator is cropped on smaller displays


Set the resolution larger in your VM.


ControlUp Logon Simulator errors when you attempt to save the configuration

“The logon simulator failed for the following reason: Creating an instance of the COM component with CLSID {C0B4E2F3-BA21-4773-8DBA-335EC946EB8B} from the IClassFactory failed due to the following error: 80040111 ClassFactory cannot supply requested class (Exception from HRESULT: 0x80040111 (CLASS_E_CLASSNOTAVAILABLE)).  An application event log has been written to handle this crash.”


Copy ExplorerFrame.dll from the SysWow64 in either the install.wim or another “Windows Server 2019 (Desktop Experience)” install and put it in the C:\Windows\SysWow64 folder of your robot.  Add the following registry:

ControlUp Logon Simulator detects admin rights

Admin rights detected The logon simulator should not be run as an administrator, please restart the app as a standard user.


Run the logon simulator as a standard user.


Once you’ve implemented all the fixes, install Citrix Workspace App and ControlUp Logon Simulator with an account that is an administrator.

Configure ControlUpLogonSim.  With the simulator open, enter your Storefront details, ensuring to use the “Store” account as seen in the Storefront console.



For the “Resource to Launch” ensure the name matches the display name in Storefront:


In order to avoid session stealing in the simulator, each application will require a unique user name.  Setup a unique account per application you are going to test.


From here, enter your logon credentials for the account associated with the application.  Run your first test by clicking the green triangle and ensure it works correctly.


Now that we have a successful run we set “Repeat Test” to ON and save the configuration.

I then created another application to monitor by renaming the “Resource to Launch” as another application and saved a second configuration.  I saved all my files to a C:\Swinst folder.


The point of all of this is to ensure the simulator is running in an automated fashion.  To do so, we need to be able to configure the simulator to “launch” multiple different applications when the operating system starts.  We have already configured autologon, we’ve setup our configuration files for each application we want to monitor, now we need to set the monitor to auto-start.

Add the following registry key:

And create a file “C:\Swinst\StartAppMonitors.cmd” with the following contents:

And watch the magic fly!

And so the final question and the point of all this work, how much does this consume for our resources?


1.1GB of RAM for the ENTIRE system, a peak CPU consumption of 7%, and the processes required to do the monitor use no CPU and only ~55MB of RAM.  Each Citrix process consumes ~20MB of memory and is the most significant consumer of CPU but at the single digit % range.

I anticipate doing some more stress testing to determine what the maximum amount of monitors I can get on one system, but I’m thrilled with these results.  With this one box I would expect to be able to monitor dozens of application…  Maybe a hundred?

In the end, this was a fair bit of work to get this setup on Server Core, but I do believe the savings in resource consumption and overhead reduction will pay off.

Read More

Citrix Logon Simulator’s – Part 1

/ /
in Blog

“Help!  I can’t launch my application!”
“Is something wrong with Citrix?”
“Hey man, I heard Citrix was down?”
“Can you help? I need to get this work done!  The deadline is today and I can’t open my app!”

Welcome to the world of a Citrix Administrator.  If an application stops working then the calls flood in and you get pinged a million times.  Is there a way to be proactive about when an application goes down so you maximize your time trying to fix the issue between the failure and first call?

The answer to this is a Citrix Logon Simulator.

There are a few different logon simulators out there including two powershell scripts I wrote for performance testing.  One for testing the “Web” service and one for the “Store” service.  The difference between the two services is found in the name, with “Web” typically appended to the web service (eg, “/Citrix/StoreWeb”) and the “Store” service ending thusly (eg, “/Citrix/Store”).

The “Web” service is the user-facing front end for Storefront.  When you open a browser and go to your Storefront URL you are using the web service.

“Web” service. User logs into Storefront and launches an app using a web browser

Each “Web” service has a corresponding “Store” service.  However, the “Store” service does not require a “Web” service and you can create Store services without a Web Service.  Store services are used when you configure Citrix Reciever/Workspace App to connect to Storefront.  When you launch apps via Citrix Receiver/Workspace App you are using the Store service.  In addition, when thin clients are configured to use Storefront they, typically, use the Store service.

Using the “Store” service. Not the program is “Citrix Workspace” and not a web browser.

I haven’t found a logon simulator that tests each service, the products out there only test one or the other.

In Summary

Web Service

Testing the web service simulates a users experience authenticating and launching an application via a web browser.  These simulators launch a web browser, browse to your URL, login, find your application and then click it to launch it.  This does make an impressive demo of automation watching the web browser do actions without a human.

Store Service

Testing the store service simulates a user authenticating and launching an application, via a Citrix client.  This is done through API’s or REST API calls, it’s up to the client to generate a GUI from the information returned (if desired).


Web Service Simulators

Executing the logon simulators that use the web service is impressive watching the web browser manipulate itself.  However, the requirement of using a web browser was limiting in that executing multiple concurrent applications was not feasible.  Options seemed to range from providing a list of applications to be tested (which are tested sequentially) or expanding the number of VM’s that will run the logon simulator.  In addition, it’s possible to create “Store” services that host applications without the corresponding “Web” service. Simulators that only test the Web Service will be unable to do any type of testing for these Stores.

Single VM

If you opt for a single VM to test as many applications as possible, the time between applications increases linearly.  For 10 applications to be tested to validate they are operational, with a 2 minute interval you will only be testing that application every 20 minutes (at best).  If you have 100 applications you’ll be waiting over 3 hours between tests.

Multiple VM’s

Multiple VM’s operate very well with the web service.  But they introduce another wrinkle.  How feasible is it to expand your environment 100 VM’s to test if 100 applications are operational?  With a operating system overhead of ~1GB at best, you’ll be consuming at least 100vCPU and 100GB more of memory.  This is pretty much dedicating a host just for robots.  This may be worth it when compared to the cost of time when a application is down… But this is now becoming a very, very expensive solution.  Hardware costs for hosts, hypervisor licenses, and Windows licenses compound to the pain of a multi-VM solution.

Store Service Simulators

In terms of a demo, the store service is less visually impressive.  The automation is done programmatically so you don’t get to see those gratifying “clicks”.  However, there is no browser requirement.  This does mean you don’t need a full GUI operating system to run a store service logon simulator.  In addition, because the Store Service simulator operates via API calls, it’s completely possible to run multiple in parallel.  This means there is a very large opportunity to save VM costs by consolidating all the testing into one, or just a couple VM’s and for each test it will keep that tight interval.  However, the draw back of the Store Service simulator is additional configuration is required for testing through a Netscaler.  Essentially, if you have not setup the DNS SRV record to allow Store Service communication than a Store Service simulator will not work externally.

What’s the plan?

After exploring these considerations, I set out to design something with some goals.

  1. Minimize the number of VM’s to run the robots
  2. As little resource consumption as possible
  3. Still provide operational alerts
  4. Operate on-premise

My next post will explore how to achieve this and the solution I settled on.

Read More

Citrix Storefront – Adventures in customization – Add a help button to your Storefront UI

/ /
in Blog

This customization is pretty easy.  Add the following to your custom.js file:

Replace “” with the URL you want your help screen to be.

Read More

Citrix Storefront – Adventures in customization – Default to “Store” view if you have no favourited app’s

/ /
in Blog

We are in the process of migrating users from Web Interface to Storefront.  We have identified a potential issue; new users are directed to the “Favourites” view which doesn’t have any applications be default, instead it has instructions on how to add apps to the favourites view.

New users might say, “Where did my apps go?!”

The concern is users may become confused because Web Interface shows all your applications, and this new view shows none.  What we want to do to solve this is default to the “Store” view if you have no favourite apps, and default to the favourites view if you have at least 1 app favourite.


We can do this.


Just add the code above to your custom.js file and the default view will be changed to the store if you have no favorited apps.  Done!

Read More

Citrix Storefront – Adventures in customization – Define a custom resolution for a specific application

/ /
in Blog

Currently, Storefront does not grant the ability to define applications with specific resolutions.  In order to configure the resolution, Citrix recommends you modify the default.ica file.  This is terrible!  If you had specific applications that required specific resolutions, what are you to do?  Direct users to a variety of stores depending on the resolution required?!

Fortunately, again, we can extend StoreFront to make it so we can configure custom resolutions for different applications on the same store.  The solution is a Storefront extension I’ve already written.

The steps to set this up:

  1. Download the Storefront_CustomizationLaunch.dll.
  2. Copy the file to C:\inetpub\wwwroot\Citrix\Store\bin
  3. Edit the web.config in the Store directory and enable the extension
  4. We need to enable Header pass-through for DesiredHRES, DesiredVRES, and TWIMode in the “C:\inetpub\wwwroot\Citrix\StoreWeb\web.config” file:
  5. Lastly, add the following to the custom.js file in your StoreWeb/custom folder:
  6. And enjoy the results!  🙂

Read More

Citrix Storefront – Adventures in customization – Prepopulate Explicit Logon Credentials

/ /
in Blog

Citrix Storefront allows you to prepopulate the credentials for your Explicit Logon.  The explicit logon screen is generally seen here:

And you can prepopulate the Username/Password fields.  If you don’t want to prepopulate the password, that’s fine too.  There are 3 properties and none are required.  Username, Password and Domain.  In order to prepopulate you must pass your credentials through to Storefront somehow, either as a cookie, header or as a URL search query.  I will demo it in the URL search query since I already have that code for pulling the parameters.  You must have “Explicit Authentication” enabled, aka, “User name and Password”:

Put the following code into your custom.js file:

The url to query is:

And the result:

Read More

Citrix Storefront – Adventures in customization – Login via credentials in URL search query

/ /
in Blog

If you use a 3rd party service to connect to your Citrix Storefront environment, you may want to “pass-through” credentials without using domain authentication or whatever.  This post illustrates how you can login to your Storefront environment using nothing more than a URL with your credentials embedded in them.  To enable this functionality, this code must be in your custom.js file.

You MUST have HTTP Basic enabled as an authentication method on your Citrix Storefront Store.

The URL to login would look like this:

Put it all together:

Read More

Citrix Storefront – Adventures in customization – Change any ICA parameter

/ /
in Blog

When I was originally exploring using the Citrix SDK to manipulate some ICA parameters, I found I couldn’t do it.  Using Powershell and passing a header parameter I could manipulate the ICA file to how I wanted, but when I attempted to do so with Internet Explorer, I found it wasn’t passing the header parameter.  I assumed this was because of how browsers were launching the ICA file.  However, I attempted to use Sam Jacob’s Citrix Storefront clientname manipulation extension, I discovered I had the same problem.  I originally thought I was doing something wrong, but on a whim I tried Chrome and it worked…  Perfectly!

When I investigated further I found it appears that when Storefront detects IE it doesn’t use the GetLaunchStatus API, which passes the headers to Storefront for ICA manipulation.  I found a way to fix this was the add the IE detection to the script.js and add the missing call to the GetLaunchStatus API.

But now that I have headers being passed properly, I thought I should revisit my ICA parameter manipulation.  Sam’s customization works great for manipulating the client name, but we have a few applications with various different requirements:

  1. Pass parameters to some specific applications
  2. Modify clientname based on the specific application that is launched

Can we replace Sam’s customization with one that can manipulate any ICA parameter we so choose?

Yes.  Yes we can.  Storefront is very nice, flexible and powerful 🙂

I’ve designed this customization to look for an additional app setting tag.  This needs to be added to the web.config at the “”C:\inetpub\wwwroot\Citrix\Store\web.config”” level:

Any parameter you want passed through needs to be enabled as a forwarded header in the “”C:\inetpub\wwwroot\Citrix\StoreWeb\web.config”” file:


Lastly, you need to edit your \custom\script.js file to include your application and whatever parameters you want passed to it:

One of the cool things about this is you can still use tags to change the behaviour of these applications.  For instance, if you want a certain subset of your applications to be 8bit you can do set check for that tag on app launch and add the header to set the desired color.  You can set certain applications to keep their ICA file by setting “RemoveICAFile” to Off.  You can individually modify any setting for a specific application or subset of applications.

Here is the StoreCustomization_Launch.dll and source code.

Here is the source code for prosperity:



Read More

Citrix Storefront – Adventures in customization – Customization breaks in internet explorer

/ /
in Blog

I ran into a frustrating issue with my last post (changing the clientname based on the application).  The issue was, it wasn’t working!  Sometimes!  On some versions of IE!  On some Operating Systems!


On Windows 10, IE11 or Edge it worked fine.  On Windows 7 or Server 2008 R2 with IE11 it worked…  SOMETIMES.

I started to dig into what was happening.  Why wasn’t the ClientName being set consistently?

It turns out that the code path for the “StoreFront Customization SDK” (at least the ICA file modification portion) operates when a request is made to “GetLaunchStatus”.  A working application launch from StoreFront looks like this:

Notice when I click the application icon, TWO requests are made.  The first one, GetLaunchStatus contains the headers that is passed to the SDK customization plugin, the second is a hidden iFrame to pull the ICA file.

Now, if I login to a server or PC that I’ve never logged into before (so that I have a fresh profile) and launch IE and immediately go to Storefront, this is the result:

Notice it only goes to “LaunchIca”.  Because of this my ClientName is not modified.

To validate the theory a bit further that something in Storefront maybe causing my issue, I opened up Chrome and changed it’s UserAgent to be identical of IE11 on Server 2008 R2:

And what happened?

Only LaunchIca is called.  We have a reproducible failure.

As I was digging into the Citrix code to launch the “GetLaunchStatus” URL I found it would “skip” going to URL under a series of conditions, one of them relates to checking for the presence of IE (CTXS.Device.isIE).  I found two candidate functions that maybe causing this failure, and I think this one is the most likely:

Specifically, this line under the switch statement:

CTXS.Device.isIE() && CTXS.ClientManager.usingNativeClientInInternetZone() ? (g(a, CTXS.LAUNCH_SUCCESS), g(a, CTXS.LAUNCH_READY), a.isLaunchReady = !0) : (CTXS.ClientManager.getLaunchMethod() == CTXS.LaunchMethod.PROTOCOL_HANDLER && (e.ticket = f.fileFetchTicket, e.staTicket = f.fileFetchStaTicket, e.fileFetchUrl = f.fileFetchUrl, e.serverProtocolVersion = f.serverProtocolVersion), d(a, c, e));

I found if I modified the UserAgent at that exact point so CTXS.Device.isIE() did not return TRUE that it would execute the GetLaunchStatus.

Now that I suspect I have my culprit I examined the code that calls GetLaunchStatus URL and added it to my custom.js file:

The end result now looks like this:

And now my customizations are called correctly and work with IE11.  I haven’t done extensive testing so “your mileage may vary” with this fix, but if you are finding your customizations aren’t operating correctly you may want to try this fix.


Read More

Citrix Storefront – Adventures in customization – Assign a custom clientname to an application

/ /
in Blog

I have set a personal goal to avoid creating more than a single store for Storefront.  With that, I’ve been working on customizing Storefront for our organization and occasionally a problem comes up that requires a unwieldy solution…  Like creating multiple stores.

An example of this is we have an application that configures itself based on the CLIENTNAME variable.  The current solution for  this problem is to provide ICA files with CLIENTNAME preconfigured.  The application is launched, detects the client name variable then displays the relevant data.

Really, this is a pretty terrible way for the app to configure itself.

You would hope the application would have been coded to accept a switch or something for configuring it and then just publish out the application(s) instead.

But, I’m not the developer of this application and have to come up with a solution that works within this framework.  The initial thought was we can enable ‘overrideicaclientname’ and then modify the default.ica files with the hard coded client name.  Then we’d create as many stores as is required to support the different configurations…  Then direct users to the different URL based on their needed configuration…

If this is starting to sound ugly, it’s because it is.

Citrix provides some guidance for manipulating the CLIENTNAME.  Unfortunately, the manipulation of the CLIENTNAME in the example would not be sufficient.  We need to configure it to be a specific string and all the examples within are dynamically generated.

Fortunately, Citrix CTP Sam Jacobs has come to the rescue and extended the work of Simon Frost. Sam’s addition was to accept a custom HEADER and configure the CLIENTNAME on that value.  This sounds perfect.  I think I can configure a custom header during the launch of a specific application, and StoreFront will take that name, configure the CLIENTNAME and voila!

So how would you do this?  Jason Samuel goes over the configuration of the necessary steps (it’s in both Sam and Simon’s posts as well, but I found Jason’s post more clean and clear).  The exception is (step 6 in Jason’s post) the clientNameRewriteRule needs to be set with the custom header we are going to look for.

My instructions are:

  1. Edit “C:\inetpub\wwwroot\Citrix\Store\web.config” (note: this is the “STORE” web.config and not the STOREWEB)
    Configure a section “appSettings” to be like so:
  2. Find the “overrideIcaClientName” and ensure it’s set to “on”:
  3. Edit “C:\inetpub\wwwroot\Citrix\StoreWeb\web.config”  (note: this is the “STOREWEB” web.config)
    Add a ‘forwardedHeaders’ section under “communication”
  4. Edit the “C:\inetpub\wwwroot\Citrix\StoreWeb\custom\script.js” file and add the following:
  5. Download Sam’s “StoreCustomization_Input.dll” from here and overwrite the placeholder located here:

And?  Did it work?!

Look at that!  It works!  Splendid!

And now I can configure ClientName based on the application that is launched!  So now we do not need to create multiple stores, we can keep this to a single store and it’s more dynamic and cleaner (IMHO).  The only caveat is upgrading Storefront these steps may need to be done again as the web.config files may be cleaned or reset.

UDPATE! I found that customizations were being inconsistently applied!  Check this post for further details and a possible fix!

Read More