Network Factory Administrator Guide

PC DOCTOR, INC.
Delivering Confident Computing
TM
PC-Doctor Network Factory Administrator Guide
How to use PC-Doctor Network Factory
CONFIDENTIAL
Last revised: 2009 03 20
Copyright 1993-2009 PC-Doctor, Inc. ALL RIGHTS RESERVED. PC-Doctor is a trademark of PCDoctor, Inc., Reno, NV. All other brand and product names are registered trademarks, trademarks or servicemarks of their respective holders and are gratefully acknowledged. Product specifications subject to change without notice. All PC-Doctor products are protected by one or more of the following patents: 6,742,148; 6,792,562; 6,829,726. Other patents pending.
2005 PC-Doctor, Inc. All rights reserved
CONFIDENTIAL
2 | PC-Doctor Network Factory Administrator Guide | TOC
Contents
Welcome to PC-Doctor Network Factory...........................................................................6 Before you Begin Tips for Implementing Network Factory ..........................................8
Understanding how Network Factory Works...........................................................................................8 Network Factory Implementation Planning.............................................................................................9 Implementation Planning Worksheet...........................................................................................9 About the PC-Doctor Network Factory Mapping Program Logic.............................................10 About using wild cards for defining mappings..........................................................................12
Getting Started Installing Network Factory..................................................................14

Hardware and Software Requirements...................................................................................................14 Hardware Requirements for servers supporting 51-150 UUTs..................................................14 Supported Windows Client Operating Systems.........................................................................15 Suggested Linux Client Operating Systems...............................................................................15 Calculating Space Requirements to Support Archiving.............................................................15 Running the PC-Doctor Network Factory Server Installer....................................................................16 Before Launching the PC-Doctor Network Factory Server Installer.........................................16 Installing the PC-Doctor Network Factory Server.....................................................................16 Installing a Dual Server Configuration......................................................................................17 Starting PC-Doctor Network Factory Server.........................................................................................18 Finding the Server IP Address...................................................................................................18 Launching the Monitoring Console............................................................................................18
Implementing Your Network Factory Integration...........................................................22

Composing PC-Doctor Network Factory test scripts.............................................................................22 Composing Test Scripts for Specific Device Testing.................................................................22 Composing Test Scripts Designed to Run Tests in Parallel.......................................................28 Composing Test Scripts Designed to Perform Burn-in Testing.................................................28 Using Test Parameters................................................................................................................29 Setting Up and Running an Inventory Test............................................................................................31 Composing an Inventory Test Script..........................................................................................31 Adjusting Inventory Auditing Criteria Tolerances.....................................................................35 Manually Editing an Inventory File...........................................................................................37 Range Tolerance Symbols..........................................................................................................39 Composing Inventory Script Files..............................................................................................40 Generating Inventory Files.........................................................................................................41 Modifying PC-Doctor Network Factory Configuration.........................................................................41 Implementing your Network Factory mappings........................................................................42 Modifying Network Factory Configuration Timing Values.......................................................45 Connecting UUTs to the Network Factory Server.................................................................................47 Defining Configuration Labels...................................................................................................48 Additional label options for UUTs.............................................................................................48
Installing and Running the Network Factory Client.......................................................50

Installing and Running the Windows Client..........................................................................................50
PC-Doctor Network Factory Administrator Guide | TOC | 3
Installing and Running the Linux Client................................................................................................50 Defining File Association Links.................................................................................................51 Installing the Linux Client..........................................................................................................51 Running from a Network Share Drive...................................................................................................52 About Network Share Limitations.............................................................................................52
The Progress Monitor.........................................................................................................53 Generating Reports.............................................................................................................56

Things You Should Know Before Generating a Report.........................................................................56 About the Hide and Delete System links....................................................................................56 About Report Pane Icons............................................................................................................57 About Generating Reports from Active and Archived Databases.............................................57 Generating a Testing Overview Report..................................................................................................58 Generating a Component Overview Report ..........................................................................................59 Generating a System Information Report...............................................................................................60 Guidelines for Generating a System Information Report...........................................................60 Generating Custom Reports...................................................................................................................64
Managing Components through a Parts List...................................................................65

Defining a New Part...............................................................................................................................65 Managing Parts.......................................................................................................................................68 Modifying Part Details...........................................................................................................................68 Using a Parts File to Test Hardware Configurations..............................................................................70 About the extras.xml File...........................................................................................................70 Running a Parts Verification Test...............................................................................................70
Creating and Managing Accounts.....................................................................................72

The User Mgmt Tab...............................................................................................................................72 Adding a User Account..............................................................................................................73 Modifying User Account Privileges...........................................................................................73 Deleting User Accounts..............................................................................................................73
Managing the Database......................................................................................................75

The DBAdmin Tab.................................................................................................................................75 Adding Data to the system_extra Table.....................................................................................75 Adding Fields to the system_extra Table...................................................................................76 Maintaining the Network Factory Database...........................................................................................78 Before You Begin.......................................................................................................................80 Archiving the PC-Doctor Network Factory Database................................................................81 Backing up the PC-Doctor Network Factory Database..............................................................84
The Help Tab.......................................................................................................................86

Available Help Tab Features..................................................................................................................86 Sample Network Factory Database Schema..............................................................................87 Database Configuration Information..........................................................................................87 Reporting an Issue......................................................................................................................87
Troubleshooting Tips and FAQ..........................................................................................91

Installation and Setup.............................................................................................................................91 What type of hardware should I use for maximum efficiency?.................................................91
4 | PC-Doctor Network Factory Administrator Guide | TOC
How do I make sure that my installation goes smoothly?..........................................................91 UUTs do not show up in the Progress Monitor..........................................................................91 My UUTs are listed as UUT_TIMED_OUT, but the UUTs are still running. ..........................91 Can I use my own serial loopback adapter with PC-Doctor Network Factory?........................92 How do I reduce the amount of time a test script needs to run?................................................92 How do I run a Pattern Test on my system drive?......................................................................92 How do I modify the server port numbers after Network Factory is installed?.........................93 I just upgraded Network Factory but nothing has changed........................................................93 Using Network Factory Features............................................................................................................93 How do I increase the amount of time a UUT is tested?............................................................93 How do I decrease the amount of time a UUT is tested?...........................................................94 Where do I find Network Factory log files?...............................................................................94 Why cant I run video tests on my Linux UUTs?.......................................................................95 PC-Doctor Network Factory Database...................................................................................................95 How do I back up the PC-Doctor Network Factory database?..................................................95 How do I restore the database from a backed-up database file?................................................95 Selecting the ODBC Example under Reports produces the error Database Connection Failed.95 Where can I find more information on databases used with Network Factory?........................96
ODBC Connectivity with Firebird Database....................................................................97

Prerequisites...........................................................................................................................................97 Installing Firebird ODBC Drivers..........................................................................................................97 Creating an ODBC Data Source Name..................................................................................................98 ODBC Data Sources using MS Access, Cold Fusion, and PHP..........................................................100 Using MS Access.....................................................................................................................100 Using ColdFusion.....................................................................................................................103 Using PHP................................................................................................................................103 Setting Up ColdFusion Third Party Database Access..........................................................................104 Sample Database Queries.....................................................................................................................106
Using the DOS UUT..........................................................................................................111

Overview of the DOS UUT..................................................................................................................111 Summary of Steps for Configuring and Testing a DOS UUT..............................................................112 DOS UUT File Dependencies..............................................................................................................112 About DOS_UUT.CFG........................................................................................................................114 Setting Up Support for PXE Booting...................................................................................................115 Configuring a DOS UUT to Operate in a Network Factory Environment...........................................115 Guidelines for Configuring a DOS UUT.................................................................................115 Modifying the Test Process..................................................................................................................116 Supporting UUT Updates.........................................................................................................116 Using a Bootstrap.....................................................................................................................117 Using the DOS Proxy...........................................................................................................................118 Using Test Scripts to Automate DOS Testing......................................................................................118 Creating DOS Test Overlays....................................................................................................119 Integrating a Custom Test Overlay into your Network Factory Test Environment.................119 Known Issues and Workarounds for Network Factory server and DOS Proxy Communication........120 Reports and System Information Errors...................................................................................120
PC-Doctor Network Factory Administrator Guide | TOC | 5
Script Warnings are not Shown in the Progress Monitor.........................................................120 DOS UUT Environment Variables.......................................................................................................120 Working From the Command Line......................................................................................................121 The ba:xx and ms:xx Command Line Switches.......................................................................121 The rt:nn, rt:nn,x and rt:nn/x Switches.....................................................................................121 The au:Fname Switch...............................................................................................................129 General Command Line Switch Functions..............................................................................129 Determining and Using Bitmap Values................................................................................................139
For More Information......................................................................................................141
6 | PC-Doctor Network Factory Administrator Guide | Welcome to PC-Doctor Network Factory
Welcome to PC-Doctor Network Factory

PC-Doctor Network Factory is a network-based diagnostic testing system designed to manage and track computer system manufacturing from start to finish. Providing seamless integration between production, defect tracking, factory floor management and database results storage, Network Factory streamlines all phases of the production process. With Network Factory you can: Run diagnostics on multiple Units Under Test (UUT). Monitor and manage everything from a central server. Perform inventory audit testing. Generate useful reports. Identify warranty cost reduction opportunities.
PC-Doctor Network Factory consists of four major elements: Server software: provides for management of UUTs connected to Network Factory. The server manages diagnostic progress with all UUTs and records the results in the database.
Figure 1: Web and database server
SQL-compliant database: stores all test results and system information reports. The database provides an audit trail that allows you to increase productivity and reduce costs by performing trend analysis. You can integrate the SQL-compliant database into external applications using standard Open Database Connectivity (ODBC). For more information on ODBC, SEE ALSO ODBC Connectivity with Firebird Database on page 97. Unit Under Test (UUT) software: consists of PC-Doctor hardware diagnostics, system information utilities and scripting tools that provide scripting capabilities and connectivity to the server. Monitoring Console: viewed using Firefox 2.x web browser and available from anywhere that is accessible through the network. The Monitoring Console allows users to manage the testing process, track testing progress and create custom reports. The Monitoring Console support various levels of account permission that allow you to restrict or enable features based on account privilege. For more information on available account privileges, SEE ALSO Creating and Managing Accounts on page 72. The main components of the Monitoring Console consist of the following: Progress Monitor: Provides real-time diagnostic progress. SEE ALSO The Progress Monitor on page 53.
PC-Doctor Network Factory Administrator Guide | Welcome to PC-Doctor Network Factory | 7
Reports: Provides access to reporting tools for generating custom reports such as test result or system information reports. SEE ALSO Generating Reports on page 56. Script Editor: Provides access to diagnostic script composition tools that allow you to tailor your test environment to your specific needs. SEE ALSO Composing PC-Doctor Network Factory test scripts on page 22. Inventory Auditing: provides tools for quickly performing inventory audits of a system hardware configuration to verify it conforms to a standard specification. SEE ALSO Setting Up and Running an Inventory Test on page 31. Network Factory Configuration: Provides access to tools for modifying your Network Factory test environment including script mapping, server and UUT communication and system information report filters. SEE ALSO Modifying PC-Doctor Network Factory Configuration on page 41. User management: Provides tools for adding information to the database, guidelines for maintaining the Network Factory database and complete control over user account access and privileges. SEE ALSO Managing the Database on page 75 and Creating and Managing Accounts on page 72.
8 | PC-Doctor Network Factory Administrator Guide | Before you Begin Tips for Implementing Network Factory
Before you Begin Tips for Implementing Network Factory

In this chapter you will find information on Understanding how Network Factory Works on page 8 Network Factory Implementation Planning on page 9
Understanding how Network Factory Works

PC-Doctor Network Factory is a very flexible and robust diagnostic application. A successful implementation of Network Factory is greatly enhanced by anticipating test needs and understanding how Network Factory can help you organize an efficient test solution. Before you begin using Network Factory, you should take some time to determine how it best fits in with your test plan. The first step in implementing Network Factory is to plan how you want to use the product. One of the key factors in a successful implementation of Network Factory is organization. Good organization will greatly enhance your consolidation of specific test requirements. For example, a UUT entering a burn-in testing phase will run a completely different set of tests than if it were entering a functional testing phase. You should begin thinking of ways to efficiently organize your test plan and test environment. Network Factory provides three classifications to help accomplish this Group: Use this classification to organize UUTs by physical location on the manufacturing floor. For example, you can specify all UUTs connected to rack 1, area 64 as a single test group. Configuration: Use this classification to sub-divide UUTs by model or operating system. For example, one of your test groups may contain UUTs where half of them run Windows, and half of them run Linux. You can use the configuration classification to provide this distinction, allowing Network Factory to send Windows specific test scripts to the Windows UUTs, and Linux specific test scripts to the Linux UUTs. Phase: Use this classification to further sub-divide UUTs by their current test phase within the manufacturing process. For example, your manufacturing process may include an initial inventory phase, a second functional testing phase and finally a system burn-in phase.
How you organize your test groups is the basis for your script configurations. It allows you to setup Network Factory to send specific test scripts to specific UUTs. For example, one section of your operation (rack1) performs strictly functional testing. Unique functional testing is performed on two UUTs, modelT42 and model886, that are located in this section of the manufacturing floor but have different testing requirements. You can specify this in Network Factory in the following way:
group=rack1, configuration=modelT42, phase=functional group=rack1, configuration=model886, phase=functional
If you have several UUTs per order that require the same test plan, this would allow you to view UUTs in the Progress Monitor by order number. You can apply the same principles in other areas within your operation, providing a wide degree of customizing options for Network Factory. You can even make the group name something specific. For example, if you want to group UUTs by order number XYZ1234, you can specify the group name as the order number. Using the above example, you would specify the following:
group=XYZ1234, configuration=modelT42, phase=functional
PC-Doctor Network Factory Administrator Guide | Before you Begin Tips for Implementing Network Factory | 9
The next step in planning your Network Factory implementation is specifically what hardware components you want to test. Logically, if a UUT does not have a serial port for example, you would exclude serial port testing from the script that you create for that UUT. Consider these key points: What do you want to test? How do you want to test it?
Network Factory Implementation Planning

Creating a Network Factory implementation planning outline or worksheet is the first step towards understanding how you plan to use Network Factory. The following section guides you in developing a Network Factory Implementation Planning worksheet.
Implementation Planning Worksheet

PC-Doctor provides these instructions to help plan your Network Factory implementation. How you define Group, Configuration and Phase for your test environment is completely optional. The instructions are designed to demonstrate how a customer might frame their Network Factory implementation strategy and what kinds of questions may surface during this process. Step 1: Decide how you want to define Group Is there a specific physical location on the manufacturing floor where testing will occur? For example, row 3, rack 6, and so on. This information might be used to track a particular area of manufacturing or repair. List these groups on your implementation planning worksheet. For example: Do you dedicate a section of your manufacturing or repair center to a particular testing method? For example, you might dedicate a single bench section to testing before installation of the final customer image. You may decide to define this group as bench4. Does your manufacturing process designate a single technician as responsible for a particular area? For example, specific technicians are responsible for specific areas of the manufacturing floor, such as a technician manning rack 6 or area 51. You could then define a group as rack6 or area51.
Step 2: Decide how you want to define Configuration Do you test models or types of systems that require distinct testing? Using Configuration, all systems that match the configuration distinction will use the same script. Define each unique configuration of testing required on your implementation planning worksheet. For example: Do a group of systems requiring identical testing run in a specific operating system, such as Windows? You may decide to define this configuration as Windows. Do specific models of systems require identical testing? You may decide to define this configuration by model number, such as T42 or EO656. Do specific types of systems (laptop, desktop, and so on) require identical testing? You may decide to define this configuration by system type, such as laptop or desktop.
Step 3: Decide how you want to define Phase What types of test processes or phases does your test plan include? For each one, define a name on your worksheet that distinguishes it from other types of test processes or phases. For example: Will you require inventory testing that compares components in a UUT against a master system configuration to ensure that a system is built to specification? You may decide to define this phase as Inventory. Will you require functional testing that exercises a system in a particular operating system? If so, you may decide to define this phase as Functional.
Will you require burn-in testing that performs heavy testing on a system over an extended period of time? If so, you may decide to define this phase as Burn-in.
Step 4: Decide on what tests will run as part of your configurations and phases The next step is to decide what you want to test specifically for each configuration and phase. To help you coordinate this, look at the Add Tests list in the Scripts pane to view the available test selections (for more information on test scripts, SEE ALSO Implementing Your Network Factory Integration on page 22). You will need to specify an operating system to view the available test selections, which are operating system specific. For more information on available diagnostics, SEE ALSO the PC-Doctor Test Descriptions guide for the appropriate operating system. For example, in your test plan, you may want to run an inventory test against a master configuration system before running any other tests. During the Functional test phase of the Windows configurations, you would like to use the following tests: CD-ROM Linear Seek CD-ROM Random Seek All CMOS tests All CPU tests Hard drive Linear Seek Hard drive Random Seek All memory tests
In addition, during the Burn-in phase, you want to run all the tests that you did for functional, add the funnel seek tests for hard drives and CD-ROMs, and run it in 50 test passes. Use a separate sheet for each set of tests you would like to use for each configuration and phase. Step 5: Determine if the tests you select are the same across a group, configuration or phase For example, after checking off which tests you want to run for both the T456 and R42 Windows configurations, you notice the tests selected for the Functional phase of each model are identical. You also notice the tests selected for the Burn-in phase of each model are identical as well. Identifying the similarities in testing is relevant during the mapping portion of implementation. Step 6: Determine if you want to use a batch file to handle command-line entries at the UUT For example, you would like to run the Inventory and Functional tests sequentially, but you want to run the Burn-in test later because that occurs in a separate location of the facility. In this case, you could create a batch file that runs the Inventory and Functional tests. Step 7: Explore mapping options and implement your test plan The next step is to apply your implementation plan to your diagnostic environment within Network Factory. At this point, you may want to refer to the analysis you did in step 5 of this worksheet. Mapping is a method for associating scripts and files to specific groups, configurations, and phases that you define. This is how Network Factory determines the logical association between, for example, a script file and the UUT it should run on. You can save effort in creating mappings by using wild card symbols (*). Wild cards allow you to consolidate common tests within a group, configuration or phase.
About the PC-Doctor Network Factory Mapping Program Logic

Understanding the mapping logic and sequence within Network Factory will give you a better idea of how to use wild cards. Each Network Factory mapping is defined by three values: Group Configuration Phase
Once these values are defined and applied to a single mapping, you will need to define the following two values for each mapping you create: Script file name with test selections specific to systems associated to this mapping. Inventory file name that is specific to systems associated to this mapping.
Using an earlier example, a typical mapping would look like this:

rack1:modelT42:Functional.script = functional_test.xml rack1:modelT42:Functional.inventory = system_inventory.xml
The previous example specifies Network Factory to use the: functional_test.xml script file, system_inventory.xml inventory file, with the rack1 group, that has a modelT42 configuration, and entering the Functional phase of testing.
For a logical progression of how mappings work in Network Factory, see below.
Figure 2: Network Factory Mapping Logic Flowchart
About using wild cards for defining mappings

The following is an explanation of how you can use wild cards for mapping scripts: As seen in the flowchart for the mapping logic and sequence, a UUT must execute at least the script file during a single test. If you include ExactMatchInventory, the UUT will also execute the inventory script (how to create an inventory file is covered later in this guide). In addition a UUT may execute several different mappings in the course of testing. For example, the current process may require that a UUT first undergoes inventory testing, followed immediately by functional testing, and finally burn-in testing. From the Configuration tab the mapping sets might look like this:
rack1:modelT42:INVENTORY.script = inventory_test.xml rack1:modelT42:INVENTORY.inventory = system_inventory.xml rack1:modelT42:FUNCTIONAL.script = functional_test.xml rack1:modelT42:FUNCTIONAL.inventory = none rack1:modelT42:BURN-IN.script = burn-in_test.xml rack1:modelT42:BURN-IN.inventory = none
If the UUT is running Windows, you could create a batch script as follows:
pcd uut -s 192.168.31.145 -g rack1 -c modelT42 -p INVENTORY pcd uut -s 192.168.31.145 -g rack1 -c modelT42 -p FUNCTIONAL pcd uut -s 192.168.31.145 -g rack1 -c modelT42 -p BURN-IN
Note: By default, Network Factory uses TCP port 4560 and UDP port 6001 to conduct communication between the UUT and server. If you plan on using a different port for this communication, you will need to specify it in your batch file. For example:
pcd uut -s 192.168.31.145:5555 -g rack1 -c modelT42 -p INVENTORY pcd uut -s 192.168.31.145:5555 -g rack1 -c modelT42 -p FUNCTIONAL pcd uut -s 192.168.31.145:5555 -g rack1 -c modelT42 -p BURN-IN
The tests complete in the order listed in the batch file. The above example is useful for varying configurations and groups. For example, your process includes the above mentioned phases: inventory, functional, and burn-in. You also have 10 different hardware configurations, requiring 10 different inventory tests. At one extreme you could create 30 different mapping sets with a unique test script for all of them or you could use the same burn-in test among all of them and only create 21 mapping sets. An even better solution is using the same functional and burn-in tests for all 10 configurations and then create a unique inventory mapping set for each configuration. This would result in only 12 mapping sets instead of the original 30, demonstrating why it is important to look for common tests during your implementation planning.To take advantage of using the wildcard capability, you could create the following mapping sets. These mapping sets share both the functional and the burn-in test for multiple systems and have unique inventory scripts for each configuration.
*:*:FUNCTIONAL.script - functional_test.xml *:*:FUNCTIONAL.inventory - none *:*:BURN-IN.script - burn-in_test.xml *:*:BURN-IN.inventory - none
You would then create 10 different inventory mappings:

