Developing

Figure 3 illustrates the primary activities that occur during the Developing Phase. Most of these activities involve preparation of the servers used to install applications and migration of existing user data. These tasks may be repetitive depending on the deployment strategy. Some deployments may require that the following sequence of server installation, stabilization, and deployment be repeated several times, either serially or in parallel, to complete an organization-wide deployment.

Figure 3. Activities during the Developing Phase

Figure 3. Activities during the Developing Phase

On This Page

Roles and Responsibilities Roles and Responsibilities
Creating the Test Environment Creating the Test Environment
Determining When Virtualization Is Appropriate Determining When Virtualization Is Appropriate
Testing the Mitigation Strategies Testing the Mitigation Strategies
Creating the Application Mitigation Packages Creating the Application Mitigation Packages
Milestone: Application Mitigations Created Milestone: Application Mitigations Created

Roles and Responsibilities

All six role clusters from the MSF Team Model play a role in the Developing Phase of the initiative. Table 5 lists those roles and defines the focus areas for each role cluster relative to the deployment process in the Planning Phase. For more information about MSF Role Clusters, see Microsoft Solutions Framework at https://www.microsoft.com/technet/itsolutions/msf/default.mspx.

Table 5. Team Roles and Responsibilities in the Developing Phase

Role

Focus

Product Management

  • Business requirements analysis

  • Communications plan

Program Management

  • Budget

  • Master project plan and master project schedule

Development

  • Development plan and schedule

  • Establishing the lab

  • Logical and physical design

  • Technology evaluations

Test

  • Test plan and schedule

  • Testing requirements definition

User Experience

  • Localization/accessibility requirements

  • Schedules

  • Training plans

  • Usage scenarios/use cases

  • User documentation

  • User requirements

Release Management

  • Application and hardware inventory

  • Interacting with the Operations Readiness and Security feature teams

  • Network discovery

  • Operations requirements

  • Pilot and deployment plan/schedule

Creating the Test Environment

After creating the application portfolio and identifying mitigation strategies for each incompatible application, create the test environment in which the mitigation strategies can be validated. In most cases, this test environment can be shared with the Application Management feature team.

The test environment is a long-term investment in the overall deployment process. Retain the test environment after the deployment to assist in future deployment projects.

To create the test environment:

  • Determine how to model the production environment in the test environment.

  • Configure the test environment to support automated testing of the mitigation strategies.

Determining How to Model the Production Environment

The goal of the test environment is to model the production environment within reason. The more accurately the Application Compatibility feature team can model the production environment, the greater the validity of the testing performed in that test environment.

Follow these recommendations when creating a test environment:

  • Use virtual or physical images of production computers to create their test environment counterparts. Virtual or physical images help ensure that the test environment configuration accurately reflects the production environment. In addition, the images contain live information (such as users, user profiles, and file permissions) to use in testing.

  • Physically separate the test environment from the production environment. A physically separate test environment lets the Application Compatibility feature team use an identical IP configuration and helps ensure that tests conducted in the test environment do not affect the production environment. Using the identical IP address, subnets and other network configuration information helps ensure the fidelity of the test environment. However, duplicating IP addresses may not always be the best option when applications do not rely on a hard-coded IP address. It may also be preferable to pass some network traffic through the router from the production environment to reduce the need for replicating network services—for example, opening the ports for DHCP to pass through eliminates the need for a separate DHCP server in the test lab.

  • Ensure that the test environment is at the same service pack and update level as the production environment. If the Application Compatibility feature team created the test environment some time ago, the current version of service packs and updates may be outdated. Before performing application mitigation testing, update the lab environment by applying service packs and updates or by refreshing the virtual or physical images of the production counterparts. Consider adding the test environment to the change-management process to simplify tracking the updates.

  • Ensure that tests are performed with accounts that have similar permissions as the production environment. If the users in the organization are not administrative-level users on their local computers, ensure that similar permissions are in place for the users in the test environment. This process ensures that Application Compatibility feature team members accurately test all compatibility issues, some of which may be security related.

