Logo
PREGNANCY
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
 
 
Windows Server

Migrating to Windows Server 2008 R2 : Preparing for Compatibility Testing

3/3/2011 10:33:43 PM
Although the amount of preparation needed will vary based on a number of factors, certain steps should be followed in any organization—the scope of the testing should be identified (what’s in and what’s out), the goals of the testing process should be clarified, and the process should be mapped out.

A significant advantage of following a phased design methodology, is in the planning discussions that take place and in the resulting statements of work, design, and migration documents that are created as deliverables. Often, companies contract with migration experts or Microsoft partners—such as Convergent Computing, also known as CCO—to help companies avoid classic mistakes in the upgrade process. By the end of this planning process, it will be very clear why the project is happening, which departments need which features and capabilities, and what budget is available to perform the work. The timeline and key milestones also will be defined.

If a phased discovery and design process hasn’t been followed, this information needs to be gathered to ensure that the testing process addresses the goals of the project stakeholders, and that the right applications are in fact tested and verified by the appropriate people.

Determining the Scope for Application Testing

At this point in the process, a list should be put together that clarifies which Windows Server 2008 R2 version is to be used, which version of server software will be used, which add-in features are required, and which third-party applications are needed. As discussed previously, Windows Server 2008 R2 comes in Web, Standard, Enterprise, and Datacenter Editions. New in Windows Server 2008 R2, the server comes in 64-bit version only, eliminating the 32-bit version of the server operating system. Smaller companies might choose to use the Standard Edition of Windows Server 2008 R2 operating system, whereas larger organizations might require Enterprise Edition on their server systems for more advanced scalability and fault tolerance.

A key issue to discuss at this point is whether it is acceptable to have multiple versions of the Windows Server operating system in the final solution. Some organizations want to control standards on both software and support services, and require just a single network operating system such as Windows Server 2008 R2 across the board.

Note

Although the Standard Edition of Windows Server 2008 R2 is significantly less expensive than the Enterprise Edition of the license, cost should not be the primary reason for choosing one version over another. It is a daunting task to upgrade from the Standard to Enterprise Edition, not as simple as just changing a software license key. It requires either setting up a brand-new server with the Windows Server 2008 R2, Enterprise Edition and migrating applications from server to server, or a full upgrade of the Enterprise Edition over an existing Standard Edition license. An organization should seriously consider whether it needs the functionality of the Enterprise Edition before choosing to buy and install the Standard Edition and attempting to upgrade later.


Third-party applications should be identified as well. The applications most often used include tape-backup software modules or agents, antivirus software, fax software, and voicemail integration products. Additional third-party add-on products might include the following:

  • Administration

  • Antispam

  • Backup and storage

  • Customer relationship management (CRM)

  • Log monitoring

  • Line-of-business applications

  • Migration

  • Reporting

  • Security and encryption

The hardware to be used should be listed as well, to ensure that it is available when needed. Ideally, the exact hardware to be used in the upgrade will be ordered for the application testing process, but if that is not possible, hardware with specifications similar to that of the servers that will eventually be used should be allocated. Although processor speed and amount of RAM will most likely not make a difference to whether the application functions properly on the server platform, certain hardware devices should be as similar as possible. Tape drives, for example, should have the same features as the ones to be used in the production environment because this is one of the most critical components. If an autoloader will be used in the production environment, one should be made available for the application testing process. If faxing from the Outlook Inbox is required, the same faxing hardware should be allocated as well. Another example is implementing clustering with a storage area network (SAN) back end. If a SAN will be utilized in production and the test criteria of the lab is to validate clustering functionality, the same production SAN should be utilized in the test environment. By using the same SAN solution, clustering test criteria and clustering functionality can be validated and guaranteed.

Some applications require clients to be present for the testing process, so at least one workstation class system should be available for this purpose. Connectivity to the Internet might also be necessary for testing the functionality of remote access products and antivirus software.

Table 1 shows a sample checklist of requirements for summarizing the scope of the application testing phase.

Table 1. Checklist for Application Testing
Server #1 Details (Include Version Numbers)
Server specs required:

Processor

RAM

Hard drive configuration

Other

Network OS and service packs:

Tape backup software version and agents:

Additional third-party apps required:

Virtualization? Yes/No

Additional hardware required:

SAN device

Tape drive

UPS

Switch/hub

Other

Internet access required? Yes/No

This process should not take a great deal of time if previous planning has taken place. If the planning phase was skipped, some brainstorming will be required to ensure that the scope includes all the key ingredients required for the application testing. The goals for the application testing process will also affect the scope, which is covered in the following section.

Defining the Goals for Compatibility Testing

As with the previous step of defining the scope of the testing process, defining the goals might be a very quick process, or could require some discussions with the stakeholders involved in the project.

One useful way of looking at the goals for the project is to treat them as the checklist for successful completion of the testing. What conditions need to be met for the organization to confidently move forward with the next step in the Windows migration? The next step might be a more complete prototype testing phase. For smaller organizations, it might be a pilot rollout, where the new networking environment is offered to a select group of savvy users.

