Failing to become active can be due to many reasons in two categories. I have some options and settings that help mitigate some of these issues.

• A problem on the Storefront/Citrix side.
• A problem running the users login script. 

 

Login VSI uses the Storefront API to launch sessions in a Storefront environment. It therefor relies heavily on Citrix to get a session up and running. Issues we see include the Storefront server taking too long to respond to a request (30+ seconds). Not enough machines being available. Machines being in maintenance mode. Machines being in the process of starting. Etc. 


Resolution

 

Request timing out.

Requests timing out are typically due to the fact that the Storefront server (or the IIS server on which Storefront relies) is not keeping up with the requests it receives. If this is the case you need to look into the time frame in which you launch sessions, assign more resources to your Storefront server or set up additional Storefront servers. It could also be because the back-end that Storefront relies on is not keeping up. Database servers, AD, etc. 

To help mitigate the issue you can increase the timeout. This tells SFConnect to wait longer for a response from the Storefront server. 

1. Open the VSI management console. 
2. In the VSI management console navigate to Test Setup > Connection. 
3. Under command line add the following:
   /timeout 120​
4. Your complete command line will look like:
   {VSISHARE}\_VSI_Binaries\Connectors\SFConnect.exe /url https://desktop.ncirl.ie/Citrix/NCI-Apps /user {domain}\{username} /password {password} /resource 'Student Labs 2016-2017' /timeout 120

Not enough machines available

Storefront cannot launch a machine that is not available. Please ensure that before you start a test your delivery group shows all VMs in a ready/available state and NOT in maintenance mode. Also ensure that the machine are all started. While Storefront supports starting machines when needed it can often take too long for machines to become available. Especially during a load test. When a machine is in the process of being started Storefront will tell us to retry after a specified time. That time is specified by Storefront but is typically 5-10 seconds. Login VSI will retry up to 3 times before giving up. 30 seconds is often not enough time to have a machine become available once Storefront has fallen behind in keeping enough machines available. 

Other issues

Other issues in getting a Citrix session running might pop up. After a test login in to the launchers. What do you see on the launchers? If you see that SFConnect.exe has stopped working please try and find the so called stack trace. If there is a dialog that offers a continue and quit button then please make sure you capture the details by clicking the details button. See the image below. Please note that the image below is a generic image I found on Google to illustrate the details button only. 

You might also be able to find the stack trace in the event logs. Open Windows event viewer and search for .net or CLR related events under the application log. 

Running the login script

There can be many reasons why the login script doesn't function. Common issues include the user account simply not having a login script defined. Domain controller replication issues. Anti-virus or user environment management (UEM) software like RES, Appsense, etc, interrupting or stopping the logon script. 

Now there isn't much that I can do here to help you mitigate this. But I can help you diagnose this issue. Please note that this assumes a default VSI installation. If you are running the VSI script through other means then some or all of this might not apply. 

Verifying that this happens

The easiest way to verify that the Citrix portion is working but the login script isn't running is looking at the environment after a test is completed. Are there users that are still logged in? When you take those sessions over by logging into Storefront with that user account/password, do you see the user sitting idle at the desktop? If there are applications active then the session might have gotten stuck somewhere.

Once you verify that the login script is a problem you can look into why the login script isn't running.

Verifying that the users have a login script defined

Verifying that a login script is defined requires access to active directory. Simply verify that every user account has V4-VSI_Logon.cmd defined under login script path on the profile tab. 

Verifying that the login script is being replicated

When logged into a VM as one of the users that fails to run the login script (IE from Verifying that this happens). Open a command prompt and type set logon. This will tell you what domain controller is handling this user. Once you know what the domain controller is do the following:

1. Open a Windows explorer window. 
2. Browse to \\domaincontroller\netlogon. Where domaincontroller is the domain controller you get from running the set logon command. 
3. Verify that V4-VSI_Logon.cmd exists. 

​

If V4-VSI_Logon.cmd is missing then you need to figure out why one of your domain controllers isn't replicating the sysvol folder. As this will not only break login scripts but also things like group policy. 

Applies to Login PI 1.0 and greater & Login VSI 4.0 and greater