This page describes how to configure the MMC, in order to have your test do what you want. This is a quick setup guide, to get a test started ASAP. If you're looking for a more detailed and thorough walk-through, see the Management Console section.

If you are looking for troubleshooting issues, please check out our new Knowledge Base, or take a look at some of the most FAQs

AD setup

You can have AD users pre-made for the test. This can be done using the PS1 script provided by LoginVSI, or can be done by making the users manually. To see how to do this manually, please see this section. We highly recommend that you use the PS1 script provided by the AD Setup tab of the Login VSI Management Console, since this saves a lot of trouble and is much faster.

Requirements

• Sufficient privileges to create User Accounts / Groups and GPOs in Active Directory
• An installed copy of the Login VSI Management Console
• The AD script should be run on the Domain Controller/Member Server logged on as Domain Admin
• Group Policy Management Console has to be installed on the Domain Controller/Member Server
• When choosing a password for the Login VSI users, make sure it meets the basic requirements of the password complexity set on your domain

Note: Please ensure the domain controller (DC) is performing accordingly. Login VSI has minimal load, but be proactive in order to prevent the DC, or the AD, from causing any bottlenecks.

Important: Please disable AppSense when testing, as it has been found to often prevent the logon scripts from running properly.

Launchers

This is the launcher tab. This is where you will want to have certain machines as your launcher machines for the test. Add the host name/IP address/Fully Qualified Domain Name to the "name" portion. Capacity is the number of users you can run on each launcher. For Citrix and VMware Connectors, the recommended maximum is 25, RDP is 50, and DDC is 1000. Enabling launchers is required for the test. This is just a recommendation as you can certainly add in more users per launcher, but we officially only support up to 25. You are free to run a lower amount of users as well.

Example: If you would like to run a 500 user test using Citrix StoreFront, you will need to have 20 launchers enabled with 25 users assigned to each.

Content Library

The content library gives you an overview of the documents available for use within Login VSI. The OfficeWorker, TaskWorker and KnowledgeWorker workloads will run without the Pro Library. The Pro Library must be downloaded separately. The Pro Library contains extra data files which are used by the Login VSI PowerWorker Workload. The idea is to have a 'larger' pool of 'random' files (think of caching) that will be processed during a workload.

Important: If you are using the Multimedia Workload or any customized workload with different applications, then please refresh the Content Library before you start testing. To do this, click the Refresh Content button in the Content Library tab. This will update the library with the specific files the workload requires to complete its commands.

Settings

Be sure you have your Microsoft Office version set properly in this section.

If you run into issues during the test, such as stuck sessions, we recommend you enable two debugging options: Workload Debugging and Engine Debugging. These two will help find the reason for the stuck sessions by looking onto \\Server\VSIShare\_VSI_Binaries\<testname>\Debug\ErrorShots and seeing the error messages received during the test. If you cannot figure out what is going on, please contact LoginVSI Support.

If you already have an H: or G: drive, please change the mapped drives to another one. If you do not, this will probably create a conflict, and cause the test to fail. If App-Sense is on the Target Machines, please disable it, as it is found to remove the mapped drives while a test is running.

For LoginVSI 4.1.3: The mapped drives may be disabled for the test, if you cannot create these drives or they lead to conflict and there is no other option.

Are you running into application start timeouts and/or application focus timeouts? Then you can change the number to something higher than 120 seconds, if you believe this is appropriate for your test or users. Depending on the environment, it can be increased to 180 if there is more security, or decreased to perhaps 90 seconds to check for better performance. Please be aware, LoginVSI is expecting default timers, so if they are changed the LoginVSI data will be skewed as well. This does not invalidate the test, it just changes the visuals in the Analyzer.

Scenario

At the top choose which workload you want to use. Select the number of test users you would like to run under "Sessions" and then choose how long the users will take to logon with "Logon Rate". The number placed in the latter will change the length of the test. It is important to choose a logon time that works for your test scenarios, so find one that works. The default is 2880, we recommend this amount for scalability testing. The number can be decreased by half, if a logon storm test is desired. We recommend you figure out what number you deem appropriate, but the Analyzer will have skewed results if the default is not used. This will not invalidate the test, it is just create different Analyzer visuals.

Choosing an appropriate workload is important when running your test(s). The section Login VSI Workloads will tell you the differences between them and their utilization of resources.

Connection

In this section, you must choose what connection type you want to use. Everything for the connections must already be known, and input into the fill ins. All connections have their own unique information, so be sure it is put in correctly.

There is no quick way to do this, and I would highly recommend going through the connectors reference in this page: http://www.loginvsi.com/documentation/Login_VSI_Connectors_Reference

If you cannot get a test to connect properly even after following the above link, please contact LoginVSI Support.

ESXTop integration and configuration (ver4.1.25+)

To help identify performance bottlenecks more easily, Login VSI now provides the option to collect and generate VMware ESXTop performance logs, instead of having to create and import a CSV file manually into the Login VSI Analyzer. For this option to work, please ensure that SSH is enabled on the VMware host in use. Please note that this functionality only supports one ESX host at a time.

To enable this option, please navigate to the Workload section/options of the MMC, and configure the fields as follows:

• Enable: mark the checkbox
• Server: enter the full name of the physical server where the VM is hosted
• SSH: this should be configured to either admin or root
• Username: define a username of your choice
• Password: define a password of your choice
• Interval between recording (seconds): default 30, best practice 30
• Amount of recording samples: default 120 (at 30 second samples this will run the esxtop batch for 60 minutes)
• Time to keep file (days): select the length of time to keep the generated data

Start Test

An important part of this is the "logoff timer". This is a timer that will count down when the last users signs on. The default is 120, and is recommended for scalability testing. If you would like to have your test run longer after all of the users have signed on, choose a number that will work better for your test. You can run the test for as many integers you can place into this portion.

Example: For stress testing, it is common to see default timers and a logoff of 432000 seconds, so all users are running continuously for 5 days straight.

Another important part is the Launcher Workflow. This is designed for a test that has a large number of testers. Input the Launcher user information from your AD setup, and it will connect via RDP into your launcher machines from the machine that is running the LoginVSI Management Console. If a security warning is received on the launcher machine for the RDPConnect, then placing the VSIshare into the local Intranet will prevent it from appearing on the launcher machines.

Make sure that the Session Monitor and the Agent are running in their respective locations. If they are not, then you will not be able to begin the test. If you run into issues with the launchers flipping back and forth between Ready->Error, please check Disable Launcher Heart Beat in the settings. It may be a timing issue as well, and if the above does not work, please contact Login VSI support.

SOAK testing enhancements

Login VSI now includes upgrades for SOAK testing that improve the overall stability during long-term testing. SOAK testing now runs faster than before, does not run out of memory during large scale data tests, and can be run continuously if required. This type of test can help identify issues relating to memory allocation/leaks, log file handles, storage problems and database resource utilization.

If you want to run a SOAK test to evaluate your system's long-term stability, you can define how long the test should run in the start test wizard. If you want to run a test continuously, please set the toggle to 0. We also advise disabling (unchecking) certain charts in the Analyzer Preferences that are not required when running a SOAK test. For more information, see the Analyzer Tabs section.

Session status per launcher

The Login VSI dashboard now includes more information on how many active sessions are being run per launcher. When a test is running, there is now an extra column in the Launchers section, called active sessions, which contains this detailed information.