rack1:modelT42:inventory script: inventory-test.xml rack1:modelT42:inventory inventory: system1-inventory.xml rack1:model886:inventory script: inventory-test.xml rack1:model886:inventory inventory: system2-inventory.xml rack1:model987:inventory script: inventory-test.xml rack1:model987:inventory inventory: system3-inventory.xml
On the UUT, you can create a batch file for this scenario that would look like this:
pcd uut -s 192.168.31.145 -g rack1 -c modelT42 -p inventory pcd uut -s 192.168.31.145 -p functional pcd uut -s 192.168.31.145 -p burn-in
Note: Ensure you include the port number if you are using a port other than 4560 for communication between the UUT and server. Using your understanding of the mapping flow (see Figure 2: Network Factory Mapping Logic Flowchart on page 11), you can see that the first line in the batch file would look specifically for a named group, configuration and phase. The second line in the batch file would look for *.*.functional and the third test would look for *.*.burn-in. This example would apply to any combination of group, configuration and phase. Understanding how systems are designed and the options available to you can greatly reduce the amount of work required to implement Network Factory. For more information on Network Factory mappings, SEE ALSO Implementing Your Network Factory Integration on page 22.
14 | PC-Doctor Network Factory Administrator Guide | Getting Started Installing Network Factory
Getting Started Installing Network Factory

In this chapter you will find information on: Hardware and Software Requirements on page 14 Running the PC-Doctor Network Factory Server Installer on page 16 Starting PC-Doctor Network Factory Server on page 18 PC-Doctor Network Factory requires installation of at least two software elements: the Network Factory Server, and a Network Factory Client. First, install the PC-Doctor Network Factory Server. Caution: Install PC-Doctor Network Factory only on a secured network. PC-Doctor Network Factory should never be exposed to the Internet or a network that is not secure. PC-Doctor, Inc. designed user permissions to make the product simple to use. User permissions are not a security mechanism to prevent unauthorized use of PC-Doctor Network Factory.
Hardware and Software Requirements

Before you begin using Network Factory, determine your hardware needs. In general, the Network Factory server can handle more clients with better hardware. To ensure optimal performance for the PC-Doctor Network Factory Server, PC-Doctor recommends the following minimum hardware specifications for servers supporting 50 UUTs or less: 3.4Ghz Pentium 4 or Opteron 146 or similar 2GB of RAM (depending on what else is installed on the system) 120GB 7200RPM SATA or SCSI hard drive(s) including archive space (SEE ALSO Calculating Space Requirements to Support Archiving on page 15) Important: Mirrored (RAID 1) is highly recommended Uninterruptable Power Supply (UPS) with power management software
PC-Doctor Network Factory Server runs on the Windows operating system. Verify that your server is running one of the following: Windows 2003 Server Windows 2000 Server with Service Pack 4 Windows 2000 Pro with Service Pack 4 Windows XP Pro
Hardware Requirements for servers supporting 51-150 UUTs

PC-Doctor recommends a two server configuration for test environments that support a large number of UUTs. Use one server as the database server and one server as the web server. To facilitate quick communication between the two servers, PC-Doctor recommends using a 100Mb or faster dedicated Ethernet connection. Recommended database server configuration: 3.4Ghz Pentium 4 (800Mhz FSB) or Opteron 148 or higher 1.5GB of RAM 80GB 7200RPM SATA or SCSI hard drive UPS with power management software
PC-Doctor Network Factory Administrator Guide | Getting Started Installing Network Factory | 15
Recommended web server configuration: Dual Xeon 3.4Ghz or Dual Opteron 246 processors or a dual-core processor of similar specifications 4GB of RAM 120GB 7200RPM SATA or SCSI hard drive(s) including archive space (SEE ALSO Calculating Space Requirements to Support Archiving on page 15) Important: Mirrored+Striped (RAID 10) is highly recommended. UPS with power management software.
If you require a diagnostic solution that will support more than 150 simultaneous UUTs, consult with your PC-Doctor representative. Important: PC-Doctor Network Factory Server requires the use of HTTP port 8080, TCP port 4560, TCP port 4586, TCP port 3050 and UDP port 6001 by default. Disable any services that may interfere with communication on these ports. For example, virus checkers, firewalls, web servers and application servers. Disable virus scanning for the PC-Doctor Network Factory Server installation directory. Virus scanning in the installation directory may corrupt the Network Factory database.
Supported Windows Client Operating Systems

The PC-Doctor Network Factory Windows client requires one of the following: Windows XP (all versions) Windows 2000 Pro Windows 2000 Server Windows 2003 Server Windows PE 1.5, 1.6 and 2.0 Windows Vista (all versions)
Suggested Linux Client Operating Systems

The PC-Doctor Network Factory Linux client runs on the following Linux distributions: Linux kernel 2.6 Note: For evaluation purposes, we recommend you use one of the following Linux distributions: Fedora Core 4, Red Hat Advanced Server 4.0, or SuSE 10.
Calculating Space Requirements to Support Archiving

To determine the approximate amount of space required to support archiving in your test environment, use the following formula:
(Number of Systems per Week) * (Number of Script Runs per System) * .09 MB
For example, if you test an average of 2000 systems per week and each system runs an average of three different test scripts, a week of archived data will occupy:
2000 * 3 * .09 MB = 540 MB
Running the PC-Doctor Network Factory Server Installer

Use the following guidelines for installing a Network Factory server.
Before Launching the PC-Doctor Network Factory Server Installer

1. Login to the operating system as Administrator or as a user with administrative privileges. 2. Shutdown any running Web servers (for example, IIS) or ensure HTTP port 8080, TCP port 4586, TCP port 4560 and UDP port 6001 are free. To verify this, open a command window and run the following command: netstat -a 3. Disable any running firewall or enable incoming HTTP connections on port 8080, incoming TCP connections on port 4560, 4586 and incoming UDP connections on port 6001. 4. Ensure the drive on which you are installing Network Factory Server has at least 20 GB of free space left over for temp directory activity. 5. Ensure you are not installing the server on a domain controller. Note: By default, Network Factory will use TCP port 4560 and UDP port 6001 to conduct communication between the UUT and the server. If you plan on using a different port for this, ensure that the port is not in use and is not running an active firewall.
Installing the PC-Doctor Network Factory Server

Important: Ensure you install the Network Factory server software on a system connected to a UPS. A sudden loss of power to the server may result in corruption of the Network Factory database. The following set of instructions will show you how to install the Network Factory server software. 1. Copy the PC-Doctor Network Factory Server zip file to any directory on the target PC. Take note of the directory as you will need to come back to it later. 2. 3. 4. 5. Decompress the zip file Double-click the setup.exe file and follow the instructions. Type your companys name in the text box prompt and click the Next button. Take note of the destination folder and click the Next button. This is the default installation directory for PC-Doctor Network Factory Server. 6. When prompted for a port number, leave the default port number unchanged and click the Next button. The default port number should be 8080. 7. Click the Finish button. When installation is complete, attach the green USB dongle to a USB port on the Network Factory server before launching it. The green USB dongle must always be attached to the server or Network Factory will not run. Note: In addition to HTTP port 8080, PC-Doctor Network Factory Server requires the use of TCP port 4560 and UDP port 6001 (by default) for communication between the UUT and server, and TCP port 4586 for validating client licenses.
Installing a Dual Server Configuration

Use the following guidelines for setting up a Network Factory dual server configuration (SEE ALSO Hardware and Software Requirements on page 14): 1. Install Network Factory on the database server. 2. Install Network Factory on the Apache server. Ensure you insert the USB license dongle after installation of the web server is complete. 3. Determine the IP of the database server. This can be done by opening a DOS command prompt and running Ipconfig. 4. On the Apache server browse to: <install_directory>\Apache2\htdocs\properties\ 5. Using any standard text editor, locate and open the file network_factory.properties. 6. Locate the following parameter:
database.firebird.host = 127.0.0.1
7. Change the listed IP address to the address of the database server. For example:
database.firebird.host = 192.168.1.40
Optional Procedure for Managing Server Processes The following steps are optional but will prevent unneeded processes from running on both servers. 1. On both servers browse to: <install_directory>\bin\ 2. Open the files start.cmd and restart.cmd. You will need to modify the contents of both files on both servers. 3. On the database server replace the contents of start.cmd with:
cd "<install_directory>\Firebird\bin" instsvc start
4. On the database server replace the contents of restart.cmd to:

cd "<install_directory>\Firebird\bin" instsvc stop cd "<install_directory>\Firebird\bin" instsvc start
5. On the Apache server replace the contents of start.cmd with:

"<install_directory>\Apache2\bin\Apache.exe" -k start "<install_directory>\php\php.exe" -n -f start_license_server.php
6. On the Apache server replace the contents of restart.cmd to:

cd "<install_directory>\bin" "<install_directory>\Apache2\bin\Apache.exe" -k stop "<install_directory>\Apache2\bin\Apache.exe" -k uninstall "<install_directory>\php\php.exe" -n -f terminate_license_server.php "<install_directory>\Apache2\bin\Apache.exe" -k install "<install_directory>\Apache2\bin\Apache.exe" -k start "<install_directory>\php\php.exe" -n -f start_license_server.php
7. If you did not reboot after installation, reboot now. Once the servers boot up, start the Network Factory database by selecting:
Start->All Programs->PC-Doctor Network Factory Server->Start Network Factory Server
Once the database is up and running, use the same procedure for starting the web server.
Starting PC-Doctor Network Factory Server

Once you have installed the server and USB dongle, you can begin using PC-Doctor Network Factory. Start the PC-Doctor Network Factory Server by clicking the Start Network Factory Server short-cut located in the PC-Doctor Network Factory for Windows program directory. See Figure 3: Network Factory Start Server short-cut on page 18.
Figure 3: Network Factory Start Server short-cut
Finding the Server IP Address

You will need the IP address of your PC-Doctor Network Factory Server to continue. If you do not know the server IP address, find it using Ipconfig by doing the following: 1. On the PC running the Network Factory Server, left click the Start button and select Run. 2. In the Open field, type cmd and click the OK button. This will open a command prompt window. 3. At the c: prompt, type Ipconfig and press ENTER. 4. Take note of the server IP Address as you will need it when setting up the PC-Doctor Network Factory clients. See Figure 4: Using ipconfig to determine the server IP address on page 18.
Figure 4: Using ipconfig to determine the server IP address
If your server has multiple IP addresses, use the address that connects to the network containing the UUTs.
Launching the Monitoring Console

After starting the PC-Doctor Network Factory Server, launch the Monitoring Console.
Note: The minimum supported resolution for the Monitoring Console is 1024 x 768. 1. Open a Web browser (Firefox 2.x) on any system connected to the same network as the Network Factory server. Although any standard browser will support the Progress Monitor, Network Factory is optimized for Firefox 2.x. 2. In the Address field, type the server IP address from the previous section and port number specified during installation. For example, http://192.168.25.212:8080. See Figure 5: Typing Server IP in the Address field on page 19.
Figure 5: Typing Server IP in the Address field
3. When prompted for a user name and password, type admin for both and click the OK button. See Figure 6: The Network Factory User Login on page 19
Figure 6: The Network Factory User Login
The Monitoring Console opens, displaying the Progress Monitor. You are now logged into the Network Factory Server with full administrative privileges. See Figure 7: The Monitoring Console Progress Monitor on page 20.
Figure 7: The Monitoring Console Progress Monitor
Troubleshooting Monitoring Console Connection Issues The Monitoring Console view will refresh periodically, and display a No System Found message on the left side of the window until you connect clients to the server. Note: Leave the browser open as you will use it later. If the Progress Monitor does not appear or an error message displays saying the connection was refused, try these steps: 1. Verify you are using the correct operating system and browser. 2. Verify the Network Factory Server software is running. 3. Verify you are using the correct IP address and port number you specified during installation (default is 8080). Some browsers may require you type http:// before the server address. 4. Verify any running firewall is disabled. 5. Verify that your monitor resolution is set to at least 1024x768. 6. Verify the USB dongle is attached. If you remove the USB dongle while running Network Factory, stop the server, insert the dongle, and restart the server. 7. Stop and Start the Network Factory Server by doing the following: a) Stop the PC-Doctor Network Factory Server by clicking the Stop Network Factory Server short-cut located in the PC-Doctor Network Factory for Windows program directory.
Figure 8: Network Factory Stop Server short-cut
b) Start the PC-Doctor Network Factory Server by clicking the Start Network Factory Server short-cut located in the PC-Doctor Network Factory for Windows program directory
22 | PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration
Implementing Your Network Factory Integration

In this chapter you will find information on: Composing PC-Doctor Network Factory test scripts on page 22 Using Test Parameters on page 29 Setting Up and Running an Inventory Test on page 31 Modifying PC-Doctor Network Factory Configuration on page 41 Implementing your Network Factory mappings on page 42
Composing PC-Doctor Network Factory test scripts

PC-Doctor Network Factory diagnostics are contained in test scripts, which you can create and modify through the Scripts tab. Test scripts are essentially batch files that allow you to automate test runs. You can compose test scripts to run specific tests on specific devices, compose scripts for conducting inventory audit testing, compose scripts specifically designed to perform burn-in testing, and so on. Using the examples from chapter two, you will compose test scripts for three different test phases: Functional Burn-in Inventory
After you compose your test scripts, you will map them to their appropriate group and configuration.
Composing Test Scripts for Specific Device Testing

Using the implementation guide from chapter two, compose a device specific test script. For example, you may need to compose a test script that tests the core functions of a system: CPU Hard Drive Memory Systemboard
For the purposes of this exercise, you will name this script functional. To access the script editor, click the Scripts tab. The Scripts pane will open divided into two sections. You will see a drop-down arrow at the top of the left pane for selecting an operating system, and New and Open buttons at the top of the right pane. See below.
Figure 9: The Scripts tab
When you select an operating system for the script, the Scripts Test List will open. See below.
PC-Doctor Network Factory Administrator Guide | Implementing Your Network Factory Integration | 23
Figure 10: Creating a new test script
When composing a script for a specific operating system, use a file name that is descriptive of the supported operating system. For example, when creating a script for Linux, use LinMyTest.xml as the file name. If you were creating a script for Windows, use WinMyTest.xml as the file name. Descriptive file names are highly beneficial when mapping the script to a group as explained later in this document. Some tests may not be compatible with a particular operating system. If you run a script against the incorrect operating system, the incompatible test in the script will log a false negative. This failure is due to the differences in operating systems instead of an actual hardware failure. Guidelines for Composing a Device Specific Test Script Use the following guidelines for composing a device specific test script. The tests used in this example were chosen specifically because the test times are short. 1. Select the supported operating system for the script by clicking the drop-down arrow. 2. Click the New button. The New Script dialog box opens. See below.
Figure 11: The New Script Dialog Box
3. Type functional.xml and click the OK button. This opens the Save Script options and places a header for the script you are creating at the top of the Scripts pane. See below.
Figure 12: Save Script options for a new script
4. In the Test List, locate the available CPU test selections. Test categories are listed in alphabetical order. 5. A box with a check mark means a test will be included in the script. Under the CPU test category, select the following tests by clicking the adjacent check box. See below: a) Register b) Cache c) MMX
Figure 13: The Test List
6. For the Hard Drive, Memory, and System Board (a.k.a motherboard) test categories, select the following tests: Hard Drive: Linear Seek, Random Seek Memory: Pattern System Board: RTC Rollover
7. When you are done selecting tests, click the Add Test button. The populated test script appears in the right pane. See below.
Figure 14: Adding tests to a new test script
8. Type a description for the script that helps explain its purpose in the Description field. This is different from the file name you entered earlier. 9. Click the Save link at the top of the Scripts pane. See below.
Figure 15: Script Description field
10. Click the Save link. Ensure that the text Script File Saved appears at the top right corner of the Scripts pane. See below. If you save your script successfully, you will see the following indicator (see below):
Figure 16: Saved Script Indicator
To discard any changes you have made to a test script, click the Discard Changes or Remove Selected links. To close a currently open test script, click the Close link. If you click Close without saving, you will lose your changes. Organizing Tests into Test Sets You may find it necessary to organize your test script into succinct groups of tests called test sets. For example, you may want to create a separate test set for motherboard functions. To do this, you will first need to add another test set to the script. 1. Using the functional test script example you created in the previous steps, select the RTC Accuracy Test available in the Systemboard list and click the Add Tests button. This will automatically add another test set. 2. Locate the arrow buttons to the right of the RTCRolloverTest entry in your script. See below.
Figure 17: Test Set Arrows
3. Click the Down Arrow button.
This will move the RTCRolloverTest down once in the test order, forming a test set with the RTC Accuracy Test. See below. Note: If a test is listed as the first test in a test set, it will move to the proceeding test set when you click the Up Arrow button. If a test is listed as the last test in a test set, it will move to the following test set when you click the Down Arrow button. Your test script pane should look like the above figure.
Figure 18: Shifting a test up in test order
4. Click the Save link. The resulting script, functional.xml, is saved on the server in the following directory:
<install_directory>\Apache2\htdocs\scripts
Removing Test Selections If you need to remove tests or test sets from your script, you can do so by using the Remove Selected link. For example, if you wanted to remove the Pattern Test from functional.xml: 1. Select the Pattern Test by clicking the check mark next to the test entry. See below.
Figure 19: Removing the Pattern Test
2. Click the Remove Selected link. 3. Click the Save link.
Composing Test Scripts Designed to Run Tests in Parallel

As a system manufacturer, time is a valuable commodity. One tool you can use to save time in your test plan is to set up your test scripts to test devices simultaneously. This is known as parallel testing. When you mark tests to run in parallel, they will run simultaneously with other tests that are marked to run in parallel. However, separate tests designed for the same device will not run in parallel with each other. For example, if you attempt to run a Linear Seek Test and a Random Seek Test on the same hard drive in parallel, the first test to run will run normally but the second test will report a result of DEVICE IS BUSY. When the first test completes, the second test will begin. Guidelines for Composing a Test Script that Supports Parallel Testing To compose a test script that supports parallel testing: 1. Using the CoreTests.xml script example you created in the previous steps, locate the isParallel check box for the CPU test set. 2. Mark the CPU test set to run in parallel by clicking the isParallel check box. See below.
Figure 20: Marking test sets to run in parallel
3. Repeat steps one and two for the Hard Drive, Memory, and Motherboard test sets. 4. Click the Save link. Now when you run the CoreTests.xml script on a UUT, all four test sets will begin at the same time instead of running in sequential order.
Composing Test Scripts Designed to Perform Burn-in Testing

Burn-in testing scripts are designed to inflict a heavy stress workload on the UUT. Burn-in testing is also referred to as stress testing, where the persistent heavy workload imposed simulates the wear and tear a typical system goes through during the course of its use. Guidelines for Composing a Test Script that Supports Burn-in Testing To compose a burn-in testing script: 1. Using the CoreTests.xml script example you created in the previous steps, locate the Passes field in the top right corner of the Script pane. 2. Use the mouse to highlight the value in the Passes field. 3. In the Passes field, type 20. See below.
Figure 21: Adjusting the test pass count
4. Click the Save link. Now when you run the CoreTests.xml script on a UUT, it will run 50 consecutive times instead of just once. Several options are available for modifying script behavior by directly editing Network Factory script files. You can locate these files in:
For more information on editing test scripts, SEE ALSO Composing PC-Doctor Network Factory test scripts on page 22.
Using Test Parameters

Some tests include parameters you can adjust that affect how that test runs. Parameter effects range from basic features, such as disabling a test, to complex features, such as adjusting how a video test writes to the video card memory. All tests are affected by two specific global parameters: Passes and Halt On Conditions. Passes indicates how many times a test script will run on a UUT. You can use the Passes count to effectively create a burn-in test script. To change the number of test passes, highlight the passes count and provide a numeric value. Halt On Conditions provides a method for halting all test script operations when a test produces a test result that you specify. To modify Halt On Conditions: Adjusting Halt On Conditions 1. Click the green plus sign next to Halt On Conditions. 2. Begin selecting conditions (test results or events) that will force Network Factory to halt testing. If you want to halt testing when Network Factory produces a test result other than Pass, click the All except Pass link. If you want to quickly deselect all specified Halt On Conditions, click the None link. 3. Continue in this fashion until you have selected all the conditions you want to include. To select more than one condition from the list, hold down the CTRL button while clicking a condition. To select a consecutive range of conditions, hold the SHIFT key down while clicking the last condition in the consecutive range. 4. When finished, click the Save Conditions button. See below.
Figure 22: Modifying Halt On Conditions
Sample Parameter Modification The CoreTests.xml script that you created in the previous section includes two tests with parameters: the Linear Seek Test, and Random Seek Test. To adjust these parameters: 1. Click the green plus sign next to the Linear Seek Test. This will open the Add Parameter dialog box. See below.
Figure 23: The Add Parameters dialog box
2. In the SectorPercentToTest field, type a value you desire. This specifies what percentage of each sector the test will seek through before moving on to the next sector. 3. In the NumberOfSeeks field, type a value you desire. This specifies the total number of seeks the test will perform.
4. In the MaxErrors field, type a value you desire. This specifies the total number of errors Network Factory will allow before logging a Failed test result. 5. In the StartRange field, type a value you desire. This specifies the starting point (in sectors) for the Linear Seek Test. Specifying start and end ranges for seek tests allows you to cut down on test time, and test specific areas of the drive. You can specify this as MIN (starting sector), any valid sector number, or as a percentage. 6. In the EndRange field, type a value you desire. This specifies the ending point (in sectors) for the Linear Seek Test. Specifying start and end ranges for seek tests allows you to cut down on test time, and test specific areas of the drive. You can specify this as MAX (last testable sector), any valid sector number greater than the start range, or as a percentage greater than the start range. 7. Click the Add button. The Progress Monitor will update to reflect the changes you made to the parameters. See below.
Figure 24: Adjusting test parameters
Note: For more detail on PC-Doctor test parameters, SEE ALSO PC-Doctor for Windows 5 Test Descriptions guide.
Setting Up and Running an Inventory Test

Inventory test scripts allow you to verify a system contains the appropriate hardware configuration. Using a system with an ideal hardware configuration, you can use the Inventory Test to record a template of that hardware configuration, and use that template to verify other systems contain the same configuration.
Composing an Inventory Test Script

To compose an inventory test script:
1. Run the following command on the system you want to use as the template system:
pcd uut -s <server-IP>
This command gathers the hardware configuration for the UUT and sends it to the server. Note: If using a port other than 4560 for communication between the UUT and server, specify the port number with the server IP. 2. On the Monitoring Console, click the System Info tab. See below.
Figure 25: The System Info Tab
This opens the System Information pane. 3. Select the system to use as the template system by clicking the System drop-down menu on the top left corner of the System Information pane. See below.
Figure 26: Selecting a template system
4. For View, click the Inventory link. See below.
Figure 27: Selecting the Inventory view
This opens the System Devices list. See below.
Figure 28: System Devices list
5. Select items you want the Inventory Test to check against by clicking the check box next to a device name in the System Devices list. See below.
Figure 29: Selecting devices to include in the inventory template file
Items you check are items Network Factory will use to check against when the Inventory test is run on other systems. 6. When you are done selecting devices to include in the inventory file, scroll to the top of the System Devices list and click the Create New Inventory File button. 7. Type a name for the inventory file in the New dialog box and click the Ok button. Ensure you include the filename extension (.xml). See below. When you save the inventory file, Network Factory opens the Inventory page. From the Inventory page, you can manage all your inventory files, alter which devices inventory files check against, or provide acceptable threshold values that loosen up inventory test requirements. See below.
Figure 30: The Inventory Page
Adjusting Inventory Auditing Criteria Tolerances

Once you have created an inventory file, you can use the Regular Expression Editor to adjust the inventory auditing criteria. The following instructions will guide you in an example of adjusting inventory auditing criteria for installed memory. To use the Regular Expression Editor: 1. Start by clicking a device property link for which you want to provide range tolerances. See below. For example, if you want to provide a range tolerance for the amount of physical memory allowed in tested systems, click the device property link for TotalMemory.
Figure 31: The Regular Expression Editor
This accomplishes two things: populates the Regular Expression Editor with the associated value (including appropriate syntax), and establishes a device association between the Regular Expression Editor and the inventory file you are editing. Note: If you provide range tolerances in the Regular Expression Editor without first establishing a device association, your changes will not be saved to the inventory file. 2. Place the curser just after the caret symbol (^) and click the PCDR Range button. See below.
Figure 32: The PCDR Range expression
This will populate the Regular Expression Editor with a PCDR Range expression. Note: All valid regular expressions begin with a caret symbol (^) and end with a dollar sign symbol ($). Tolerance values must be framed in square brackets ( [] ). 3. Remove the numeric value that was placed in the Regular Expression Editor when you clicked the device property link. Important: Do not remove specified units of measure such as KB, MB, GB and so on. Do not remove the dollar sign symbol ($) that marks the end of the regular expression. 4. You will need to adjust the x and y variables for the PCDR Range expression with appropriate range tolerance values for the device (for more information, SEE ALSO Adjusting Inventory Auditing Criteria Tolerances on page 35).
For example, if you want to provide a range tolerance of 1.0 GB to 2.0 GB for total physical memory allowed in a system, you would write the regular expression like below:
Figure 33: Range tolerance values for total physical memory
5. After you have created a regular expression, you can test it by entering a value in the Test Value field and clicking the Test button. See below.
Figure 34: Testing a Regular Expression
If the value is between the specified tolerances, the Regular Expression Editor will produce a Passed result. 6. If you successfully created a regular expression, you save it to the inventory file by clicking the Save button and clicking the Save link at the top of the Inventory page. If you attempt to leave the Inventory page without clicking the Save link, Network Factory will prompt you to save your changes.
Manually Editing an Inventory File

If you require more robust filtering options, you can extend the capabilities of your inventory testing by manually editing your inventory files. Inventory files are generated in xml format, which requires you have some working knowledge of xml, but you can edit with any text editor. Each inventory file is composed of four basic elements: Inventory-Check, Device, property, and value. Caution: If an inventory file contains junk values (values that are meaningless), do not save the file using Notepad! Saving an inventory script file with junk values using Notepad may corrupt the file. If you need to use Notepad, delete all junk values before you save. The element nesting is as follows:
<Inventory-Check> <Device> <property/> <value/> <property/> <value/> <property/> <value/> </Device> </Inventory-Check>
Each Device element includes a name attribute and a specified device type using a type attribute. Each property element includes a key attribute and can include an optional value attribute. Values expressed in inventory files use the Perl
Compatible Regular Expressions (PCRE) library. For more information on the PCRE library, visit http://www.pcre.org/pcre.txt. Below is an example of specified attributes:
<Inventory-Check> <Device name="AMD Athlon(tm) 64 Processor 3400+ CPU:0" type=CPU> <property key="Family"> <value value="^F H$"/> <property key="Stepping"> <value value="^0$"/> <property key="Model"> <value value="^14$"/> </Device> </Inventory-Check>
Using Logic Elements as Filters In addition to the filtering options covered in the previous sections, you can use three important logic elements to adjust inventory auditing criteria: <and>, <or>, and <not>. These elements are supported anywhere within the inventory file element hierarchy, and do the following: and When an <and> element surrounds two <Device> elements, both devices must be present as part of the matching criteria. This also applies to the <property> element. By default, the inventory script file is generated with an implied <and> element between each <Device> element. So, if you run the inventory test against a system without adjusting the inventory file first, it will look for an exact match on every device in the file. Using an <and> element to specify both devices must be present as part of the matching criteria:
<and> <Device name="AMD Athlon(tm) 64 Processor 3400+ CPU:0" type=CPU> <property key="Family"> <value value="^F H$"/> <property key="Stepping"> <value value="^0$"/> <property key="Model"> <value value="^14$"/> </Device> <Device name="AMD X2 Dualcore 64 Processor 4800+ CPU:0" type=CPU> <property key="Family"> <value value="^F H$"/> <property key="Stepping"> <value value="^0$"/> <property key="Model"> <value value="^14$"/> </Device> <and>
or When an <or> element surrounds two <Device> elements, Device #1 or Device #2 must be present as part of the matching criteria. This also applies to the <property> element. not When surrounding a <Device> element, the device should not be present as part of the matching criteria. This is a way of excluding devices from the matching criteria.
Range Tolerance Symbols

In addition to using logic elements, you can also provide range tolerances to further enhance auditing criteria. Range tolerances allow you to define a range of values for a device or property that is acceptable for passing inventory testing. You can define a specific range of values or use a PCDR# expression to specify values are greater than or less than a specific value. There are five ways to provide range tolerances: > Specifies the matching criteria can be greater than a specific value. Specifies any memory capacity above 256 MB is acceptable.
<property key="TotalPhysicalMemory"> <value value="^PCDR#[>256] MB$"/> </property>
< Specifies the matching criteria can be less than a specific value. Specifies any memory capacity below 256 MB is acceptable.
<property key="TotalPhysicalMemory"> <value value="^PCDR#[<256] MB$"/> </property>
>= Specifies the matching criteria can be greater than or equal to a specific value. Specifies any memory capacity above or equal to 256 MB is acceptable.
<property key="TotalPhysicalMemory"> <value value="^PCDR#[>=256] MB$"/> </property>
<= Specifies the matching criteria can be less than or equal to a specific value. Specifies any memory capacity below or equal to 256 MB is acceptable.
<property key="TotalPhysicalMemory"> <value value="^PCDR#[<=256] MB$"/> </property>
## Specifies the matching criteria can fall anywhere between two specific values. Specifies any memory capacity that falls between 128 and 256 MB is acceptable.
<property key="TotalPhysicalMemory">
<value value="^PCDR#[128-256] MB$"/> </property>
Using Range Tolerance Symbols To adjust inventory auditing criteria in your inventory file using Range Tolerance Symbols: 1. Navigate to the bin directory of your build. By default, inventory files are saved to the bin directory. 2. Use any text editor to open the inventory file. 3. Modify inventory matching criteria using logic elements and regular expressions. Below is an example of a Device element for memory with an adjusted range tolerance for TotalPhysicalMemory. Any system tested with between 128 and 256 MB of memory would pass this inventory test:
<device name="System Memory" type="Memory"> <property key="TotalPhysicalMemory"> <value value="^PCDR#[128-256] MB$"/> </property> <property key="AvailablePhysicalMemory"> <value value="^42.22 MB$"/> </property> <property key="TotalVirtualMemory"> <value value="^2.00 GB$"/> </property> <property key="AvailableVirtualMemory"> <value value="^1.96 GB$"/> </property> <property key="PageFileSpace"> <value value="^617.07 MB$"/> </property> <property key="PageFileLocation"> <value value="^d:\pagefile.sys$"/> </property> </device>
Composing Inventory Script Files

Now that you have created an inventory file and specified tolerance ranges, you will need to create an inventory script. To compose an inventory script: Guidelines for Composing an Inventory Test Script File 1. 2. 3. 4. Click the Script tab. Select the operating system for the script by clicking the Select operating system drop-down menu. Click the New button. Type a file name in the Save Script dialog box and click the Ok button. For example, InvScript.xml.
5. Type a description for the script in the Description field. For example, Inventory Script. 6. Scroll down the Test List until you find the DIAGINVENTORY device category. 7. Select InventoryTest by clicking the check box next to it. See below.
Figure 35: Composing an Inventory Script
8. Click the Add Tests button. 9. Click the Save link. See below.
Figure 36: Saving an Inventory Test script
Generating Inventory Files

To generate an inventory file through the command line: 1. 2. 3. 4. Copy the application build files to a system you plan to use as a template. Navigate to the bin directory of the build. Open a command prompt. Run the following command and replace <inventory-filename> with the name you will use for your inventory file including the xml extension:
pcd inv -g -f <inventory-filename>
The -g option is used to generate the inventory file. The -f option is used to save the report to a file that you specify. This will generate an inventory file, listing all the devices that are part of the system configuration with the filename you specify.
Modifying PC-Doctor Network Factory Configuration

The Config pane allows you add, edit, or delete Network Factory mappings. Mappings are values that apply to defined variables. The groups, configurations, and phases you defined in chapter two are the variables, which are always applied to one of two constants: script and inventory. If you do not specify a group, configuration, or phase for a UUT when connecting it, Network Factory uses a default label of * to define the UUTs group, configuration, and phase. You may want to take a minute to review the Figure 2: Network Factory Mapping Logic Flowchart on page 11. See below.
Figure 37: Config mappings
When you add mappings to your Network Factory configuration, the labels you define for group, configuration, and phase appear in the Edit Mappings section. In the top left corner of the Config pane are a group of links for further refining your Network Factory configuration including adding more mappings, deleting mappings, and editing timing values. You may want to take a minute to review your defined groups, configurations, and phases from chapter two. See below.
Figure 38: Editing config mappings
Implementing your Network Factory mappings

To implement your Network Factory mappings: 1. On the Monitoring Console, click the Config tab. 2. Click the Add New Mappings link. See below.
Figure 39: Adding new mappings
3. Click the Group field. This will place the cursor in the Group field. 4. In the Group field, type the group name you defined in chapter two and press ENTER. For example, rack1. See below.
Figure 40: Defining a Group label
This will populate the Group field with the label rack1. 5. Repeat step three for the Configuration field. 6. In the Configuration field, type Windows and press ENTER. See below.
Figure 41: Defining a Configuration label
This will populate the Configuration field with the label Windows. 7. Repeat step three for the Phase field. 8. In the Phase field, type Functional and press ENTER. See below.
Figure 42: Defining a Phase label
This will populate the Phase field with the label Functional. Defining Mapping Values Before you can add your new mappings, you must define the mapping values. To do this: 1. Click the Script field to open a context menu with available scripts and select a script you want to use for this mapping. See below.
Figure 43: Specifying a script value
2. Repeat step one for the Inventory field. 3. Since the Inventory test will not run as part of this mapping, there is no need to define a value for it. Leave this blank. This will populate the Inventory field with a value of none. 4. Click the Add Entries button. See below.
Figure 44: Specifying an inventory value
Your new mappings are saved to the server and will appear in the Edit Mappings and Delete Mappings section. To ensure your mappings are correctly copied to the server, click the Update Mappings button. See below.
Figure 45: Edit Mappings and Delete Mappings sections
Now when you connect a UUT to your Network Factory server that: Belongs to the rack1 group, and Uses a Windows configuration, and Is entering the Functional phase of testing, Network Factory will use functional.xml and will not conduct inventory testing as specified by your mappings.
Modifying Network Factory Configuration Timing Values

In addition to editing mappings, the Config pane allows you to modify timing values for the entire Network Factory application. This includes time-out values, update intervals, and so on. To edit Network Factory timing values, click the Edit Timings link in the top left corner of the Config pane or by stopping the Network Factory server and edit the file: Caution: If this file is changed while the server is running, database corruption could occur. Shut down the Network Factory server before you edit this file.
<install_path>\Apache2\htdocs\properties
Guidelines for Editing Timing Values You can modify the timing values for Network Factory by doing the following: 1. Click the Edit Timings link located on the left side of the Configuration pane. 2. Adjust the values with appropriate timings for your configuration. Timing values are expressed in seconds. See below.
Figure 46: Timing values for Network Factory
Editing the Sysinfo Filter The SysInfo Filter allows you to adjust how much and what level of information a system information report will generate. If a device or category appears in the Device or Category list on the right, Network Factory will filter out that information when generating system information reports. To add devices and categories to the filter lists: 1. Click the System Info tab. 2. For System, click the drop-down menu and select the system you want to filter. 3. For View, click the Filteringlink. You can also access the SysInfo Filter by clicking the direct link from the Config tab. 4. Click the OK button. See below.
Figure 47: Opening the SysInfo Filter list for a client
This opens a list of devices and properties with checkboxes you use to define filtering. A check in the checkbox specifies that the selected item is included in system information reports. 5. From the list of devices and properties, select items you want to include in system information reports. 6. Click the Save button. See below.
Figure 48: Adding items to system information reports
From this point, when you generate a system information report, it will contain information on the devices you selected. Note: If you make changes to the SysInfo Filter but want to reconfigure the filter back to the default configuration, click the Load Default Filter link. See below.
Figure 49: Loading the default SysInfo Filter for a Linux configuration
Connecting UUTs to the Network Factory Server

Once you have created your script files, inventory file, and defined your mappings, the final step is connecting UUTs to the Network Factory server.
Defining Configuration Labels

As mentioned previously, Network Factory labels the UUT group, configuration, and phase with a default value of * unless you specify these when connecting the UUT. To do this: 1. On the UUT, open a command prompt in the bin directory of the Network Factory client. 2. At the prompt, type the following command and press ENTER:
pcd uut -s <server-IP> -g rack1 -c Windows -p Functional Table 1: Switches used in the above command Switch -s -g -c -p Function Specifies the Network Factory server IP and port number. Specifies the group name to which the UUT belongs. Specifies a configuration label such as the operating system for the UUT. Specifies what particular phase of testing the UUT is entering.
By default, Network Factory will use TCP port 4560 and UDP port 6001 to conduct communication between the UUT and server. If you want to use a different port for this communication, include the port number when running the above command from step 2:
pcd uut -s <server-IP>:<port-number> -g rack1 -c Windows -p Functional
Additional label options for UUTs

In addition to the above label options (-g, -c, -p), you can use the following switches to further label and organize your UUTs.
Table 2: Optional switches for labeling UUTs Switch -a Function Specifies an alias ID for the UUT that appears in the Progress Monitor as Alias. For example, ServerConfig. This switch is optional and purely for tracking purposes only. Specifies a unique system ID for the UUT. You can use an order number for this label as long as it is unique. You can also use the -id switch to capture the SMBIOS serial number for the UUT as the unique system ID (see below). The default value is the MAC address for the network interface card connected to the Network Factory server.
-id
Using the SMBIOS Serial Number as the System ID To specify a UUT system ID using the SMBIOS serial number: 1. For Linux, run the following command:
./pcd uut -s <server-IP> -id \$SMBIOS.SN
or
./pcd uut -s <server-IP> -id \$SMB.SN
You need to escape the $ with the escape symbol. If you don't escape the $, the server gets the id.SN for the system. 2. For Windows, run the following command:
pcd uut -s <server-IP> -id $SMBIOS.SN
or
pcd uut -s <server-IP> -id $SMB.SN
Using the additional label options, the command for connecting the UUT to the server would look like this:
pcd uut -s <server-IP> -g rack1 -c Windows -p Functional -a CoreTests -id $SMBIOS.SN
On the Progress Monitor, you will see the UUT with all the defined label options. See below.
Figure 50: Network Factory label options
50 | PC-Doctor Network Factory Administrator Guide | Installing and Running the Network Factory Client
Installing and Running the Network Factory Client

In this chapter you will find information on: Installing and Running the Windows Client on page 50 Installing and Running the Linux Client on page 50 Running from a Network Share Drive on page 52
Installing and Running the Windows Client

Use the following guidelines for installing and running the PC-Doctor Network Factory Windows Client software: 1. Copy the PC-Doctor Network Factory Client zip file to the directory of your choice on the target UUT. Take note of the directory. 2. 3. 4. 5. Decompress the zip file. Open a command prompt window. Navigate to the bin directory of the PC-Doctor Network Factory Client software in the directory from step 1. Type the following command line and press ENTER:
pcd uut -s <server_IP>
For example:
pcd uut -s 192.168.25.212
The PC-Doctor Network Factory Client will perform license authentication before initiating testing. Once connected, the client will display brief status messages on PC-Doctor Network Factory activity. Test progress will display in the Progress Monitor window. By default, Network Factory uses TCP port 4560 and UDP port 6001 to conduct communication between the UUT and server. If you plan on using a different port for this communication, include the port number with the server IP when running the command from the previous step:
pcd uut -s <server_IP>:<port_number>
For example:
pcd uut -s 192.168.25.212:5555
Installing and Running the Linux Client

Use the following guidelines for installing and running the PC-Doctor Network Factory Linux Client software: 1. Install a Linux distribution. 2. Log in as root and open a terminal window. 3. Copy the PC-Doctor self-extracting file to any directory on the machine.
PC-Doctor Network Factory Administrator Guide | Installing and Running the Network Factory Client | 51
4. Decompress the self-extracting file by doing the following: a) Change directory to where you copied the self-extracting file.
cd <install_path>
b) Change permissions so you can execute the self-extracting file

chmod +x <install_script_name>
c) Launch the self-extracting file:

./<install_script_name>
5. Follow the on-screen instructions to complete the extraction.
Defining File Association Links

Important: If you do not perform the following step, the Linux client will not connect to the Network Factory server. When installing a Linux client, PC-Doctor needs to know where certain files are located. To do this: 1. Add this command to your login script:
export LD_LIBRARY_PATH=<installpath>\pcdoctor\bin
a) For Bash shell users, the login script is located at:

<your_home_path>\.bashrc
a) For C shell users, the login script is

<your_home_path>\.cshrc
Installing the Linux Client

To install the Linux client: 1. Type the following command and press ENTER:
pcd uut -s <server-IP>
For example,
./pcd uut -s 192.168.25.212
By default, Network Factory uses TCP port 4560 and UDP port 6001 to conduct communication between the UUT and server. 2. If you plan on using a different port for network communication, include the port number with the server IP when running the command from step 2:
pcd uut -s <server_IP>:<port_number>
For example:
pcd uut -s 192.168.25.212:5555
52 | PC-Doctor Network Factory Administrator Guide | Installing and Running the Network Factory Client
The PC-Doctor Network Factory Client will perform license authentication before testing begins. Once connected, the client will display brief status messages on PC-Doctor Network Factory activity. Note: For information on configuring a DOS client, SEE ALSO Using the DOS UUT on page 111.
Running from a Network Share Drive

When using a PC-Doctor Network Factory share or other external connection for diagnostics, use the following -bd option:
pcd list -bd clientdata
The above option will place all log files, scripts, debug information and so on into client1 data directory. You can specify a relative or absolute directory. When specifying this option, UUTs will not write to the current directory or any other directory except the one specified by -bd. The reason for this is to run multiple UUTs from a net-mount without having the UUTs over-write other UUT logs and scripts. Using -bd also allows you to run the UUT from read-only media. To use the -bd switch: Note: Network Factory does not support spaces in directory paths or the $NF_SYSTEM_ID flag. If the directory path must contain spaces, you will need to place the directory path between quotes. Windows: pcd uut -s <server-IP> -bd "c:\New Folder\client1" Linux: ./pcd uut -s <server-IP> -bd "/tmp/uut logs/client1" You can use the $NF_SYSTEM_ID variable with the uut command to create a log directory that is specific to the client ID. For example:
pcd uut -s <server-IP> -id client1 -bd "c:\New Folder\$NF_SYSTEM_ID"
A sub-directory called client1 is created in New Folder and Network Factory will use the new path to store log files:
c:\New Folder\client1
If you plan to use the $NF_SYSTEM_ID variable in a Linux environment, keep in mind that the $ symbol indicates an environment variable that Linux will substitute with a specified string. This means you will need to escape the $ sign when using the $NF_SYSTEM_ID variable. For example:
pcd uut -s <server-IP> -bd "/var/logs/pcd/\$NF_SYSTEM_ID
Note: When specifying path or file names, keep in mind that the following characters are invalid in most cases:
\ / " : * ? < > |
About Network Share Limitations

Due to imposed limitations by Windows for loading kernel-mode drivers over a network share, you will need to manually copy driver files to the client drivers directory. This will allow you to run Network Factory from a network share. 1. Navigate to the bin directory of the client build. 2. In the bin directory, locate: pcd5srvc.pkms. 3. Copy and paste the above file to: WINDOWS\system32\drivers
PC-Doctor Network Factory Administrator Guide | The Progress Monitor | 53
The Progress Monitor

In this chapter you will find information on: The Progress Monitor on page 53 The Progress Monitor pane allows you to view test progress and status for UUTs. To view the Progress Monitor pane, click the Progress Monitor tab. When you connect a UUT to the server, you will notice an object representing the UUT appears in the top left corner. See below.
Figure 51: The Progress Monitor
Just above the UUT, you will see six drop-down menus Group, Config, Phase, Alias, Status and Page and two fields for providing date ranges. You can use the drop down boxes to view UUT details for other UUTs based off of specified Group, Config, or Phase labels. You can also view UUT details for testing that occurred during a specific time period by specifying test date ranges. To the right, you will see test run progress bars that dynamically update as tests complete. Note: The Progress Monitor will only display 200 UUTs one page at a time. If you have more than 200 UUTs in your test environment, use the Page menu to alternate between views. On the UUT, you will see two icons. Click the green plus sign to update the system_extra table for the system (for more information on the system_extra table, SEE ALSO Managing the Database on page 75). Click the red and white icon to abort testing at anytime. When testing completes, this icon becomes a red X. Click the red X to hide or display the system in the Progress Monitor view. See below.
54 | PC-Doctor Network Factory Administrator Guide | The Progress Monitor
Figure 52: Test results displayed in real-time
When all test runs complete, the Monitoring Console updates the Status field to display the overall result of the test run. See below.
Figure 53: Overall test result for the UUT
Using the device links on the right, you can view individual component details. When you click one of these links, Network Factory displays a Component Summary Testing report for the specified device. This report includes a Component Information Summary and a Component Testing Summary. See below.
PC-Doctor Network Factory Administrator Guide | The Progress Monitor | 55
Figure 54: Component Testing Summary Report
Note: For more information on Network Factory Reports, SEE ALSO Generating Reports on page 56.
56 | PC-Doctor Network Factory Administrator Guide | Generating Reports
Generating Reports
In this chapter you will find information on: Things You Should Know Before Generating a Report on page 56 Generating a Testing Overview Report on page 58 Generating a Component Overview Report on page 59 Generating a System Information Report on page 60 Generating Custom Reports on page 64 Reports offer an easy way to generate information about test runs and UUTs. When you generate a report, Network Factory will display it in a brief summary view, or a more detailed view. You can print reports by clicking the Show Printable link. See Figure 55: Testing Overview report in Summary view on page 56.
Figure 55: Testing Overview report in Summary view
Things You Should Know Before Generating a Report

Take a minute to familiarize yourself with these features before you generate a report.
About the Hide and Delete System links

There are two links available in this view that perform special functions: hide/unhide and delete system. Even though both links are there to help you manage your test environment, they perform distinctly different functions. See below.
PC-Doctor Network Factory Administrator Guide | Generating Reports | 57
Figure 56: The Hide and Delete System Links
The hide link allows you to temporarily remove the specified system from the Progress Monitor view. When you click this link, Network Factory will remove the specified system from the UUT list. However, the UUT will remain visible in the Reports pane. You will notice that the hide link will turn into an unhide link. Click this link to make the specified system visible though the Progress Monitor view. The delete system link allows you to permanently remove the UUT from the Network Factory database. This includes all files associated with the UUT such as scripts, inventory files, and log files. Danger: Use the delete system link only if you want to permanently remove the UUT and all records of it from your test environment! Once you delete a UUT, all records of it are permanently lost. Network Factory will display a warning prompt if you click this link.
About Report Pane Icons

When you generate a testing overview summary report, three icons are available to the left of each listed UUT. See below.
Figure 57: Report pane icons
The System_Extra icon allows you to update the system_extra table for the specified UUT. For more information on the system_extra table, SEE ALSO Managing the Database on page 75.The System Information icon allows you to automatically generate a system information report for the specified UUT. When you click this icon, Network Factory switches to the System Info tab and displays a complete system information report for the UUT. For more information on generating system Information reports, SEE ALSO Generating a System Information Report on page 60. The Inventory File icon allows you to generate an inventory template file for the specified UUT. When you click this link, Network Factory switches to the System Info tab and displays the hardware inventory for the UUT. From here, you can select or deselect devices to include in your inventory file. Remember to save any changes you make to this file.
About Generating Reports from Active and Archived Databases

When generating reports, you can generate them from an active or archived Network Factory database. To do this, click the Database drop-down menu. If you have archived any databases, they will appear as selections in this menu along with the main Network Factory database. See below.
Figure 58: Selecting an archived or active database
If you want to generate a report for an archived database, the database must be accessible. To verify an archived database is accessible: Note: For more information on archiving databases, SEE ALSO Archiving the PC-Doctor Network Factory Database on page 81. 1. Click the DBAdmin tab. 2. Under the Links menu, click the Manage Archives link. 3. Verify a green check mark appears in the Status field for the database. See below.
Figure 59: Managing database archives
Generating a Testing Overview Report

To generate a Testing Overview report: 1. Click the Reports tab. 2. On the left side of the screen, click the Testing Overview link. 3. Under System, indicate a specific group, configuration, phase, alias or system ID to use as a filter if necessary. This allows you to generate reports for systems if you know what group, configuration or phase they belong to or if you know the system ID number. 4. Under Date, indicate a specific date range to use as a filter if necessary. This allows you to generate reports for systems that were tested within a specific date range. 5. Under View, indicate if you would like to exclude systems that produced a Pass result. You can also indicate if you would like to generate the report from the main Network Factory database or a different database. 6. Click the Generate Report button.
The Monitoring Console will display a testing overview report using the filter options you specify. When you click the System link, Network Factory displays a system testing summary and a detailed system testing report.
Figure 60: Additional report details for Summary view
Figure 61: Detailed System Testing Report
Generating a Component Overview Report

To generate a Component Overview report: 1. On the left side of the screen, click the Component Overview link. 2. Under System, indicate a specific group, configuration, phase, alias or system ID to use as a filter if necessary. This allows you to generate reports for systems if you know what group, configuration or phase they belong to or if you know the system ID number. 3. Under Date, indicate a specific date range to use as a filter if necessary.
This allows you to generate reports for systems that were tested within a specific date range. 4. Under View, indicate if you would like to exclude systems that produced a Pass result. You can also indicate if you would like to generate the report from the main Network Factory database or a different database. 5. Under Component Type, select a component and the specific capability that component supports. 6. Click the Generate Report button. Network Factory will display a Component Overview report. See below.
Figure 62: A Component Overview report
Generating a System Information Report

In general, System Information is a report that you can generate for UUTs that detail the various components found in the system.
Guidelines for Generating a System Information Report

To access system information 1. Click the System Info tab. See below.
Figure 63: The System Information pane
This opens the System Information pane.
2. Click the System drop-down menu. 3. Select the system you want to view. See below.
Figure 64: The System drop-down menu
4. For View, click the link that represents the system information perspective you want to see outlined in the report. The View links allow you to view system information reports using different methods to organize the data. For example, the Device Category view lists devices in a system according to what category of device it belongs. See below.
Figure 65: The Device Category view
The Device Capability view list devices in a system according to the functions the device supports. See below.
Figure 66: The Device Capability view
The Device Connection view list devices in a system according to its relationship with other devices. Network Factory displays this information in a collapsible tree view. A plus sign (+) next to a device in the Device Connection view indicates other devices connect to the device in a hierarchy. See below.
Figure 67: The Device Connection view
For the purposes of this exercise, leave the View unchanged. 5. Under Device Types, select All Device Types. See below.
Figure 68: Selecting All Device Types
6. For Property Types and Property Tiers, leave the selections unchanged and click the OK button. See below.
Figure 69: Property Types and Tiers
Network Factory will generate a system information report for the Device View, Device Types, Property Types, and Property Tiers that you specify.
Generating Custom Reports

You can create custom reports from scratch or modify an included sample report and use them in your test environment. These are found in:
<Install-Path>\Apache2\htdocs\src\custom_reports
Any files added to this directory will display as hyperlinks in the Custom Reports section of the Reports pane. The reports are based on PHP, a common web scripting language. You can achieve more complex integration by linking to other web servers and using ODBC to run SQL queries. To quickly familiarize yourself with custom report generation, the file ODBC_Example.php shows a simple report that uses PHP and ODBC. Other reports use the database directly using SQL queries. Caution: Please copy and rename the file and leave in the same directory. The reports should never modify the database except for calling the stored procedures in the system_extra table. For more information on the system_extra table, SEE ALSO Managing the Database on page 75. To view this report, you must perform the steps outlined in ODBC Connectivity with Firebird Database for Creating an ODBC Datasource Name. You must also add a user account with ODBC privileges. The common reports are included in: <Install_Path>\Apache2\htdocs\src For more information on adding and modifying user accounts, SEE ALSO Creating and Managing Accounts on page 72.
PC-Doctor Network Factory Administrator Guide | Managing Components through a Parts List | 65
Managing Components through a Parts List

In this chapter you will find information on: Defining a New Part on page 65 Managing Parts on page 68 Modifying Part Details on page 68 Using a Parts File to Test Hardware Configurations on page 70 A Network Factory Part is a component that is associated with a specific product ID that is defined in an organizations Bill of Materials (BOM). Using a Parts list, you can associate components detected by Network Factory with product IDs that sync with organizational processes. When used as a tool for reporting, defining parts allow you to effectively manage and track detected components through a centralized Parts list. Parts files are composed of XML and are almost identical in structure to inventory files. Network Factory features for inventory files, including Using Logic Elements as Filters on page 38 and Adjusting Inventory Auditing Criteria Tolerances on page 35, are also supported in Parts files.
Defining a New Part

1. Connect a UUT to the server you want to use for developing a Parts list. For example:
pcd uut -s <server_IP> -g <group> -c <configuration> -p <phase>
2. Click the System info tab. 3. At the top of the page, click the Parts link. 4. Click the System drop-down menu and select the system you will use as a basis for your Parts list. See below.
66 | PC-Doctor Network Factory Administrator Guide | Managing Components through a Parts List
Figure 70: Selecting a system to create a Parts list.
When you select a system, a devices list will appear on the right. 5. In the devices list, select device properties that you would like to define for the part. For example, if a system contains an AMD Athlon (tm) 64 3000+ CPU and this is a CPU requirement for other systems you test, you would check the CPU specification property in the devices list. The device properties you select are used by the Parts Verification test to determine if detected components in other systems adequately satisfy Parts list requirements. 6. When done selecting device properties, click the Create New Part button. See below.
Figure 71: Defining device properties for a part.
This will open a dialog window for associating a part ID with the part. 7. Type the part ID and click the OK button.
Figure 72: Defining the part ID.
Network Factory will automatically switch to the Parts tab with the part you just created selected. The description for the part is the part ID by default, which you can change from the Parts page. For more information on modifying part details, SEE ALSO Modifying Part Details on page 68.
Managing Parts
The Parts page provides features for you to manage your parts list. When you click the Parts tab, the currently loaded Parts list is shown on the left side of the page. By default, parts list files are saved as parts.xml, which are located in:
<install_directory>\Apache2\htdocs\src\parts
Figure 73: Managing a part from the Parts tab.
Modifying Part Details

If a part in the list is selected, a summary of the part is shown to the right of the list. This summary includes: Part ID: The actual part number your organization uses for inventory tracking. Part Description: A human-readable label for the part, which you can modify once a part is created. The Part Description for all new parts is the Part ID by default. Part Revision: Keeps track of revisions to part information.
Figure 74: Part details summary.
To view the XML structure for a part, click the Show XML link. The structure will resemble the following example.
Figure 75: XML structure for a part.
Caution: Editing XML files for Network Factory is an advanced feature. You should only edit XML manually if you have experience working with XML. To modify the details of a part, click the Edit Part button. Network Factory will switch to the part revision page where you can edit component data using regular expressions (SEE ALSO Adjusting Inventory Auditing Criteria Tolerances on page 35). See below.
Figure 76: The part revision page.
Note: If you save any changes to part details with the exception of the Part ID, you will create a new part revision. If you save any changes to the Part ID, you will create a new part using the properties shown.
Using a Parts File to Test Hardware Configurations

When you are done defining parts, you can use the part data to verify other systems contain the same parts.
About the extras.xml File

The extras.xml file lists high-dollar components and acts as a gatekeeper for the Parts Verification Test to ensure systems do not contain extra devices. If a system contains an extra device type defined by extras.xml, it will fail the Parts Verification Test. The extras.xml file is configurable using any standard text editor and is located in:
<install_directory>\Apache2\htdocs\src\parts
Running a Parts Verification Test

The following steps guide you in running a Parts Verification test. These steps reference example_parts.pf as a sample parts file. Note: The Parts Verification Test will always run as the first test when you connect a UUT with the -pf option. This is reflected in the Progress Monitor. Even though the Parts Verification Test runs as the first test, it runs independently of your test script. You cannot add the Parts Verification Test to a test script through the Script Editor. 1. On the UUT, open a command prompt. 2. Navigate to the bin directory of the Network Factory client build. 3. When connecting the UUT to the server, indicate the parts file to use with the Parts Verification Test using the -pf option. Keep in mind a parts file (.pf) contains part IDs scanned from your organizations BOM that Network Factory can programmatically parse. For example: pcd uut -s <server_IP> -pf example_parts.pf -g <group> -c <config> -p <phase>
This command will download a test script defined by Network Factory mappings, the parts.xml file, the extras.xml file and runs the Parts Verification Test as the first test. At this point, the client does the following: a) Parses example_file.pf. b) Looks in parts.xml for all the part numbers found in example_file.pf. c) Pre-pends any device types defined in extras.xml to the inventory file stored in memory. d) Conducts the Parts Verification Test using the pre-pended inventory file stored in memory. The Parts Verification Test will report one of three results: Pass: All the parts found in example_file.pf were successfully found on the UUT. Also, Network Factory did not detect any extra parts defined in extras.xml. Fail: One or more parts found in example_file.pf were not found on the UUT or Network Factory detected extra parts that are defined in extras.xml. Misconfigured: A problem exists with parts.xml or extras.xml that is preventing the Parts Verification Test from running.
Figure 77: The Parts Verification Test as seen in the Progress Monitor.
Figure 78: An example of Parts Verification Test log error messages.
72 | PC-Doctor Network Factory Administrator Guide | Creating and Managing Accounts
Creating and Managing Accounts

In this chapter you will find information on: The User Mgmt Tab on page 72 Adding a User Account on page 73 Modifying User Account Privileges on page 73 Deleting User Accounts on page 73
The User Mgmt Tab

You can quickly and easily create, modify, and delete user accounts for Network Factory by using the User Mgmt tab. See below.
Figure 79: The User Mgmt tab
Network Factory functions are granted through an account privileges tier. There are four default account privilege login accounts, which provides access to the following Network Factory functions:
Account Guest Tester Manager Account privileges View tested systems through the progress monitor and run reports. View tested systems, edit system extra information, and run reports. View tested systems, edit system extra information, run reports, gather system information, generate inventory files, create and modify test scripts, All available privileges.
Admin
PC-Doctor Network Factory Administrator Guide | Creating and Managing Accounts | 73
Note: We recommend you change the default administrator account for security purposes.
Adding a User Account

To add a user account: 1. In the User Name field, type the login name for the account. 2. In the User Password field, type the login password for the account. 3. In the Re-Enter Password field, type the password exactly as you did in the User Password field. 4. Select user privileges for the account. 5. Click the Add User button. See below.
Figure 80: Adding a user account
The new user will be added to the list of available accounts.
Modifying User Account Privileges

To modify user account privileges: 1. Deselect account privileges that are not appropriate for the account. 2. Select account privileges you want to include for the account. 3. Click the Update button. See below.
Figure 81: Modifying a user account
The Monitoring Console will refresh to reflect the modifications to user privileges.
Deleting User Accounts

To delete a user account:
74 | PC-Doctor Network Factory Administrator Guide | Creating and Managing Accounts
1. Click the Delete Account link or scroll to the bottom of the User Mgmt pane. 2. Select an account by clicking the check box next to the account login. 3. Click the Remove User button. See below.
Figure 82: Deleting a user account
The Monitoring Console will refresh to reflect that an account was deleted.
PC-Doctor Network Factory Administrator Guide | Managing the Database | 75
Managing the Database

In this chapter you will find information on: The DBAdmin Tab on page 75 Adding Data to the system_extra Table on page 75 Adding Fields to the system_extra Table on page 76 Maintaining the Network Factory Database on page 78
The DBAdmin Tab

The DBAdmin pane provides access to a custom database table called system_extra. This table allows you to add extra information to the Network Factory database, and is automatically associated with each system that is tested. For example, you can use the system_extra table to add a tester_id field, allowing you to track who tested what system. See below.
Figure 83: The DBAdmin Features
Adding Data to the system_extra Table

To add data to the system_extra table through either the Progress Monitor or Reports pane: 1. Click the green plus sign (+) to the left of a UUT. See below.
76 | PC-Doctor Network Factory Administrator Guide | Managing the Database
Figure 84: system_extra table access through the Progress Monitor pane.
Figure 85: system_extra table access through the Reports pane
This will open the Extra System Information window. See below.
Figure 86: The Extra System Information window
2. Type the name of the tester in the tester field. For example, Joe Tester. 3. Type the e-mail address for the tester in the tester_email field. For example, joetester@tester.com. 4. Click the Update Record button.
Adding Fields to the system_extra Table

To add fields to the system_extra table through the DBAdmin pane: 1. Create the Field Name field by typing a name for the extra data you want to display. See below. For example, order_number.
Figure 87: system_extra Table Field Name
2. Modify the Default Value field. See below.
Figure 88: system_extra Table Default Value
3. Click the Add fields button. This will add a order_number to the system_extra table with a default value of abc123. See below.
Figure 89: system_extra table custom field
There are three ways you can add data to the newly created field: Click the + next to the UUT system ID on the Progress Monitor or Reports pane. On the UUT, use the -e or -eo option with the pcd uut command. For more information on available command line options, SEE ALSO PC-Doctor 5 Command Line Interface Guide. Using the ODBC connection, connect directly to the database and update the field.
Updating the system_extra table using SQL The instructions below demonstrate how to use SQL to call a stored procedure that updates the system_extra table: 1. Connect through ODBC to the PC-Doctor Network Factory Database. 2. Use stored procedures:
insert_system_extra( system_id INTEGER, ...) ... refers to every field defined for the system_extra table, by default ... = tester VARCHAR(1024), tester_email VARCHAR(1024)
update_system_extra( system_id INTEGER, ...) ... refers to every field defined for the system_extra table, by default ... = tester VARCHAR(1024), tester_email VARCHAR(1024) delete_system_extra( system_id INTEGER )
Updating the system_extra table using ColdFusion The example below shows the suggested way to call a stored procedure to update the system_extra table directly using ColdFusion. The field names shown in this example (phase_1_complete, phase_2_complete, and so on) are simply sample fields. These field names will be the field names created when adding additional fields using the DBAdmin tab of the Monitoring Console.
 <CFQUERY NAME="updateSystemExtra" DATASOURCE="PCDR"> EXECUTE PROCEDURE update_system_extra 94478, 'false', 'false', 'false', 'false' </CFQUERY>  <CFSTOREDPROC PROCEDURE="update_system_extra" DATASOURCE="PCDR" RETURNCODE="No"> <CFPROCPARAM TYPE="In" CFSQLTYPE="CF_SQL_INTEGER" VALUE="94474" NULL="No" DBVARNAME="system_id"> <CFPROCPARAM TYPE="In" CFSQLTYPE="CF_SQL_VARCHAR" VALUE="false" NULL="No" DBVARNAME="phase_1_complete"> <CFPROCPARAM TYPE="In" CFSQLTYPE="CF_SQL_VARCHAR" VALUE="false" NULL="No" DBVARNAME="phase_2_complete"> <CFPROCPARAM TYPE="In" CFSQLTYPE="CF_SQL_VARCHAR" VALUE="false" NULL="No" DBVARNAME="phase_1_email_sent"> <CFPROCPARAM TYPE="In" CFSQLTYPE="CF_SQL_VARCHAR" VALUE="false" NULL="No" DBVARNAME="phase_2_email_sent"> </CFSTOREDPROC>
Updating the system_extra table using PHP The example below shows the suggested way to call a stored procedure to update the system_extra table directly using PHP:
$db = odbc_connect("nf5dsn", "odbc", "odbc"); if(!$db) die("could not open dsn"); // insert a new record into system_extra $sql = "EXECUTE PROCEDURE insert_system_extra 1, 'New Tester', 'NewTester@Testers.org'"; odbc_exec($db, $sql); // update the record with new information $sql = "EXECUTE PROCEDURE update_system_extra 1, 'Other Tester', 'OtherTester@Testers.org'"; odbc_exec($db, $sql); // delete the record because it is boring $sql = "EXECUTE PROCEDURE delete_system_extra 1"; odbc_exec($db, $sql); odbc_close($db);
Maintaining the Network Factory Database

The DBAdmin tab also provides access to Network Factory database maintenance tools. As more and more UUTs send data to the Network Factory database, the database will start to get considerably large and you will need to perform regular maintenance. Doing this will keep your Network Factory server and clients running at peak efficiency. You can break down the maintenance into two different procedures: Archiving the database: Ideally, you should archive your systems once a month for maximum efficiency. Backing up the database:
Important: We highly recommend you perform this procedure once a week. If your test environment includes at least 50 UUTs, this procedure is required. Network Factory does the following when archiving a Network Factory database: 1. Brings the uutUploadServer down. Clients will not be able to connect after this step. 2. Runs a Backup and Restore on the production database. 3. Performs a filesystem copy of the production database to the archive database. 4. Runs the archiving scripts on the new archived database. This deletes all systems that have not been archived. These systems will remain in the production database. 5. Run the archiving scripts on the production database. This deletes all systems that have been archived. These systems are in the archived database in step 4. 6. Runs Backup and Restore on the archive database. 7. Runs Backup and Restore on the production database. 8. Brings the uutUploadServer up. Clients will be able to connect after this step. Note: For information on archiving a database, SEE ALSO Archiving the PC-Doctor Network Factory Database on page 81. Network Factory does the following when backing up and restoring a Network Factory database: 1. Takes the production database offline so that data stays consistent. Clients will not be able to connect after this happens. 2. Makes a filesystem copy of the untouched production database in case Backup/Restore fails. 3. Runs the following command: gfix -mend -full -ignore . This will prepare the production database for backup 4. Runs the following command: gbak -b. This will create the compressed backup file. 5. Runs the following command: gbak -c . This will restore the compressed backup file to a cleaned-up and optimized functional database file. 6. Overwrites the production database with the newly restored database file. 7. Brings the new production database online. Clients can now connect. Note: For more information on backing up and restoring a database, SEE ALSO Backing up the PC-Doctor Network Factory Database on page 84 The following diagram demonstrates the process flow and Network Factory database component relationships when archiving.
Figure 90: Network Factory Archiving Process Flow
Before You Begin

