The procedures presented in this section outline the process for testing your Windows Server 2008 System for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the system.

Note  You must use the latest version of the WDK to compile your driver in order for it to pass testing and obtain a logo.

Using the Test Procedure Help Topics

The test procedures are divided into the following types of topics:

Overview: The overview topics describe the hardware, software, and tester knowledge requirements.

Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.

Running: The running topics describe how to run to run the tests for your device or system.

Windows Server 2008 System Tests

The list of tests you must run depend upon the capabilities of the device or system being tested. To see the complete list of tests that could be required for your system, see the System Tests topic.

System Functionality Tests

The System Functionality Tests are individual tests of the capabilities of the system. Some tests are run for every system, and some tests only run if the capability exists in the system.

System Stress Test

System Stress Test consists of several server scenario workloads operating from the user level address space applied to the system to exercise the system hardware, system-specific devices and drivers, network and storage adapters and drivers, and any filter drivers that might be part of the system configuration, such as multipath storage drivers, storage or file system filter drivers, or intermediate layer network drivers.

The workloads applied are:

These workloads will automatically scale to the number of network and storage adapters found in the system that have connected clients or storage devices, respectively. For example, if the test discovers one network adapter and one storage adapter (along with the necessary connected clients or storage devices, respectively), the test will create workload processes for that number of adapters in order to provide the stress workload. If the system has multiple network and storage adapters, test processes are created for each of those adapters, drivers, and connected resources (clients or storage devices) in order to provide the same relative stress workload. Additionally, the network and storage adapters and their respective resources need not be the same type. For example, GigaBit Ethernet and 10GigBit Ethernet adapters could be tested at the same time, as long as network clients were connected to both devices. Similarly, Fibre Channel and iSCSI storage adapters can be tested at the same time, as long as the appropriate storage media is attached. And any HBA units that are attached to the server under test (SUT) must be connected to the appropriate type of storage media.

Additionally, the system test is designed to achieve the same relative amount of stress on the system, regardless of the number or type of processors, amount of memory, or the number of network and storage adapters in the system. The test detects the number of processors/cores in the system, as well as the amount of memory in the system. The test then creates as many processor-specific and memory-specific stress processes as are needed to achieve a predetermined level of processor and memory utilization and will terminate those processes if the utilization level exceeds the predetermined level of stress. Thus, the level of utilization for those resources is always commensurate with the capabilities of the system. A system that only supports a few processors/cores and an appropriate amount of memory for the system will have the same relative levels of stress as a larger system with more processors/cores and a greater amount of memory.

Shutdown/Restart Test

The Server test also includes a shutdown and restart test. This test signals the system to shut down and restart. The test records the event log information related to shutting down and restarting the system, such as vetoes that prevent shutdown, the ‘startup event,’ and any driver errors received after restarting the system. This test is designed to ensure that all device drivers in the system comply with system shutdown, do not veto, and cleanly restart in the system without conflicting with other drivers. For more information, see I/O Completion Cancellation Guidelines.

There are 3 DTM jobs within System Stress Test kit:

• LoadGen Server Stress - Run First - Set Machine Policies (run time < 30 minutes)
• LoadGen Server Stress - Start Test for Server (run time = 24 hours)
• LoadGen Server Stress - Run Last - Reset Machine Policies (run time < 20 minutes)
• LoadGen Server Stress - Start Test for Server (run time = 24 hours)
• LoadGen Server Stress - Run Last - Reset Machine Policies (run time < 20 minutes)
• LoadGen Server Stress - Run Last - Reset Machine Policies (run time < 20 minutes)

As the names indicate, you must schedule the "Run First - Set Machine Policies" job before the "Start Test for Server" job. And you must schedule the "Run Last - Reset Machine Policies" job afterwards, when the "Start Test for Server" job has finished.

You need to schedule the Run First and Run Last jobs only once for each submission, but you must schedule and run the "Start Test" job multiple times until it passes. You also need to schedule the "Run Last - Reset Machine Policies" job if you are going to schedule other different jobs on the same machine pool.

Details

LoadGen is a test tool that generates load on a given system under test. The system can be a standalone server (such as a datacenter server or fault-tolerant server) or any solution that consists of multiple computers (such as a multi-node cluster or a dynamic partitioned machine). LoadGen is started on the master client and can use multiple subordinate client computers to generate network load on the system under test.