These goals are separate from the business goals the company might have, such as a more reliable network infrastructure or improved security. A more complete prototype phase could seek to address these goals, while the application testing process stays focused on the performance of the specific combinations of the operating system and embedded and connected applications.

A convenient way to differentiate the goals of the project is to split them into key areas, as described in the following sections.

Time Frame for the Testing

This goal can be defined with the statement: “The testing must be completed in X days/weeks.”

If there is very little time available to perform the testing, this limits how much time can be spent on each application and how many end users can put each through its paces. It also necessitates a lesser degree of documentation. Remember to include time for researching the applications’ compatibility with the vendors as part of the timeline. A quick project plan might be useful in this process as a way of verifying the assumptions and selling the timeline to the decision makers.

Contingency time should ideally be built in to this goal. Resources assigned to the testing can get sick or might be pulled back into the office for production support, or applications might require additional testing when problems are encountered. Vendors might not provide trial versions of the software as quickly as desired, or new versions of software or even the hardware itself can be delayed. With many companies seeking to consolidate the number of servers in use, it is not uncommon to see labs evolve through the testing process. Different versions of the Windows operating system are used, as are different versions of various application software programs.

Budget for the Testing

This goal can be defined with the statement: “The testing must be completed within a budget of $X.”

Of course, there might be no budget allocated for testing, but it’s better to know this as soon as possible. A lack of budget means that no new hardware can be ordered, evaluation copies of the software (both Microsoft and the third-party applications) need to be used, and no external resources will be brought in. If the budget is available or can be accessed in advance of the production upgrade, a subset of the production hardware should be ordered for this phase. Testing on the exact hardware that will be used in the actual upgrade rather than a cast-off server will yield more valuable results.

More and more virtualization technology is being utilized in test labs for reducing costs associated with hardware procurement. Virtualization is an excellent way to reduce capital expenditures. Keep in mind that hardware-specific prototype testing cannot be achieved when using virtualization as the guest operating system. In addition, performance metrics might get skewed when running more than one guest operating system on a virtual server.

Resources to Be Used

This goal can be defined with the statement: “The testing will be completed by in-house resources and/or external consultants.”

Often, the internal network administration staff is too busy with daily tasks or tackling emergencies that spring up (which might be the reason for the upgrade in the first place), and staff personnel should not be expected to dedicate 100% of their time to the testing process.

If an outside consulting firm with expertise in Windows Server 2008 R2 is going to be used in the testing process, it can be a good leverage point to have already created and decided upon an internal budget for the testing process. This cuts down on the time it takes to debate the approaches from competing firms.

Extent of the Testing

The extent of compatibility testing can be defined with the statement: “Each application will be tested for basic, midlevel, or complete compatibility and feature sets.”

This goal might be set for different types of applications where some mission-critical applications would need to have extensive testing, whereas less-critical applications might have more basic testing performed. A short time frame with a tightly limited budget won’t allow for extensive testing, so basic compatibility will most likely be the goal.

Training Requirements During Testing

This goal can be defined with the statement: “Company IT resources will/will not receive training during the application testing process.”

Although the IT resources performing the testing will learn a great deal by going through the testing process, the organization might want to provide additional training to these individuals, especially if new functionality and applications are being tested. If external consultants are brought in, it is important that the organization’s own resources are still involved in the testing process for training and validation purposes. The application testing phase might be an excellent time to have help desk personnel or departmental managers in the user community learn more about new features that will soon be offered so they can help support the user community and generate excitement for the project.

Documentation Required

This goal can be defined with the statement: “Documentation will/will not be generated to summarize the process and results.”

Again, the budget and timeline for the testing will affect the answer to this question. Many organizations require a paper trail for all testing procedures, especially when the Windows infrastructure will have an impact on the viability of the business itself. For other organizations, the networking environment is not as critical, so less or no documentation might be required.

The application testing phase is a great opportunity to document the steps required for application installations or upgrades if time permits, and this level of instruction can greatly facilitate the production rollout of the upgraded networking components.

Extent of User Community Involvement

This goal can be defined with the statement: “End users will be included/will not be included in the testing process.”

If there are applications such as customer relationship management (CRM), document routing, voicemail or paging add-ons, or connectivity to PDAs and mobile devices, a higher level of user testing (at least from the power users and executives) should be considered.

Fate of the Testing Lab

This goal can be defined with the statement: “The application testing lab will/will not remain in place after the testing is complete.”

There are a number of reasons that organizations decide to keep labs in place after their primary purpose has been served. Whenever a patch or upgrade to Windows Server 2008 R2 or to a third-party application integrates with Windows Server 2008 R2, it is advisable to test it in a nonproduction environment. Even seemingly innocent patches to antivirus products can crash a production server. Other items might require user testing to see whether they should be rolled out to the production servers.

Documenting the Compatibility Testing Plan