Next, determine which production computers to model in the test environment. Model production computers should be:

  • Part of the network infrastructure, including DHCP, DNS, WINS, and other network infrastructure services, unless the Application Compatibility feature team plans to allow these services to pass into the test environment from the production network.

  • Part of the remote access infrastructure, including Routing and Remote Access and Internet Authentication Service.

  • Part of the Active Directory infrastructure, including domain controllers and DNS services.

  • Part of the messaging infrastructure, including Microsoft Exchange Server front-end servers, back-end servers, and bridgehead servers.

  • Part of the organization’s extranet, including Web servers and firewalls.

  • Included in the application inventory earlier in the process.

Configuring the Test Environment for Automated Testing

In most instances, the Application Compatibility feature team must test the mitigation strategies more than once. Automate this testing as much as possible to ensure repeatability and consistency in the testing process.

In addition, the Application Compatibility feature team should ensure that it can restore the test environment to a configuration before running the test so that team members can repeat the same test on the same configuration. Automating the restoration of the test environment to a previous state helps ensure that team members perform their tests by using the identical data and configuration.

Application Compatibility feature team members can automate:

  • Running their test cases by using test automation tools that they purchase or develop. For more information about developing a test automation tool, see “Lightweight UI Test Automation with .NET” at https://msdn.microsoft.com/msdnmag/issues/05/01/TestRun.

  • Restoration of the test environment to a previous state by using:

    • Disk-imaging software for physical images of the servers.

    • The software virtualization features that allow reversing changes to virtualized hard disks (such as the Undo Disks settings in Virtual PC 2004 and Virtual Server 2005).

Determining When Virtualization Is Appropriate

By using Virtual PC 2004 and Virtual Server 2005, the Application Compatibility feature team can create and run virtualized servers on computers running Windows Vista and Window Server 2003, respectively. One of the primary purposes of these products is to help facilitate test environments.

The advantages to virtualization include:

  • The ability to support a large number of servers in a limited amount of physical rack space is enhanced. Many environments have a limited amount of rack space in which to place physical computers. The Application Compatibility feature team can run as many virtual servers as the physical computer’s resources (such as memory, multiple processors, and free disk space) allow.

  • Sharing a test environment between teams is easier. After creating a test environment, the Application Compatibility feature team can share that environment with other teams. For example, the Test feature team can create a virtualized test environment and provide the Development Role Cluster with a copy of its test environment to use in its development process.

  • Multiple developers or testers are able to perform simultaneous testing. In traditional test environments, multiple users may be competing for access to the test environment. Virtualization of the servers allows each user to potentially have a dedicated test environment. With this process, the testing and development processes are more streamlined.

  • The virtualized server configuration can easily be restored to a previous state. Most virtualization software includes a method to reverse changes to the virtualized hard disks (such as the Undo Disks feature in Virtual PC 2004 and Virtual Server 2005). This feature allows the Application Compatibility feature team to roll back the server configuration to a previous state. In situations where team members must perform the same sequence of steps repeatedly, this feature can help restore the environment quickly.

The disadvantages of virtualization include:

  • Performance of virtualized servers is slower than their physical counterparts. Virtualized servers are significantly slower, because many of the physical resources (such as disks) are virtualized. In particular, any disk-related activity is significantly slower in virtualized environments.

  • Hardware-specific device drivers and applications are not supported in virtualized servers. In some instances, Application Compatibility feature team members must test the compatibility of hardware-specific device drivers and applications. Virtualized servers use virtualized device drivers that emulate their physical counterparts. Access to any hardware resources is through these virtualized device drivers.

Testing the Mitigation Strategies

After identifying the configuration of the test environment, determine the mitigation strategies to test. The Application Compatibility feature team must test each strategy identified in the application portfolio earlier in the process.

Test the mitigation strategies by:

  • Creating the text matrix (which includes the list of applications to be tested and the criteria for determining successful compatibility).

  • Deploying the test environment to test the mitigation strategies.

Creating the Test Matrix

The test matrix defines the tests that the Application Compatibility feature team will complete and how the team determines the success or failure of each test. The test matrix is a blueprint for completing testing and is the primary document used to communicate the test procedures between the Development and Test Role Clusters.

Create the test matrix by:

  • Categorizing the applications the Application Compatibility feature team will test so that team members can determine their priority in the testing process.

  • Determining the criteria for success in mitigating application incompatibilities.

