2. Configure Active Directory with the AD Deployment Routine.
3. Manually configure a File Share for logging.
4. Prepare the Launcher workstation(s).
5. Unpack the Login VSI archive
Unpack the Login VSI archive file on the launcher workstation. The archive contains:
Setup-AD: Active directory preparation
Setup-Target: Prepare target workstation or server
Setup-Launcher: Install launcher software
Setup-Analyzer: Install analyzer software
Configure Active Directory with the AD Deployment setup
1. Active Directory Configuration
The AD Deployment setup will prepare the Active Directory for use with Login VSI. A new root OU is created, test users are created and GPO’s are imported and linked. Ensure the domain controller is performing accordingly. Login VSI has a minimal load, but you want to prevent the domain controller or you active directory becomes a bottleneck. The AD Deployment 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. To ensure AD is configured for use with Login VSI, please use the supplied AD Setup. The AD Deployment script can be found in the folder: “AD Setup”. In the PRO version of VSI the installation of the active directory component is optional, you can also provide your own / already existing users to Login VSI to work with. When not using the VSI Active directory configuration or moving the machines to a non-VSI OU please keep in mind that the Login VSI policy will not be applied, the policy object installed by Login VSI will make sure workloads can run smooth by disabling unnecessary popups etc.
This video contains audio
2. Configure VSIShare
To store the results gathered by Login VSI a file share in the network is needed. Create a file share with the following permissions when running a default Login VSI installation. Default groups inherited within your domain do not need to be removed as long as they don’t conflict with specified settings below.
Share security:
Group Login_VSI_TS – Modify
Group Administrators – Modify
NTFS security:
Group Login_VSI_TS – Modify
Group Administrators – Modify
Preferably disable or exclude virus protection, a lot of read/write occur in this share. Ensure there is no other load on the file server while conducting the tests; this could negatively impact the results.
This video contains audio
3. Target Deployment
The Target Deployment script will prepare the test machine with the necessary software, registry settings and the benchmarking user action runtimes. First you need to configure and prepare your target platform. Logically, you need to ensure you setup the required infrastructure components for the tested platform (such as licensing and connection broker).
3.1. Preparing the target platform
On your target platform (or you prepare an image) install:
A clean and default installation of Windows (XP/ Vista /7/2003/2008/Win7/2008R2) with the latest service pack. An English version of the OS is required for the express version of Login VSI; other languages should work but have not been extensively tested.
Only install drivers that are truly required. It is not recommended to install management/security software if you do not intend to analyze their specific performance impact.
Install a default installation of Microsoft Office (English), other languages are only supported in Login VSI PRO. Note: Added September2009) Service pack 1 for Office 2007 seems to have a considerable performance overhead caused by a bug in Outlook. It is therefore recommended to install SP2, instead of SP1; OF we suggest you to use Office 2007 without service packs or Office 2007 with SP2. The latest service pack resolves the Outlook bug.
Install the latest Microsoft hot fixes from Microsoft Update.
Citrix/Terminal only:
Enable Terminal Services.
VDI specific:
Install client/agent software.
Do not forget to perform additional system tuning recommended by the vendor.
Execute the “create profiles” run to pre-configure the local or roaming profiles required for the test runs.
The creation of a new windows user profile when a test user first logs on will create a measurable (10-15%) overhead. Therefore, it is important to pre-create the profiles on the images of the target system image or as roaming profiles to ensure you have valid results with every single benchmark you perform.
The Login VSI target deployment will install and configure:
This video contains captions (subtitles)
The Login VSI runtimes (will be automatically installed in %programfiles%\login consultants\Login_VSI) and configuration
Adobe Acrobat Reader 9.1
Adobe Flash Player 10
Adobe Shockwave Player 10
Bullzip PDF Printer
Freemind
Kid-Keylock
Essential Tuning Parameters
3.2. Automatic configuration reporting:
During the target deployment the system specifications will be gathered by a tool called “WinAudit”. In the earlier defined Login VSI share a folder called “Reports” will be automatically created. This folder contains the report based on the hostname and a random number. The random number is to ensure reports are not overwritten when running the WinAudit.cmd again on the same host. To re-run the automatic configuration reporting manually, run the Winaudit.cmd from the “Reports” folder.
3.3. Tuning by Login VSI on target sytem
To prevent test runs are negatively affected by not using obvious configuration best practices the Target Deployment script will automatically setup and configure the page file size and “last access time stamp on NTFS” within Windows:
The page file should be configured with a fixed size depending on the amount of memory. This means as the load increases, the page does not need to be grown by the system which normally introduces a considerable overhead. For SBC environments it is recommended to set the page file twice the size of the internal memory. Always reconfigure the page file manually if you change the memory of the target system later on. As a general best practice we also disable last access time stamp on a NTFS level by setting the NtfsDisableLastAccessUpdate to Dword:1 in HKEY_LOCAL_MACHINE -> SYSTEM -> CurrentControlSet -> Control -> FileSystem. This reduces overhead on a file system level.
4. Install the launcher workstation(s)
The launcher can be run from a 32bit & 64bit windows system. Important: in addition to the launcher you need to install the client software:
When testing Terminal Services, the Microsoft Terminal Services Client must be installed. Both RDP 5 and 6 are supported.
When testing XenApp or XenDesktop, the Citrix ICA client must be installed in the default location. (Program Files\Citrix\ICA Client).
When testing VMWare View the WSWC client must be installed.
4.1. GDI Limit
There is a theoretical limit of 65,536 GDI handles per session. However, the maximum number of GDI handles that can be opened per session is usually lower, since it is affected by available memory. GDI objects support only one handle per object. Handles to GDI objects are private to a process. That is, only the process that created the GDI object can use the object handle. There is also a default per-process limit of GDI handles. To change this limit, set the following registry value: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\GDIProcessHandleQuota This value can be set to a number between 256 and 65,536. More information can be found here.
4.2. Launcher Sizing
The amount of sessions you can run on a workstation with RDP/ICA is limited to system recourses. Especially memory and CPU (single core) can be a limiting factor which will be reflected in the results. A safe method to calculate how many sessions you can start from one workstation/server is: RECOMMENDED: Use a maximum of 45 sessions per machine with 2 Cores (or 2 dedicated vCPU¡¦s) & 2GB RAM, when the GDI limit not has been tuned (default).
When the GDI limit has been tuned, calculate 30 sessions per CPU core (Intel core2 duo or AMD equivalent );
Subtract 256Mb from total memory which is already consumed by the operating system. Divide the remaining total memory by 15Mb per session (on 32bit platforms).
When using the multimedia workload, do not exceed more than 20 sessions per launcher. The multimedia workloads will put a considerably higher load on launcher clients.
It is not recommended to start more than 45 sessions per launcher workstation. If you need to launch more sessions run additional launcher workstations when the first launcher is finished.
This video contains captions (subtitles)
5. Install the Analyzer
The steps below describe how-to install the analyzer component of Login VSI. The analyzer converts the response time measurements taken by Login VSI into clear graphs and automatically calculates the VSIMax.
This video contains audio
This video contains captions (subtitles)