How to Install and Configure LoginVSI

During the last couple of years LoginVSI has positioned itself as the industry standard load testing tool for any Application or VDI environment based on Citrix, VMWare or Microsoft protocols. This is not the first tool this team has released, if you have been in our community for long you might remember or even used (I did) Flex Profiles. I have recently done some testing myself with this great tool and I wanted to share my findings on how to install and configure LoginVSI.

Due to length of the topics I have decided to create a three part series about LoginVSI of which this is part 1. The second part will cover how to actually start or launch a test and the third part will be how to analyze your results.

This is a highly customizable tool that will give you tons of insight into your environment and can quickly help you to understand where your bottle necks are, whether that is memory, CPU or IOPS at the host level or if the issue is the VDT (virtual desktop) itself.

Some of the things that will happen during the testing are (if using the built-in profiles): users opening websites, watching videos, reading PDFs, editing, saving and printing documents, reading and sending emails, user down time while “talking to co-workers about football” (American football that is, not the real football ). Access to the internet is not required as the tool uses a shared folder to simulate the

My test even helped me to identify issues with applications like Microsoft Office that was constantly crashing during the test, so I was able to identify the issue, install the hotfix and prevent an issue that my users could have ran into. You should always use this tool before rolling a new VDT image into production, especially if new applications or patches have been installed.

On this article you will find the description of the environment components and its roles as well as my sizing suggestion based on tests that I did with the tool. This test was done for a Citrix XenDesktop environment but the design below should work in a Horizon/View or RDS environment.

There are four main components

• DataServer: this is the brains of the solution and can be a Windows 2008 or Windows 2012, I tested with a Windows 2012.
  • The File server role must be installed as you will need to create a shared folder for the other components, this shared folder will host executable for the launchers and the test results
  • The LoginVSI licensing file is also hosted on this server
  • The Management and Configuration console will run on this server
  • The Session Monitor console will also run on this server while you are executing the test. This console is in charge of monitoring the status of the connections to XenDesktop or your preferred VDI solution.
  • This server will need access to your directory services (AD) to create the accounts and OUs necessary to run the solution, If you don’t have an account with access to create new AD accounts or OUs, you can generate a PowerShell script to be handed over your AD administration team
• Launcher: this is can be a workstation running Windows 7/8 or Windows Server 2008/2012, you will need multiple launchers depending on how much resources  (CPU and RAM) each launcher has.
  • It needs access to the shared folder hosted on the DataServer
  • It needs to have the correct client to access your VDI environment, i.e Citrix Receiver, Microsoft RDP or VMWare PCoIP
• VDI environment: as mentioned before it can be any of the major industry players, for this post we are using XenDesktop 7.5. The environment has
  • Web Interface .5.4
  • XenDesktop Controller/Director 7.5
  • Provisioning Server 7.1
  • XenServer 6.2
• Active Directory: when LoginVSI is configured a set of Group Policies, user accounts, OUs and groups are created automatically or via a PowerShell script that are necessary to run the test.
  • If trying to use the automatic configuration the account that you are running the Management console must have rights to create AD elements on the test OU
  • The PowerShell script can be edited to add things like home folders and any other default configurations your environment requires
  • It is very important that the test accounts that you are creating have a similar configuration as a production user to have more accurate results, especially if there are other GPOs in effect in your test environment.
  • If you are using folder redirection to a home drive on your network and the test account doesn’t have that created it is very possible that the test will fail, at least it did for me because the tests will create files, read emails, read PDF, etc.

Components Sizing

• DataServer: this server requires storage more than anything else and you could use some other file server in your environment, in my case I collocated this server with my PVS server

  • CPU: 4vCPU if using a virtual server, if using physical any newer server will work great
  • RAM: just for the LoginVSI functions you are not going to need more that 2GB of RAM.
  • Storage: minimum 2GB of space but it will depend on how many tests you are going to do and whether or not you are going to keep all those test’s results. I would recommend 10GB to be safe
• Launcher: this is where most of the work happens, it launches your ICA sessions to your VDTs, so it will act like your end users workstation, tablet or thin client. In our test we used a Windows 2012 virtual server running on XenServer 6.2
  • LoginVSI suggests to use 2vCPUs and 4GB of RAM launcher to run 50 sessions but during our testing we could only get about 30 sessions before we got 100% utilization on CPU and once we got 36 session then memory reached 100% memory, as shown on the chart below. At which point the launcher was crawling and never opened the last 14 sessions
  • If you want to run 50 sessions per launcher my recommendation is to go to 4vCPUs and 6GB of RAM. The vCPU utilization was still higher than the RAM but we got 50 sessions consistently

LoginVSI Installation

As mentioned before this is the main server and should login to the server with an account that has local administrator rights and hopefully enough rights to AD to create OUs, GPOs, user accounts and groups.

1. Login to the DataServer also know as management server
2. Download LoginVSI installation media, click on this link
3. Create a shared folder on this server where you will install necessary files for the launchers and VDTs. I called mine “LoginVSI”, not very creative but very descriptive
4. Double click the Setup file
5. Click Next on the welcome screen
6. Point the installation folder to the recently created shared folder and click Next, this is also known as the VSIshare.
7. The installation will start to create the “VSIshare”
8. At the end of the installation the LoginVSI Management Console will automatically open. Specify the shared folder where you installed LoginVSI and the folder where you have the licensing file              
9. The main screen will open so you can start the configuration.Lets start by clicking on the Infrastructure link to configure the AD connection.
10. The first configuration step is to execute the “AD Setup”, where you will specify the OU base location where the new groups and users will be created.
11. Since I have multiple domain controllers and I wanted to control which domain controller was being used (improving speed) I decided to generate the powershell script instead of running it from the console
    • I basically added the –server parameter to all the cmdlets. Please see the example below:New-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $false -name “LoginVSI” -path “$baseOU” -server “FQDN.server”
12. Once you have run the AD powershell script, I recommend you update the Shared folder where LoginVSI was installed to grant R/W access to the LoginVSI group at the shared and NTFS Level
13. Now lets “Add launchers”; at this point you haven’t install anything on you launcher and you don’t have to, great feature of LoginVSI, you just need to “declare” who your launchers are going to be. Click on Add launcher
14. You can enter each launcher manually (single entry) or load a bunch of launchers at once (batch entry). I only had two launchers so I selected Single Entry and click Next
15. Specify the FQDN server name and how many sessions you plan to run on it, this is important since you can have different launcher sizes
16. Configure the Workload. An workload is the specification of what test profile you want to use. Since my users are not that unique I decided to go with the prebuilt “Medium Load”,which I find to be pretty good to what my normal users do.
    • Select the version and language for Microsoft Office
17. Configure Connection: this is how the launcher is going to connect to the VDT or published application. Through the connection wizard you can point the configuration to your Web Interface server and a list of possible desktops will be shown. You will also configure the credentials the launchers will use to connect to the VDTs. A very important feature is that you can use wildcard values

Congratulations you are now ready to start to start a test and then review the results. Another good source of information for the installation is this video and this wiki page put together for the LoginVSI folks. There are a few more steps for those two process that you can find as part 2 – Starting a LoginVSI test and part 3 – Analyzing LoginVSI results.