Help… my sessions aren’t doing anything – Troubleshooting Login VSI tests
As a support engineer for Login VSI, I have the chance to help customers get the most out of Login VSI performance tests in their virtualized desktop environments. While many of the issues I see are unique, some are common. One issue I see often is: sessions are logging in but nothing is happening. In this post I will describe how Login VSI startup works and how to troubleshoot problems during startup like the one I just described. (For any TL;DRers, you can jump to my summary of components necessary to run a Login VSI test).
How does Login VSI startup work?
Login VSI is very dependent on the logon process of a user. During AD setup, Login VSI configures the users and sets a logon script: V4-VSI_Logon.cmd. This logon script points to (and opens) a specific file on the VSIshare named “logon.cmd”. This “logon.cmd” initiates a few actions:
- Writes the logon time to the VSIshare
- Checks if the VSI folder in the %tmp% directory is there and if it is, logon.cmd deletes it and re-creates it
- Creates the VSI directory tree in the %tmp%VSI directory
- Copies all the files from the \VSIshare_VSI_BinariesTarget folder to the %tmp%VSIRuntime folder
- Calls on Login VSI in logon mode and starts directly after the logon script (chained) or places a registry key that will trigger Login VSI to run when the desktop is loaded (shell)
When everything is said and done, the VSI.exe will be executed and a test will start.
The Login VSI session is logged in but nothing is happening
The previous description was an ideal Login VSI startup procedure. If Login VSI does not start in a session, there are a couple of things you can check to see if everything worked properly. My own path of inquiry looks something like this:
Is the VSI folder there?
My first step in troubleshooting is to find out if the logon script ran in its entirety. To do this, log in to a session with a Login VSI user (or your own defined test user) and see if the %tmp%VSI folder exists and if it contains files.
An extra note is that it is very important that all users used for the test are logged off all of the VMs (including users from disconnected/failed tests). If a session is already logged on and Login VSI logs in that machine with the same user, the session will be taken over. Which means that the logon process never happens and the Login VSI test will never start.
So before checking if the VSI folder / logon process is there, or has ran, make sure that there are no users logged in to any of the VMs.
Where’s my VSI folder?
If the VSI folder is not there, I check to see if the logon script is configured in the user on the AD. If this is not set, I check in the \%logonserver%NETLOGON folder if the V4 –VSI_Logon.cmd exists. Depending on how the users were created, via our AD script or manually, it’s time to troubleshoot what went wrong. However, when the logon script is not there, I will create it manually.
The logon script only contains:
When the logon script is created, I link it to one user and test if the logon script is working again in a session. I then troubleshoot until this is working.
VSI folder is there but nothing is happening
What if the logon script worked like a charm and the %tmp%VSI folder is there but Login VSI still doesn’t start? The best first step is to set the Engine Startup to Chained instead of the default value Shell. You can find this setting in the Management Console > Workload > Settings tab.
Possible reasons the Shell setting might not work are:
- A profile management system is used, like RES or AppSense
- Logon scripts are running synchronously
Another situation is that the logon script has done its job but certain files are missing. In this case, the most probably cause is a virus scanner. This can be either the virus scanner on the VMs or on the VSIShare itself. We recommend that when you are testing either exclude the %tmp%VSI folder (and sub folders) and the \VSIshare from scanning or disable the virus scanner all together.
In summary, you must make sure that the following are working:
- Logon script is running
- VSI files are in the %tmp% directory
- The engine startup is set correctly (shell or chained)
- VSI folders are excluded from antivirus software scans
And if none of my tips worked for you, the Login VSI Support team will always be glad to help.
Ps. this blog might be interesting to you as well: Disconnected Login VSI Sessions