Before performing either function, its a good idea to create directories for preserving your archives and backups. 1. Create an NF5_ARCHIVES directory, preferably on a separate machine or network drive that has redundant storage and frequent backups. 2. Create an NF5_BACKUPS directory, preferably on a separate machine or network drive that has redundant storage and frequent backups. 3. Copy the archive and backup files from the archives and backup directories. Archives are located in: <install_directory>\Apache2\htdocs\archives Backups are located in: <install_directory>\Apache2\htdocs\backups
Archiving the PC-Doctor Network Factory Database

PC-Doctor Network Factory uses Firebird as the database server, which is stored in the following location:
<installation_directory>\Firebird
You can perform database maintenance manually through the Progress Monitor, command line or schedule a regular maintenance task through the Task Scheduler. For more information on scheduling a task, SEE ALSO Using the Task Scheduler on page 83. Network Factory will backup the database before and after archiving old systems. After the archiving is complete, you will find a newly created archive and a newly created backup in the following directories: For backups:
<installation_directory>\Apache2\htdocs\backups
For archives:
<installation_directory>\Apache2\htdocs\archives
Important: To avoid database corruption, the Network Factory server will halt all testing and cut off communication with UUTs until it completes the archive or backup process. If a UUT is in the middle of testing when a scheduled archive or backup/retore occurs, the UUT will continue to test until completion but will not upload the results to the server. Monitoring Console Archiving Guidelines Caution: Ensure that nothing is writing to the database file before beginning the archive process. To archive the database from the Monitoring Console: 1. Click the DBAdmin tab. 2. Under the Links menu, click the Archive Database link or scroll down to the Archive Database section. 3. For Archive Systems Tested, provide a date range for systems you would like to archive. 4. For Archive name, type a name for the archive that will display in the Monitoring Console. 5. For Archive directory, copy/paste or type the directory path to the archive. 6. Click the Begin Archive button. See below.
Figure 91: Archiving the Network Factory database
A warning dialog will appear pointing out that the changes you are making will influence the database schema. 7. Click the OK button to continue with the archive. An Archive Report window will open. 8. Click the Begin Archive button to complete the archive. See below.
Figure 92: The Archive Report window
Command Line Archiving Guidelines Caution: Ensure that UUTs are not connected to the server prior to performing this. To archive the database from the command line: 1. 2. 3. 4. 5. Open a command window on the server. Navigate to: <install_path>\apache2\htdocs\src\batches. Run the following command: archive_database.cmd Answer Yes at the prompt. Run the following command: backup_database.cmd -r The purpose of this command is to reduce the size of the main database and optimize performance. Available Archiving Command Line Options You can use the following options with archive_database.cmd: -s Archives the database in silent mode.
archive_database -s
h Displays optional switches to use with the archive_database.cmd.
archive_database -h
-name Provides a name for the archive that will appear in the Reports pane. This example runs archive_database.cmd using functional-10.01.07 as the archive name
archive_database -name functional-10.01.07
-path Specifies the directory path to the archive.
This example runs archive_database.cmd and places the archive in C:\recent_archives.

archive_database -path "C:\recent_archives"
-from When archiving systems that were tested within a specific date range, this switch defines the start date. This example runs archive_database.cmd, archives systems that were tested between August 1st, 2007 and September 1st, 2007, and copies the archive to C:\recent_archives.
archive_database -from 08/01/2007 -to 09/01/2007 -path "C:\recent_archives"
-to When archiving systems that were tested within a specific date range, this switch defines the end date. This example runs archive_database.cmd, archives systems that were tested between August 1st, 2007 and September 1st, 2007, and copies the archive to C:\recent_archives.
archive_database -from 08/01/2007 -to 09/01/2007 -path "C:\recent_archives"
-keep This switch allows you to archive all systems except for systems tested within the last 0-52 weeks. This example runs archive_database.cmd and archives all systems tested except those tested within the last two weeks.
archive_database.cmd -keep 2
Using the Task Scheduler If you schedule an archive through the Task Scheduler, you must ensure that the task will occur at a time when no other system is connected to Network Factory. Network Factory will disconnect all running systems when the scheduled task starts. To use the Task Scheduler: Note: This feature is only compatible with XP Pro or Server 2003. 1. Scroll to the bottom of the DBAdmin pane or click the Scheduled Task link. Note: PC-Doctor recommends you use the default settings when scheduling an archive. The default settings are to archive the database every four weeks and to keep four weeks of systems in the main production database during each archive. 2. For Scheduled Time, specify the exact time you want the archive to occur. 3. For Day of the week to run, indicate the day of the week you want the archive to occur. The default is Saturday. 4. For Backup and clean database every, indicate the time interval for when this occurs. The default is every four weeks. 5. For On backup, keep in production database the last, indicate how many weeks of data to keep stored for UUTs.
The default is four weeks. Note: The first time this runs, all the systems are preserved since they are all less than four weeks old. 6. For Path for archive directory, indicate the directory path where you will save the archive. The default is: <install_directory>\PC-Doctor Network Factory Server\Apache2\htdocs\archives Using the Archive Scheduler You can setup Network Factory to automatically perform scheduled archives at regular intervals through the Archive Scheduler. 1. For Scheduled time, use the drop-down menus to define the time when the archive is to occur. 2. For Day of the week to run, use the drop-down menu to select a day of the week on which the archive should occur. 3. For Backup and clean database every, use the drop-down menu to select how often Network Factory performs database maintenance. 4. For On backup, keep in production database the last, to specify how many weeks of data to perserve in the archive. 5. For Path for archive directory, specify the directory path Network Factory will use to store archives. 6. Click the Create Windows Task button. Network Factory will automatically perform an archive of the database using the date/time/location you specify. See below.
Backing up the PC-Doctor Network Factory Database

As explained earlier, although Network Factory performs a backup of the database prior to archiving, you should still perform or schedule periodic backups of the production database to keep it running efficiently. Important: To avoid database corruption, the Network Factory server will halt all testing and cut off communication with UUTs until it completes the archive or backup process. If a UUT is in the middle of testing when a scheduled archive or backup occurs, the UUT will continue to test until completion but will not upload the results to the server. Available Backup Command Line Options You can use the following options with backup_database.cmd. Note: These options must be used concurrently when running backup_database.cmd. -d Specifies the production database file Network Factory will backup.
This example will restore a backed up database (NF5.fdb) and store it in C:\recent_backups.
backup_database -d "<install_directory>\Apache2\htdocs\data\NF5.fdb" -b "C:\recent_backups"
-b Specifies the target directory path where Network Factory will store the backup. This example will restore a backed up database (NF5.fdb) and store it in C:\recent_backups.
backup_database -d "<install_directory>\Apache2\htdocs\data\NF5.fdb" -b "C:\recent_backups"
General Backup Guidelines To backup and restore the Network Factory database: 1. Open a command prompt. 2. Navigate to: <install_path>\Apache2\htdocs\src\batches 3. Run the following command:
backup_database.cmd
4. Locate the database backup in: <install_directory>\Apache2\htdocs\backups The backup will reside in a directory with the current date and time stamp. 5. Copy and paste the database backup to your NF5_BACKUPS directory. SEE ALSO Archiving the PC-Doctor Network Factory Database on page 81.
86 | PC-Doctor Network Factory Administrator Guide | The Help Tab
The Help Tab

In this chapter you will find information on: Available Help Tab Features on page 86 Sample Network Factory Database Schema on page 87 Database Configuration Information on page 87 Reporting an Issue on page 87
Available Help Tab Features

The Help tab provides tools and documentation that support your use of Network Factory. Through the Help tab, you can: Summarize testing information Look up schema and server version information Look up specific database schema details Check the status of the license server View Network Factory user interface and diagnostic documentation. Report defects and issues. See below.
Figure 93: The Help tab
Note: If the License Server status is anything other than OK, your UUTs will not connect to the server.
PC-Doctor Network Factory Administrator Guide | The Help Tab | 87
Sample Network Factory Database Schema

The Help tab also provides access to Network Factory configuration information and a sample database schema. When you click the Database Schema link, the Monitoring Console displays a functional PC-Doctor Network Factory database schema. If you use the schema frequently, you may want to save the image locally (usually by right-clicking on it). You can then use a standard graphics application such as MS Paint to print it out or zoom-in on specific regions. See below.
Figure 94: Sample PC-Doctor Network Factory database schema
Database Configuration Information

You can access information about the database configuration by clicking the Database Tables.pdf link You can also find the Database Tables.pdf by looking in <install_directory>\PC-Doctor Network Factory Server\Apache2\htdocs\docs.
Reporting an Issue
If Network Factory encounters a critical error during the course of operation, it will draw attention to the error by producing an alert with a link to the Error Report Form.The Error Report Form is accessible through the Help tab. You can use the Error Report Form to fill out detailed bug reports, attach screenshots, attach all of the applicable client log files and send it all to your PC-Doctor customer representative. Once the form is filled out, Network Factory will compile the server logs along with the form information and any additional files that have been attached into a zip file. See below.
Figure 95: The Error Report Form
Filling Out the Error Report Form To complete the Error Report Form: Note: All fields marked with an asterisk are required to complete the form. 1. For the Company name field, type the name of your company. 2. For the Engineer name field, type the name of the engineer who discovered the error. 3. In the Detailed description field, provide a thorough description of the error. 4. In the System information field, provide any relevant system information reports. If the error occurred on the server, provide PC-Doctor with the hardware and software configuration information for the server. If the error occurred on a UUT, provide PC-Doctor with the hardware and software information for all relevant UUTs. 5. In the Steps to reproduce field, provide a thorough step-by-step list of actions performed to produce the error. 6. For the Severity of issue/request drop-down menu, select a level of severity that matches the impact of the issue on your production environment. 7. For the Priority of issue/request drop-down menu, select a level of priority that matches the urgency of issue resolution for the error. 8. For the Script file(s) field: a) Click the Browse... button. b) Navigate to the location of diagnostic script file that was used when the error occurred.
<installation_directory>\Apache2\htdocs\scripts
c) Double-click the script file. You can include multiple script files if necessary.
PC-Doctor Network Factory Administrator Guide | The Help Tab | 89
Note: This field is mandatory if the error occurred on a UUT. 9. For the Client UUT log(s) field: a) Click the Browse... button. b) Navigate to the location of the UUT log file for the UUT that produced an error. c) Double-click the log file. You can include multiple log files if necessary. Note: This field is mandatory if the error occurred on a UUT. 10. For the Screenshot(s) field, attach any screenshots that help support issue resolution. Note: Screenshots of the Progress Monitor and UUT screen are mandatory when reporting UUT-specific errors. However, you may want to consider providing screenshots for sever errors too. Although screenshots are optional for server errors, they are still a valuable tool for troubleshooting. 11. Click the Proceed button. Network Factory will process the request and package all necessary files into a zip file. You will need to save the file to a location that can be reached when this file is e-mailed to PC-Doctor. Important: Do not navigate away from the page that appears when you click the Proceed button until after you have saved the Error Report Form zip package. If you do, you will lose your report and will need to repopulate the Error Report Form. See below.
Figure 96: Saving the Error Report Form
Disabling Critical Error Warnings The critical warning banners at the top of the monitoring console pages can be turned off using the following procedure. This will not prevent the errors from occurring nor will it prevent the errors from logging, it will simply disable the banner warnings. To disable critical error warnings:
1. On the Network Factory server, navigate to:

<install_directory>\Apache2\htdocs\properties
2. Locate the file: network_factory.properties 3. Open the file using a standard text editor. 4. Locate the parameter: nf.errors.debug The default value for nf.errors.debug is no, which enables critical error warnings. 5. Change the value of nf.errors.debug to yes. Critical error warnings will now no longer appear when Network Factory encounters a critical error. However, you can still access the Error Report Form and report issues as you normally would.
PC-Doctor Network Factory Administrator Guide | Troubleshooting Tips and FAQ | 91
Troubleshooting Tips and FAQ

In this chapter you will find information on: Installation and Setup on page 91 Using Network Factory Features on page 93 PC-Doctor Network Factory Database on page 95 The following are answers to common questions and issues you may have while installing or using PC-Doctor Network Factory:
Installation and Setup

What type of hardware should I use for maximum efficiency?
PC-Doctor recommends a dual 64-bit processor system with a minimum of 2GB memory and a SATA RAID hard drive. Although this configuration is not required to run Network Factory, it is ideal for maximum efficiency and scalability.
How do I make sure that my installation goes smoothly?

Ensure there are no running servers (Web, IIS) on the port where you install the PC-Doctor Network Factory server (default is 8080).
UUTs do not show up in the Progress Monitor

Check the following: Ensure the UUTs are connecting with the correct hostname for the PC-Doctor Network Factory Server. For example: pcd uut -s 192.168.78.78. If you are using a different port for communication between the UUT and server than the default port (4560), ensure you specify the correct port number when connecting to the server. Ensure the License Server is active. Under The Help Tab on page 86, look for License Server Status: OK. If it is anything other than OK, the License Server will not authenticate UUTs. Check that there is network connectivity between the Client and Server.
My UUTs are listed as UUT_TIMED_OUT, but the UUTs are still running.
PC-Doctor Network Factory has configuration settings for how long to wait for a UUT before declaring it as UUT_TIMED_OUT. It may be that your UUTs are slow and the time-out settings are not set high enough. Click the Configuration tab on the Monitoring Console, click on View Configuration, and look for:
[ nf.inactive.uut.timeout ] 120 [ nf.enumeration.uut.timeout ] 120
These values are expressed in seconds. Try to set these values to a higher value. To do this, edit the Network Factory properties file located here:
<install_directory>/Apache2/htdocs/properties/network_factory.properties
92 | PC-Doctor Network Factory Administrator Guide | Troubleshooting Tips and FAQ
Can I use my own serial loopback adapter with PC-Doctor Network Factory?
PC-Doctor, Inc. recommends that you use only PC-Doctor provided loopback adapters. If you need to acquire PC-Doctor loopback adapters, please contact your PC-Doctor Customer Relationship Manager or sales representative.
How do I reduce the amount of time a test script needs to run?

Look in:
<install_directory>\Apache2\htdocs\src\p5ms\<operating_system>
Guidelines for Decreasing Test Times Using the hard drive test as an example: 1. Open the pcdrharddrive.p5m file. 2. Find the test section in this file for the test you would like to modify. 3. Find the parameters you would like to modify. 4. Open the xml script that you want to modify. 5. Open the harddrivetest.xml in:
In this example, the surface scan test has been modified to scan a percentage of the hard drive instead of the entire hard drive. See below.
<?xml version="1.0" encoding="UTF-8"?> <Script description="Hard Drive tests" passes="1"> <TestSet description="" isParallel="false"> <Test key="LinearSeekTest" module="pcdrharddrive" capabilities="HardDrive"/> <Test key="RandomSeekTest" module="pcdrharddrive" capabilities="HardDrive"/> <Test key="FunnelSeekTest" module="pcdrharddrive" capabilities="HardDrive"/> <Test key="PatternTest" module="pcdrharddrive" capabilities="HardDrive"> <Parameter key="SystemDiskPatternTest" value="true"/> <Test key="SurfaceScanTest" module="pcdrharddrive" capabilities="HardDrive"> <Parameter key="StartRange" value="MIN"/> <Parameter key="EndRange" value="20%"/> <Parameter key="SectorPercentToTest" value="10"/> <Test key="SurfaceScanTest" module="pcdrharddrive" capabilities="HardDrive"> <Parameter key="StartRange" value="80%"/> <Parameter key="EndRange" value="MAX"/> <Parameter key="SectorPercentToTest" value="10"/> </Test> </TestSet> </Script> </Test>
</Test>
How do I run a Pattern Test on my system drive?

Danger: The pattern test has the potential to remove existing data on the hard drive. Do not run this test if the tested drive contains sensitive data!
Using the same method demonstrated in the previous Q and A, you will need to change the value of the SystemDiskPatternTest parameter from false (the Pattern Test will not run on the system drive) to true (the Pattern Test will run on the system drive). See below.
<Test key="PatternTest" module="pcdrharddrive" capabilities="HardDrive"> <Parameter key="SystemDiskPatternTest" value="true"/></Test>
How do I modify the server port numbers after Network Factory is installed?
To change the license server port number look in:
<install_directory>\Apache2\htdocs\properties\network_factory.properties
Look for the following property and modify it with your license server port number:
nf.authentication.server.port = 4586
To change the HTTP port number, look in:

<install_directory>\Apache2\conf\httpd.conf
Look for the following parameter and modify it with your HTTP port number:
Listen 8080
Note: If you make changes to either of these files, you must restart the Network Factory server.
I just upgraded Network Factory but nothing has changed

Your Web browser is probably displaying a cached version of the Progress Monitor. Before you upgrade to a new version of Network Factory, make sure you clear the browser cache.
Using Network Factory Features

How do I increase the amount of time a UUT is tested?
To increase the amount of time a UUT is tested: 1. Click the Scripts tab. 2. Open the script you want to modify. 3. In the Passes field, increase the value to a desired pass count. See below.
Figure 97: Increasing the Passes count
Passes indicate how many times the script will run on UUTs. This effectively increase the total amount of time the UUT will remain under test. 4. Click the Save link located at the top of the Scripts pane. The next time the script runs, it will run all the tests it contains the number of times indicated by the Passes field.
How do I decrease the amount of time a UUT is tested?

To decrease the amount of time a UUT is tested, do the following: 1. 2. 3. 4. Click the Scripts tab. Open the script you want to modify. For each test in the script, locate the isParallel check box. Click the isParallel check box for each test in the script. A check mark will appear in the check box, indicating the test will run simultaneously with other tests configured to run in parallel. 5. Click the Save link located at the top of the Scripts pane. The next time the script runs, it will run all tests configured to run in parallel simultaneously. This effectively decrease the total amount of time the UUT will remain under test. For more information on running tests in parallel, SEE ALSO Composing Test Scripts Designed to Run Tests in Parallel on page 28. Note: You can not specify tests that run on the same device to run in parallel. For example, you can not specify a Linear Seek test and Random Seek test to run in parallel on the same hard drive.
Where do I find Network Factory log files?

These log files are available on the Network Factory server in the following locations: Apache2 Logs
<install_directory>/Apache2/logs
Firebird Log
<install-directory>/Firebird/firebird.log
Network Factory logs

<install-directory>/Apache2/htdocs/logs
Network Factory License Server Logs

<install_directory>/Apache2/htdocs/license-server/logs
Why cant I run video tests on my Linux UUTs?

Ensure you are running the correct Linux video test. In order to run a 2d/3d Video test on Linux UUTs, X Window System (or XWindows) is required on the UUT. However, you cannot run Framebuffer Video tests while logged into an XWindows session. To run Framebuffer Video tests, the UUT must provide kernel framebuffer support or the tests will not enumerate.
PC-Doctor Network Factory Database

How do I back up the PC-Doctor Network Factory database?
PC-Doctor Network Factory uses the Firebird database server, which is stored in a single file at:
<installation_directory>/Apache2/htdocs/data/nf5.fdb
To back up the database, first make sure that nothing is writing to it (UUTs are not running and Web-browsers are not pointing to the Monitoring Console). Once you are sure that nothing is writing to the database file, copy the file to your preferred backup destination. For more information on backing up a Network Factory database, SEE ALSO Maintaining the Network Factory Database on page 78
How do I restore the database from a backed-up database file?

Make sure that nothing is writing to the database file. Overwrite the PC-Doctor Network Factory database file with your backed-up database file. If you get an error from the Operating System, something is writing to the database file. For more information on restoring a Network Factory database, SEE ALSO Maintaining the Network Factory Database on page 78.
Selecting the ODBC Example under Reports produces the error Database Connection Failed
Guidelines for Using the ODBC Example Report To use the ODBC Example report: 1. Click the User Mgmt tab. 2. Under the Add Users section, type odbc in the User Name field. 3. Type odbc in the User Password and Re-Enter Password field. 4. Select Dbremote. 5. Click the Add User button. For more information on other user account features, SEE ALSO The User Mgmt Tab on page 72.
Where can I find more information on databases used with Network Factory?
You can find additional information through the following resources. Online Resources PHP Manual and Tutorial SQL Tutorial from www.SQLCourse.com SQL Tutorial from www.w3schools.com Firebird/Interbase Manual Available Books The Firebird Book: A Reference for Database Developers (Paperback) SQL In A Nutshell, 2nd Edition (Paperback) Sams Teach Yourself SQL in 10 Minutes, Third Edition (Paperback) PHP and MySQL Web Development (3rd Edition, Developer's Library, Paperback) Beginning PHP 5 and MySQL: From Novice to Professional (Paperback) Web Database Applications with PHP & MySQL, 2nd Edition (Paperback)
PC-Doctor Network Factory Administrator Guide | ODBC Connectivity with Firebird Database | 97
ODBC Connectivity with Firebird Database

In this chapter you will find information on: Prerequisites on page 97 Installing Firebird ODBC Drivers on page 97 Creating an ODBC Data Source Name on page 98 ODBC Data Sources using MS Access, Cold Fusion, and PHP on page 100 Setting Up ColdFusion Third Party Database Access on page 104 Use the following guidelines to help you setup remote connectivity to your PC-Doctor Network Factory database.
Prerequisites
Before setting up ODBC connectivity, verify that you meet the following requirements: PCDoctor Network Factory installed on local server A Windows workstation where the installation takes place Microsoft Access, PHP, or other 3rd party database application.
Installing Firebird ODBC Drivers

Use the following guidelines to install Firebird ODBC drivers on the work station that will access the PC-Doctor Network Factory Server. Note: This document uses a image taken while using the 1.2.0.69 driver. 1. Install the Firebird ODBC driver with the Developer Install or Deployment Install method. After installing the driver kit, you may need to configure the Windows Network Services file on the work station to support Network Factory. The Windows Network Services file on the server should already be configured: 2. Open the Windows Network Services file. For most workstations, you will find it here:
C:\windows\system32\drivers\etc\services
3. Add the following line:

gds_db 3050/tcp #Firebird Database
4. Save and close the file. Note: Ensure each component in the above line is separated by at least a single space. See below.
98 | PC-Doctor Network Factory Administrator Guide | ODBC Connectivity with Firebird Database
Figure 98: Modifying the Services file
Creating an ODBC Data Source Name

ODBC data sources are available at two different access levels. User data sources are only available to the current user of the Windows workstation. System data sources are available to all users of the system, including system services. PC-Doctor recommends setting the system data sources to ensure proper operation. 1. Go into: Control Panel/Administrative Tools/ODBC Data Source Administrator 2. Click the System DSN tab and then click the Add button. This will create a system level data source. 3. In the Create New Data Source dialog box, select Firebird/Interbase Driver. See below. Note: Installation of the driver is covered in the previous section.
Figure 99: Choosing a Firebird data source
This will allow you to choose a Firebird data source after the Firebird ODBC driver is installed. The data source name should be nf5dsn to enable the provided ODBC example report. 4. Provide the host IP:database in the database field. For example, if your Network Factory Server is located at 192.168.0.5, the database field would be 192.168.0.1:NF5. If you are performing this step on the system with Network Factory Server installed, you can use the actual IP of the server or the local host IP (127.0.0.1). Note: Network Factory Server installs a Firebird alias that will automatically map a database location NF5 to the physical database file. PCDoctor recommends that you use the alias in the Firebird ODBC setup instead of specifying the full database path, allowing for easy database relocation on the server. The database file is located in:
<NF5_install_directory>\Apache2\htdocs\data\NF5.FDB
5. In the Client field, type:

<NF5_install_directory>\Firebird\bin\fbclient.dll
Note: If installing this on a separate workstation: a) Copy and paste the fbclient.dll file to a safe location on the workstation. b) In the Client field, type the directory path where fbclient.dll is located on the workstation. 6. In the Database Account and Password fields, type any user name and password that were created through the Monitoring Console. See below.
Figure 100: The FireBird ODBC Setup dialog
To access ODBC, you must specify a user with remote database permissions. Type the username for this account in the Database Account field, and type the password for this account in the Password field. Note: For more information on creating a remote database user account, SEE ALSO Creating and Managing Accounts on page 72. 7. Test the connection by clicking the Test Connection button. Your PC-Doctor Network Factory Server database is now accessible through ODBC connectivity.
ODBC Data Sources using MS Access, Cold Fusion, and PHP

The following are examples of using MS Access, Cold Fusion, and PHP to open an ODBC database.
Using MS Access
1. Open the ODBC Database in MS Access. See below.
Figure 101: Using MS Access to open an ODBC
2. Choose your data source name. See below.
Figure 102: Selecting a data source in MS Access
3. Choose the table you would like to have access to when working inside MS Access. See below.
Figure 103: Linking tables in MS Access
Caution: Ensure that you only link to the tables. You do not want to import!
After linking the tables, you are now ready to use Microsoft Access as if the database were any other locally stored database. Below is an image of the Microsoft Access query designer. See below.
Figure 104: Designing queries using MS Access
The above query in SQL form is:

SELECT system.serial_number, system.product, system.alias, test_script.date_tested, test_script.result FROM system LEFT JOIN test_script ON system.system_id = test_script.system_id WHERE test_script.result IS NOT NULL;
This will produce the following result. See below.
Figure 105: Query result using the MS Access query designer
Using ColdFusion
To connect and query from ColdFusion Markup after the data source has been added to the Cold Fusion administrator: 1. Use the following:
<cfquery name = "myQueryName" datasource="myODBCDSN"> SELECT field, field2, field3 FROM table </cfquery>
Using PHP
To connect and query an ODBC data source from PHP: 1. Use the following:
<? $fh = odbc_connect("myODBCDSN","username","password"); if (0 === $fh) die("Could not connect to data base"); $results = odbc_exec($fh,"SELECT field1, field2 from table"); while ($row = odbc_fetch_array($fh)) echo "Field1: ".$row['field1']." Field2: ".$row['field2']."\n"; odbc_close($fh); ?>
For example:
<? $db = odbc_connect("nf5dsn","odbc","odbc"); if (0 == $db) die("Could not connect to data base"); $query = "SELECT s.serial_number, s.product, sa.alias, ts.start_date,
r.result"; $query.= " FROM system s JOIN test_script ts ON s.id =ts.system_id "; $query .= " join test_result r ON r.id = ts.result_id "; $query .= " join alias sa ON sa.id = s.alias_id "; $query .= " WHERE r.id IS NOT NULL "; $results = odbc_exec($db,$query); if (FALSE == $results) die("Could not execute query"); while ($row = odbc_fetch_array($results)) { echo "<b>Test System</b><br>"; echo "Serial Number: ".$row['SERIAL_NUMBER']."<br>"; echo "Product: ".$row['PRODUCT']."<br>"; echo "System Alias: ".$row['ALIAS']."<br>"; echo "Date: ".$row['START_DATE']."<br>"; echo "Result: ".$row['RESULT']."<br>"; echo "--<br>"; } ?>
Setting Up ColdFusion Third Party Database Access

Use the following procedure for setting up third party Network Factory database access using ColdFusion: 1. Download the latest Firebird JDBC driver from: 2. Unzip and place the driver in the default location of:
<CFROOT>\wwwroot\WEB-INF\classes\firebird
You will need to manually create the Firebird directory. See below.
Figure 106: Specifying the class path
3. Add a new data source and setup as shown. See below.
Figure 107: Adding and setting up a data source
4. Click the Driver drop-down arrow and select Other. See below.
Figure 108: Selecting a driver
Sample Database Queries

Finding tested systems between specific dates If you want to find the first five systems tested between two dates, use a query like this:
SELECT FIRST 5 DISTINCT s.serial_number, s.id FROM system s JOIN test_script ts ON ts.system_id = s.id WHERE ts.end_date > '1/1/2005' AND ts.end_date < '2/1/2010'
Finding tested systems with a specific configuration If you want to find the first five systems by a certain configuration in the same date range, use a query like this:
SELECT FIRST 5 DISTINCT s.serial_number, s.id, c.configuration FROM system s, test_script ts, configuration c WHERE ts.end_date > '1/1/2005' AND ts.end_date < '2/1/2010' AND s.id=ts.system_id AND c.id=s.configuration_id AND c.configuration='*'
Finding values for custom fields If you want to find the first five values for a custom field called "tester" in the system_extra table for all systems, use a query like this: Note: If you specify field names for the system_extra table in SQL, you must contain them in quotes. Field names are case sensitive.
SELECT FIRST 5 "tester" from system_extra
Finding device component information If you want to find all the latest properties and property values for a particular component from a given system using its component id number (component_id) and system id number (system_id), assuming component_id=1 and system_id=1, use a query like this:
SELECT p.name, pc.category, pv.property_value, pvl.component_id FROM property p, property_category pc, property_value pv, property_value_list pvl WHERE pv.id = pvl.property_value_id AND pvl.property_id = p.id AND p.category_id=pc.id AND pvl.component_id = 1 AND pvl.system_id = 1 AND pvl.test_script_id = ( SELECT MAX(test_script_id) FROM property_value_list
WHERE system_id = 1 )
Finding all tests that result in Failed If you want to find the total number of test failures on each system, use a query like this:
SELECT FIRST 5 system.uut_key,count(*) AS number_failed FROM system, test_script, test_run WHERE system.id=test_script.system_id AND test_script.id=test_run.test_script_id AND test_run.test_result_id!= (SELECT first 1 test_result.id FROM test_result WHERE test_result.result='PASS') GROUP BY system.uut_key
Finding test event messages If you want to find all the test event messages for each system, use a query like this:
SELECT FIRST 5 s.uut_key, t.name, et.event_type, event_message FROM system s, test_script ts, test_run tr, test_run_event tre, test t,event_type et WHERE s.id=ts.system_id AND ts.id = tr.test_script_id AND tr.id = tre.test_run_id AND t.id=tr.test_id AND et.id=tre.event_type_id
Finding dates and test results for test script runs If you want to find the date and result for each test script executed, use a query like this:
SELECT FIRST 5 s.uut_key, sc.script_file, ts.end_date,res.result FROM system s, test_script ts, script_file sc, test_result res WHERE s.id=ts.system_id AND ts.script_file_id = sc.id AND ts.result_id = res.id
Finding the CPU speed for tested systems If you want to determine the CPU speed in megahertz for a system with a unique system ID, use a query like this:
SELECT c.product, p.name, pv.property_value FROM property p, property_value pv, property_value_list pvl,component c, capability cp, capability_list cpl WHERE pvl.property_id = p.id AND pvl.property_value_id = pv.id AND c.id = cpl.component_id AND cpl.capability_id = cp.id AND cpl.test_script_id = (SELECT MAX(test_script_id) FROM capability_list WHERE system_id = 1) AND pvl.test_script_id = (SELECT MAX(test_script_id) FROM capability_list WHERE system_id = 1) AND pvl.component_id = c.id AND cp.capability='CPU'
AND pvl.system_id = 1 AND p.property_key = 'SpeedEstimateTSC';
Finding hard drive size for tested systems If you want to determine the size of all installed hard drives for a system with a unique system ID, use a query like this:
SELECT c.product, p.name, pv.property_value FROM property p, property_value pv, property_value_list pvl, component c, capability cp, capability_list cpl WHERE pvl.property_id = p.id AND pvl.property_value_id = pv.id AND c.id = cpl.component_id AND cpl.capability_id = cp.id AND cpl.test_script_id = (SELECT MAX(test_script_id) FROM capability_list WHERE system_id = 1) AND pvl.test_script_id = (SELECT MAX(test_script_id) FROM capability_list WHERE system_id = 1) AND pvl.component_id = c.id AND cp.capability='HardDrive' AND pvl.system_id = 1 AND p.property_key = 'TotalCapacity';
Finding the total amount of installed memory If you want to determine the total amount of installed memory for a system with a unique system ID, use a query like this:
SELECT c.product, p.name, pv.property_value FROM property p, property_value pv, property_value_list pvl,component c, capability cp, capability_list cpl WHERE pvl.property_id = p.id AND pvl.property_value_id = pv.id AND c.id = cpl.component_id AND cpl.capability_id = cp.id AND cpl.test_script_id = (SELECT MAX(test_script_id) FROM capability_list WHERE system_id = 1) AND pvl.test_script_id = (SELECT MAX(test_script_id) FROM capability_list WHERE system_id = 1) AND pvl.component_id = c.id AND cp.capability='Memory' AND pvl.system_id = 1 AND p.property_key = 'TotalPhysicalMemory';
Combining queries The three previous queries could be combined into one: Note: The sub-selects for the MAX(test_script_id) ensure that you are getting the latest information.
SELECT c.product, p.name, pv.property_value FROM property p, property_value pv, property_value_list pvl, component c, capability cp, capability_list cpl WHERE pvl.property_id = p.id AND pvl.property_value_id = pv.id AND c.id = cpl.component_id AND cpl.capability_id = cp.id AND cpl.test_script_id = (SELECT MAX(test_script_id) FROM capability_list
WHERE system_id = 1) AND pvl.test_script_id = (SELECT MAX(test_script_id) FROM capability_list WHERE system_id = 1) AND pvl.component_id = c.id AND cp.capability IN ('CPU','HardDrive','Memory') AND pvl.system_id = 1 AND p.property_key IN ('SpeedEstimateTSC','TotalCapacity','TotalPhysicalMemory');
Finding what was tested on a system using a serial number The below snippet of code queries the database for a list of modules run against a system with a specific serial number. This would run into problems if a system is tested multiple times against multiple versions of tests as it would grab multiple copies of the same modules distinguishable only by the module_id numbers. With this list of modules, the code queries the database to compare the tests belonging to each module with the tests run on the system, ignoring pass, fail or abort results. It then calculates the percentage of tests run against the number of existing tests per module. To find what was tested on a system using a serial number:
<?php // Count all modules tested against a serial number $serial_number="System Serial Number";$query_modules_sql = "SELECT DISTINCT m.name, m.id FROM module as m, test as t, test_run as tr,test_script as ts, system as s WHERE s.serial_number = '$serial_number' AND s.id = ts.system_id AND ts.id = tr.test_script_id AND tr.test_id = t.id AND t.module_id = m.id";$module_result = ibase_query($db, $query_modules_sql);$rows = Array(); while( $arr = ibase_fetch_row($module_result)) array_push($rows, $arr); $module_number=count($rows); echo "<div>$module_number modules found</div>"; $module_count = 0; foreach($rows as $moduledata){ $module_name = $moduledata[0]; $module_id = $moduledata[1]; // Count all tests per modules $query_testcount_sql = "SELECT DISTINCT COUNT(*) FROM test as t WHERE t.module_id = $module_id"; $testcount_result = ibase_query($db, $query_testcount_sql); $array_result=ibase_fetch_row($testcount_result); $testcount = $array_result[0]; echo "<div>$testcount is the testcount for module $module_id $module_name</div>"; } //Count all tests run per module $query_testruncount_sql = "SELECT DISTINCT COUNT(*) FROM test_run as tr, system as s,test_script as ts, test as t WHERE tr.test_id = t.id AND t.module_id = $module_id AND tr.test_script_id = ts.id AND ts.system_id = s.id and s.serial_number = $serial_number'"; $testruncount_result = ibase_query($db, $query_testruncount_sql); $array_result = ibase_fetch_row($testruncount_result); $testruncount = $array_result[0]; $module_count = $module_count + $testruncount/$testcount; echo "<div>Testruncount is $testruncount and the module_count is $module_count</div>"; } if ($module_count != 0){ $string = "$module_count out of $module_number test modules were
run on $serial_number"; } else { $string = "No modules or tests were run on $serial_number"; } echo "<div>$string</div>"; ?>
PC-Doctor Network Factory Administrator Guide | Using the DOS UUT | 111
Using the DOS UUT

In this chapter you will find information on: Overview of the DOS UUT on page 111 DOS UUT File Dependencies on page 112 About DOS_UUT.CFG on page 114 Configuring a DOS UUT to Operate in a Network Factory Environment on page 115 Modifying the Test Process on page 116 Using the DOS Proxy on page 118 Using Test Scripts to Automate DOS Testing on page 118 DOS UUT Environment Variables on page 120
Overview of the DOS UUT

If you support DOS as part of your test environment, you can use the following procedure to setup your Network Factory configuration to support DOS. There are six different components necessary to test and track test results for a DOS UUT: Network Factory Server (includes the License Manager (LM), UUT Upload Server (UUS) and DOS-proxy) TFTP/PXE Server DOS Unit-Under Test software (UUT or client)
In general, the DOS UUT starts by attempting to PXE boot from a PXE server. If a DOS UUT successfully boots from a PXE server, it will download all predefined diagnostics, test script files and other necessary components. The DOS UUT then displays a menu of diagnostic choices and periodically attempts to authenticate with the LM using UDP packets. When done testing, the DOS UUT will store the logs on the TFTP server. DOS test scripts are known as overlays and are contained in PDO files. Overlays are equivalent to a standard Network Factory test script. For more information on overlays and PDO files, SEE ALSO Using Test Scripts to Automate DOS Testing on page 118. The DOS UUT sequentially runs the tests specified in the PDO file. When testing completes, the DOS UUT saves the log files on the TFTP server. The following diagram summarizes the basic DOS UUT/Network Factory server communication path.
112 | PC-Doctor Network Factory Administrator Guide | Using the DOS UUT
Figure 109: Basic Diagram of DOS UUT Communication
Note: Since the DOS UUT does not communicate directly with the Network Factory server, results are not updated in real-time. Results for a DOS UUT are not reflected in the Network Factory Monitoring Console until the logs are uploaded.
Summary of Steps for Configuring and Testing a DOS UUT

The following steps summarize what you need to do to setup your DOS UUT Network Factory environment. 1. Setup the PXE/TFTP server (Setting Up Support for PXE Booting on page 115). The DOS UUT starts by attempting to PXE boot from a PXE server. 2. Modify the DOS_UUT.CFG file and place it in the root of the TFTP server (About DOS_UUT.CFG on page 114). 3. Configure the DOS proxy.p5i file (Using the DOS Proxy on page 118). A DOS proxy is required for the Network Factory server to parse DOS client logs and record the results of those logs into the database. 4. Optionally, modify a DOS PDO file to include tests you want to run on the DOS UUT. 5. On the Network Factory server, create a Group/Configuration/Phase mapping. A mapping is what assocaites build files with a specific UUT.
DOS UUT File Dependencies

The following files are used to test a DOS UUT through Network Factory: Executables:
PSR.EXE: A logfile parser used to display results. REBOOT.COM: Performs a (cold) reboot of the machine.
Menu batch files: Note: These files can vary widely depending on your configuration.
MENU.BAT: The default menu that provides an interface to various pre-defined test selections and running system
information reports. 1.bat: Runs the diagnostics in overlay 1 of the default PDO file.
2.bat: Runs the diagnostics in overlay 2 of the default PDO file. x.bat: See above.
Files stored on the TFTP server:

DOS_UUT.CFG: This file is parsed by _CONFIG.BAT to setup critical UUT parameters including: LICENSE,
TFTP_ADDR, and LOG_LOC. UPDATES.CFG: A file used to define updates for a UUT. Updates are defined as file downloads the UUT will download after booting.
Workflow scripts:
_CONFIG.BAT: Performs configuration of client variables. DOSUUT.BAT: Usually launched from AUTOEXEC.BAT, this file starts the workflow. FIXSPACE.BAT: A utility script used for stripping excess spaces from the ends of environment variables such as the
serial number.
_NFFIELD.BAT: Adds the GROUP, CONFIG, PHASE and other variables to a log file based on parameters passed
into it or available as environment variables. _PARSE.BAT: Uses setenvar.exe to parse a file based on the parameters passed to it. _TIMSTMP.BAT: Sets the environment variables TIME and DATE to the current time and date. These variables can then be placed in the logfile and later used on the server to determine script times during parsing. _UPLOG.BAT: Uploads a log file to the server specified by the variable TFTP_ADDR. The log will be uploaded to the location specified by LOG_LOC and will have the filename DOSLOG__%ID%.LOG, where "%ID%" is the UUT ID specified by the variable ID. UPDATES.BAT: Parses the UPDATES.CFG file and downloads defined update componets _RESULTS.BAT: Uses PSR.EXE to parse log files and display relevant results to users. Internally contains an order of precedence to determine and display only the worst results. For example, if a test reports "Canceled" but other tests report "Fail", only the fail results are displayed.
Optional workflow scripts:

_FF.BAT: If this file is present, it is called when a test failure is detected. Not included by default. Contact PC-Doctor
if you plan to use the results of a test to control a workflow process. The following diagram demonstrates how a typical DOS UUT is configured and operates within a Network Factory environment.
Figure 110: Process flow for a DOS UUT in Network Factory
About DOS_UUT.CFG
The DOS_UUT.CFG file is used to define the initial configuration for the DOS UUT and contains five fields. See below.
# Network Factory DOS UUT # # # DO NOT MODIFY THE HEADER OF THIS FILE! LICENSE=[192.168.31.54] TFTP_ADDR=[192.168.31.54] LOG_LOC=[DOS_LOGS\] BOOTSTRAP=[] UPDATES=[]
LICENSE: Defines the IP address for the LM on your network. This is usually the IP address of the Network Factory server.
TFTP_ADDR: Defines the IP address of the TFTP server to where the DOS UUT uploads logs. This can be a separate server than the TFTP server from which clients PXE boot. For example, you may want to run a separate TFTP server (such as TFTPD32) for log collection directly on the Network Factory server. LOG_LOC: Defines the directory where the DOS UUT should upload logs. Depending on the type of file system and the folder specified, ensure you use the correct slash or back-slash to define the file path. BOOTSTRAP: If running a custom setup with a bootstrap file, defines the name of the bootstrap file. If using the default process, leave this blank. UPDATES: Defines update components the UUT will download after booting.
Setting Up Support for PXE Booting

Before you begin testing DOS UUTs in a Network Factory environment, you must configure the TFTP server to support PXE and offer the DOS UUT as a boot option. 1. Create a directory on the TFTP server you will use to store DOS logs. 2. Copy the DOS image provided by PC-Doctor to the root of the TFTP server. 3. Configure the PXE server to offer this image as an option. The following is an example of configuring the PXE server using pxelinux. Note: The keeppxe option for memdisk is required. The DOS UUT will not connect to the network without specifying keeppxe.
TIMEOUT 500 PROMPT 1 DEFAULT 0 APPEND menu1.txt LABEL 0 LOCALBOOT 0 LABEL 1 KERNEL memdisk APPEND keeppxe floppy ro initrd=DOS_BUILD.IMA
4. Copy DOS_UUT.CFG to the root of the TFTP server. 5. Modify DOS_UUT.CFG. For more information on DOS_UUT.CFG, SEE ALSO About DOS_UUT.CFG on page 114.
Configuring a DOS UUT to Operate in a Network Factory Environment

Use the following guidelines for configuring a DOS UUT to operate within a Network Factory environment. Keep in mind you will need to create mappings that support your DOS UUTs. The main difference between a mapping for DOS UUTs and other mappings is DOS UUTs do not use standard test scripts. DOS test scripts are contained in PDO files and are called test overlays. For more information on creating DOS test scripts, SEE ALSO Creating DOS Test Overlays on page 119.
Guidelines for Configuring a DOS UUT

To configure your DOS UUT: 1. Configure the DOS proxy.p5i file. For more information on the DOS proxy server, SEE ALSO Using the DOS Proxy on page 118.
2. On the DOS UUT, modify a DOS PDO file. For more information on modifying a PDO, SEE ALSO Using Test Scripts to Automate DOS Testing on page 118. 3. When you are done creating overlays, save the modified PDO on the TFTP server and use the update feature to have the UUT downaload the modified PDO. For more information on the updates feature, SEE ALSO Supporting UUT Updates on page 116. Note: Alternatively, you can save the PDO inside the diagnostic image for the DOS disk image on your TFTP server. Ensure you replace the already present PCDR.PDO file. 4. On the Network Factory server, create a Group/Configuration/Phase mapping (Group=DOS, Config=*, Phase=*). Specify the PDO file name (PCDR.PDO) as the script in your mapping. For more information on creating a mapping, SEE ALSO Implementing Your Network Factory Integration on page 22. 5. Click the Add Entries button. You will see the PDO file name in the Mappings section of the Config pane. 6. On the Network Factory server, copy your modified PDO or create an empty file called PCDR.PDO and place it in the Scripts directory located at:
<install_directory>\apache2\htdocs\scripts
Modifying the Test Process

