Developing a Test Network Environment


When implementing a new network or computer solution, you should perform a thorough battery of testing before deploying it into production. You’ll begin the test process in an isolated lab where new technologies will have no chance of adversely affecting the existing computing environment. After you are satisfied with the new technology’s performance in the test lab, you can expand testing into a pilot deployment involving a few actual users, analyzing their input and reactions to make any necessary adjustments to your design. Only after you are satisfied with the pilot deployment should you perform a full-scale deployment in your production environment.

Test Day Tip

Depending on the total number of users you have, you might want to split your full-scale deployment schedule into stages. After each stage, you can verify that your system is accommodating the increased processing load from the additional users as expected before you begin deploying the next group of users.

The success of any network deployment depends heavily on your ability to develop an effective test environment. This test lab can consist of a single lab or several labs, each of which can test various pieces of the overall design without risking the integrity of your production environment. Working in the test lab will allow you to verify the effectiveness of your design, discover any potential deployment problems, and increase your staff’s familiarity with the new technology before it “goes live.” In short, a well-developed test environment will reduce the risk of errors during the deployment of a new technology, thus minimizing any potential downtime for your clients and users.

Planning the Test Network

Before you begin testing your network design, you need to plan the test network itself. The first step is to determine the hardware resources required to set up the lab. This involves identifying the standard configurations of your existing or new client computers. (If you support diverse workstations, do your best to include a representative workstation from each supported configuration.) Be sure to include all components and peripherals, including the following:

  • BIOS versions

  • USB adapters

  • CD and DVD drives

  • Sound cards

  • Video cards

  • Network adapters

  • Smart card readers

  • Removable storage devices, such as Zip drives or external hard drives

  • Small Computer System Interface (SCSI) adapters

  • Removable storage devices

  • Mouse or trackball devices

  • Keyboards

Although using separate hardware devices for your test lab is the ideal, many small and medium-sized businesses simply cannot afford to buy dozens of computers for the test lab. Using a third-party product such as VMware (www.vmware.com) will allow you to simulate a multiple server/domain environment, as well as multiple desktop operations systems, without the expense of multiple individual machines. VMware can run multiple operating systems—such as Microsoft Windows, Linux, and Novell NetWare—simultaneously on a single PC, including all networking and connectivity that you would need to perform your testing.

In addition to purchasing hardware or virtual PC environments for the test lab, you need to secure appropriate licensing for all necessary software, including operating systems, service packs, management utilities, and business applications. Make sure that you can obtain or duplicate the following configuration and information when creating a test lab for Windows Server 2003:

  • Network services Install the same services on a test server that will be used in the actual deployment. This can include Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), Windows Internet Name Service (WINS), or any other Windows service.

  • User accounts Create a domain controller in your test environment to effectively simulate any upgrade procedures.

    Test Day Tip

    You can use the Clone Principal tool (Clonepr.dll) utility, included in the Windows Server 2003 Resource Kit, to copy production users into a test domain.

  • Domain structure Simulate the domain hierarchy of your proposed environment, including forests, trees, parent and child domains, and all necessary trust relationships. Configure sites as necessary to simulate any WAN testing considerations.

  • Network protocols and topology Re-create the network technologies that will be used in your production environment as completely as possible. For example, if your production environment will be using 100MB cabling, using Gigabit Ethernet when doing performance testing will provide erroneous results. You should also include routers to test for performance latency as well as replication across WAN links.

  • Domain authentication Use the appropriate authentication to mimic the desired production environment, including mixed mode versus native mode, and NTLM versus Kerberos client authentication. Selecting the appropriate authentication model will allow you to compare apples to apples during testing and avoid any unexpected behavior later.

    Exam Warning

    Remember that Windows NT 4.0 workstations or servers cannot use Kerberos authentication. You will need to rely on either NTLM authentication or its stronger successor, NTLM version 2.

  • Group Policy Object (GPO) settings Create GPOs with the settings that you wish to deploy in your production environment. You can use the GPMC (discussed earlier) to test the potential behavior of any policy objects on user and group objects.

One important (but often overlooked) step in the planning process is that of carefully selecting a location for your test lab. Too often, the test lab is relegated to a corner of a server room or whatever room is available in a file or storage area. However, if you will be performing tests for an extended period of time, you should consider allocating a permanent or semipermanent location for the lab. Be sure to locate the test lab in an area with enough space for all necessary equipment and personnel. If you will be testing network equipment that will be deployed to multiple locations, you should consider deploying a test lab at each site to test WAN links, replication, and site configurations. Also, identify the personnel you’ll need to perform testing, as well as whatever training they will need.

start sidebar
Head of the Class...
Test Lab Domain Structure

Although you usually want your test lab to mimic your production environment as closely as possible, there are exceptions to every rule. Some tests that you might wish to perform will affect an entire domain or forest, rather than a single machine. If you are testing this type of functionality, you might wish to create a separate domain within the test lab so that the remainder of the lab environment will not be adversely affected.

Some of the tests for which you might wish to create a separate, isolated domain or forest are as follows:

  • Switching from mixed mode to native mode Changing from mixed mode to native mode will allow for much tighter security in a Windows 2000 or Windows Server 2003 environment, but it assumes that you have no Windows NT 4.0 backup domain controllers (BDCs) remaining in your domain. (After the switch to native mode, Windows NT 4.0 BDCs will no longer be able to replicate with Windows 2000 or Windows Server 2003 domain controllers.) This change will affect an entire domain and cannot be reversed.

  • Upgrading the domain or forest functional level This feature was introduced in Windows 2000, where you had the ability to run a domain in mixed mode for backward compatibility or native mode for increased security and functionality. Windows Server 2003 expands on this by creating several levels of both forest and domain functionality that can expose different features of the operating system for your use. For example, raising the functional level of a domain to Windows Server 2003 native will prevent any existing Windows NT 4.0 or Windows 2000 Server domain controllers from participating in domain replication. Like the switch from mixed to native mode, this will affect the entire domain and/or forest in question and cannot be undone.

  • DNS settings Changes to a DNS server will affect all clients who use that server for name resolution. Although this does not involve the kinds of one-way changes described above, you should still proceed with caution before making changes that can affect other tests that might be running simultaneously in the lab environment.

end sidebar

Finally, be sure to provide both physical and technological security measures for the equipment and resources of the test lab. This includes isolating the test lab topology from your corporate network using routers, switches, or firewalls, as appropriate. If you need to provide a connection from the test lab to the corporate network, decide in advance how you will control and monitor that connection, and be sure to devise a way to quickly terminate the connection if something unexpected or adverse occurs.

start sidebar
Configuring and Implementing…
Building a Test Lab

How you create your test lab depends on your specific requirements. Here, we present the basic steps for building a test lab, which you can alter as necessary to meet the needs of your organization:

  1. Begin by acquiring the necessary hardware and software, including the following:

    • Routers, switches, cabling, and other network infrastructure devices

    • Computer hardware for servers and workstations

    • Operating system software and any administrative tools

    • Line-of-business software applications

  2. Install and configure the necessary routers and switches to provide network connectivity for the test lab. Label all devices and network cables.

  3. Install and configure server hardware. Try to use the same random access memory (RAM) and central processing unit (CPU) configuration that you plan to deploy in your production environment. Configure the hard drive arrays, partitions, and drive letters to match the intended production environment.

  4. Defragment all hard drives and install up-to-date antivirus software.

  5. Install the appropriate operating system for the test environment.

  6. If you will be deploying new Windows Server 2003 servers, perform a clean installation of Windows Server 2003.

  7. If you will be upgrading an existing server, install a copy of your existing network operating system (NOS) to test the upgrade process.

  8. If you will be repeating the test process several times, consider using a disk-imaging utility to save time when re-creating the test environment.

  9. Test the network connectivity in the lab environment. Testing the network connectivity first allows you to isolate any problems more easily.

  10. Install all application software that will be present in the production environment. Include all server-based applications and administrative tools such as SMS. If you are using Terminal Services in your production environment, install all applications that will be present in the production environment.

  11. Install and configure all client computers.

  12. Secure the test lab using physical measures, such as a card-reader on the entrance door, and technical measures, such as a dual-homed router to segregate network traffic originating in the test lab from traffic passing on the production network.

