Chapter 7 - Setting Up a Test Environment

  • Article
Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Bob Hunt, Managing Consultant, E-Sync Networks, Inc.
Paul Sebben, Managing Consultant, E-Sync Networks, Inc. 

Setting up a test environment to evaluate new technologies is a common practice for successful deployments. When new, complex technology is business critical and affects many users, it is prudent to do a thorough product evaluation. When you perform a complete product evaluation and a scenario-based test plan, you will gain knowledge of a product and how it will react in different situations. This is the best insurance plan your company can have for an enterprise-wide implementation.

The tests need to put the product through most of the scenarios relevant to your company's implementation of Microsoft Exchange 2000. This chapter provides information about setting up test environments and putting together thorough test plans for Exchange 2000. This chapter also cites specific features that should be tested in various scenarios relevant to an enterprise-wide implementation of Exchange 2000.

Why Testing is Important

With any enterprise software deployment, the importance of testing and establishing a relevant testing environment cannot be stressed enough. You should not worry that a specific feature does not function as advertised, but rather how a specific feature affects the enterprise. At the highest level, a test environment allows you to install and configure a new product prior to its implementation. Many enterprise-wide application deployments are complex in size and scope; the depth of which may not be understood until actual implementation. However, gaining in-depth knowledge of a product prior to implementation reduces risk because each phase of implementation has been tested in a similar environment.

For example, there are various connectors available in Exchange for linking locations across a company's WAN. Knowledge of the connector network overhead provides the information that you need to select connectors, based on available bandwidth between locations.

When you install software in specific test scenarios that are similar in scope to the actual enterprise-wide implementation, you can perform one or more trials. This reduces the likelihood of potential failures in an actual network environment. Your test environment does not have to completely duplicate the company's network infrastructure, but it should include the major architectural components necessary for validating the majority of the implementation scenarios. If the test lab closely mirrors the production environment, tests performed in the lab can set expectations for the behavior of the application's production environment.

Planning the Test Lab

The goal of the test lab is to establish a model of the pre-implementation production environment. The first step is to identify what comprises a small-scale model of your network infrastructure. Keep in mind that simultaneous testing of several production environment scenarios is desirable, but is not necessarily a requirement when planning for the test lab.

Realistic budgeting is essential. Although the acquisition and construction of a test lab can be expensive, it is important to avoid using some or all of the lab equipment for the production environment. It is important to understand that the need for a test lab does not go away after the implementation is complete. Convenient and easy to use disk imaging software enables companies to build lasting and substantial test lab environments that can be used in their enterprise application deployments for many years. For example, companies must have the ability to assess the impact of new service packs in a test environment. New applications, including third-party add-ons, can be installed in the test environment for evaluation and testing purposes. Another use for the test lab environment is as a training center for new employees or administrators. Test labs can also be used for application fine-tuning, network performance and analysis, backup and restore, and disaster recovery.

Install and maintain the lab as if it were a production environment. Investing in a test lab allows your support staff to test administration, support, maintenance, and troubleshooting techniques without affecting the production environment. The lab itself should always be ready to test new products or version upgrades, patches, and service packs. You can appoint a lab manager or coordinator to ensure control over the lab conditions. This person can be the primary contact for the lab configuration, and should have signature authority on changes to the environment.

A system of change control is essential to keep the lab in a continuously stable and known state. The lab manager can ensure that the testing efforts of multiple groups do not interfere with each other. The lab manager is also in charge of the process to image and restore computers to their original state. Include a step for verifying changes in the test environment.

Office Space

When you consider space for your test lab, select a location that can be kept clean, cool, and undisturbed. Tables, chairs, and other office furniture are necessary so the lab environment is usable and dependable; this furniture should be dedicated to the lab. Find a secure location where test scenarios can be left running without disturbance from other users, and where hardware is secure.

Hardware

Approach choosing hardware for the test lab in one of two ways. First, you can ensure that the hardware you choose is identical to the hardware used for production deployment. The advantages of this strategy are that it allows you to perform server scalability and performance testing, and to use lab hardware as backup for the production environment. A disadvantage is high cost. Having enterprise-class hardware sitting idle may not fit the corporate information technology budget.