There are three primary methods of modifying the test process. Modify the DOS image file directly. This involves: Extracting the files from the DOS disk image. Extracting the files from the zip file in the image. Modifying or replacing the batch files inside the zip.
Specify files to download after boot using the Updates feature. This is the easiest method. Use a bootstrap, create replacement files and store them on the TFTP server and/or in the image.
Supporting UUT Updates

You can configure a DOS UUT to download specific files after booting using the Updates feature. This allows you to make modifications to the UUT without having to write a bootstrap script or modify the diagnostic disk image. To use this feature, start by creating a text file (usually called UPDATES.CFG) that lists all of the files to download after boot. To add files, simply specify f=filename, where filename is the name of the file the UUT will download after booting. You can specify any number of files in the updates file. The file format for the updates file must be configured in the following way:
# Network Factory DOS UUT # # You must use ALL CAPS # [FILES] f=FILE1 f=TESTF1.TXT f=TESTF2.TXT f=TESTF3.TXT
Caution: Do not modify the file header! You can use the Updates feature to automate tasks such as downloading an updated PDO file. If you want to add, remove or change the PDO file, you simply place the modified version on the TFTP server and specify the path and filename in the UPDATES.CFG file.
The UPDATES.CFG file itself must reside in the root of the TFTP server. (the same location as your DOS_UUT.CFG file). Downloadable files can reside in a sub-directory on the TFTP server. Example of Using Updates Feature In this example, the PCDR.PDO file and the MENU.BAT have been updated to change the tests assigned for one menu option. The modifed files are placed in the UUT directory on a Linux TFTP server. The UPDATES.CFG file is in the root directory of the TFTP server. The file DOS_UUT.CFG has been updated to specify this file. The modifed DOS_UUT.CFG.
# Network Factory DOS UUT # # # DO NOT MODIFY THE HEADER OF THIS FILE! LICENSE=[192.168.29.16] TFTP_ADDR=[192.168.31.22] LOG_LOC=[DOS_LOGS/] BOOTSTRAP=[] UPDATES=[UPDATES.CFG]
The modified UPDATES.CFG file.

# Network Factory DOS UUT # # You must use ALL CAPS # [FILES] f=UUT/PCDR.PDO f=UUT/MENU.BAT
Using a Bootstrap
If a BOOTSTRAP file is specified in DOS_UUT.CFG, this file is downloaded after configuring the UUT and downloading any specified updates. The bootstrap is then given full control of the UUT. This is one method of modifying the DOS UUT and makes it possible to completely re-design the test process without the need to modify the DOS image. Sample Basic Bootstrap Procedure A simple bootstrap file might do the following. 1. Download a replacement PDO file to use instead of PCDR.PDO. 2. Download alternate batch files to replace 1.bat, 2.bat, 3.bat and so on. You could alternately download these files using the UPDATES features. 3. Run menu.bat in a loop to call the newly downloaded files. Sample Advanced Bootstrap Procedure A more complex bootstrap file might do the following. 1. Determine the type of system based on: MAC, SN or IP which are listed as environment variables. OR Use setenvar.exe to obtain product name from the SMBIOS information.
For example:
PCDR.EXE /SI:18 | SETENVAR.EXE PRO
2. Change ID of the system based on the type of the system or the Serial number. Note: The default ID is the MAC address. 3. Based on the type or ID of the system, download a batch file specific to this type or ID. This specific batch file could then: a) Download other files needed for testing this specific unit. b) Start a test overlay (from PDO) running automatically or present a menu for the technician. 4. Finally upload result logs either between running scripts or upload all logs at the completion of testing.
Using the DOS Proxy

A DOS proxy is required for the Network Factory server to parse DOS client logs and record the results of those logs into the database. Configuration settings for the DOS proxy are stored in:
<installation_directory>\Apache2\htdocs\dos-proxy\proxy.p5i
The DOS proxy is responsible for setting the default values for Group, Configuration, and Phase. The values for Group, Configuration, and Phase are initially set to *, then set to the values defined in proxy.p5i if they exist, then set to the values defined in the DOS log if they exist. The DOS proxy is also responsible for defining the polling method. The three polling options are No polling, Local Machine logs, and Network Mount logs.
Table 3: DOS Proxy Polling Options Polling Method No polling Description On install, DOS proxy is in this state with "Network Mount logs" and "Local Machine logs" sections of proxy.p5i commented out. This effectively turns off the polling capability of DOS proxy. To set DOS proxy to poll a local directory for DOS log files, uncomment the section "Local Machine logs" in proxy.p5i. You will then need to define the directory paths where the DOS proxy will look for logs. To set DOS proxy to mount and poll a network directory for DOS log files, uncomment the section "Network Mount logs" in proxy.p5i. You will then need to define the network paths where the DOS proxy will look for logs.
Read logs from local directory
Read logs from network share
Using Test Scripts to Automate DOS Testing

Network Factory test scripts for DOS are called Test Overlays, which are contained in the PCDR.PDO file by default. PDO files are saved in the root directory of DOS UUT builds and are launched when a DOS test script is invoked. You can define up to ten different test overlays in a single PDO file. Note: Only one PDO can be loaded on a DOS UUT at a time. You may want to copy the default PDO to a safe location if you plan to reuse the default overlays it contains.
Creating DOS Test Overlays

You can create test overlays by running the DOS UUT in Ad hoc mode. Use the following guidelines for creating a DOS test overlay and storing it in PCDR.PDO. 1. Select a category from the Diagnostics menu. 2. Select one or more subtests you want to include in the overlay and deselect all others. Press the F10 key to quickly deselect or select all subtests in the Test Category window. To select or deselect individual subtests, highlight the desired subtest and press the SPACEBAR. 3. When you have finished selecting tests for a test category, press the PAGE UP or PAGE DOWN key to move to another Test Category window. 4. Select or deselect subtests you wish to include or exclude, continuing this process for each test category. 5. When you finish selecting tests, click [Options] or press F2 to open the Test Options window and select Save Overlay. See below.
Figure 111: Saving a Test Overlay
6. Select a slot to save the overlay and press ENTER. 7. Provide a name or description for the overlay in the Save dialog and press ENTER (the name or description can not exceed eight characters).
Integrating a Custom Test Overlay into your Network Factory Test Environment
Use the following guidelines for successfully integrating custom test overlays into your test environment. 1. Copy your PDO file to a floppy disk or other storage media. 2. Copy the modified PDO to the TFTP server and modify your updates file to include the modified PDO. Alternatively, you can manually copy the modified PDO directly to the image. If you plan on developing and using multiple PDO files, rename the file using a descriptive filename that indicates the purpose of the PDO.
3. In the Network Factory web interface, browse to the Config tab and create a mapping for the PDO file. Be sure to specify the PDO name correctly including the .PDO extension. Note: Unlike Windows and Linux UUTs, DOS does not download the PDO (test script) from the Network Factory server. The PDO must be contained in the image or downloaded from the TFTP server. For more information on mapping scripts, SEE ALSO Modifying PC-Doctor Network Factory Configuration on page 41. 4. On the Network Factory server create a place holder file in the scripts directory (PCDR.PDO). By default, the scripts directory is located in <install_directory>\Apache2\htdocs\scripts\ Note: The place-holder file is required in order for the DOS UUT to retrieve the PDO file.
You should now be able to test using your new overlay.
Known Issues and Workarounds for Network Factory server and DOS Proxy Communication
The following known issues currently exist for Network Factory servers configured to communicate with a DOS proxy server.
Reports and System Information Errors

Currently, some reports (including system information reports) do not yet work with DOS UUTs. As a result, you may see errors displayed when attempting to access this information. These reports may display a query error because system information is not available from the DOS UUT. Reports that do not require system information will work with DOS UUTs. These features work as intended for Windows and Linux UUTs.
Script Warnings are not Shown in the Progress Monitor

Tests that are not enumerated by the DOS UUT are not displayed as Script Warnings in the Progress Monitor. These tests will instead display as NOTAPPLICABLE during testing.
DOS UUT Environment Variables

The following environment variables apply to the DOS UUT:
Variable SERVER LICENSE LOGNAME Description IP address of an alternate TFTP server. Used when sending memory-based logs to a server interactively via the F3/Save function. IP address of an alternate License Manager Server. If not present, SERVER is used if SERVER is present. Otherwise, the default server address is used. Full path/filename of the default destination file to receive logs.
Working From the Command Line

The basic command format is:
pcdr /switch /switch
There are four methods to launch tests from the command line using switches. A space must precede the forward slash that begins each switch. You can use up to 128 characters on a single command line, allowing a variety of switch combinations:
ba:xx: Use this switch to run one of the 10 test sets stored in the test overlay file: PCDR.pdo.
Note: This switch cannot be used in combination with any other ba, ms or rt switch.
ms:xx: Use this switch to run the Maximum System Load for xx minutes.
Note: This switch cannot be used in combination with any other ba, ms or rt switch.
rt:nn: Use this switch to run the specified test with the ID nn. au:fname: Use this switch to specify a script file to run in automated scripting mode.
The rt:nn switch supports up to 10 different rt:nn switch combinations on a single command line, but you can only specify one test category for each rt:nn switch. The au:fname switch runs an automated scripting mode and cannot be combined with other ba, ms, or rt switches. In addition, there are restrictions for using the au:fname switch. This switch specifies a custom ini file you create, including options and parameters you would include on the command line. The following sections detail the available command line switches and provide examples for command line switch use.
The ba:xx and ms:xx Command Line Switches

The ba:xx command line switch starts batch mode testing of test overlay (or test set) number xx. The overlay number must range from 1-10. When you run an overlay, it starts automatically and returns to the DOS prompt when complete. For best results with this switch, combine it with the pr:nnnn switch, and possibly the eo and he switches. At the end of batch mode testing, an errorlevel return code is returned. Note: Please refer to your DOS documentation on how to use the errorlevel feature for branching in batch files. The ms:xx switch runs a batch-mode Maximum System Load Test for xx minutes. The number of minutes must be in the range of 2-9999. The Maximum System Load Test will automatically start and return to the DOS prompt when complete.
The rt:nn, rt:nn,x and rt:nn/x Switches

The rt:nn, rt:nn,x, and rt:nn/x switches are used to run individual tests in a variety of ways. The following explains the differences between the three rt commands rt:nn This switch runs a specified test category (all available tests for a specific device) or subtest specified by the variable nn. The variable in this switch represents the ID for the test category or subtest to run. You can specify all the subtests in a category with an *. You can combine up to 10 rt:nn switches on the same command line. Note: You can only specify one test category with each rt:nn switch.
This switch will run all the tests in the CPU/Coprocessor Test Category (cpu&*).
pcdr /rt:cpu&*
rt:nn,x This switch allows the user to specify which device to test. The variable nn represents the test category or subtest to run. The variable x is an integer that identifies the device, where 0 is the first device, 1 is the second and so on. This switch will run the hard disk seek test (hd&4) on the first hard drive (0).
pcdr /rt:hd&4,0
rt:nn/x This switch would run the hard disk seek test (hd&4) on the first and third hard drives (5=00000101).
pcdr /rt:hd&4/5
For more information on bit masks, SEE ALSO Determining and Using Bitmap Values on page 139. Supported Test IDs Diagnostics are generally broken down into individual subtests, with each subtest designed for testing various aspects of a hardware component. Each subtest has a specific test ID which is used to identify which test to run when launched from a command line. The following is a list of diagnostic categories and test IDs supported by the rt:nn, /rt:nn,x and rt:nn/x command line switches. Note: Only one test ID per each use of the switch is supported.
Table 4: CPU and Coprocessor Test IDs Test Name CPU Registers CPU Arithmetics CPU Logical Operations CPU String Operations CPU Interrupts/Exceptions CPU Buffers/Cache CPU C&T/Cyrix Specific CoProc Registers CoProc Commands CoProc Arithmetics CoProc Transcendental Test ID CPU&1 CPU&2 CPU&3 CPU&4 CPU&5 CPU&6 CPU&7 CPU&8 CPU&9 CPU&10 CPU&11
Test Name CoProc Exceptions CoProc Cyrix/IIT MMX Test CPU Miscellaneous Operations Table 5: Memory Test IDs Test Name Fast Pattern Fast Address Medium Pattern Medium Address Heavy Pattern Heavy Address Bus Throughput Code Test Advanced Pattern Test Memory Fault Test Address Fault Test Random Pattern Test Short Advanced Pattern Test Extended Advanced Pattern Test Table 6: Systemboard Test IDs Test Name System Timer BIOS Timer IRQ Controller DMA Channels RAM Refresh RTC Clock CMOS RAM Keyboard External Cache PCI PCMCIA
Test ID CPU&12 CPU&13 CPU&14 CPU&15
Test ID MEM&1 MEM&2 MEM&3 MEM&4 MEM&5 MEM&6 MEM&7 MEM&8 MEM&12 PCDMEM&1 PCDMEM&2 PCDMEM&3 PCDMEM&4 PCDMEM&5
Test ID MB&1 MB&2 MB&3 MB&4 MB&5 MB&6 MB&7 MB&8 MB&9 MB&10 MB&11
Test Name PCMCIA External Loop USB Port USB Port External Loop (front) USB Port External Loop (rear) Table 7: Video Adapter Test IDs Test Name Video Memory Video Pages VGA Controller Registers VGA Color-DAC Registers VESA Full Video Memory Test Video Memory (non-linear) AGP PCI Express Video Memory Video Pages VGA Controller Registers VGA Color-DAC Registers VESA Full Video Memory Test Video Memory (non-linear) AGP Table 8: Serial Port Test IDs Test Name Registers And Interrupts Internal Loopback External Loopback FIFO Buffers (16550A) Registers And Interrupts Internal Loopback External Loopback FIFO Buffers (16550A) Registers And Interrupts Internal Loopback Test ID COM&1 COM&2 COM&3 COM&4 COM&1 COM&2 COM&3 COM&4 COM&1 COM&2 Test ID VID&1 VID&2 VID&3 VID&4 VID&5 VID&9 AGP&1 AGP&2 VID&1 VID&2 VID&3 VID&4 VID&5 VID&9 AGP&1
Test ID PCMCIA&2 MB&12 USB&2 USB&3
Test Name External Loopback FIFO Buffers (16550A) Registers And Interrupts Internal Loopback External Loopback Table 9: Parallel Port Test IDs Test Name Command And Data Port External Loopback And IRQ Table 10: Fixed Disk Test IDs Test Name Controller Hi-Low Seek Funnel Seek Track To Track Seek Random Seek Linear Verify Random Verify SMART Test Read Test (Surface Scan) Write/Verify (Surface Scan) Write/Read (Surface Scan) SMART Self-Test Short SMART Self-Test Long Inner/Outer Surface Read Full Surface Read Table 11: Diskette Drive Test IDs Test Name Hi-Low Seek Funnel Seek Track To Track Seek Random Seek
Test ID COM&3 COM&4 COM&1 COM&2 COM&3
Test ID LPT&1 LPT&2
Test ID HD&1 HD&2 HD&3 HD&4 HD&5 HD&6 HD&7 HD&8 HD&9 HD&10 HD&11 HD&12 HD&13 HD&14 HD&15
Test ID FD&1 FD&2 FD&3 FD&4
Test Name Linear Verify Random Verify Linear Write/Read Linear Write/Random Read Hi-Low Seek Funnel Seek Track To Track Seek Random Seek Linear Verify Random Verify Linear Write/Read
Test ID FD&5 FD&6 FD&7 FD&8 FD&1 FD&2 FD&3 FD&4 FD&5 FD&6 FD&7
Danger: The Linear Write/Read and Linear Write/Random Read tests will destroy any data already on the floppy disk. Use only a newly formatted disk for these tests.
Table 12: Other Devices Test IDs Test Name Sound Blaster Sound card test CAS Diagnostic Stacker CD-ROM/DVD CD-ROM/DVD LS-120/240 Drive SCSI Asset ID Alert on LAN Year 2000 Test DIMM/RIMM EEPROM ID SMBUS Hardware Monitoring Temperature Monitoring Table 13: Interactive Test IDs Test Name Keyboard Keys Test ID I_KBD&1 Test ID MSC&1 SBTEST&1 MSC&2 MSC&3 MSC&4 CDTEST&1 LS12TEST&1 MSC&5 RFIDTEST&1 AP_TEST&1 Y2KTEST&1 DIMMTEST&1 SMBTEST&1 LM80TEST&1 LM75TEST&1
Test Name Keyboard LED's Keyboard Repeat Video Character Set Video Color Palette Video Monitor Quality Video Mode Internal Speaker Mouse Test Diskette Change Signal Diskette Write Protect CD-ROM/DVD Open Tray CD-ROM/DVD Close Tray CD-ROM/DVD Drive Capabilities CD-ROM/DVD Reset Test CD-ROM/DVD Linear Scan CD-ROM/DVD Random Scan CD-ROM/DVD Funnel Scan Joystick Test Maximum load test Printer Test SCSI Devices Test Stereo Speaker Test LCD Panel Test USB Loopback Test Table 14: Zip Drive Test IDs Test Name Controller Hi-Low Seek Funnel Seek Track To Track Seek Random Seek Linear Verify Random Verify
Test ID I_KBD&2 I_KBD&3 I_VID&1 I_VID&2 I_VID&3 I_VID&5 I_SPKR&1 I_MOUSE&1 I_DSK&1 I_DSK&2 I_CDR&1 I_CDR&2 I_CDR&3 I_CDR&4 I_CDR&5 I_CDR&6 I_CDR&7 I_JOY&1 I_MSL&1 I_PRN&1 I_SCSI&1 I_SND&1 I_LCD&1 I_USB&1
Test ID ZIP&1 ZIP&2 ZIP&3 ZIP&4 ZIP&5 ZIP&6 ZIP&7
Test Name Eject Disk Table 15: SCSI Fixed Disk Test IDs Test Name Controller Hi-Low Seek Funnel Seek Track To Track Seek Random Seek Linear Verify Random Verify Read Surface Scan Write Surface Scan Table 16: CD-Rom/DVD Drive Test IDs Test Name CD-ROM/DVD Linear Seek CD-ROM/DVD Random Seek CD-ROM/DVD Funnel Seek Table 17: CD-RW/DVD-RW Drive Test IDs Test Name ATAPI CD-RW Drive ATAPI DVD-RW Drive ATAPI DVD+RW Drive ATAPI DVD-RAM Drive
Test ID ZIP&8
Test ID SHD&1 SHD&2 SHD&3 SHD&4 SHD&5 SHD&6 SHD&7 SHD&8 SHD&9
Test ID MSC&7 MSC&8 MSC&9
Test ID CDRW&1 CDRW&2 CDRW&3 CDRW&4
This is an example of how to run all of the non-interactive CPU tests, followed by the Memory Heavy Address test:
pcdr /rt:cpu&* /rt:MEM&6
This is an example of how to run the non-interactive CPU test (CPU Registers), all the interactive keyboard tests and the interactive Diskette Write Protect test.
pcdr /rt:cpu&1 /rt:i_kbd&* /rt:i_dsk&2
The au:Fname Switch

The au:fname switch launches a test script specified by fname. The specified script file can be PCDRAUTO.INI or any other valid filename. If the file specified by fname does not exist, an error message is returned. Note: When using the au:fname switch, any specified he, np, or eo switches are ignored. This example will run the test script test001.ini.
pcdr /au:test001.ini
You can also use the au:fname switch to start the script from a specified point. This example will run test001.ini and start the script on line number 10.
pcdr /au:test001.ini,10
Note: For a list of available switches to use with the au:fname command line switch, SEE ALSO The ba:xx and ms:xx Command Line Switches on page 121.
In addition, you can use au:fname with the following switches:

dj tmx:y txx:y
The following switches are ignored when used with the au:fname switch:
eo fd:x,y,z he np
General Command Line Switch Functions

The following is a complete and detailed description of the test switches you can run from the command line. ac Changes the colors in the user interface. This example runs the first CPU test and alternates the background color. The test output is logged into the file testout.log.
pcdr /rt:cpu&1 /pr:testout /ac
an Enables automatic test log numbering. PC-Doctor will automatically track the sequential order of log files by adding an incremental entry to a PCDR.NUM file. You can edit this file using any standard text editor. PC-Doctor will automatically increment a test log number if the file PCDR.NUM exists (if you have previously used the an switch). To disable this feature you must delete the PCDR.NUM file.
This example runs all of the CPU tests, logs the results into test1.log and automatically increment the PCDR.NUM file.
pcdr /rt:cpu&* /pr:c:\test1.log /an
ci Assigns an IRQ number for a particular COM port address (expressed in hexadecimal). Up to 8 such addresses are allowed, with a comma separating the COM port address and the IRQ number. A colon separates each COM port address that is specified. Note that COM1 and COM2 are not affected because they are hard coded to use IRQ4 and IRQ3 respectively. The syntax is:
/ci:<HexAddress1>,IRQ:<HexAddress2>,IRQ
This example forces COM port with address 3F8H to use IRQ5.
pcdr /ci:3F8,5
This example forces COM port 3F8H to use IRQ5 and 2E8H to use IRQ11.
pcdr /ci:3F8,5:2E8,11
dj This switch will force Joystick tests to use direct joystick I/O. This will force the test to read joystick status and position directly from the hardware even if the BIOS has functions for the same purpose. This bypasses bugs in some BIOSes and problems that occur with EMM386 on some laptop systems. In some systems, the test will automatically select the use of direct joystick I/O. For those systems, this switch forces the test to disable direct joystick I/O. This example runs the Interactive Joystick test, displaying the position and status information on-screen, which is read directly from the hardware.
pcdr /rt:I_joy&1 /dj
eo If enabled, the test log will only include results for tests that fail. You can use this switch to bypass Passed and N/A test results in order to produce shorter test logs. This example command line runs all the hard drive and floppy drive tests, and records test results for all tests that produce a Failed result in the testlog.log file.
pcdr /rt:hd&* /rt:fd&* /pr:testlog.log /eo
Note: This switch will not filter out N/A or Passed test results that display a warning or informational message.
fd:x,y,z This switch enables you to specify tracks to test in the Linear Verify Test. The variables x,y,z are track numbers specified as decimal values in the range 0-79. You can specify track numbers in any order. You can specify as many tracks as you wish but cannot exceed 256 characters on one line.
This example will run the Linear Verify test on diskette tracks 0, 12, 34, and 67.
pcdr /rt:fd&5 /fd:0,12,34,67
fnmi This switch forces the memory test to report Failed on any nonmaskable interrupt (NMI). An NMI is issued to the microprocessor only in disastrous circumstances, such as severe memory corruption. Without this switch, if a NMI is caused by a memory parity error, the test will log as Failed and record the number of unexpected NMIs generated. ft:n This switch indicates a failure threshold. This is used with DOS DAPI test modules to indicate the failure level to apply. The variable n sets a failure threshold between 0 and 9 and passes this value to an external DOS DAPI module. For further details, please check the DOS DAPI specification, or SDK. he This switch enables halt-on-errors mode. If a test fails, it prompts the user to indicate if it should continue or abort testing. In this example, all of the hard drive tests will run but will stop and prompt the user if any test fails. If all tests pass, the test results are logged in test11.log.
pcdr /rt:hd&* /pr:test11.log /he
id:nnnn This switch adds the text string nnnn to the top of the test log for identification purposes. If you want to use spaces in the text string, you must encapsulate the entire switch in quotes. This example will run all of the video adapter tests and will display the string Video Device Log at the top of the log.
pcdr /rt:vid&* "/id:Video Device Log"
mr:type:start:end This switch specifies the memory type and the memory range to be tested. The memory range must be valid. If you specify incorrect memory range values, the test display the error as incorrect values in both hexadecimal and decimal and will exit.
Table 18: Memory Range Switch Components Switch Component type Description Specifies the type of memory for which to set the range. Supported values are: start end B: Specifies base memory X: Specifies legacy memory P: Specifies expanded memory U: Specifies upper memory
Specifies the new starting memory location in hexadecimal. Specifies the new ending memory location in hexadecimal.
This command line runs the Fast Pattern Memory Test on the first available memory module for base memory in the range 0000 to 9FFF.
pcdr /rt:mem&1,0 /mr:b:0000:9FFF
In rt:mem&n,x, if you do not specify the value for x, the test attempts to run on all available memory modules. The following charts show you what you must code on the command line to test different ranges of memory
Table 19: Command Line Arguments for Testing Different Ranges of Base and Legacy Memory Test Fast Pattern Fast Address Medium Pattern Medium Address Heavy Pattern Heavy Address Bus Throughput Code Test Base rt:mem&1,0 /mr:b:xxxx:xxxx rt:mem&2,0 /mr:b:xxxx:xxxx rt:mem&3,0 /mr:b:xxxx:xxxx rt:mem&4,0 /mr:b:xxxx:xxxx rt:mem&5,0 /mr:b:xxxx:xxxx rt:mem&6,0 /mr:b:xxxx:xxxx rt:mem&7,0 /mr:b:xxxx:xxxx rt:mem&8,0 /mr:b:xxxx:xxxx Legacy rt:mem&1,1 /mr:x:xxxx:xxxx rt:mem&2,1 /mr:x:xxxx:xxxx rt:mem&3,1 /mr:x:xxxx:xxxx rt:mem&4,1 /mr:x:xxxx:xxxx rt:mem&5,1 /mr:x:xxxx:xxxx rt:mem&6,1 /mr:x:xxxx:xxxx - - - - - - - rt:mem&8,1 /mr:x:xxxx:xxxx
Table 20: Command Line Arguments for Testing Different Ranges of Expanded and UMB Memory Test Fast Pattern Fast Address Medium Pattern Medium Address Heavy Pattern Heavy Address Bus Throughput Code Test Expanded rt:mem&1,2 /mr:p:xxxx:xxxx rt:mem&2,2 /mr:p:xxxx:xxxx rt:mem&3,2 /mr:p:xxxx:xxxx rt:mem&4,2 /mr:p:xxxx:xxxx rt:mem&5,2 /mr:p:xxxx:xxxx rt:mem&6,2 /mr:p:xxxx:xxxx rt:mem&7,2 /mr:p:xxxx:xxxx rt:mem&8,2 /mr:p:xxxx:xxxx UMB rt:mem&1,3 /mr:u:xxxx:xxxx rt:mem&2,3 /mr:u:xxxx:xxxx rt:mem&3,3 /mr:u:xxxx:xxxx rt:mem&4,3 /mr:u:xxxx:xxxx rt:mem&5,3 /mr:u:xxxx:xxxx rt:mem&6,3 /mr:u:xxxx:xxxx rt:mem&7,3 /mr:u:xxxx:xxxx rt:mem&8,3 /mr:u:xxxx:xxxx
ms:xxxx This switch runs a batch-mode Maximum System Load Test for xxxx minutes. The number of minutes must be in the range of 2-9999. The Maximum System Load Test will automatically start and exit when complete. At the end of testing, one of the following ERRORLEVEL return codes is returned: 0 = Errors were not detected 1 = One or more errors were detected 2 = Testing was canceled by the user Note: Refer to your DOS documentation on how to use the ERRORLEVEL feature for branching in batch files.
na2f This switch will force a test to log as Failed if it is unable to detect the appropriate device. This example runs the Floppy Diskette Hi-Low Seek test and logs the results in testlog.log. If the test is unable to detect an installed floppy diskette drive, it logs as Failed.
pcdr /rt:fd&1 /pr:testlog /na2f
ncd This switch will configure optical disc tests to not recognize CD-ROMs. If you use this switch, you can not run CD-ROM tests. You may need to use this switch if you are attempting to test DVD drives and want to limit acceptable test media to DVD discs only. This example will run the CD-ROM/DVD Linear Seek test and log the results in testlog.log. If the user attempts to run the test using a CD-ROM disc, the test will not recognize the disc.
pcdr /rt:msc$7 /pr:testlog /ncd
nf This switch disables floppy drive detection, allowing you to save test time or narrow the focus of testing. When this switch is used, all floppy drive detection and tests are disabled. This example runs the CD-ROM/DVD test and logs the results into testlog.log.
pcdr /rt:msc&4 /pr:testlog /nf
nn This switch disables enumerating network cards. Use this if your system hangs while enumerating network cards. This example disables enumeration of network cards, runs all of the serial port tests, and logs the results into testlog.log.
pcdr /rt:com&* /pr:testlog /nn
nomouse This switch disables mouse functionality. This example disables enumeration of pointing devices, runs all of the serial port tests and logs the results into testlog.log.
pcdr /rt:com&* /pr:testlog /nomouse
np This switch disables all user dialog prompting. When a test prompts the user for a response, all testing is paused until the user responds to the prompt. This switch makes unattended automated testing possible.
This example will run test overlay #1, disabling all prompting and log the results into testlog.log.
pcdr /ba:01 /pr:testlog /np
nps2m This switch disables BIOS calls that attempt to determine the presence of a PS/2 mouse. Some BIOSes have bugs that might otherwise cause the system to hang. This switch is automatically used if the system has a Phoenix BIOS. This example disables the BIOS calls to determine the presence of a PS/2 mouse, runs all of the parallel port tests and logs the results into testlog.log.
pcdr /rt:lpt&* /pr:testlog /nps2m
ns This switch disables enumeration of sound cards. This example disables enumeration of sound cards, runs the modem test and logs the results into testlog.log.
pcdr /rt:msc&6 /pr:testlog /ns
nsc This switch disables enumeration of SCSI cards. This example disables enumeration of SCSI cards, runs the modem test and logs the results into testlog.log.
pcdr /rt:msc&6 /pr:testlog /nsc
nv This switch bypasses an internal virus check on PCDR.exe when it is initially launched. This example disables checking for internal viruses, runs all the hard drive tests and sends the results to testlog.log.
pcdr /rt:hd&* /pr:testlog /nv
ol:xx This switch will load a test overlay where xx specifies a value of 1-10 (up to 10 overlays are stored in the PCDR.PDO file). When you run this switch, the main screen appears but the overlay does not immediately run. If you then go to any diagnostic test and press F5, the overlay you specified on the command line will run. This example will run overlay #7 when you press the F5 key from the Diagnostic window.
pcdr /ol:07
pc:xx This switch defines a test pass count ranging between 1-9999 as specified by the xx variable. Upon completion, the test will re-run for the indicated number of passes. This example will run all the hard drive tests 100 times and log the results into testlog.log.
pcdr /rt:hd&* /pr:testlog /pc:100
This switch can also be used with script files and will repeat the script the number of times indicated. This command line will run the entire script file config001.ini four times.
pcdr /au:config001.ini /pc:4
pi:n This switch specifies a directory path where ini files are stored. If a test is unable to locate an ini file in the specified directory path, it looks in the default directory. This switch must be used every time you run tests from the command line if your ini files are in a different directory from the default directory. This example will look in the directory c:\otherdir for the ini file associated with the cpu tests.
pcdr /pi:c:\otherdir /rt:cpu&*
pr:nnnn This switch configures a test to record all test log information in a log file. The filename is specified by the variable nnnn. The test will automatically send test results to the file nnnn. The name of the file can optionally include a path. When you send the results to a file, this file can be viewed in any text editor and printed out. Note: If you do not specify a filename extension for your log file, the test will save the log as a plain-text file without a file extension. You can still use any standard text editor to view a log file. However, if you plan on viewing the log file on a Windows-based system, you will need to append a txt filename extension to the filename. This example runs all the hard drive tests and records the results to testlog.txt.
pcdr /rt:hd&* /pr:testlog.txt
pause This switch allows the user to interact with system info reports. This example will run Memory Info and PCI Info system information reports and cause the GUI window to appear.
pcdr /si:2 /si:15 /pause
ri:fn&tn This switch launches external test modules (PDI files) from the command line, where fn is the name of the PDI file and tn is the subtest to run. You can only run one external module at a time and cannot run them in combination with other tests.
This example will launch the external module LED.PDI and run all tests.
pcdr /ri:led.pdi&*
You can also use this switch to run specific tests from an external module. This example will launch the external module LED.PDI and run the second available test.
pcdr /ri:led.pdi&2
ri:nnn This switch launches external test modules (PDI files) from the command line, where nnn is the name of the PDI file either with or without the file extension. You can only run one external module at a time. You can combine this switch with rt:nn on page 121 and np on page 133. This example will run the PDITEST external module and record the results to the test log file testlog.txt. The test log file will also report that np was not set.
pcdr /ri:PDITEST /pr:testlog.txt
This example will do the same as the previous example, but the test log file, testlog.txt, will now report that np was set.
pcdr /ri:PDITEST /pr:testlog.txt /np
si:xx This switch will generate the system information report which corresponds to Hardware Info menu items as specified by xx. The supported values for xx is determined by the available Hardware Info menu selections. The value 1 represents the first item in the menu, 2 represents the second and so on. If a value for xx is not specified, the system information report will default to using the 1st available menu selection. This example runs the system information module which corresponds to menu selection #2 on the Hardware Info menu and records the results in testlog.log.
pcdr /si:02 /pr:testlog.log
You can also run multiple system information reports using multiple instances of the si switch on one command line. This example will generate separate system information reports for items #1 and #2 on the Hardware Info menu, and save the output to the file Info.log.
pcdr /si:1 /si:2 /pr:info.log
Note: The System Info reports are generated in the order specified. Redundant switches are not ignored and will generate duplicate reports if the same switch is used more than once.
sl:n This switch will start the program in the language specified by the variable n, where n specifies a numeric language code. The language codes are:
Table 21: Available Language Codes Language Simplified Chinese Dutch French German Italian Japanese Portuguese Spanish Traditional Chinese Code 2 4 7 8 14 15 18 20 24
This example runs PC-Doctor in French if the specified language is supported.

pcdr /sl:7
st This switch will force a test to report all hardware bugs. When this switch is enabled, all devices that a test determines has a known hardware defect is noted in the test log as Failed. If a hardware defect is found when this switch is enabled, it does not mean the equipment is defective. The hardware in question may contain a bug which does not hinder its performance. This example runs all the hard disk tests and records the results in testlog.log. If a hardware defect is found on the hard disk, the recorded test result is Failed.
pcdr /rt:hd&* /pr:testlog1.txt /st
stl:xx This switch specifies the amount of RAM to reserve for use with the test log buffer as specified by the variable xx. Supported values range from 7,000 to 32,000 bytes. You can use the Memory contents system information module to verify the available memory for use. This example will reserve 15,000 bytes of RAM for the test log buffer:
pcdr /stl:15000
tm:nn This switch defines the minimum test time for tests and scripts run from the command line specified by the variable nn. If a test has not finished when the specified time has elapsed, it will complete before exiting back to DOS.
When using this switch with script files, any specified passcount defined by the iPasscount parameter in the script is ignored. This switch cannot be used with pc:xx on page 135. When tm:nn on page 137 is used with a script file, the minimum time specified applies to each test set defined in the ini file. When the pc switch is used with a script file, the entire script file runs for the specified number of times. This example runs all of the cpu tests for a minimum of ten minutes and records the results in testlog.log.
pcdr /rt:cpu&* /pr:testlog.log /tm:10
This example runs the script file Script.ini and repeats each test set it defines for 10 minutes. The first test set runs for 10 minutes then the second test set runs for 10 minutes and so on.
pcdr /au:script.ini /tm:10
This example runs all the CPU tests until 10 minutes have elapsed. The final test will finish its run before exiting back to DOS.
pcdr /rt:cpu&* /tm:10
This example alternates running all the subtests of the CPU test set and the Track to Track Seek subtest of the Fixed Disk test set until 20 minutes have elapsed. After 20 minutes have elapsed, the currently running tests (from both sets) will finish their runs before exiting back to DOS.
pcdr /rt:cpu&* /rt:hd&4 /tm:20
tmx:y This switch will run a test set from a script file ranging from 1-9 specified by the variable x. The tests will run for the amount of time specified by the variable y. In the script file, the names of the test sets do not matter. The first test set following the RUN command in the script file is always test set one and the second test set following RUN is always test set two and so on. This switch supports up to nine test sets on one command line. After the specified time has elapsed, the test currently in progress will finish its run before exiting back to DOS. When using this switch with script files, any specified passcount defined by the iPasscount parameter in the script is ignored. This example runs the script file script.ini and repeats test set one for 10 minutes. All other test sets defined in the script file run the number of passes specified with the iPasscount parameter in the script.ini file.
pcdr /au:script.ini /tm1:10
This example runs the script file script.ini and repeats test set one for 10 minutes, test set two for 20 minutes and test set three for 25 minutes. All other test sets defined in the script file run the number of passes specified with the iPasscount parameter in the script.ini file.
pcdr /au:script.ini /tm1:10 /tm2:20 /tm3:25
This example runs the script file script.ini and repeats test sets one and two for 10 minutes each and test set three for 15 minutes. All other test sets defined in the script file run for 10 minutes each as specified by /tm:10.
pcdr /au:script.ini /tm:10 /tm3:15
tx:n This switch defines the maximum test time for tests and scripts run from the command line specified by the variable n. If a test has not completed in the specified amount of time, the test aborts and records Failed in the test log. This example runs the sixth test of the Fixed Disk test set (the Linear Verify test) for 10 minutes and sends the result to the file testlog.log. If the test does not complete after 10 minutes, the test aborts and records Failed in the test log.
pcdr /rt:hd&6 /pr:testlog.log /tx:10
txx:y This switch specifies the maximum time duration allowed for test sets in a script file, where x specifies the test set defined in the script file and y specifies the maximum test time duration. In the script file, the names of the test sets do not matter. The first test set following the RUN command in the script file is always test set 1, the second test set following RUN is always test set 2 and so on. This switch supports up to nine test sets on one command line. In this example, tx1:10 causes the first test set defined in the script file to run for a maximum of 10 minutes, tx2:20 causes the second test set to run for a maximum of 20 minutes and tx3:60 causes the third test set to run for a maximum of 60 minutes.
pcdr /au:script.ini /tx1:10 /tx2:20 tx3:60
ver Displays the current version of the application. This example displays the version number at the DOS prompt.
pcdr /ver c:\ 2.0.788
Determining and Using Bitmap Values

A bitmap is a data structure in memory that represents information in binary format, or in other words, mapped out as a collection of individual bits. The following gives an explanation of how to determine and use bit values in a bitmap. A bitmap is a set of bits with a single bit representing a 0 or a 1. This is an example of a bit mask with all bits set to zero.
00000000
Bits are numbered from right to left in a bitmap. The far right bit is bit number 0. The next bit to the left is bit number 1, the next bit to the left of bit number 1 is bit number 2 and so on. This is an example of bit order. Bit values are read from right to left.
76543210
Starting from bit number 0, each bit has a value that is half the value of the bit on its immediate left (the bit value is not the same as the bit order). Bit number 0 has a value of 1, bit number 1 has a value of 2, bit number 2 has a value of 4, bit number 3 has a value of 8 and so on. This is an example of bit values.
128 64 32 16 8 4 2 1
Each bit in a bitmap can be used to represent a subtest in a test category or an installed hardware device. You can also use bitmaps to indicate features or devices that you want to use or mask. For example, in the PCDR.INI file a bitmap can disable specific subtests in a test set. Bitmaps can also be used on the command line. For example, a bitmap can be used with the rt switch (SEE ALSO rt:nn on page 121) to define a device count (four hard drives, four serial ports, two USB ports and so on). The first subtest or device represented in a bitmap is designated with a value of 0. Bit number 0 represents the first subtest or device, bit number 1 represents the second subtest or device, bit number 2 represents the third subtest or device and so on. The effects of a bitmask depend on how it is used. A bitmask can be used to prevent specific subtests from running or to designate specific devices for testing. To enable a subtest or device in a bitmask, you would switch its assigned bit to 1. For example, using the bitmap in the PCDR.INI file, to indicate that you do not want to run the first and third CPU subtests their assigned bits (bits 0 and 2) are set to 1. Used with the rt switch, the same bitmap would run tests on the first and third hard drives in a system with four hard drives. This is an example of a bitmap that is defined to filter out the first and third subtests or running available tests on the first and third device.
00000101
Specified subtests and devices are defined by the sum total of the bit values for bit numbers set to 1. The above bit map can be defined by an integer value of 5. Bit number 0 contains a bit value of 1, bit number 2 contains a bit value of 4. The sum total of the bit values for bit number 0 and bit number 2 is 5.
00000101 = 4+1 or 5
PC-Doctor Network Factory Administrator Guide | For More Information | 141
For More Information

Contact PC-Doctor, Inc 9805 Double R Blvd. Suite 301 Reno, NV 89521 Phone: 775-336-4000 Fax: 775-336-4099 E-mail: PC-Doctor E-mail support Web: Official PC-Doctor Website

Network Factory Administrator Guide

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Network Factory Administrator Guide

Uploaded by

Copyright:

Available Formats

PC DOCTOR, INC.

Delivering Confident Computing

PC-Doctor Network Factory Administrator Guide

How to use PC-Doctor Network Factory

Last revised: 2009 03 20

2005 PC-Doctor, Inc. All rights reserved

2 | PC-Doctor Network Factory Administrator Guide | TOC

Getting Started Installing Network Factory..................................................................14

Implementing Your Network Factory Integration...........................................................22

Installing and Running the Network Factory Client.......................................................50

PC-Doctor Network Factory Administrator Guide | TOC | 3

The Progress Monitor.........................................................................................................53 Generating Reports.............................................................................................................56

Managing Components through a Parts List...................................................................65

Creating and Managing Accounts.....................................................................................72

Managing the Database......................................................................................................75

The Help Tab.......................................................................................................................86

Troubleshooting Tips and FAQ..........................................................................................91

4 | PC-Doctor Network Factory Administrator Guide | TOC

ODBC Connectivity with Firebird Database....................................................................97

Using the DOS UUT..........................................................................................................111

PC-Doctor Network Factory Administrator Guide | TOC | 5

For More Information......................................................................................................141

6 | PC-Doctor Network Factory Administrator Guide | Welcome to PC-Doctor Network Factory

Welcome to PC-Doctor Network Factory

Figure 1: Web and database server

PC-Doctor Network Factory Administrator Guide | Welcome to PC-Doctor Network Factory | 7

Before you Begin Tips for Implementing Network Factory

Understanding how Network Factory Works

Network Factory Implementation Planning

Implementation Planning Worksheet

About the PC-Doctor Network Factory Mapping Program Logic

Using an earlier example, a typical mapping would look like this:

Figure 2: Network Factory Mapping Logic Flowchart

About using wild cards for defining mappings

You would then create 10 different inventory mappings:

Getting Started Installing Network Factory

Hardware and Software Requirements

Hardware Requirements for servers supporting 51-150 UUTs

Supported Windows Client Operating Systems

Suggested Linux Client Operating Systems

Calculating Space Requirements to Support Archiving

Running the PC-Doctor Network Factory Server Installer

Before Launching the PC-Doctor Network Factory Server Installer

Installing the PC-Doctor Network Factory Server

Installing a Dual Server Configuration

4. On the database server replace the contents of restart.cmd to:

5. On the Apache server replace the contents of start.cmd with:

6. On the Apache server replace the contents of restart.cmd to:

Starting PC-Doctor Network Factory Server

Figure 3: Network Factory Start Server short-cut

Finding the Server IP Address

Figure 4: Using ipconfig to determine the server IP address

Launching the Monitoring Console

Figure 5: Typing Server IP in the Address field

Figure 6: The Network Factory User Login

Figure 7: The Monitoring Console Progress Monitor

Figure 8: Network Factory Stop Server short-cut

Implementing Your Network Factory Integration

Composing PC-Doctor Network Factory test scripts

Composing Test Scripts for Specific Device Testing

Figure 9: The Scripts tab

Figure 10: Creating a new test script

Figure 11: The New Script Dialog Box