Microsoft

Microsoft Client Server Validation Test

 

Draft — Version 0.4 — November 11th 1999

This document describes the test plan for the Client Server Validation Test, including the hardware and software requirements to run this test.

 

Contents

 

Introduction....................................................................................................................................................................... 3

Definitions................................................................................................................................................................... 3

Obtaining a HCT kit CD............................................................................................................................................. 3

Checking the Server HCL on the Web.................................................................................................................... 3

Systems Requirements and Configurations................................................................................................................. 3

Server Requirements for Client Server Validation................................................................................................. 4

Datacenter Server Requirements for Client Server Validation............................................................................. 4

Network requirements for running tests................................................................................................................. 5

Client Requirements for running tests.................................................................................................................... 5

Setup Instructions for Validation Testing.................................................................................................................... 6

Client Server Tests........................................................................................................................................................... 6

Setting up and running the Client Server Tests.................................................................................................... 7

Interpreting the log.................................................................................................................................................... 8

File I/O Testing Using an SMB Share..................................................................................................................... 9

IIS Testing................................................................................................................................................................. 11

What to do if tests fail, but you think it is a test bug?....................................................................................... 13

How to Return Log results...................................................................................................................................... 14

 

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

This documentation is an early release of the final product documentation. It is meant to accompany software that is still in development. Some of the information in this documentation may be inaccurate or may not be an accurate representation of the functionality of the final retail product. Microsoft assumes no responsibility for any damages that might occur either directly or indirectly from these inaccuracies.

Microsoft Corporation may have patents or pending patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. The furnishing of this document does not give you any license to the patents, trademarks, copyrights, or other intellectual property rights except as expressly provided in any written license agreement from Microsoft Corporation.

Microsoft does not make any representation or warranty regarding specifications in this document or any product or item developed based on these specifications. Microsoft disclaims all express and implied warranties, including but not limited to the implied warranties or merchantability, fitness for a particular purpose, and freedom from infringement. Without limiting the generality of the foregoing, Microsoft does not make any warranty of any kind that any item developed based on these specifications, or any portion of a specification, will not infringe any copyright, patent, trade secret, or other intellectual property right of any person or entity in any country. It is your responsibility to seek licenses for such intellectual property rights where appropriate. Microsoft shall not be liable for any damages arising out of or in connection with the use of these specifications, including liability for lost profit, business interruption, or any other damages whatsoever. Some states do not allow the exclusion or limitation of liability or consequential or incidental damages; the above limitation may not apply to you.

ActiveMovie, ActiveX, BackOffice, Developer Studio, Direct3D, DirectDraw, DirectInput, DirectPlay, DirectSound, DirectVideo, DirectX, Microsoft, NetMeeting, NetShow, Visual Basic, Win32, Windows, and Windows NT are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries. Other product and company names mentioned herein may be the trademarks of their respective owners.

© 1999 Microsoft Corporation. All rights reserved.

Introduction

This test kit in intended for use on Windows 2000 Server RC 3 and Windows NT 4.0 Server with Service Pack 6 or later. 

This document is the test plan for Server system validation. It describes the hardware and software requirements for the validation process. The intended audience is people who are involved in validation of Server systems and also IHVs who wish to have systems validated. This document does not go into great detail about each specific test. Microsoft has other documents for each test that give specific testing criteria and methodology.  This document is in draft form and the contents of this document are subject to change. Please refer to the most recent HCT CD for the latest Client-Server  Validation Test documentation.

This test plan is not meant for server system device testing.

Definitions

The following terms are used throughout this document.

HCL: Hardware Compatibility List. The list of hardware components that are validated for the Microsoft® Windows NT, Windows® 95, Windows 98, or Windows 2000 operating systems.

HCT: Hardware Compatibility Tests. The set of tests that are run to perform validation of hardware that will be added to the HCL. An HCT kit is available from Microsoft, as described in the following section.

HW RAID: A RAID that is done with no knowledge of the operating system. As far as Windows NT knows, these RAID sets appear to be a normal physical disk and the RAID operations are all done in hardware.