The second option is to choose hardware that is less expensive than the enterprise-class hardware that you intend to use for the deployment. The primary advantage of this option is the hardware for the test lab can be obtained at a relatively low cost. Disadvantages to this approach include, not gaining familiarity with the hardware to be used during the deployment, and not being able to perform hardware scalability and performance tests.

The most important factor to keep in mind is that the lab must contain the major components of the company's production infrastructure for relevant software testing. If resources are not available for the test lab, you can still perform specific software implementation scenarios on less capable computers. Early acquisition of a production-class server allows for scalability testing on the chosen hardware prior to implementation. The company can then verify performance, mailbox count, server size, and other potential issues that need to be addressed.

Microsoft TechNet and the Exchange Web site at https://www.microsoft.com/exchange contain documentation on scalability, users per server, and other benchmarks. Some server hardware vendors may have information on Exchange server sizing on their company Web sites. All of these resources will give you information on the size of a server to be purchased.

Backup hardware for the test servers is a valuable component of any test lab. In addition to testing backup software and hardware, the test lab can be used as a mailbox recovery location if a mailbox needs to be restored. The company standard for backup software and hardware needs to be tested together and put through a number of backup and recovery scenarios so the organization is prepared for an unexpected loss of data.

Dedicate client workstations to the test lab environment using standard company software, and each type of messaging client in the organization. Include all versions of Microsoft Outlook supported by the information technology group.

Networking

As discussed earlier, the test lab's network environment must include the major components of the company's actual production network for relevant test scenarios. While it is preferred that identical network hardware that is in use in the production environment is procured for the test lab, duplicate functionality is most important.

It is important to keep the test environment completely separate from the production environment and on its own network. This will ensure that testing activity does not affect the production LAN or messaging environment. The only shared component from the network infrastructure (between the testing and production environments) should be Internet connectivity, unless an entirely separate connection is available.

It is important to set up a separate mail-testing domain for the testing environment that is configured to send and receive mail from the Internet. This is because Internet mail capability is a requirement for company e-mail systems. For example, if an e-mail domain name is microsoft.com, enabling a domain named test.microsoft.com requires making only a few Domain Name System (DNS) entries and any necessary changes to the firewall. It may be necessary to set up a cache-only or secondary DNS server for the testing environment for the separate root domain controller that holds the test environment's Active Directory.

An additional option to consider is how the production network will look in the future. Equip the test lab network with network upgrade hardware prior to production implementation so the impact of the upgrade can be measured.

Software

As mentioned previously, try to duplicate the company's network environment to create a model of the production environment. Because it is important that this model be separate from the production environment, the software resources located on the production network should be duplicated in the test lab. This includes domain controllers, Dynamic Host Configuration Protocol (DHCP) and Windows Internet Name Service (WINS) servers, any Microsoft Windows NT 4.0 servers with Microsoft Exchange Server 5.5, a computer running Microsoft Windows 2000 with a copy of the company's root Active Directory, and so on.

Have available in the test lab any third-party applications that might affect the production Exchange environment. This includes fax gateways, public folder add-ons, and backup software and agents. In addition, any e-mail systems that interact with Exchange in the production environment should be duplicated in the test lab. E-mail clients that are used throughout the organization also need to be made available in the test lab. These can include Outlook, Internet Message Access Protocol version 4 (IMAP4), Post Office Protocol version 3 (POP3), Microsoft Outlook Web Access, and Network News Transfer Protocol (NNTP) e-mail clients.

Gathering Requirements

Before testing begins, you should have a full understanding of the proposed messaging environment. A good place to start is to identify the shortfalls of the current environment ranging from significant issues, such as switching between different messaging systems, to specific drawbacks of the current environment. An example is the need to change the Exchange-organization name due to a company name change or an acquisition. If you are currently planning your test environment, it is likely that the requirements gathering phase for the Exchange 2000 messaging environment is complete.

Developing a Test Plan

A test or migration plan is essential for your company's successful Exchange environment implementation. It is important at this stage to understand all aspects of the product intended for the future production environment, and that this process of gathering information should end before you draft a test plan. All features, protocols, and connectors identified in the requirements gathering phase should be included in your test plan, so all architectural components of the production environment are tested in the lab.

Identify Risks and Contingencies

