Building a Windows 2000 Test Lab
Building a Windows 2000 Test Lab |
|
Strive to design your lab for flexibility. In addition, at a minimum, try to meet the following two criteria:
Although you might decide to use one lab for both server and client computer testing, this section presents lab design considerations for each separately.
Plan to test as much of the proposed logical and physical production environment as possible, including computer hardware, network topology, WAN connections, domain architecture, services, databases, business applications, administrative tools, security model, application deployment methodology, and network server storage methods.
This section presents some considerations for designing a lab to test Windows 2000 Server. The issues presented here might not apply to all Windows 2000 Server implementations. Focus on the considerations that apply to your design.
Use the same type of hardware components and drivers that you use, or plan to use, on servers in the production environment. Be sure to obtain an updated BIOS that is compatible with Windows 2000.
Use the same services and configurations that you will use in the actual deployment. For example, duplicate the DNS, DHCP, and WINS configurations. If you are not planning on using the DNS and DHCP services built into Windows 2000, include the third-party services you plan to use.
If you are migrating from Microsoft® Windows NT® 4.0, set up your domain controllers as replicas of your production domain controllers, using copies of the production user accounts. You can use the ClonePrincipal tool to copy production users to your test domain. For more information about strategies for migrating user accounts and the tools to use, see "Determining Domain Migration Strategies" in this book. Coordinate with your IT security division whenever you copy production data to lab databases.
If you are implementing Active Directory, simulate the domain hierarchy. For example, include a forest with multiple trees, a tree with parent and child domains, and transitive and one-way trust relationships, as appropriate. Reflect your IT centralized or decentralized administration in the organizational unit. Include Active Directory sites as appropriate.
Include file and print servers, application servers, Web servers, database servers, and other utility servers that are, or will be, in your production environment. If you plan to use SMS to deploy Windows 2000 Server, include it in the lab.
To accommodate both the mixed environment during a phased rollout and the Windows 2000 environment after the completion of the rollout, plan for some domains of the following types:
By simulating the interim state, you can determine functional problems that might occur during the phased implementation. The servers with operating systems other than Windows 2000 Server should mirror the services in the current production environment.
Use the same mix of client computers as in your production environment. If you plan to deploy Windows 2000 Server first and Windows 2000 Professional later, include the client computer operating system that you will use until Windows 2000 Professional is deployed.
If you plan to deploy Windows 2000 Professional first, test for how the extended server functionality will be introduced into your environment as the infrastructure is deployed.
If you plan to have a phased rollout, include the same mix that will occur during rollout. For example, have client computers with Microsoft® Windows® 95 and client computers with Windows 2000 Professional.
Mirror the network topology and protocols you use in your production environment as closely as possible. For example, if your production network uses both Ethernet and Token Ring, the lab should include both.
If you have a WAN, the lab should have routers to test network latency. If you have the facilities and budget, you might want to set up a secondary lab at a remote location to test network latency across the WAN link. For example, you should test domain controller and Global Catalog replication across the link. If you have a multinational organization, it is recommended that the secondary lab be in a different region of the world to test real-world latency problems.
If you do not have a secondary lab location where you can test the WAN link, you can cable two routers together in the same lab and use a link simulator to test the link.
Provide the same types of remote connectivity, such as Routing and Remote Access Service and VPN, to allow you to test Point-to-Point Tunneling Protocol (PPTP), Internet Protocol Security (IPSec), Layer 2 Tunneling Protocol (L2TP), and Demand Dial Routing.
Include a representative sample of the types of peripherals used in your production environment. For example, include the same types of printers and scanners, along with their associated drivers.
If you plan to implement Windows 2000 Server so that it operates with networks or computers using another operating system, mimic the interoperability infrastructure. For example, include connections to mainframe hosts, UNIX systems, or other network operating systems. To keep your lab configuration and test suite manageable, decide which interoperability scenarios are most important to your organization and focus on those.
Include the tools (Windows 2000, third party, or custom built) that you currently use or plan to use for server-based administrative tasks. You need to test the tools for compatibility and effectiveness in the new environment.
Test any fault tolerance techniques you plan to use in your production environment. For example, if you plan to use clustering, include a clustered server in the lab.
If you plan to implement Terminal Services, install the appropriate mix of applications on the server. You need to understand the impact of running applications in a multi-user environment. You might need to modify the default operating environment for some applications to obtain the desired functionality. For more information about Terminal Services, see "Deploying Terminal Services" in this book.
Note
If you are concerned that some of your critical applications might not be compatible with Windows 2000 Professional, consider installing Terminal Services. You can install Terminal Services on a Windows NT 4.0 server and set up your Windows 2000 client computers to access the applications with problems from that server. Think of this approach only as a contingency plan to avoid last minute schedule slips.
You should isolate the test lab from your corporate network. If you need to provide a connection from the lab to the corporate network, plan for ways to regulate and control the connection and devise a way to quickly terminate the connection.
Design router configurations to protect the production network. For example, consider using a multihomed router with two network adapters to connect the lab to the production network for specific, controlled uses. Configure the router so that the production network can access the test network, but the test network cannot access the production network. This approach protects the production environment from anything going on in the lab but allows a user in production to access resources in the lab. For example, you could use this approach to test logon scripts on a lab server with a small number of users before moving the scripts to a pilot in the production environment.
Design the client computer lab so that you can test the same functions and features you use in your production environment. Include the same types of hardware, applications, and network configurations. This section covers some considerations for designing a lab to test Windows 2000 Professional. The issues presented here might not apply to all Windows 2000 Professional implementations. Focus on the considerations that apply to your design.
Include at least one client computer for each vendor and model that is to run Windows 2000 in your production environment. If your organization uses laptops, docking stations, or port replicators, be sure to include those vendors and models as well. Be sure to obtain an updated BIOS that is compatible with Windows 2000.
It is recommended that you develop a standard hardware configuration for Windows 2000 Professional as part of your deployment project. Your lab testing can help you define and refine a standard configuration. As you define hardware configurations, verify that the components are compatible with Windows 2000. For example, you might need to verify compatibility for the following components:
To determine compatibility, look up the components on the Microsoft Hardware Compatibility List (HCL), which you can find at http://www.microsoft.com by searching with the keyword "HCL." The HCL includes all the hardware that Microsoft supports. If your hardware is not on the list, contact the vendor to find out if there is a driver. If your components use 16-bit drivers, you need to obtain a 32-bit driver.
You can also use Windows 2000 Professional Setup to check for hardware compatibility. Run Setup in check-upgrade-only mode to obtain log files that indicate hardware and software incompatibilities and device drivers that need to be updated. The command line format for check-upgrade-only mode is:
winnt32 /checkupgradeonly
On computers running Windows 9x, the log file, called Upgrade.txt, is located in the Windows installation folder. On systems running Windows NT, the log file is called Winnt32.log and is located in the installation folder.
If updated device drivers for your devices are not included with Windows 2000, contact the vendor to obtain an updated driver.
Once you decide on the standard hardware configuration, inventory the computers in your production environment to determine which ones need to be upgraded before you deploy Windows 2000. For information about how to use SMS to perform the inventory, see "Using Systems Management Server To Analyze Your Network Infrastructure" in this book.
For more information about developing client computer standards, see "Defining Client Administration and Configuration Standards" in this book.
Provide connectivity to the same types of networks that you use in the production environment, such as a local area network (LAN), a WAN, or the Internet.
If you plan to use Routing and Remote Access or a proxy network service in the production environment, include these types of connections in the lab.
Configure servers for the services used in the production environment. For example, include services such as:
Remember to provide for administrative services such as:
If your organization uses, or plans to use, domain authentication, simulate your authentication configuration in the lab. If you are migrating from Windows NT 4.0 to Windows 2000 Server, plan for authentication in the mixed environment that will occur during the phased rollout.
Include network services used in your environment, such as Simple Network Management Protocol (SNMP).
Use the protocols you plan to use in the production environment. Verify the protocols you use on client computers before connecting them to the production network.
You need licenses for and access to the software for all applications, stand-alone or server-based, that are to be supported on Windows 2000 Professional client computers. For more information about testing applications in a lab, see "Testing Applications for Compatibility with Windows 2000" in this book.
Include a representative sample of the types of peripherals, such as printers and scanners, used in the production environment.
Simulate the server platforms to be accessed by Windows 2000 Professional client computers. If you have a separate server lab, consider connecting the client computer lab to it instead of installing servers in the client computer lab. You might need to establish connectivity to the following systems:
If you plan to deploy Windows 2000 Professional at the same time as Windows 2000 Server, include any type of server that a client computer can access during the deployment period, unless these tests are to be performed by the Windows 2000 Server team.
As part of your Windows 2000 Professional project, your organization might decide to evaluate standard client configurations and Group Policy for managing them. Lab tests can provide information for recommending specific configurations and Group Policy objects to management. If you decide to perform this type of evaluative testing, include side-by-side comparisons of different configurations and Group Policy settings.
Plan to have enough computers of the same make and model to allow for the side-by-side evaluations. Evaluate client configurations based on performance, ease of use, stability, hardware and software compatibility, functionality, and security model. Evaluate Group Policy objects by verifying that they produce the desired result, particularly when more than one applies to a configuration, and that the resulting logon time is acceptable.
Use the lab to start evaluating the impact on your network traffic by testing for changes in baseline traffic patterns without user activity. For more information about performance concepts and monitoring tools, see "Overview of Performance Monitoring" in the Microsoft® Windows® 2000 Server Resource Kit Server Operations Guide.
Your client computer lab, like the server lab, needs to be isolated from the corporate network. If you need to provide a connection from the lab to the corporate network, plan how you will use routers to separate the two networks.
Because some tests alter the lab environment, they can inadvertently influence other tests. Care must be taken to isolate, coordinate, and manage these types of tests. For example, server upgrade tests change the state of the servers. Address scenarios such as these in the lab domain design. Other scenarios might need to be addressed in the lab management procedures. For example, schema changes affect the entire forest, so schedule this type of test and communicate it to other lab users.
Remember that the lab needs to change frequently to reflect the current focus of testing. Make backups of baseline configurations so testers can quickly restore a computer to its prior state. Be sure to test the restore process. Document the backup files and store them in a safe, accessible place.
Design the lab domain structure to provide consistent setup and configuration so that testers can rely on a known-state infrastructure. For example, allocate a single domain for migration and mixed-mode testing. If you do this, the domain should always be in the mixed-mode state except for scheduled periods when it is rolled back to the prior state to test the migration process. In this way, lab users always know what to expect.
To summarize, design the lab domain hierarchy to segregate tests into separate domains. Examples of the types of tests that might require separate domains are:
A large manufacturing company designed its lab with specific testing in mind. Figure 4.4 illustrates the logical domain structure of the lab.
This company created a root domain with four child domains. The domain structure allowed the project team to use a separate domain for each of these types of tests:
An isolated domain allowed the team to test DNS without affecting any other testing.
Figure 4.4 Example of Test Lab Logical Domain Design