SW RAID: This is what is meant when using the Windows NT Server Ftdisk driver or Windows 2000 “dynamic disks” to take several physical disks and make one logical fault-tolerant (FT) volume out of them.

WHQL: Windows Hardware Quality Labs. The Microsoft lab that performs the component validation testing for components that must be submitted to Microsoft.

Obtaining a HCT kit CD

Visit http://www.microsoft.com/hwtest/hctcd to order an HCT CD.  The HCT CD contains the Client Server Validation Test along with other device and system Self-Tests.

Checking the Server HCL on the Web

Visit the site at:

http://www.microsoft.com/hcl

Systems Requirements and Configurations

This section presents the system configuration criteria for a Server test system. Note that all components in this system must be validated to run on Windows NT 4.0 or Windows 2000. Components that are not on the HCL must pass HCT tests prior to running Client Server Validation testing.   This is because Client Server Validation testing is designed to test server requirements, not general Windows NT/2000 requirements.

Server Requirements for Client Server Validation

The server must have:

·         128-MB minimum system memory

·         Two additional disk drives separate from the system installation disk.  These drives will be used for testing and must have at least 300 MB of free space.

·         Network card to connect to clients and client master.  This network should be 100 Mbits.

·         250 MB of free space on the system installation drive.

 

Datacenter Server Requirements for Client Server Validation

A Datacenter server must have:

·         256-MB minimum system memory

·         Four additional disk drives separated from the installation disk.  These disk drives will be used for testing and must be on a separate disk bus then the system installation disk.  These test drives must have must at least 300 MB of free space.

·         Two network cards setup as separate segmented networks for connecting to the client systems.  Half of the clients on each network.   The client master must be connected to both networks, meaning the client master must have two network cards in this configuration. These networks should be 100 Mbits.

·         250 MB free hard disk space on system installation drive

 

In addition to the server the Client Server Validation Test requires:

·         At least eight client machines.

·         One client monitoring system (ie client master) that can connect to the server and all eight clients through the TCP/IP network.  The client master, must have Windows NT Server version 4.0 Service Pack 6 or higher or Windows 2000 Server installed.

Each client and the client master must have:

·         64-MB minimum system memory

·         Network card to connect to the server.  This network should be 100 Mbits.

·         250 MB free hard disk space on system installation drive

 

·         Figure 1. Standard Server Test configuration

Network requirements for running tests


The test will generate a lot of network traffic doing client-server type of IO.  We recommend that all of the client machines and server system be on a private network.  The client master system may be setup as a domain controller.

The client systems, client master system, and the server must all be a member of this same domain.  We typically have our lab setup to have all machines logged on as the same domain account, which has administrator rights on each system.

The server will experience very high stress loads with file I/O, IIS queries, FTP queries and socket queries.  This is by design and is done to simulate real world customer usage of high-end server configurations.  The network stress loads however are probably higher than what any customer would normally utilize.  We recommend that all testing be done on a private network.

Client Requirements for running tests

The client machines will be used to simulate client-server stress against the server. The eight required client systems cannot be used to test more than one server at a time.  For each server system that you want to test in parallel, you must have a different set of client machines. These clients must meet the following hardware and software requirements:

·         Each client must be on the Windows NT/2000 HCL list.

·         Each client should have at least 64 MB of memory

·         Each client should have 250 MB free space on the installation disk

·         Each client should be at least a Pentium equivalent or better machine. Microsoft recommends a client mix as close to your typical customers’ use as possible. Microsoft uses six 64-MB Pentium machines, and two high-end workstations. Each client must use a network card that is listed on the HCL.

·         Each client must be able to communicate with the server over TCP/IP.

·         The clients must be in the same domain as the server.

·         Each client must have Windows NT 4.0 Workstation (SP6 or greater) installed to test a Windows NT 4.0 Server (SP6 or greater), or Windows 2000 Professional installed to test a Windows 2000 Server.

 

An additional client monitoring system (ie client master) will also be needed. This client master should be separate from the clients used for client-server stress testing.  It has the same hardware requirements as other client machines, but serves as a launch platform and monitoring station for the tests. It should be running Windows NT 4.0 Server (SP6 or greater) or Windows 2000 Server.  This system is used to:

·         Provide a share point to start up the client tests on the other nodes.

·         Initiate the client-server tests, monitor the test status, shutdown the client-server tests and summarize the results.

·         Serve as the kernel debugger for the server. This requires one free serial port for each server to set up the kernel debugger. Please see documentation in the Windows 2000 device driver kit (DDK) for setting up a kernel debugger.

Setup Instructions for Validation Testing

This section summarizes setup for both the hardware and software.

Before running the Client Server Validation Test:

1.        Set up the hardware as shown in Figure 1 earlier in this document.

2.        Install Windows 2000 Server or Windows NT 4.0 Server and the latest service pack on the server system.

3.        Install FTP service (Windows 2000 only)

4.        Install Windows 2000 Server or Windows NT 4.0 Server and the latest service pack on the client master.

5.        Install Windows 2000 Professional or Windows NT 4.0 Workstation and the latest service pack on the eight client systems.

6.        Run the Client Server Validation test (Server Test) from the client master system.

Client Server Tests

The client-server tests can be broken down in the following type of tests:

 

1.        File IO using a SMB share

2.        IIS tests

3.        Winsock test

4.        Tapi test

 

These tests are designed to stress the most common server services that users will run on a high-end server system.  All of these tests will log their results to a log file.  The tests should be run for the period of 24 hours after which time the tests will shutdown.  The log files will then be examined and summarized into one log file on the client master. This ‘summary’ log will later be used for submitting the results to WHQL. If the test kit fails the individual log files on the client and server systems can also be examined in detail to determine the specific reasons for failure during the test run.

 

All of the client-server tests will be run concurrently on each client node.  The client tests will use the servers name or one of the associated IP addresses to access the server services.  A GUI interface (valdclus.exe) will setup and configure the server as well as the client systems for the tests.

 

Setting up and running the Client Server Tests

 

Installing test components for FTP

The FTP service is not installed by default on Windows 2000 Server. To Install it go to Start -> Settings -> Control Panel from the task bar.  Double click on Add/Remove Programs.  Click on Add/Remove Windows Components button. Under the Windows Components Wizard highlight the Internet Information Services(IIS) list item and click on the Details button.  Select the list item check box for File Transfer Protocol(FTP) Server.  Click on the OK button.  Follow the directions for the rest of the prompts.

 

Step by Step Instructions to start the Client Server Validation Test.

 

1.        On the client-master insert the HCT CD.  Start the Test Launcher by running hwtest.exe.  This will lead you though several prompts asking for information about your hardware.  For the most part this information is redundant since the actual system you’re testing is the server, however you must answer these questions before it will start the Test Manager.  You should only have to answer these questions once.

2.        The Microsoft Windows Hardware Compatibility Test Window appears giving the user 2 options.

1.        System, Server, NIC, Storage, Audio, Modem Tests and

2.        Other Device Kits

The user must select option number one.

3.        Files are copied from the HCT CD to the Test System.

4.        When the MS HCT (Win32) popup appears for setup, the user must hit enter to continue.  The popup makes reference how this setup will configure the system for the user and run the tests thereby require a reboot.

5.        A popup prompting user to reboot appears, select yes to continue.

6.        Reboot occurs and the user is prompted to logon back into the system.

7.        The first dialog for the Test Manager will contain optional locations for the HCT update directory as well as the source and destination of the test binaries.  By default these will be set to the CD as the source and the C:\hct directory as the destination.   Verify these locations and then press the OK button.

8.        A tester type window appears, whereby prompting the user to select the hardware that they are testing for submission.  Considering this install is occurring on the client master server, the user must scroll down and select, “Server Testing – Client Master Setup for the Server Test.”  If this were this was the OEM Test Server, the user should select, “Server Testing SDG 2.0 (Server Design Guide). 

9.        Gas gauge that scans the system for devices occurs.

10.     Identification Window appears prompting user for machine ID and Product Name.  The user hits enter to continue.

11.     System Configuration Window appears prompting user to complete the entry of system information of the following categories prior to continuation.  These categories include;

1.        System