Because all activities related to the production deployment cannot be tested in a lab, a staff with a working knowledge of the product is insurance against potential disasters. While some problems may occur, thorough product knowledge prepares a team for unexpected issues.

Network Effects

An unavoidable risk during implementation is how changes to the messaging environment will affect the network infrastructure. An environment is only as strong as the infrastructure it runs on; unfortunately, you cannot test or know how the messaging infrastructure is going to impact the network infrastructure prior to the implementation.

As a contingency plan, you should test as many network-related items as can be duplicated in a test lab while considering the impact of adding the messaging components to the environment. A simulated test WAN on your network that measures messaging performance is valuable, but is not altogether conclusive without further information, such as the amount of messaging and replication traffic generated and sent to each site.

Implementation teams should gather network performance information from the company's WAN to assess available bandwidth, rather than identify the total link bandwidth. You should analyze the available bandwidth between each site during business and non-business hours to determine WAN traffic patterns. You should also compile a detailed protocol-level analysis of the company's WAN to determine the amount of e-mail, replication, standard network, and other WAN traffic. After you have gathered this information, you can test messaging components with a simulation of the anticipated bandwidth.

Administrative Access

Another risk during an Exchange 2000 deployment involves changes to administrative access. Administrative groups in Exchange 2000 allow specific control over administrative rights, but like many other security features, they must be thoroughly planned and tested. Doing this in the test environment allows information technology personnel to understand the power and flexibility of administrative groups. For example, if a company has two branch offices and within one are multiple divisions that share the LAN with the second branch office, you can set up separate administrative groups for each branch office. This allows users to modify only their own branch servers.

SMTP Connector

A critical detail in this process is the vital and potentially challenging Simple Mail Transfer Protocol (SMTP) Connector upgrade. This component is a core feature of Windows 2000, as opposed to a Microsoft Exchange 5.x add-on. It can be helpful to perform a test server in-place upgrade to understand the impact of the changes before production deployment.

A final consideration when upgrading is that when Exchange 5.5 public folders are replicated or upgraded to Exchange 2000, any associated distribution groups are converted to universal security groups. Even in native-mode Exchange 2000 organizations, when an administrator or a client changes the permissions on a public folder, they can create a distribution list and set permissions to allow members of that list to access the public folder. When you set permissions on a public folder, all associated distribution groups convert to universal security groups, and a native Windows 2000 domain must host them. Remember this restriction when assessing the risks of upgrading public folders.

Replication Latency

When you are performing potentially risky tasks, be aware that it might take time for your changes to replicate and become available. For example, if you set permissions on a domain controller, it may take a short period of time before the permission settings are replicated to other domain controllers in the same domain and Windows 2000 site. However, it is possible for Exchange services to request permission-related data from a domain controller without the most current replication information. Thus, when you make configuration changes such as adding new users and servers or moving mailboxes, you may experience a lag time before the settings are replicated to other domain controllers in the same domain and site. Site-to-site replication depends on your schedule for it. If you schedule replication every eight hours, changes in one site will take up to eight hours to replicate to all other sites.

Training

Training users is essential throughout enterprise deployments. Users who are unfamiliar with new software and functionality are a significant burden on the help desk and other support staff. This situation is easily avoided by establishing a training and ongoing support program for the users prior to production deployment. In addition, telling users where to find product documentation and general information is essential to the success of the project.

Third-Party Connectors

A final area of concern is third-party connectors, because there are many add-ons for Exchange 5.5 and earlier versions of Exchange that organizations use for core functionality. Many of these products are not compatible with Exchange 2000 and require thorough evaluation before upgrading. You can avoid this issue by keeping one or more Exchange 5.5 (or earlier) servers that run third-party connectors until new versions of connectors become available. After new versions become available, information technology personnel can identify migration scenarios to move this functionality to a new server.

Client Software Test Plan

Each client protocol in use must be included in the test plan to ensure compatibility. Some of the testing that should occur includes:

  • E-mail delivery between Exchange 2000 and Exchange 5.5 servers in a different site. 

  • E-mail delivery between different e-mail systems over older connectors. 

  • Outlook offline and online client configurations connecting to global catalog servers to get directory information. 