end sidebar

Implementing the Test Network

After you’ve finished designing your test lab, you can finally get down to the actual business of testing. The steps needed to create test procedures can be broken down into two conceptual halves: What do we want to test and how should the tests be performed? You’ll often hear the former referred to as a feature test description, which lists all features or aspects of a technology that need to be tested. For example, the feature test description when assessing how trust relationships behave during an operating system upgrade might read something like this:

“All trust relationships between the Windows NT 4.0 domain PRODUCTION and the Windows NT 4.0 domain SALES should continue to function normally when the SALES domain is upgraded to Windows Server 2003.”

You should design tests that will measure the functionality of each feature included in your design plan. Additionally, you need to test how your new network will function in conjunction with any existing systems in the production environment. For Windows systems, you need to test hardware, driver, and application compatibility on every hardware configuration that will be running a Windows operating system.

Test Day Tip

Be sure to test functionality with existing technologies even if they are going to be upgraded or replaced as part of the new installation. Although the new technology may need to coexist with the old technology for only a short period of time, you need to know in advance how the interoperability will behave.

Another key factor in using a test lab is creating a schedule of when testing should be performed. Especially if you have many different individuals or teams performing various tests, this scheduling should be formalized, rather than handled on an ad hoc basis. Ideally, you should designate someone to act as a lab manager to maintain and upgrade the lab schedule, as well as review testing plans to ensure that all necessary equipment and software can be made available at the requested time. Even if the lab manager is not dedicated solely to this function, he or she should be responsible for the following:

  • Establish and enforce test lab policies, procedures, budget, and inventory control.

  • Oversee scheduling of required configuration changes and communicate these changes to other test lab users.

  • Develop and manage an incident reporting and tracking system.

  • Monitor the change-control process.

  • Maintain test lab documentation (we’ll discuss documentation in the next section).

  • Manage hardware and software configurations, updates, and preventative maintenance.

  • Establish and maintain physical security.

start sidebar
New & Noteworthy…
Exploring the Group Policy Management Console (GMPC)

A prominent new feature of Windows Server 2003 is the GPMC, which allows administrators to monitor, troubleshoot, and plan Group Policy settings across an entire enterprise from a single management console. Along with a console window that provides a graphical representation of GPO settings, the GPMC also includes a collection of scripts that you can run from the command line to streamline administration and planning tasks. You can download and install the GPMC from Microsoft’s Web site. Once it’s installed, you’ll have a shortcut to it in the Administrative Tools folder, and it will be available as an MMC snap-in.

The scripts that are included with GPMC can greatly simplify your life when you attempt to take stock of an existing network environment (for example, when you begin to plan for an upgrade). Using GPMC, you can quickly perform the following tasks using its automated scripting function:

  • List all GPOs that are present in a given domain

  • List any disabled GPOs

  • List GPOs at a backup location

  • List GPOs by policy extension or security group

  • List any orphaned GPOs (GPOs that are no longer linked to any AD object) that are still present in the SYSVOL directory

  • List unlinked GPOs in a domain

  • List GPOs with duplicate names

  • List GPOs without security filtering

    GPMC’s reporting functions will also generate HTML-formatted reports in an easy-to-read format, which is always a hit when you’re presenting the upgrade proposal to management or a budget committee. Additionally, the GPMC includes the Resultant Set of Policy Planning function to allow you to simulate changes to GPO settings for a user, computer, or container object. Both of these functions will greatly assist you with the administrative and technical aspects of a network design project.

end sidebar




MCSE Planning and Maintaining a Windows Server 2003 Network Infrastructure. Exam 70-293 Study Guide and DVD Training System
MCSE Planning and Maintaining a Windows Server 2003 Network Infrastructure: Exam 70-293 Study Guide and DVD Training System
ISBN: 1931836930
EAN: 2147483647
Year: 2003
Pages: 173

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net