2.        Processor

3.        Video

4.        I/O

5.        Network

6.        Multimedia

12.     After a short while, another window titled:  “TestManager” should popup and it should display two tree windows titled “Available Tests” and “Selected Tests”. Click on plus box for Server in “Available Tests” Window.

13.     Select “ServerTests” under the “Server Tests” subtree in the “Available Tests” tree.

14.     Click on the Add button.

15.     Click on the Start button.  This should start the “Validation Tests” process.

16.     Type in the server’s name into the ‘Server Name:’ editbox.  If you make a mistake simply type over the name. 

17.     (Optional) Click on the Verify button.  This will attempt to connect with the server and query information about the system.  The server name should show up in the list box.

18.     Type in each client name and add the name to the list by using the Add button.  If you make a mistake select the client name you wish to remove and click on the Del button.  The number of entered client names is displayed immediately to the right in the ‘Num Clients:’ field.

19.     (Optional) The ‘Min Clients:’ field can be edited to match the ‘Num Clients:’ field.  This is so the test can be run with fewer clients.  Please note that a validation run for submission must have at least eight clients.

20.     (Optional) The length of a test run can also be configured by editing the  ‘Run Test(hrs):’ field.  Please note that a validation run for submission, must be at least 24 hours long.

21.     (Optional) Individual client tests can be removed from a test run.  To do this click on the ‘Configure’ tab.  You may be prompted as mentioned below in step 15 for account/password info.  This is so it can query the clients and configure the default parameters for each of the tests.  Once it has completed configuring the default parameters it will display a ‘Tests’ list view.  At this point you can the check boxes to select/deselect individual tests.

22.     (Optional) Parameter combinations of a particular test can also be removed.  Select the test name in the left hand pane by clicking on the name.  In the right hand pane is a list view with the parameter combinations the test will be run under.  Select the row you wish to delete and click on the ‘Del’ button.  Clicking on the Scan button will re-compute the parameters for all of the tests.

22.     (Optional) On the Connect tab, the 'Max Res Grps' field defaults to 8. A resource group is a unique combination of resources useful for a test. The Client-Server test uses network and disk resources. If there is one NIC and one 2 disks, there are 2 resource groups. If there are 2 NICs and 2 disks, there are 4 resource groups. Note that a resource group is not necessarily the same as a cluster group. If you are testing with more than 8 clients, you may want to reset this number to the number of clients you will test with. For HCT testing, leave this field at 8.

23.     Click on the Start button

24.     At this point a dialog titled “Specify Account Password” will appear.  Enter the account and password for the domain account with administrative privileges on each of the test systems.  This will allow a special monitoring service (qserv) to be installed and run in the desired security context.  If the password/account information entered is incorrect there should be a dialog indicating this, when this happens return to step 14.

 

After step 14, the client master will install qserv and other needed test services and files onto the server system.  It then will proceed to do the same for each client in the client list.  When step 15 completes the tests will then be started on each of the clients, on the server node and then finally on the local system (i.e. client master).  When that is completed the valdclus process will switch to the ‘Status’ tab and start the clock.  The tests will then run for 24 hours.  After that period the tests will automatically stop and the run results will be summarized into a log file.  The summary log is reported to the test manager. 

 

The client tests are designed to constantly access the server and put stress on the network.  In addition local tests will be configure to run on the server to directly stress the disk bus.  These tests are designed to simulate what will happen in a real high-end server environment when you have 100s of clients accessing the server system under load. We currently have 5 different client/server tests and more will be added in the future.  So at least 10 test instances will be started against the server from each client system.

 

Clicking the ‘Abort’ button will stop any running tests, and initiate the cleanup code.  The clean up code will attempt to stop all the test process, removed the test services and return the summary log to the test manager.  Closing the window will also initiate the abort process.

Interpreting the log

 

When the Server Tests exit a summary log (srvtsts.log) should be generated.   If all of the tests started successfully the first part of the log will be a listing of the machines involved.  It should look something like this:

 

****

 +VAR+INFO     0 : [<computer>] <type>: 1381 Service Pack 6, cpu:2, level:21164, num: 1, mem:63, page:112

 

<computer>: is the computer name of the system

<type>: is either client, node or local

cpu: is the platform type ( 0 for x86,  2 for alpha)

level: is the level of the chip ( 4, 5, 6 for x86  21064, 21164 for alpha)

num: is the number of processors in the system

mem: is the amount of physical memory (in meg)

page: is the max commit limit (in meg)

 

If the test failed to complete there should be a line like this:

 

+VAR+SEV2     0 : Test stopped with XXX minutes elapsed.

 

Where XXX < the expected time.   This should be next to another line indicating the state the test was in when it exited.

 

+VAR+SEV2     1 : Tests did not complete

Exiting while in state: <State> : <StateNum>

 

Possible states include:

 

Unknown: <StateNum>  - this is an unmapped error the <StateNum> indicates the value

 

Stopped:, Connect_Error, Start_Error  Running and Stop_Error:

                                       - test was aborted by the user while in this state.

 

Running_Error: - this likely indicates a failure in one of the ‘critical’ processes.  For the Server Test kit this usually means that we lost communication with a qserv, process on one of the systems.   This could be due to a network problem or could indicate that one of the test systems crashed or rebooted.

 

Which critical process failed is usually indicated a few lines above.  For example if the spfail.exe process exited then you’ll see the message:

 

  +VAR+SEV2     0 : A critical process: spfail.exe has stopped on <computer-name>

 

In which case the next place to look is in the spfail.log for the error on the <computer-name>.  If this were a qserv, process there would be a log file under the %windir%\system32\qserv.log.   For most other test processes the log file would be located under %windir%\srvtst or one of srvtsts subdirectories.

 

The server test kit does not reboot the system.  So if one of the systems was restarted, or if it hangs or freezes it likely means that the system crashed.   By default there should be a memory.dmp file under the %windir% directory.  This memory.dmp can be debugged using windbg from the DDK.  Alternately you could install the kernel debugger on a separate system (such as the client monitoring node) and catch the crash ‘in the act’.  Consult the DDK documents on how to setup a debugger and kernel mode debugging in general.  How to debug a crash dump is also in the DDK documents. 

 

If the system freezes at the ‘black screen’ (ie before boot option prompt) then you likely have a hardware/firmware bug.  Consult your vendor on how to resolve this issue.

 

If you suspect a communication problem then additional debugging information can be usually found in the qserv.log.   The qserv.log is in the %windir%\system32 directory on every system running qserv as a service.  On the client master the qserv.log is in the testbin directory with the rest of the logs.   Communication problems are usually due to a problem in the network configuration.  Consult your site net admin and see the section on netcard validation in the HCT kit.

 

If the test ran to completion it is still possible for the test to fail if:

·         We lost communication to one or more of client srv’s or the local srv.

·         We lost communication with all of the node srv’s.  (ie the server in the server test kit)

·         We failed in test cleanup of the test resources.

·         We started the test without sufficient client srv’s, node srv’s or the local srv registered with valdclus.exe.

 

This last point can be verified by counting the number of ‘qserv’ processes of each of the respective types.     There should be a list of the processes running at the time the test exited in the log file.  The list is in the form:

 

+VAR+INFO     2 : <process>|<pid>|<mem>|<state>|<elapsed time>|<computer>|<type>

 

If you suspect the problem is a test bug, or if you have a technical question about the test see the section below about sending problems to wolfhct@microsoft.com.  

 

File I/O Testing Using an SMB Share

This test requires that one of the test drives be set up with a file share.  This file share is automatically setup by the valdclus.exe process that is started on the client monitoring system.

Lrgfile Test

This test creates a large file and then reads backward and shrinks the file while checking read data.

Lrgfile uses unbuffered I/O only and retries on every file I/O operation.

The user will not be required to know the syntax of these test programs. The test launcher will start the test when it is run on each client node. If the server is set up using the well-known names that Microsoft provides, no further input will be required.

Problem resolution:

If LRGFILE test fails, look for LRGFILE.LOG log file. This file should contain error information and reason for failure. Since LRGFILE test is run with -Vn switch (leave n MB of free space on disk), common problem is that test did not start at all, because there was not enough space to start the test. LRGFILE retries 15 times with 1 second pause between retries before exiting with this error. Another common problem is disk media failure. Such a problem is reported as data corruption because expected data was not read from the disk. To eliminate that kind of error run LRGFILE test locally on server. You can find LRGFILE.EXE in your HCT\TESTBIN directory or on HCT CD. Copy it on server node  and run command from WINDOWS NT console.

lrgfile -r10 -p32 -b8 -dX:

-r10 means run 10 times

-p32 means that LRGFILE will use 32*4 kB chunks of data for each write/read operation

-b8 means that LRGFILE will use 8 buffers for asynchronous write/read

-dX: replace X with suspected shared drive letter. Be sure that disk is online on the node that runs LRGFILE!

LRGFILE will grow temporary test until it consumes entire available disk space, than shrinks file back while checking data. DO NOT MOVE/FAILOVER DISK RESOURCE DURING THIS TEST. After LRGFILE finishes, look in the log file LRGFILE.LOG (in the same directory LRGFILE.EXE was run from) and search for data errors (e.g. Disk data error: Chunk#xpct 0x12, chunk#got 0x0, Page#=0). If you see this error your disk failed and is unreliable. If your disk passes this test, but does not pass node test with random moves/failovers, it point to the cache problem. If both tests pass but client test does not it points to the problem in redirector. Mostly, data was not written on the disk, but was cached (usually on hardware level) and reported as saved at the time prior to failover/move.

Most of other errors are due to network failure.

 

Mapfile Test

This file system test sets up memory-mapped files to the server. It then modifies a section of the mapped file, committing these changes to disk by flushing the file mapping. After the flush operation completes, the test will read the data back into memory and compare that the correct data was written to the disk. If a failover happens before the flush operation, all changes are discarded and the test restarts.

Problem resolution:

Mapfile test requires 4 MB of space on tested drive. If there is not enough space, Mapfile exits. Another common problem is a network failure. If test fails because of data corruption problem (read data differs from expected), the cause is not easy to determine. Mostly, data was not written on the disk, but was cached (usually on hardware level) and reported as saved at the time prior to failover/move. See LRGFILE Problem resolution paragraph how to eliminate disk-media problem.

 

Unbuf Test

UnbufW is a Async IO stress test.  It performs asynchronous writes and reads in various combinations in attempt to stress parts of the async io system.  This test uses completion ports to perform the async io.

The different variables for test combinations include:

·        buffered/unbuffered IO

·        pre-allocated disk space/new file

·        extending existing file/over writing existing file

·        size of the target file

·        number of concurrent io threads

·        size of each IO

 

The io's are written out in a computable pattern and then read back and verified.  If an error is detected the test will optionally force a break into the debugger so that the state of the system can be examined by a filesystem guru.  In the HCT kit this feature is disable and errors are simply logged.

 

FsCmprsn Test

The fscmprsn test (ie file system compression test) is a stress test written to exercise the NTFS compression engine.  This test can also run on FAT and other file systems, but that is less interesting.

To exercise NTFS compression the test performs the following algorithm:

1.        Walks the specified <srcDirectory> (tree)

2.        Insert the contents of readable files into fscmprsn.dat.  This insert begins at the end of the file +/- some randomly chosen delta.  In this manner it grows the file, by default, up to 5M.

3.        Verify the contents of the file.  It does this by reconstructing the files contents in sections and then comparing.

4.        Toggle the file's compression state

5.        Repeat 3, then 4, then 3.

6.        Delete fscmprsn.dat

7.        Continue at 1, (at the next file) until no more files in the tree.

 

For the HCT kit, after step 7 the test deletes the fscmprsn.dat file and starts over at the beginning of the source tree.  The %windir% directory is used for the <srcDirectory>.  As such the test is engineered to ignore files that cannot be opened shared for read access.

The nature of this stress test is to deliberately force NTFS to handle writes in the middle of a compressed file as well as extending and truncating an existing compressed file.

Errors are logged and optionally the test can force a break into the debugger so that a file system guru can examine the state.

IIS Testing

As part of the server setup script, Valdclus will copy some HTML files to the test drives.  It will then setup virtual directories pointing to the target test disks.  We have modified the IIS client tests to continually poll the IIS server for information. This test simulates what an Internet Explorer version 3.0 (or higher) or other browser client would see by constantly accessing the IIS pages on the server. It will also retry in the case of errors being returned from the IIS server. The test will perform operations to make sure that the IIS server is returning correct data from the test drives.

This test will be totally automated and will connect to the IIS virtual root on each disk using the network name. A virtual root is a mapping from an IIS alias to a physical location on a disk located on the IIS server machine. A typical example would be http:\\WolfpackIIS\home mapped to I:\wwwroot\home.html, where WolfpackIIS is the network name and Home is the IIS alias or virtual root.

There will be two virtual roots for each disk:

·         WWW root

·         FTP root

 

There will be specific files that clients will access for each virtual root. For the WWW and FTP roots, Valdclus will copy HTML files from the client monitoring system to the server.

Gqstress Test

This test is designed to do constant IIS queries against the virtual root set up in each disk group. The test will make sure that the virtual root is online. If the test is unable to access the root, it will retry the operation. The test will allow the root to be offline for a certain period of time. This is expected during failovers because the network name and IP address have to be moved to the other server. This test can simulate thousands of queries in a short time; it is designed to stress the IIS virtual roots. Each client will have one instance of this test doing queries against each IIS virtual root that is a WWW root.

Problem resolution:

The name of the log file is gqstress.log. A SEV2 error indicates a failure. It is normal to have select time out as it happens during fail over. The most probable cause for the test failure is that IIS may not be started, crashed or security problems. Ensure that IIS is installed and running. Use the IIS Service Manager to check whether the IIS service is started. You can use Microsoft Internet Explorer to see if IIS is accessible from the client. If IIS is up and running check if all the virtual roots that are created are up and running (You can do this from IIS Service manager).

Do the following from the client browser to check if the IIS, network connectivity & security are fine.

·         Go to the IIS service manager & disable NT LM authentication (on the nodes). This is because gqstress does not support NT LM authentication.

·         From the browser fetch http://servername,  and http://ipaddress.   Both of them should fetch the default IIS home page.

·         If 172.31.224.44 is the IP address used for the test.  Then you can fetch the gqstress.htm from the browser as follows: http://172.31.224.44/w3svc_q/gqstress/gqstress.htm.  The server name could also be substituted for the IP address.

Past experience showed the most common cause for the failure of gqstress is security. This is noticed the server system is a PDC or a BDC. This is caused by the fact the IIS user account becomes invalid (IUSR_NODENAME) if the server is a PDC or BDC. (Windows NT 4.0 only)

 

Ftpstress Test

As part of the setup, Microsoft will copy some small test files to the test disks. This test will use FTP transfers to move that file back and forth from the clients. In the case of a failure, it will redo the last operation. It will keep track of which files have been successfully transferred to the server, and then verify that those files are actually on the server.

Problem resolution:

The name of the log file is ftpcont.log. A “FAIL: Max time out” indicates a failure. The most probable cause for the test failure is that ftp server may not be started or crashed. Ensure that ftp service is installed, running and accessible. Use the IIS Service Manager to check whether the FTP service is started. You can use the ftp client program that comes with Windows 95 or NT to check if ftp service is accessible from the client.

Winsock Sock_Srv/Sock_Clnt Test

This test is a pair of client-server applications that test the ability of winsock to accept a large number of connections, in a scenario similar to a web/ftp server.

There must be only one machine running the server binary (sockdies.exe).  There is no restriction on the number of client machines. Each of these should be running the client binary (sockdiec.exe).

There should only be one instance of each client on a system.

Problem resolution:

It is impossible to determine in advance what a good result is for an arbitrary network configuration. For example, the type of the server machine, as well as the number of clients connected greatly affects the results.   As such, this test does not provide any logging that can be interpreted as pass/fail.

Each side (client or server), creates a log file called:  sockdie{s,c}.log.<computer name>.

However, this log should not be used to interpret or analyze the progress of the test.

This test is a stress application designed to run without interruption for as long as the system is up. It will only exit on fatal error conditions,  like extremely low resource availability.

What to do if tests fail, but you think it is a test bug?

We realize that in some cases you will run into a problem where you think it is a test bug that is blocking the tests from passing at 100%.  Please go back and look in the trouble shooting section first. Failing that you can send the required log information to wolfhct@Microsoft.com so we can look at your problem.  If  we do determine that it is a test bug we will allow your configuration to be listed even if the test results are not 100% pass.  We believe that most test results of valid configurations should pass at 100% though.   At a minimum the required log information sent to wolfhct@Microsoft.com should consist of:

·         The srvtst.log.  This will be in the \hct\testbin directory

·         The qserv.log from each system.  This will be in the \hct\testbin directory on the client master and in the %windir%\system32 directory on the server and the clients.

·         The output from ipconfig /all on all systems.

·         The output from net use on all systems

·         The output from ping and net view from the client master against the server and the clients

·         The output from ping and net view from the server against the clients and the client master.

Returning Results

After the tests have completed, you will need to return the test results to a floppy disk on the Client Master.

  1. In test Manager, click on the "Return Results" menu and select "Return Server - Client Master Test Results". The OEM Contact Information dialog appears.
  2. Fill in the OEM Contact Information dialog with contact information and click "Done".
  3. The Return Test Results dialog appears. Insert a floppy disk into drive A: on the Client Master and click "Copy Logs". When the dialog tells you the log files have been copied, click "Done". Remove the floppy disk from drive A: and insert it into the floppy drive on the Server.

On the Server:

  1. In Test Manager, Select Return Test Results -> Return Server Test Results.

The Pull in Additional Test Results dialog appears.

  1. In the Pull in Additional Test Results dialog, enter the location of the test results in the Logs Location text box. For this test, the test logs are located on the floppy disk in drive A:.
  2. Click the "Import Results" button.
  3. When the text "Done Copying Logs" appears below the "Import Results" button, click "Done". When you click "Done", one or more pop-up message boxes with the following text will appear: "Error 5 Deleting: Temp_Merge". These message boxes can be safely ignored.

Uninstalling the Server Test

If you have already run the Server Test, you must remove the files that Test Manager installed from the Client Master before running this test again. You must also clean the system registry on the Client Master.

To remove the HCT files from the Client Master

In Windows Explorer, Select the /hct directory and press the 'DELETE' key. The /hct and /hct/testbin directories are removed from your system.

  1. Start Windows Explorer on the Client Master (Start -> Programs -> Windows Explorer)
  2. In Windows Explorer, select the /hct directory and press the "DELETE" key.

The /hct and /hct/testbin directories are removed from your system.

To remove the HCT from the Registry on the Client Master

  1. On the Taskbar, click Start -> Run.
  2. In the Run dialog, type "regedit" and click "OK".

The Registry Editor appears.

  1. In the Registry Editor, expand HHEY_LOCAL_MACHINE -> SOFTWARE -> Microsoft.
  2. Under Microsoft in the Registry Editor, select "HCT" and press the "DELETE" key.
  3. In the Registry Editor, expand HHEY_CLASSES_ROOT -> AutoRun -> 5 -> Shell -> AutoRun.
  4. Under AutoRun in the Registry Editor, select "command" and press the "DELETE" key.
  5. In the Registry Editor, expand HHEY_CLASSES_ROOT -> AutoRun -> 5.
  6. Under 5 in the Registry Editor, select "Default Icon" and press the "DELETE" key.

Now that the HCT installation has been removed, you may choose to remove the shortcut to the HCT from the Start menu.

To remove the shortcut to HCT from the Start menu on the Client Master

  1. On the Taskbar, right click and select Properties from the menu.
  2. In the Properties dialog, click the "Start Menu Programs" tab.
  3. Click "Remove".

The Remove Shortcuts/Folders dialog appears.

  1. In the Remove Shortcuts/Folders dialog, under Programs, select HCT and click "Remove".

The shortcut is removed. You have now completely uninstalled the HCT from the Client Master.