Include Outlook Web Access in the client test plan. Two different interfaces exist to provide access for browsers:

  • Interfaces for earlier browser versions that use frames (Internet Explorer 3.02a, Internet Explorer 4.x, Netscape Navigator 3, and Netscape Navigator 4). Java is not included and there are fewer frames, resulting in better performance than Exchange 5.5 Outlook Web Access. 

  • An interface for Internet Explorer 5.0, which has a similar interface to Outlook. 

You can test Outlook Web Access with different browsers and determine whether an upgrade to Internet Explorer 5.0 is required.

MAPI-based clients, such as Outlook 2000, Outlook 97, and Outlook 98 must be tested to ensure that you are providing the same level of support after Exchange 2000 is deployed. Testing issues include:

  • Basic messaging verification Verify that users can send and receive e-mail while online and offline, read mail using preview pane, open mail, reply to a sender and to all recipients in the To and Cc boxes, forward mail, read various types of message content (attachments, embedded messages, HTML, Rich Text Format [RTF], plain text), and read high and low priority mail. 

  • Name resolution Verify that users can resolve other user names and distribution lists in the To, Cc, and Bcc boxes. 

  • Copy and move Verify that users can copy and move e-mail messages to and from personal folders (.pst), public folders, and that they can drag and drop messages in mailbox and public folders. 

  • Folder operations Verify that users can delete, rename, copy and move messages, set permissions, apply custom views, get properties, create subfolders, copy folder design, and work with folders offline. 

  • Import and export Verify that users can import and export .pst files. 

  • Address book Verify that users can view user properties, add users to their Personal Address Book, download Offline Address Book, and check user properties. 

  • Rules Verify that users can create, enable, or disable a rule. 

  • Out of office Verify that users can enable out-of-office notification. 

  • Reports Verify that users can send e-mail with read and delivery receipts, can open and read receipts, and receive non-delivery report (NDR) messages when they send e-mail to users who are not valid. 

  • Calendar operations Verify that users can send and forward both single and recurring appointments and meeting requests, view attendee availability and status, respond to meeting requests with Accept, Tentative, and Decline, view free and busy data, edit series of a recurring meeting request, send meeting updates, and delete a meeting request to remove it from their calendars. 

  • Access permissions Verify that users can send e-mail on behalf of another user (including meeting requests), and that a delegate user can accept a meeting request for another user. 

  • Search Verify that users can search for items in folders, text in messages, messages from or to specific users, messages containing attachments, and so on. 

  • Sort Verify messages sort properly in ascending or descending order and by sender or subject. 

Public folders must be part of the client test plan. In addition to the upgrade issues mentioned earlier, even in a native-mode Exchange 2000 organization, be aware of setting permissions on public folders. When an administrator or a client changes the permissions on a public folder, they can create a distribution list and set permissions to allow members of that list to access the public folder. As soon as an access control list (ACL) is used to set permissions on a public folder, all associated distribution groups convert to universal security groups. Not all distribution lists, also called universal distribution groups, convert to universal security groups. This only happens when an ACL is used to set permissions on a public folder. When testing, ensure that all universal security groups are hosted in a native-mode Windows 2000 domain.

Testing considerations for public folders include:

  • Upgrades Upgrade an Exchange 5.5 server that has a public folder store. 

  • Access permissions Use a public folder with permissions to allow a distribution list to access the public folder. Replicate this public folder to a native-mode Windows 2000 domain. Verify that the universal distribution group converts to a universal security group after it is accessed for the first time. Test public folder replication among Exchange 5.5 and Exchange 2000 servers. Verify content and permissions. 

  • Users Add users from mixed-mode and native-mode domains to the universal security group and verify that Outlook users have appropriate access to the public folders. 

  • Outlook Test various edits to public folder permissions with Outlook. 

Third-Party Connectors Test Plan

Incorporate third-party connector and software tests to determine the upgrade strategy to Exchange 2000.

Contact the connector or software vendor to determine connector or software compatibility with Exchange 2000. With this information, you can determine the migration path, if any.

You may not be able to upgrade connectors such as fax, paging, and virus scanners that use the Exchange directory. You may be able to upgrade monitoring and backup software that does not interact with the Exchange directory.

Test upgrades in the test lab individually. If a problem occurs, you can trace it to a specific connector or software.

Test Strategy