For more information on creating the test matrix and testing strategies, see the Test Feature Team Guide.

Categorizing the Applications for Testing

The Application Compatibility feature team must categorize the applications it will test so that team members can test them based on mitigation priority and complexity.

Categorize the applications within the test matrix based on:

  • Application priority.

  • Application mitigation status, including:

    • Applications with known compatibility issues and mitigations.

    • Applications with known compatibility issues and no known mitigations.

    • Applications with unknown compatibility issues.

Create the test matrix by using a tool such as Microsoft Office Excel 2003 that can sort and organize applications by these categories and subcategories.

Determining the Criteria for Compatibility

In the test matrix, specify the criteria for successfully mitigating any compatibility issues. For each application the Application Compatibility feature team tests, specify:

  • The steps that team members will complete during the tests.

  • The correct responses to performing each step.

When an application achieves these criteria, it is deemed compatible.

Deploying the Simulated Test Environment

Earlier in the process, the Application Compatibility feature team defined the infrastructure and computers required to conduct its tests. In addition, the team determined which portions of the test environment could be based on virtualized computers and which portions must be tested on physical computers.

Regardless of the method used, deploy the test environment using images (virtual or physical) obtained from the production environment. The Application Compatibility feature team can create images to restore to physical servers by using any disk-imaging software.

For virtualized computers in the test environments, the Application Compatibility feature team can use tools to create virtual representations of physical servers in the production environment, such as the Virtual Server Migration Toolkit. (For more information on the Virtual Server Migration Toolkit, see “Virtual Server 2005 Migration Toolkit” at https://www.microsoft.com/windowsserversystem/virtualserver/evaluation/vsmt.mspx.)

Creating the Application Mitigation Packages

The final deliverables from the test process are the application mitigation packages that will be deployed in the organization. Create these packages automatically by using the application tools (such as the mitigations that the ACT creates). For other application mitigation methods, create the packages and the installation scripts or executables (including .msi files).

Create the application mitigation packages by:

  • Creating packages automatically.

  • Creating packages manually.

Creating Packages Automatically

In many instances, the application compatibility tools used can automatically create application mitigation packages. These packages can then be deployed to the appropriate target computers.

Use the Compatibility Administrator from ACT 5 to package the solutions for deployment in the test and production environments. Compatibility Administrator .sdb files and creates a self-extracting executable package. The Application Compatibility feature team can then deploy the executable package to fix the applications.

Creating Packages Manually

When tools other than automated tools discover and create mitigations, manually create the packages to be installed. In some instances, this process may include creating scripts or .msi files to facilitate installation.

Ensure that the packages can be:

  • Incorporated in the deployment images.

  • Deployed separately to existing target computers.

The method selected for installing the packages on the target computer must support both deployment scenarios. For example, a mitigation tool (such as the IECE) may create .reg files that modify the Internet Explorer configuration settings. To create a package for the .reg file, Application Compatibility feature team members must:

  1. Write a script or develop an .msi file to perform the following tasks:

    • Put the .reg file in the appropriate location.

    • Run regedit with the .reg file to modify the configuration settings on the target computer.

  2. Include the .msi file in the application package in the deployment image or deploy the .msi file by using the chosen software distribution method.

Milestone: Application Mitigations Created

Milestones are synchronization points for the overall solution. For more information, see the Plan, Build, and Deploy Guide.

At this milestone, which Table 6 shows, the Application Compatibility feature team has developed the mitigation packages necessary.

Table 6. Developing Phase Deliverables

Developing Phase milestone

Deliverable description

Owner

Test Environment Created

Test environment is created to model the production environment. The test environment is used later in the Developing Phase to test mitigation strategies and create mitigation packages.

Development

Mitigation Strategies to Be Tested Determined

Mitigation strategies that must be tested in the test environment are identified. In addition, the test plan to be conducted in the lab for each mitigation strategy is created.

Test

Application Mitigation Packages Created

Application compatibility fixes are combined into a package that can be integrated into the operating system images or deployed separately.

Development

Team Consensus and Sign-off Obtained

All stakeholders in the BDD 2007 project provide consensus for mitigating all application compatibility issues and future project milestones.

Product Management

Download

Get the Microsoft Solution Accelerator for Business Desktop Deployment 2007

Update Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions