The "Big Iron Test"

Posted by Benny Tritsch on November 25, 2004 – updated on January 31, 2005

[Introduction] [Test Setup] [Testing Methodology] [Analysis 1] [Analysis 2] [Analysis 3]

Test Setup

The test was performed at the Fujitsu Siemens Computers Laboratories in Augsburg, Germany. We used specific test scripts and tools, which will be described below. A tool for creating the test user accounts, Console User Manager, was provided by Microsoft Consulting Services. The test laboratory used Fujitsu Siemens Computers servers.

Test Environment

The Terminal Services testing laboratory provided a simple setup using two types of servers:

• 1 Fujitsu Siemens Computers Primergy T850 Enterprise Server; 8 x Intel XEON 1.6 GHz CPUs, 1 megabyte second-level cache, 8 gigabytes of memory.
• 20 Fujitsu Siemens Computers BX300 Blade Servers used as client; 2 x Intel 966 MHz CPUs, 2 gigabytes of memory.

The Primergy T850 Enterprise Server was booted with the /PEA boot.ini switch in order to be able to access the complete memory. Windows 2000 Advanced Server, Windows 2000 Datacenter Server, Windows Server 2003, Enterprise Edition, and Windows Server 2003, Datacenter Edition, can use /PAE to take advantage of physical memory beyond 4 gigabytes.

Other switches should not be used. Using the /3GB (for Windows 2000) or the /4GT (for Windows 2003) boot.ini switches is inappropriate for Terminal Server environments because those switches change the partition between the application memory space and kernel memory space. These switches gives each application 3 gigabytes of memory, which in turn only leaves 1 gigabyte for the kernel - a disaster in Terminal Server environments. I doubt that an individual application will consume 3 gigabytes of memory on a Terminal Server very often. On large Terminal Servers, it only matters if an application is able to access physical memory space beyond 4 gigabytes - and this is exactly what the /PEA boot.ini switch provides.

NOTE: If you want to know more about the /PEA boot.ini switch, see the following articles:

• Brian Madden: The 4GB Windows Memory Limit: What does it really mean?
• Microsoft: Large memory support is available in Windows 2000 and Windows Server 2003
• Microsoft: Scaling Out Versus Scaling Up with Intel Physical Addressing Extensions (PAE)
• Microsoft: RAM, Virtual Memory, Pagefile and all that stuff

Additional components of the test laboratory included a Gigabit Ethernet infrastructure.

Testing Tools and Scripts

To assist with testing, some testing scripts used on the client computers had to be developed.

Before the start of the tests, 150 user accounts had to be created. This was accomplished using two scripts and a command line tool.

 

Echo Create 150 user accounts >>User150.log time /T >> user150.log Date /T >> user150.log call nuser.cmd FSC1 "FSC1 User" x call nuser.cmd FSC2 "FSC2 User" x call nuser.cmd FSC3 "FSC3 User" x ... call nuser.cmd FSC148 "FSC148 User" x call nuser.cmd FSC149 "FSC149 User" x call nuser.cmd FSC150 "FSC150 User" x Echo Finished the creation of 150 user accounts >> user150.log time /T >> user150.log Date /T >> user150.log

Listing 1: Script User150.cmd, which creates 150 user accounts by using the secondary script Nuser.cmd.

 

The secondary script, Nuser.cmd, was used to create the individual user accounts, add them to the Remote Desktop Users group and set some required user's attributes.

 

call net user %1 /ADD call net group "Remote Desktop Users" %1 /add call cusrmgr.exe -u %1 -f %2 -P %3 -s PasswordNeverExpires

Listing 2: Script Nuser.cmd

 

Changing the users' attributes requires the usage of a command line tool that was provided by Microsoft Consulting Services. In the following, the options of the Console User Manager are displayed.

 

CUsrMgr Ver 1.0 Jan98 by G.Zanzen (c) MCS Central Europe Sets a random password to a user usage: -u UserName [-m \\MachineName] \\ default LocalMachine   Resetting Password Function     -p Set to a random password     -P xxx Sets password to xxx   User Functions     -r xxx Renames user to xxx     -d xxx deletes user xxx   Group Functions     -rlg xxx yyy Renames local group xxx to yyy     -rgg xxx yyy Renames global group xxx to yyy     -alg xxx Add user (-u UserName) to local group xxx     -agg xxx Add user (-u UserName) to global group xxx     -dlg xxx deletes user (-u UserName) from local group xxx     -dgg xxx deletes user (-u UserName) from global group xxx   SetProperties Functions     -c xxx sets Comment to xxx     -f xxx sets Full Name to xxx     -U xxx sets UserProfile to xxx     -n xxx sets LogonScript to xxx     -h xxx sets HomeDir to xxx     -H xxx sets HomeDirDrive to xxx     +s xxx sets property xxx     -s xxx resets property xxx     where xxx can be any of the following properties:       MustChangePassword       CanNotChangePassword       PasswordNeverExpires       AccountDisabled       AccountLockout       RASUser returns 0 on success

Listing 3: CUsrMgr by MCS Central Europe

 

Installing the Applications and Providing Documents

The following applications were installed on the Terminal Server:

• Microsoft Office 2000. For the test installation, the termsrvr.mst transformation file from the Office 2000 Resource Kit was used.
• Adobe Acrobat Reader 6

During the test three applications were launched using the following documents.