Prior to testing, you should establish a strategy that defines specific testing goals and their results and benefits. Create a document that lists features and functions required for the new messaging environment. This list is the basis for new features of Exchange 2000 to test. Determining a strategy with the company's existing messaging environment in mind is important. Also, defining the order of migration and implementation should be one of the goals you work towards.

In addition to testing the new features of Exchange 2000 for general operability, your test lab can have a small-scale model of the existing messaging environment for interoperability and migration testing with Exchange 2000. It may seem obvious that it is important to understand how to install and use a particular feature. However, each tester should keep in mind the level of complexity expected of a given feature in the production environment. While it may be impossible to duplicate the complexity a particular feature may introduce when fully implemented, having the test team fully understand the feature minimizes the risk of difficulties during the actual deployment.

Testing Your Scenarios

Test plans arise from the identification of all of the features to be tested and migration and implementation scenarios planned during the production implementation. A plan that includes taking the first Exchange 2000 server, and its base functionality, into the existing test environment is a good place to start. This may involve a complete build of a new Windows 2000–based server with Active Directory, or an in-place upgrade scenario. Either way, the test plan should involve deployment scenarios expected during implementation.

The list of required features that was a guideline for the test strategy section becomes more important when developing a test phase. End-user and administrator functionality can be grouped into test plans that model how features go into place during implementation.

Exchange 2000 represents a significant change in the functionality and management of the Exchange 5.5 environment. The directory has been moved from Exchange to Active Directory. A user's authentication and Exchange configuration are managed in a single place: the Active Directory Users and Computer snap-in. Exchange 5.5 sites no longer exist, and the Exchange System Manager snap-in replaces the Exchange Administrator program.

Feature Tests

Examine the new features included in Exchange 2000. Each can be tested independently to familiarize the Exchange and Windows 2000 architecture teams and administrators with this new functionality.

Some new features and corresponding test scenarios appear in the following sections. Features such as clustering services and real-time collaboration are not included.

Multiple Databases

Description Allows database size management, larger mailbox size, and faster backups and restores.

Test objective To understand functionality of multiple databases on a single Exchange 2000 server.

Test method Create two mailbox stores, create a user on one store, and dismount the other store. Move user between stores.

Storage Groups

Description Storage groups allow you to assemble databases into easily managed groups. All databases within a storage group share the same transaction log files and log settings. Storage groups and multiple databases enable users to service virtual organizations on one server.

Test objective To understand storage group functionality.

Test method Create a new storage group, create a new mailbox store in the new storage group, and move users between storage groups.

Backup and Recovery

Description Backing up the Exchange 2000 server is a simple process. Each storage group has a set of transaction log files for all the databases in the storage group. You can:

  • Back up select databases in a storage group. 

  • Back up multiple storage groups simultaneously. 

  • Restore select databases in a backup set. 

  • Restore databases simultaneously. 

A restored single database allows all transaction log files for the storage group to replay, but only the databases being restored will be processed.

Test objective To recover a single database or storage group.

Test method Dismount the database to be restored, restore all incremental and differential backup sets, and then restore the full backup set.

  • The administrator selects which databases in a storage group to simultaneously backup. 

  • The administrator backs up more than one storage group at a time. 

  • Only the damaged database must be offline to complete a restore. The other database in the backup set or storage group remain online. 

  • Multiple restore operations can occur simultaneously. 

Public Folders

Description Exchange 2000 allows you to create multiple public folder trees.

Test objective To create a new public folder hierarchy.

Test method Create a new public folder hierarchy in System Manager, and then access the public folder hierarchy using Outlook Web Access.

Full-Text Indexing

Description Full-text indexing allows users to search Exchange databases for words or phrases more quickly. Each word in a database is indexed and attachments can also be searched.

Test objective Test functionality of full-text indexing.

Test method Enable and start full-text indexing on both a mailbox and a public folder store, establish an indexing and rebuilding schedule, and search mailbox and public folder stores using an Outlook client.

Address Lists

Description Address lists replaces Address Book Views in Exchange 5.5. The lists are created using a Lightweight Directory Access Protocol (LDAP) query of Active Directory mail-enabled objects.

Test objective Create a new address book list.

Test method In System Manager, create a new address list, and browse the list with an Outlook client.

Routing Groups