You can start LoadGen with multiple command line parameters to enable you to control how it behaves. Configuration information is provided in the XML file that is passed through the –config command line parameter. The name of the system under test and subordinate clients (if any) are passed through –sut and –sc respectively. User credentials that start test process underare passed by –user and –pwd or –usellu (for LLU’s in a DTM environment). Other command line options are available through LoadGen.exe /?.

After LoadGen starts, it reads the configuration input from the command line parameters and configuration file. This input includes the system requirements, tests to start on the systems, performance counters to monitor, parameter information, and so on. During setup, LoadGen does the following:

• Copy files to all computers and start a service (named spsrv) that LoadGen uses throughout the test run to launch tests, monitor test processes, gather information, and so on.
• Check that the systems meet the requirements that are specified in the configuration file.
• Confirm that the users that is specified on the command line is a local administrator on each and every computer in the setup.
• Create the parameter tree and parameter table. These items are internal data structures that are used to assign which specific system resources (CPU, memory, disk, network, and so on) that LoadGen targets during the test run and which test processes generate the load on each resource.
• Check that the systems meet the requirements that are specified in the configuration file.
• Confirm that the users that is specified on the command line is a local administrator on each and every computer in the setup.
• Create the parameter tree and parameter table. These items are internal data structures that are used to assign which specific system resources (CPU, memory, disk, network, and so on) that LoadGen targets during the test run and which test processes generate the load on each resource.
• Confirm that the users that is specified on the command line is a local administrator on each and every computer in the setup.
• Create the parameter tree and parameter table. These items are internal data structures that are used to assign which specific system resources (CPU, memory, disk, network, and so on) that LoadGen targets during the test run and which test processes generate the load on each resource.
• Create the parameter tree and parameter table. These items are internal data structures that are used to assign which specific system resources (CPU, memory, disk, network, and so on) that LoadGen targets during the test run and which test processes generate the load on each resource.

When the test starts, it runs through a set of phases. A phase consists of one or more tests that run for a given amount of time. Some test scenarios have only one test phase. At the beginning of each phase, LoadGen starts new tests. And at the end of each phase, LoadGen stops those tests that do not run during the next phase.

Tests that run in a given phase can be one of the following:

• Tests that stress the resources on the system under test.
• Processes that test system features.
• Processes that test system features.

LoadGen starts and monitors all test processes and reacts accordingly when an instance stops. If a test process is a critical one, the entire test run is ended by LoadGen. Otherwise, the test continues to run against the system under test.

When a test fails or when the last phase of the test run ends, Loadgen does the following:

• Stops all test processes that are running on all systems.
• Collects test logs to a local folder on the master client. This folder is later copied to the DTM log share.
• Stops the services that it started on the systems.
• Deletes the files that are distributed at the beginning of the test run.
• Collects test logs to a local folder on the master client. This folder is later copied to the DTM log share.
• Stops the services that it started on the systems.
• Deletes the files that are distributed at the beginning of the test run.
• Stops the services that it started on the systems.
• Deletes the files that are distributed at the beginning of the test run.
• Deletes the files that are distributed at the beginning of the test run.

To start the Server Stress test kit, you must have the following computers that have the operating system installed, that are domain-joined, and that are connected through Ethernet:

• The system under test (SUT) is the server that you are trying to logo.
• The master client (MC) is the system that starts, monitors, and finishes the test kit.
• The subordinate clients (SCs) are the systems that generate the test load for network traffic.
• The master client (MC) is the system that starts, monitors, and finishes the test kit.
• The subordinate clients (SCs) are the systems that generate the test load for network traffic.
• The subordinate clients (SCs) are the systems that generate the test load for network traffic.

The Server Stress test kit start the following tests on the testing systems:

1. System functionality tests. These tests start at beginning of the test run and should not stop or fail before the test kit finishes. The test kit reports a failure if any of those tests failed.
2. SQL Database IO simulation. If there are extra non-system disks that are connected to SUT, this test runs on all the non-system disks. Otherwise, if there is only one system disk on SUT, this test runs on the system disk.
3. Local File System IO simulation. If there are extra non-system disks that are connected to SUT, this test runs on all of the non-system disks. Otherwise, if there is only one system disk on SUT, this test runs on the system disk.
4. System resource stress tests: The test kit monitors stress level on SUT from MC and these tests are started or stopped according to the system stress level. Their failure is not considered a failure of the test kit.
5. Client-Server IO. This test starts on the SCs and sends a large amount of data to SUT. Then, the data is stored on the disks of SUT.
6. Network Stress. This test starts on the SCs and sends network traffic to SUT.
7. CPU resource consumption. This test runs on SUT and consumes a certain percentage of the CPU resource.
8. Memory resource consumption. This test runs on SUT and consumes a certain percentage of system memory resource, including physical memory, page file, and non-paged pool.
9. System reboot test: This test runs on SUT and restarts the computer while the system is under stress. The system should be able to turn itself off and then turn on in certain period of time. This test and the whole test kit fail if the system cannot shutdown or restart.
10. SQL Database IO simulation. If there are extra non-system disks that are connected to SUT, this test runs on all the non-system disks. Otherwise, if there is only one system disk on SUT, this test runs on the system disk.
11. Local File System IO simulation. If there are extra non-system disks that are connected to SUT, this test runs on all of the non-system disks. Otherwise, if there is only one system disk on SUT, this test runs on the system disk.
12. System resource stress tests: The test kit monitors stress level on SUT from MC and these tests are started or stopped according to the system stress level. Their failure is not considered a failure of the test kit.
13. Client-Server IO. This test starts on the SCs and sends a large amount of data to SUT. Then, the data is stored on the disks of SUT.
14. Network Stress. This test starts on the SCs and sends network traffic to SUT.
15. CPU resource consumption. This test runs on SUT and consumes a certain percentage of the CPU resource.
16. Memory resource consumption. This test runs on SUT and consumes a certain percentage of system memory resource, including physical memory, page file, and non-paged pool.
17. System reboot test: This test runs on SUT and restarts the computer while the system is under stress. The system should be able to turn itself off and then turn on in certain period of time. This test and the whole test kit fail if the system cannot shutdown or restart.
18. Local File System IO simulation. If there are extra non-system disks that are connected to SUT, this test runs on all of the non-system disks. Otherwise, if there is only one system disk on SUT, this test runs on the system disk.
19. System resource stress tests: The test kit monitors stress level on SUT from MC and these tests are started or stopped according to the system stress level. Their failure is not considered a failure of the test kit.
20. Client-Server IO. This test starts on the SCs and sends a large amount of data to SUT. Then, the data is stored on the disks of SUT.
21. Network Stress. This test starts on the SCs and sends network traffic to SUT.
22. CPU resource consumption. This test runs on SUT and consumes a certain percentage of the CPU resource.
23. Memory resource consumption. This test runs on SUT and consumes a certain percentage of system memory resource, including physical memory, page file, and non-paged pool.
24. System reboot test: This test runs on SUT and restarts the computer while the system is under stress. The system should be able to turn itself off and then turn on in certain period of time. This test and the whole test kit fail if the system cannot shutdown or restart.
25. System resource stress tests: The test kit monitors stress level on SUT from MC and these tests are started or stopped according to the system stress level. Their failure is not considered a failure of the test kit.
26. Client-Server IO. This test starts on the SCs and sends a large amount of data to SUT. Then, the data is stored on the disks of SUT.
27. Network Stress. This test starts on the SCs and sends network traffic to SUT.
28. CPU resource consumption. This test runs on SUT and consumes a certain percentage of the CPU resource.
29. Memory resource consumption. This test runs on SUT and consumes a certain percentage of system memory resource, including physical memory, page file, and non-paged pool.
30. System reboot test: This test runs on SUT and restarts the computer while the system is under stress. The system should be able to turn itself off and then turn on in certain period of time. This test and the whole test kit fail if the system cannot shutdown or restart.
31. Client-Server IO. This test starts on the SCs and sends a large amount of data to SUT. Then, the data is stored on the disks of SUT.
32. Network Stress. This test starts on the SCs and sends network traffic to SUT.
33. CPU resource consumption. This test runs on SUT and consumes a certain percentage of the CPU resource.
34. Memory resource consumption. This test runs on SUT and consumes a certain percentage of system memory resource, including physical memory, page file, and non-paged pool.
35. System reboot test: This test runs on SUT and restarts the computer while the system is under stress. The system should be able to turn itself off and then turn on in certain period of time. This test and the whole test kit fail if the system cannot shutdown or restart.
36. Network Stress. This test starts on the SCs and sends network traffic to SUT.
37. CPU resource consumption. This test runs on SUT and consumes a certain percentage of the CPU resource.
38. Memory resource consumption. This test runs on SUT and consumes a certain percentage of system memory resource, including physical memory, page file, and non-paged pool.
39. System reboot test: This test runs on SUT and restarts the computer while the system is under stress. The system should be able to turn itself off and then turn on in certain period of time. This test and the whole test kit fail if the system cannot shutdown or restart.
40. CPU resource consumption. This test runs on SUT and consumes a certain percentage of the CPU resource.
41. Memory resource consumption. This test runs on SUT and consumes a certain percentage of system memory resource, including physical memory, page file, and non-paged pool.
42. System reboot test: This test runs on SUT and restarts the computer while the system is under stress. The system should be able to turn itself off and then turn on in certain period of time. This test and the whole test kit fail if the system cannot shutdown or restart.
43. Memory resource consumption. This test runs on SUT and consumes a certain percentage of system memory resource, including physical memory, page file, and non-paged pool.
44. System reboot test: This test runs on SUT and restarts the computer while the system is under stress. The system should be able to turn itself off and then turn on in certain period of time. This test and the whole test kit fail if the system cannot shutdown or restart.
45. System reboot test: This test runs on SUT and restarts the computer while the system is under stress. The system should be able to turn itself off and then turn on in certain period of time. This test and the whole test kit fail if the system cannot shutdown or restart.

The server stress test tries to generate network load for each NIC on the server under test. The desired throughput is 40% of the NIC’s capacity. If, with the current client set, the network load cannot reach the targeted level, Loadgen requires additional client to be added in to testing environment. (To add an additional client, click the “client” pane of Loadgen UI, type the name of the client system to add into the box, and click Add. Server stress test has a time-out window of 60 minutes. After it made the request, if no additional client is added after 60 minutes, the test fails and exits.

Additional Qualifications Tests

Server systems might have additional functionality beyond that required for the Windows Server 2008 Logo. The additional qualifications for which a system can test and qualify are:

These additional qualification tests can be found in the DTM test harness with the tests that are listed for systems. Vendors whose systems can meet the requirements for either of these additional qualifications must select and run the tests required for each. The Dynamic Partitioning tests exercise and confirm the hot add, hot replace, and rebalance functionality of the system, devices, and drivers. The Fault Tolerant tests exercise and confirm the ability of a fault tolerant system hardware, devices, and drivers to have a hardware failure and continue to operate without impacting other clients on the network.

Note that a system can support both dynamic partitioning and fault tolerance. In order for the vendor to validate that the system meets the requirements for one or both of the additional qualifications, one or both of the additional tests must be selected and run. Those results are then submitted along with the results of the Server test. The additional qualification test results cannot be submitted separate from Server Logo test results.

For more information about Additional Qualifications, see Additional Qualifications Information.

For more information about dynamic partitioning testing, see Dynamic Partitioning (DP) Simulator and Test.

Run time: Run time will vary depending on whether the system supports dynamic partitioning or fault tolerance. If only the Server Logo test is selected, testing will take approximately two days, with the Loadgen test taking one day to run while the remaining tests run during the second day.

Additionally, if the system being tested includes audio, video or other devices and drivers, those will be exercised as well, and that will increase test time.

Hardware requirements

The following hardware is required for running the Windows Server 2008 operating system.

The following hardware is required for Windows Server 2008 System testing.

Infrastructure Requirement and Setup for the Server Stress Test

The Server Stress test required all test machines to be in a network with a domain controller. The machines themselves will need to be joined to that domain and have a domain user account created. The reliability of the network is critical to the stress test, if your network is not reliable or setup improperly the test will either fail or won’t start. Make sure the test environment is on a stable and reliable network. Use dynamic IP addressing for all machines.

For the Win2008 Server Stress Test, it’s a requirement that IPV4 be turned on and IPV6 turned off.

Server System under Test (SUT) Requirements

• Maximum number of processors that the SUT supports.
• The maximum memory capacity that the SUT supports.

  Note  When you test an x86 SUT that has more than 4 GB of RAM, you must enable Physical Address Extension (PAE). For more information about how to enable PAE and how to configure specific values in the boot configuration datastore of the SUT, see the BCDEdit /set topic on MSDN.

• At least one Gigabit network adapter, or additional network adapters, being used for testing.
• One hard disk drive to be used for installing the operating system. This hard disk drive should have two partitions. Partition 1 should have at least 1.5 GB, and less than 5 GB, of space that is configured as Active, System. Partition 2 should have at least 40 GB of space (or the Windows Server 2008 minimum requirement) that is configured as Boot, Page File, Crash Dump.
• One Gigabit Ethernet network hub.
• The maximum memory capacity that the SUT supports.

  Note  When you test an x86 SUT that has more than 4 GB of RAM, you must enable Physical Address Extension (PAE). For more information about how to enable PAE and how to configure specific values in the boot configuration datastore of the SUT, see the BCDEdit /set topic on MSDN.

• At least one Gigabit network adapter, or additional network adapters, being used for testing.
• One hard disk drive to be used for installing the operating system. This hard disk drive should have two partitions. Partition 1 should have at least 1.5 GB, and less than 5 GB, of space that is configured as Active, System. Partition 2 should have at least 40 GB of space (or the Windows Server 2008 minimum requirement) that is configured as Boot, Page File, Crash Dump.
• One Gigabit Ethernet network hub.
• At least one Gigabit network adapter, or additional network adapters, being used for testing.
• One hard disk drive to be used for installing the operating system. This hard disk drive should have two partitions. Partition 1 should have at least 1.5 GB, and less than 5 GB, of space that is configured as Active, System. Partition 2 should have at least 40 GB of space (or the Windows Server 2008 minimum requirement) that is configured as Boot, Page File, Crash Dump.
• One Gigabit Ethernet network hub.
• One hard disk drive to be used for installing the operating system. This hard disk drive should have two partitions. Partition 1 should have at least 1.5 GB, and less than 5 GB, of space that is configured as Active, System. Partition 2 should have at least 40 GB of space (or the Windows Server 2008 minimum requirement) that is configured as Boot, Page File, Crash Dump.
• One Gigabit Ethernet network hub.
• One Gigabit Ethernet network hub.

Client System Requirements

The system failure of even a single client will cause the entire test to fail. To minimize the likelihood of client system failures, use the following criteria to help you choose computers and other hardware for this test:

• Make sure that your computers have resources that exceed the minimum CPU and RAM requirements.
• Make sure that all NICs and device drivers have already been logo-qualified. The bandwidth of the NICs in the client computers must be equal to the bandwidth of the NIC in the SUT.
• Plug all client computers into UPS power protection units
• Connect all client computers with high quality cabling, routers, and switches.
• Use highly redundant storage and memory components: For example, RAID 1 or RAID 5 memory, MPIO Duplexing for storage, RAID hard disks, Teaming for NICs etc

Example of Client, Server and Master systems Network Configuration for Windows Server 2008 Testing

Software requirements

The following software is required to run the Windows Server 2008 System tests:

• One of the following operating systems for the SUT:
  • Windows Server 2008 Datacenter Edition to enable all the processors and exercise all possible features in the system being tested. This applies for Logo testing or for any possible additional qualification such as that for the high availability, fault tolerance, or dynamic partitioning tests.
  • Windows Server 2008 Datacenter Edition to enable all the processors and exercise all possible features in the system being tested. This applies for Logo testing or for any possible additional qualification such as that for the high availability, fault tolerance, or dynamic partitioning tests.
  • Windows Server 2008 for Itanium-based systems, in order to enable all the processors and exercise all possible features in the system being tested. This applies for Logo testing or for any possible additional qualification such as that for the high availability, fault tolerance, or dynamic partitioning tests.
  • Windows Server 2008 Datacenter Edition to enable all the processors and exercise all possible features in the system being tested. This applies for Logo testing or for any possible additional qualification such as that for the high availability, fault tolerance, or dynamic partitioning tests.
  • Windows Server 2008 for Itanium-based systems, in order to enable all the processors and exercise all possible features in the system being tested. This applies for Logo testing or for any possible additional qualification such as that for the high availability, fault tolerance, or dynamic partitioning tests.
  • Windows Server 2008 for Itanium-based systems, in order to enable all the processors and exercise all possible features in the system being tested. This applies for Logo testing or for any possible additional qualification such as that for the high availability, fault tolerance, or dynamic partitioning tests.

• Windows Server 2008, Standard Edition, for either x86 or x64 platform as appropriate, for the master client and the client systems
• Any drivers that are not shipped with the Microsoft Windows operating system
• The current release of the Driver Test Manager (DTM)
• The optional Windows Server 2008 BitLocker Drive Encryption component must be installed on the server.

  Note  The System Tests topic provides more information about the system requirements for the BitLocker Drive Encryption test.

• Windows Server 2008, Standard Edition, for either x86 or x64 platform as appropriate, for the master client and the client systems
• Any drivers that are not shipped with the Microsoft Windows operating system
• The current release of the Driver Test Manager (DTM)
• The optional Windows Server 2008 BitLocker Drive Encryption component must be installed on the server.

  Note  The System Tests topic provides more information about the system requirements for the BitLocker Drive Encryption test.

• Any drivers that are not shipped with the Microsoft Windows operating system
• The current release of the Driver Test Manager (DTM)
• The optional Windows Server 2008 BitLocker Drive Encryption component must be installed on the server.

  Note  The System Tests topic provides more information about the system requirements for the BitLocker Drive Encryption test.

• The current release of the Driver Test Manager (DTM)
• The optional Windows Server 2008 BitLocker Drive Encryption component must be installed on the server.

  Note  The System Tests topic provides more information about the system requirements for the BitLocker Drive Encryption test.

• The optional Windows Server 2008 BitLocker Drive Encryption component must be installed on the server.

  Note  The System Tests topic provides more information about the system requirements for the BitLocker Drive Encryption test.

Tester knowledge requirements

To run the Windows Server 2008 System tests, testers must know how to accomplish the following tasks:

• Create, format, and remove partitions on a hard disk drive
• Set power management options
• Install and configure a network
• Install the operating system from the product DVD
• Download a service pack for an operating system
• Install the Active Directory Domain Services Role
• Create a domain
• Install and operate the Driver Test Manager and Studio Services
• Set up the systems to be used in testing at the BIOS/FW/EFI level
• Set power management options
• Install and configure a network
• Install the operating system from the product DVD
• Download a service pack for an operating system
• Install the Active Directory Domain Services Role
• Create a domain
• Install and operate the Driver Test Manager and Studio Services
• Set up the systems to be used in testing at the BIOS/FW/EFI level
• Install and configure a network
• Install the operating system from the product DVD
• Download a service pack for an operating system
• Install the Active Directory Domain Services Role
• Create a domain
• Install and operate the Driver Test Manager and Studio Services
• Set up the systems to be used in testing at the BIOS/FW/EFI level
• Install the operating system from the product DVD
• Download a service pack for an operating system
• Install the Active Directory Domain Services Role
• Create a domain
• Install and operate the Driver Test Manager and Studio Services
• Set up the systems to be used in testing at the BIOS/FW/EFI level
• Download a service pack for an operating system
• Install the Active Directory Domain Services Role
• Create a domain
• Install and operate the Driver Test Manager and Studio Services
• Set up the systems to be used in testing at the BIOS/FW/EFI level
• Install the Active Directory Domain Services Role
• Create a domain
• Install and operate the Driver Test Manager and Studio Services
• Set up the systems to be used in testing at the BIOS/FW/EFI level
• Create a domain
• Install and operate the Driver Test Manager and Studio Services
• Set up the systems to be used in testing at the BIOS/FW/EFI level
• Install and operate the Driver Test Manager and Studio Services
• Set up the systems to be used in testing at the BIOS/FW/EFI level
• Set up the systems to be used in testing at the BIOS/FW/EFI level