• Notepad.exe – Terminalservices.txt: ANSI text file; 3,140 bytes
• Acrobat Reader – PAG3.pdf: Adobe Acrobat document; 8,399,585 bytes
• Microsoft Word – FSCDemo.doc: Microsoft Word document; 2,388,992 bytes

Creating the User Sessions

The following script was used to create user-specific RDP files. These RDP files were used to launch the individual user sessions.

 

@echo off if "%1"=="" goto error set rdpusername=fsc echo screen mode id:i:1 > %rdpusername%%1.rdp echo desktopwidth:i:800 >> %rdpusername%%1.rdp echo desktopheight:i:600 >> %rdpusername%%1.rdp echo session bpp:i:16 >> %rdpusername%%1.rdp echo winposstr:s:2,3,0,0,800,600 >> %rdpusername%%1.rdp echo full address:s:p-t850-a >> %rdpusername%%1.rdp echo compression:i:1 >> %rdpusername%%1.rdp echo keyboardhook:i:2 >> %rdpusername%%1.rdp echo audiomode:i:0 >> %rdpusername%%1.rdp echo redirectdrives:i:0 >> %rdpusername%%1.rdp echo redirectprinters:i:0 >> %rdpusername%%1.rdp echo redirectcomports:i:0 >> %rdpusername%%1.rdp echo redirectsmartcards:i:0 >> %rdpusername%%1.rdp echo displayconnectionbar:i:1 >> %rdpusername%%1.rdp echo autoreconnection enabled:i:1 >> %rdpusername%%1.rdp echo username:s:fsc%1>> %rdpusername%%1.rdp echo domain:s:p-t850-a >> %rdpusername%%1.rdp echo alternate shell:s: >> %rdpusername%%1.rdp echo shell working directory:s: >> %rdpusername%%1.rdp echo disable wallpaper:i:1 >> %rdpusername%%1.rdp echo disable full window drag:i:1 >> %rdpusername%%1.rdp echo disable menu anims:i:1 >> %rdpusername%%1.rdp echo disable themes:i:1 >> %rdpusername%%1.rdp echo disable cursor setting:i:0 >> %rdpusername%%1.rdp echo bitmapcachepersistenable:i:1 >> %rdpusername%%1.rdp start /B "%programfiles%\remote desktop\mstsc.exe" %rdpusername%%1.rdp goto success :error echo Error: Parameter is missing goto end :success echo Success goto end :end

Listing 4: The script Cr.cmd to create a new session. It requires a unique session number as parameter.

 

Executing the script Cr.cmd with the parameter “1” created the following RDP file and launched the appropriate session:

 

screen mode id:i:1 desktopwidth:i:800 desktopheight:i:600 session bpp:i:16 winposstr:s:2,3,0,0,800,600 full address:s:p-t850-a compression:i:1 keyboardhook:i:2 audiomode:i:0 redirectdrives:i:0 redirectprinters:i:0 redirectcomports:i:0 redirectsmartcards:i:0 displayconnectionbar:i:1 autoreconnection enabled:i:1 username:s:fsc1 domain:s:p-t850-a alternate shell:s: shell working directory:s: disable wallpaper:i:1 disable full window drag:i:1 disable menu anims:i:1 disable themes:i:1 disable cursor setting:i:0 bitmapcachepersistenable:i:1

Listing 5: Resulting RDP configuration for user “fsc1”

 

Creating the User Profiles

It is not possible to open the same physical document file from multiple user sessions. Consequently, it was necessary to provide individual document files for all users. For this purpose, individual user profiles were used, which allowed the required documents to be copied to each user's desktop and to launch its associated application.

Creating the user profiles automatically without using a domain controller was the next challenge. To accomplish this, we created the folder %Systemroot% \System32 \Repl \Imports \scripts on the Terminal Server. We then copied the login file Logon.cmd into this folder and created a share with the name netlogon. This was the standard login share. The login script looked as follows:

 

@echo off if not exist "%userprofile%\Desktop\Terminalserverices.txt"   copy c:\Documents\Terminalservices.txt "%userprofile%\Desktop" if not exist "%userprofile%\Desktop\PAG3.pdf"   copy c:\Documents\PAG3.pdf "%userprofile%\Desktop" if not exist "%userprofile%\Desktop\FSCDemo.doc"   copy c:\Documents\FSCDemo.doc "%userprofile%\Desktop" echo Document files copied sleep 10 start /B notepad.exe "%userprofile%\Desktop\Terminalservices.txt" echo Tried to launch Notepad with Terminalservices.txt (4 KB) sleep 10 start /B "C:\Program Files\Adobe\Acrobat 6.0\Reader\AcroRd32.exe" "%userprofile%\Desktop\PAG3.pdf" echo Tried to launch Acrobat Reader with PAG3.pdf (8.2 MB) sleep 10 start /B "C:\Program Files\Microsoft Office\Office\WinWord.exe" "%userprofile%\Desktop\FSCDemo.doc" echo Tried to launch Microsoft Word with FSCDemo.doc (2.3 MB) pause

Listing 6: The login script Logon.cmd

Conclusion

This chapter describes in detail how the testing was done and how automation script were used. Each client platform was used to host 10 users in their individual session created by the Cr.cmd script. Client #1 executed "Cr 1", "Cr 2", ... , "Cr 10" commands, client #2 executed "Cr 11", "Cr 12", ... , "Cr 20", and so on. The commands were executed manually from the client's command shell, each user's password "x" was entered manually during the login phase of each session. This partially manual workflow allowed a good way to adapt to the resulting load behavior on the Terminal Server.

 

Next