The information discussed and gathered through the previous exercises needs to be gathered and distributed to the stakeholders to ensure that the members of the team are working toward the same goals. These components are the scope and the goals of the application testing process, and should include the timeline, budget, extent of the testing (basic, midlevel, complete), training requirements, documentation requirements, and fate of the testing lab. This step is even more important if a formal discovery and design phase was not completed.

By taking the time to document these constraints, the testing process will be more structured and less likely to miss a key step or get bogged down on one application. The individuals performing the testing will essentially have a checklist of the exact testing process, and are less likely to spend an inordinate amount of time on one application, or “get creative” and try products that are not within the scope of work. After the testing is complete, the stakeholders will also have made it clear what is expected in terms of documentation so the results of the testing can be presented and reviewed efficiently.

This summary document should be presented to the stakeholders of the project for review and approval. The organization will then be ready to proceed with the research and testing process for Windows Server 2008 R2 compatibility.

Other -----------------
- Migrating from Windows Server 2003/2008 to Windows Server 2008 R2 : Multiple Domain Consolidation Migration (part 5) - Migrating Other Domain Functionality
- Migrating from Windows Server 2003/2008 to Windows Server 2008 R2 : Multiple Domain Consolidation Migration (part 4) - Migrating Computer Accounts
- Migrating from Windows Server 2003/2008 to Windows Server 2008 R2 : Multiple Domain Consolidation Migration (part 3) - Migrating Groups & Migrating User Accounts
- Migrating from Windows Server 2003/2008 to Windows Server 2008 R2 : Multiple Domain Consolidation Migration (part 2)
- Migrating from Windows Server 2003/2008 to Windows Server 2008 R2 : Multiple Domain Consolidation Migration (part 1)
- Migrating from Windows Server 2003/2008 to Windows Server 2008 R2 : Phased Migration (part 4) - Upgrading Domain and Forest Functional Levels & Moving AD-Integrated DNS Zones to Application Partitions
- Migrating from Windows Server 2003/2008 to Windows Server 2008 R2 : Phased Migration (part 3) - Moving Operation Master Roles & Retiring “Phantom” Domain Controllers
- Migrating from Windows Server 2003/2008 to Windows Server 2008 R2 : Phased Migration (part 2)
- Migrating from Windows Server 2003/2008 to Windows Server 2008 R2 : Phased Migration (part 1) - Migrating Domain Controllers
- Migrating from Windows Server 2003/2008 to Windows Server 2008 R2 : Big Bang Migration
- Migrating from Windows Server 2003/2008 to Windows Server 2008 R2 : Beginning the Migration Process
 
 
Most view of day
- What's new and improved in SharePoint 2013 : Customizing the interface
- Microsoft Excel 2010 : Inserting Blank Rows (part 1) - Separating Subtotaled Rows for Print
- Windows Server 2003 on HP ProLiant Servers : Security Planning and Design (part 1)
- Windows Server 2003 on HP ProLiant Servers : The Physical Design and Developing the Pilot - Network Services
- Windows Server 2012 Group Policies and Policy Management : GPO Administrative Tasks - Backing Up and Restoring Domain GPOs
- Windows Server 2008 R2 file and print services : Administering Print and Document Services (part 1)
- Migrating to Exchange Server 2007 : Migrating from Exchange 2000 Server or Exchange Server 2003 to Exchange Server 2007 (part 6)
- Windows Phone 8 : Orientation and the PhoneApplicationPage Class (part 3) - Setting Page Orientation at Runtime
- Microsoft Dynamics CRM 4.0 : Silverlight - Developing a Basic Silverlight Application
- Microsoft Excel 2010 : Protecting and Securing a Workbook - Locking or Unlocking Worksheet Cells
Top 10
- Configuring and Troubleshooting IPv6 in Windows Vista (part 4) - Troubleshooting IPv6 Connectivity
- Configuring and Troubleshooting IPv6 in Windows Vista (part 3) - Configuring IPv6 in Windows Vista Using Netsh , Other IPv6 Configuration Tasks
- Configuring and Troubleshooting IPv6 in Windows Vista (part 2) - Configuring IPv6 in Windows Vista Using the User Interface
- Configuring and Troubleshooting IPv6 in Windows Vista (part 1) - Displaying IPv6 Address Settings
- Deploying IPv6 : IPv6 Enhancements in Windows Vista
- Games and Windows 7 : Games for Windows - LIVE (part 2) - Accessing Games for Windows - LIVE from within Compatible Games
- Games and Windows 7 : Games for Windows - LIVE (part 1) - Using the Games for Windows - LIVE Marketplace
- Sharepoint 2013 : Client-side Programming - Working with the REST API (part 3)
- Sharepoint 2013 : Client-side Programming - Working with the REST API (part 2) - Working with the REST API in JavaScript
- Sharepoint 2013 : Client-side Programming - Working with the REST API (part 1) - Understanding REST fundamentals
 
 
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro