The VSI logon process is split up in 3 phases. The first phase happens when the logon script is triggered. We'll call this the logon script phase.

Logon script

During the logon phase the following happens:

• Enumerate the amount of users currently active on the machine New in 4.1.3 due to the SBC specific timers
• Establish a time stamp for the logon timer
• Remove the %temp%\VSI folder (this will be important later on)
• Recreate the VSI folder
• Copy the runtime files from the VSIshare to the %temp%\vsi folder
• Write the VSIshare location to an ini file
• Run VSI in logon mode (VSI.exe /logon)

This all boils down to removing the VSI folder and recreating it. This is done to make sure that if you changed anything from the target binaries side that they will be refreshed. VSI in logon mode will be explained below.

VSI in logon mode

When VSI runs in logon mode it does the following:

• Write a file to the VSIshare to indicate that it is logging on
• Retrieve which session number this session is
• Copy down the following files (these will be important later on)
  • Global.ini
  • VSILauncher.ini
  • DataLocations.ini
• Parse the ini files for certain settings important to the logon mode process. Things like the drive to be used to map the home drive, etc.
• Depending on if these settings are enabled do the following:
  • Set the Freemind file type association
  • Import office version specific registry files
  • Map the user home directory
  • Map the group drive
  • Copy a random PST file for Outlook
  • Determine the engine startup (this will be important later on)
• Depending on whether engine startup is set to shell or chained the engine will do one of the following.
  • Shell: Write HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce\VSIEngine with the data portion pointing to the VSI executable. This registry key will be triggered the next time Windows Explorer is started (this will be important later on)
  • Chained: Restart VSI.exe in workload mode.

VSI in workload mode

When the logon script and VSI in logon mode are finished Windows will continue with its logon process. At some point Windows will start Windows Explorer that will load the windows shell. The desktop, the start menu, etc. Once Windows Explorer has loaded the shell it will trigger all the keys under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run and HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce. RunOnce keys are removed once they are executed.

When to use shell/chained

Use shell when
Shell is the default setting. This will trigger VSI to run once Windows Explorer is done loading. This gives the best timing to start VSI, namely right after the user shell has finished loading. It also gives the most realistic number for the logon timer.

Use chained when
Chained should only be used if shell does not work for whatever reason. There are a couple of reasons why shell doesn't work:

• The registry key was set after Windows Explorer has already been loaded. This is the most common reason why shell would not work.
  • The most common reason why the registry key was set after explorer has already been loaded is because the run logon scripts synchronously policy is not set.
  • The logon script might be triggered after Windows Explorer has been loaded. Some users run the logon script through the startup folder or other ways like User Environment Management (UEM), think RES powerfuse or Appsense.
• Some UEMsolutions or anti-virus solutions block the run and runonce keys.

Chained will cause the logon timer to be less accurate and if chained is used in a situation where the run logon scripts synchronously policy is set. This will cause Windows to delay running Explorer for quite a while, eventually timing out and running Explorer anyway.

# Q2: Why you see the knowledgeworker.txt error
With having the above explained, I believe the following happens:

1. Initial a user is logged on in shell mode.
2. Shell mode fails to run because the registry key is set after Windows Explorer is loaded, for any reason.
3. The user is (forcefully) logged off.
4. A second test is started, this time the user runs in chained or shell mode.
5. VSI.exe is started in workload mode due to the shell mode registry key that was left behind from step 1. I will refer to this as shell VSI
6. The logon script deletes the content of the `%temp%\VSI folder.
7. Shell VSI tries to read global.ini to determine the workload. Global.ini is supposed to be in the %temp%\vsi\runtime folder.
8. Shell VSI fails to read global.ini because it was deleted in step 6. Shell VSI reverts back to default settings. The default workload is KnowledgeWorker workload
9. Shell VSI tries to read the workload file. Since it reverted to defaults it tried to read KnowledgeWorker.txt. This file does not exist because it is not the workload you are running.
10. Other settings might also be garbled. The default Office version is 14 for example.

What actually happens is that Shell VSI running in workload mode and the VSI.exe instance running in logon mode are running simultaneous. Step 6-10 take a bit of lucky timing to happen but it seems you've been hitting this timing on the head quite often.

Evidence of this happening
In the log files (engine) you can see the following evidence of this happening

• ----------------- VSI STARTING IN LOGON MODE ----------------- is not the first line in the debugging. This line should always be the first line. As logon mode needs to happen before anything else.
• Activetest name resolved: Run_1175 happens before ----------------- LOGON MODE ENDED -----------------. Resolving the active test name is the first step that the engine will perform when running in workload mode. This line should never show up before logon mode ending. Please note that all of this applies to 4.1.2, the first line in 4.1.3 when running in workload mode is either OS Type is server or OS Type is client

Solution
Make sure that the registry key is gone when running a test after shell failed. Deleting the user profile should do the trick but that obviously didn't work for you. Did you check if the users use profile management or roaming profiles? We've seen this problem in your environment before where we tried to delete the appx registry keys for Adobe Reader and Windows 8. I recommend investigating why the registry keys are coming back even though you are removing user profiles.