Description From a physical, network-layer perspective, routing groups replace Exchange 5.5 sites. Move servers between two routing groups, if both routing groups appear within the same administrative group.

Test objective To understand routing group functionality.

Test method 1 Install Exchange 2000 server in an Exchange 5.5 site, run Active Directory Connector, create a mailbox on the Exchange 2000 server, and then send a message between Exchange 2000 server and Exchange 5.5 server. Install another Exchange 2000 server, create a mailbox on the new Exchange 2000 server, and then send a message to all users on all systems. Verify that the message was received.

Test method 2 Create two routing groups in an administrative group, install an Exchange 2000 server into one routing group, and move the server (drag and drop) into the second routing group.

Message Transport Between Routing Groups

Description There are three ways to send messages between routing groups:

  • Routing Group connector 

  • SMTP connector 

  • X.400 connector 

Test objective To test the functionality of the Routing Group connector.

Test method Create routing group one with servers A and B, create routing group two with servers C and D, create a new mailbox-enabled user and store the mailbox on server B, create another new mailbox-enabled user and store the mailbox on server D, create connections between the routing groups using Routing Group connectors, and send a message between routing groups. Verify receipt of the message. Unplug the network cable from the source bridgehead server A. Resend the message. Verify receipt of the message.

Administrative Groups

Description Different administrative groups are configured to manage Exchange 2000 servers. In mixed mode, only one administrative group is allowed per site. However, there is always at least one routing group per administrative group. The administrative group to routing group ratio is 1:n.

Test objective Test the functionality of administrative groups.

Test method Add a new user by using Active Directory Users and Computers. Assign the new user the Exchange Administrator role using the Exchange Administrative Delegation wizard, log on as the new user, and dismount a store.

Policies

Description Policies allow you to establish limits and rules applicable to databases. Various databases can have different storage limits and retention policies.

Test objective To establish a deleted items retention and mailbox size limitation.

Test method In System Manager, create a new mailbox policy, configure the policy to retain deleted mail for 60 days. Maximize the mailbox limit to 100 MB. Apply the policy to the appropriate mailbox store.

Distribution List Management and Usage

Description Distribution lists are stored in Active Directory. There are two types of groups that can be mail–enabled: security and distribution.

If membership needs to be viewed in all domains in a Windows 2000 mixed-mode environment, create a universal distribution group.

If the group needs to be used for permissions on public folders and includes users from more than one domain, then it must be a universal security group.

Universal security groups must be hosted in a native-mode Windows 2000 domain.

Test objective To create a mail-enabled distribution group with a membership that is visible to all domain users.

Test method Create a new group in the Active Directory Users and Computers snap-in, set group scope to Global, set group type to Distribution, and then add a user to the new group. To verify, open the address book in an Outlook client; the group should appear.

Web Folders

Description All folders and items within the store are URL-accessible.

Test objective To test URL accessibility to mailboxes and public folders.

Test method 1 (mailbox) In a Web browser, type http:\\server\exchange\alias, where server is the Exchange server name, and alias is a user name. When prompted, enter the user name, domain, and password.

Test method 2 (public folder) In a Web browser, type http:\\server\public, where server is the Exchange server name. When prompted, enter the user name, domain, and password.

Upgrade Testing

It is possible to perform the migration from Exchange 5.5 to Exchange 2000 in several different ways. The method you choose determines the software upgrade method. The following are typical upgrade paths:

  • In-place upgrade from Windows NT Server 4.0 to Windows 2000 Server and Exchange 5.5 to Exchange 2000. 

  • Move users from an Exchange 5.5 server to an Exchange 2000 server. 

Active Directory Connector (ADC) must be installed regardless of the plan to migrate to Active Directory. There are five migration paths for user data to Active Directory:

  • In-place domain upgrade followed by the installation of ADC. 

  • Populate the new Active Directory using ADC. 

  • Use ADC to populate the new Active Directory structure and then clone users by using Active Directory Migration Tool. 

  • Use Active Directory Migration Tool with SidHistory, and then run ADC. 

  • Use Active Directory Migration Tool without SidHistory, re-create the ACLs, and then run ADC. 

Evaluate and test each upgrade scenario to determine the best migration path for your organization. For more information on upgrade scenarios, see the Exchange 2000 documentation and other chapters of this book.