Planning

  • Article

Figure 2 illustrates the primary activities that occur during the Planning Phase. While other teams are developing images, project plans, and other items, the Application Compatibility feature team and the Test feature team focus on compatibility of existing applications with the new deployment. These teams must look at all the locations and departments with client computers (including terminal servers used in application mode) that will be analyzed for application compatibility and decide which applications to test in the test environment.

Figure 2. Activities during the Planning Phase

Figure 2. Activities during the Planning Phase

On This Page

Roles and Responsibilities Roles and Responsibilities
Identifying the Clients to Inventory Identifying the Clients to Inventory
Planning for the Application Inventory Planning for the Application Inventory
Collecting the Application Inventory Collecting the Application Inventory
Analyzing the Application Inventory Results Analyzing the Application Inventory Results
Creating the Application Portfolio Creating the Application Portfolio
Milestone: Application Portfolio Created Milestone: Application Portfolio Created

Roles and Responsibilities

All six role clusters from the MSF Team Model play a role in the Planning Phase of the initiative. Table 1 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 team role clusters, see Microsoft Solutions Framework at https://www.microsoft.com/technet/itsolutions/msf/default.mspx.

Table 1. Team Roles and Responsibilities in the Planning Phase

Role

Focus

Product Management

  • Business requirements analysis

  • Communications plan

  • Application retirement policy when vendors end support

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

Identifying the Clients to Inventory

Creating a complete inventory of every application and computer in the organization can be time-consuming, but the benefits outweigh the costs. Fortunately, the process of collecting the application inventory can be automated through the ACT. If the Application Compatibility feature team elects to perform lot sampling to create an inventory, the team can select the clients to inventory based on the following characteristics:

  • Operating system version

  • Service-pack level

  • Geographic location

  • Computer manufacturer model and type

  • Applications installed

  • Business unit in which the computer is used

  • Organizational role that the user performs

Although the team can use lot sampling to create a useful inventory, the preferred method is to deploy the Inventory Collector from ACT to all corporate computer assets and to perform a collection scan. The team then uploads this data to the ACT Log Processing Service and imports it to the inventory database for analysis.

Planning for the Application Inventory

The amount of storage required for the application inventory depends directly on the average number of applications on each computer, the number of computers to be inventoried, and the configuration of the data collection packages (DCPs) deployed. A general rule of thumb for application inventory storage is to plan for two to three megabytes (MB) of database storage per client computer. The Application Compatibility feature team can increase this amount if it plans to run the collection for a long period of time or if it plans extended updates. The default configuration for a data collection package includes the Inventory Collector, the UACCE, and the Windows Vista Compatibility Evaluator configures the collection package to run for three days, and collects 10 logs per computer. In a sample test lab trial, the default DCP running on 140 computers generated 1416 logs and occupied 281 MB of storage.

The following list provides some general averages for storage sizes:

  • Status logs average 0.7 kilobytes (KB—compressed size).

  • Inventory Collector-only log files average 170 KB (compressed size).

  • Default DCP log files average 115 KB (compressed size).

  • UIA DCP data log files average 600 KB (compressed size).

Install the ACT on the following computers:

  • The computer used to process the log files (running the log processing service), ideally a separate computer from the computer running SQL Server.

  • Any desktop computer on which members of the Application Compatibility feature team will be creating DCPs or accessing the inventory database.

Collecting the Application Inventory

After identifying the client computers it is going to inventory, the Application Compatibility feature team collects the application inventory.

To collect the application inventory

  1. Select the appropriate methods for inventorying applications.

  2. Configure a central repository for the inventory agents.

  3. Deploy the inventory agents to the clients.

  4. Collect the application inventory from the clients.

Selecting the Appropriate Agents for Inventorying Applications

Based on the diversity of applications in the organization, the Application Compatibility feature team can customize the compatibility evaluators used in inventorying the applications. Team members can select any combination of compatibility evaluators to capture an accurate representation of the applications that the organization uses.

The list of inventory tools includes:

  • DCPs in ACT. ACT includes a collection of compatibility evaluators that can be used to determine potential compatibility issues for the installed applications within your organization. The list of evaluators includes:

    • Inventory Collector. Provides an inventory of installed software.

    • IECE. Provides potential compatibility issue details for internal and external Web sites.

    • UCE. Provides potential application compatibility issue details resulting from Windows Updates.

    • UACCE. Provides potential application compatibility issue details resulting from users running an application with low rights and permissions.

    • Windows Vista Compatibility Evaluator. Provides potential application compatibility issue details relating to the use of Graphical Identification and Authentication (GINA) DLLs, to services running in Session 0 in a production environment, and to any application components deprecated in the Windows Vista operating system.

  • SMS Software Inventory. Configure SMS to inventory or audit software installed on computers within the organization. Typically, the Application Compatibility feature team uses SMS to identify applications with known compatibility issues. However, the team could create scripts or other executables to perform customized application compatibility inventorying, and then using the SMS Software Inventory to report the results to SMS. Also, SMS uses a database different and distinct from the database that ACT uses to store inventory information.

Selecting the Appropriate Methods for Taking Inventory of Applications

As a part of the Application Compatibility feature team’s process for taking inventory of applications, it should select the appropriate methods for performing the inventory. The primary methods for inventorying applications include:

  • Tools in ACT.

  • Software inventory and auditing in SMS 2003.

Select the methods for performing application inventory by comparing the features in Table 2.

Table 2. Application Inventory Features That the ACT and SMS 2003 Support

Application inventory feature

ACT

SMS

Ships with prepackaged tools to help identify application incompatibility

 SE_ACBullet01  

 

Automatically obtains application compatibility updates from the Internet

 SE_ACBullet01  

 

Requires preexisting infrastructure

 

 SE_ACBullet01  

Typically inventories a greater number of existing clients

 

 SE_ACBullet01  

Is integrated with application compatibility–mitigation software

 SE_ACBullet01  

 

Requires the installation and subsequent removal of additional software after inventory is performed

 SE_ACBullet01  

 

If the organization has an existing SMS infrastructure, a combination of the inventory collected from ACT and SMS 2003 is appropriate. Otherwise, a combination of the ACT and the existing software-inventory and deployment infrastructure is appropriate. The use of SMS as a method for deploying ACT DCPs is covered in the section “Deploying Data Collection Packages by Using SMS” later in this guide.

The default DCP configuration in ACT 5 runs evaluators for three days and uploads data every eight hours. The default DCP configuration runs all evaluators except the UCE and IECE.

For more information on selecting the appropriate method for inventorying applications for Microsoft Office 2003 and the 2007 Office system, see the following resources:

  • Microsoft Office 2003. See “Appendix B: Addressing Microsoft Office 2003 Compatibility.”

  • 2007 Office system. See “Appendix C: Addressing 2007 Office System Compatibility.”

Configuring a Central Repository for Inventory Agents

The various inventory agents for performing application inventory record their information in various categories of databases. Table 3 lists each of the high-level categories of inventory agents and where they record inventory information.

Table 3. Categories of Inventory Agents and Where They Record
Inventory Information

Inventory agent

Records inventory information in

ACT tools

A centralized network shared folder. A merger process then collects the logs and enters them into a database running on SQL Server 2000, SQL Server 2005 or SQL Server 2007 Express Edition configured through the Application Compatibility Manager.

For more information, see “Phase 1: Configuring the Application Compatibility Manager” in the ACT Help and Support Documentation.

SMS 2003

The SQL Server database that SMS 2003 uses as a part of the SMS software inventory.

For more information, see “Software Inventory Administrative Tasks” in Part 1, Chapter 2 of the Systems Management Server 2003 Operations Guide at https://www.microsoft.com/technet/prodtechnol/sms/sms2003/opsguide/ops_0f3b.mspx.

Access 2003 Conversion Toolkit

.xml files that the Microsoft Office Access 2003 Conversion Toolkit can easily import into the reporting tool later in the process.

For more information, see Access 2003 Conversion Toolkit at https://www.microsoft.com/downloads/details.aspx?FamilyId=2E861E76-5D89-450A-B977-980A9841111E&displaylang=en.

ACT 5 DCPs are designed to upload their collected logs to a network shared folder. The Application Compatibility feature team typically configures this folder during ACT 5 installation if the team selects the Enterprise Configuration option. (The computer will be configured to receive and process log files, merge them, and enter them into the configured SQL Server database.) The shared folder must have Write permission for the Everyone group but should not assign any other permissions to Everyone. The log-processing service account must have Read, Modify, and Folder-Traverse permissions for the shared folder. These permissions are created by default during ACT configuration.

Deploying the Data Collection Packages

After selecting the appropriate DCPs, deploy the packages to the client computers identified earlier in the process.

To deploy the data collection packages

  1. Select the appropriate deployment method.

  2. Deploy the DCPs by using SMS, Group Policy, logon scripts, or other methods.

Selecting the Deployment Method

Multiple methods are available for deploying the DCPs to the client computers. These methods include:

  • SMS 2003. Use the software deployment feature in SMS 2003 to deploy the DCPs to the client computers. The only requirement is that the client computers must be inventoried in SMS 2003.

  • Group Policy Software Installation. Use the Group Policy Software Installation feature of Active Directory in Windows Server 2003 and Windows 2000 Server to deploy the DCPs. The only requirement is that the client computers must belong to the Active Directory forest. To use Group Policy to distribute the DCPs, create an .msi package for each DCP.

  • Logon scripts. Use logon scripts in Windows Server 2003 and Windows 2000 Server to initiate the installation of the DCPs. The only requirement is that a user must log on to a domain from the client computers.

  • Non-Microsoft deployment software. If the organization has a non-Microsoft software deployment infrastructure, use that method to deploy the DCPs. For information on the requirements of the non-Microsoft deployment software, consult the software vendor.

  • Manual distribution. For computers that either are not connected to the network or have slow connections, such as small branch offices, manual distribution methods are available. These methods include distributing the collection packages through e-mail or on physical media such as a USB flash device or CD. The Application Compatibility feature team can also instruct users to visit an internal Web page that provides links to downloads or installation scripts.

The method the Application Compatibility feature team uses for deploying the data collection package is largely based on the existing infrastructure. The preference of deployment methods is as follows:

  1. If the organization has an SMS 2003 infrastructure, SMS is probably the most appropriate method for deploying the data collection package.

  2. If the organization has an Active Directory infrastructure, use Group Policy Software Installation.

  3. If the organization has an identity and authentication infrastructure other than Active Directory, such as Windows NT 4.0 domains, use logon scripts.

  4. When the software deployment infrastructure is based on a non-Microsoft product, use that method.

Deploying the Data Collection Packages by Using SMS

If the organization has an existing SMS 2003 infrastructure, the Application Compatibility feature team can deploy the DCPs by using the SMS software distribution feature. The team deploys the DCPs to the target clients like any other application.

To deploy the data collection package using SMS

  1. Ensure that the target computers are included in the SMS inventory.

  2. Create an SMS computer collection that includes the target computers.

  3. Create a shared folder that contains the source image of the data collection packages.

  4. Create an SMS package based on the source image in the shared folder created in the previous step.

  5. Specify the SMS distribution points to be used in software distribution.

  6. Create an SMS program to specify the commands and command-line options used in deploying the data collection package.

  7. Create an SMS advertisement instructing SMS clients to run the program specified in the previous step.

For more information about the SMS software distribution process, see:

Deploying the Data Collection Packages Using Group Policy

When an organization has an existing Active Directory infrastructure, the Application Compatibility feature team can deploy the DCPs by using Group Policy Software Installation. The steps for deploying the DCPs by using Group Policy Software Installation are the same as for any other application to the target clients.

Note   Group Policy Software Installation is best used with Microsoft Installer (.msi) packages, and the DCPs ACT creates are executable files. The following steps assume the ability to create custom .msi packages for distribution.

To deploy the DCPs by using Group Policy Software Installation

  1. Ensure that the target computers are members of the Active Directory forest.

  2. Create a Group Policy object (GPO) for publishing the data collection package.

  3. Assign the GPO to the organizational units (OUs) containing the target computers.

  4. Create a Windows Installer package (.msi file) for the data collection package.

  5. Create a new software installation package by using Group Policy Software Installation.

  6. Publish the software installation package by using Group Policy Software Installation.

For more information about the Group Policy Software Installation software distribution process, see Best practices for Group Policy Software Installation at https://technet2.microsoft.com/WindowsServer/en/library/5f065962-a6e3-422a-8db7-20a57f40f9f51033.mspx?mfr=true.

For more information about deploying data collection packages using Group Policy, see “Deploying a Data Collection Package” topic in the ACT Help and Support Documentation.

Deploying the Data Collection Packages Using Logon Scripts

When the organization has an existing identity management and authentication infrastructure (such as Windows NT 4.0 domains), the Application Compatibility feature team can deploy the DCPs by using logon scripts. The steps for deploying the DCPs to the target clients by using logon scripts are the same as for any other application.

To deploy the DCPs by using logon scripts installation

  1. Ensure the target computers are members of the domain or a trusted domain.

  2. Create a shared folder that contains the source image of the data collection package.

  3. Create a script or executable file that can:

    • Determine whether the data collection packages are already installed.

    • Install the data collection package from the shared folder (if the compatibility evaluators are uninstalled).

    • Return the success or failure status of the data collection package installation process.

  4. Integrate the script or executable file created in the previous step into the existing logon script logic for the target computers identified earlier in the process.

For more information about logon scripts, see:

Deploying the Inventory Agents by Using Other Methods

When the Application Compatibility feature team uses a method other than the methods currently listed, team members must consult the software vendor’s documentation regarding software deployment.

Analyzing the Application Inventory Results

After the Application Compatibility feature team collects the application inventory, the team must analyze the inventory to determine which applications are incompatible with Windows Vista. To provide a comprehensive analysis of the inventory results, team members must:

  • Review updated compatibility information that the Microsoft ACT Community Web service returned.

  • Analyze the .xml files that the Access 2003 Conversion Toolkit created.

  • Analyze the information that the ACT provided.

  • Analyze the inventory information stored in the SQL Server databases.

  • Correlate the inventory results from the various inventory databases.

Reviewing the Updated Compatibility Information Online

The ACT Community works as an integral part of ACT and allows users to connect to Microsoft over the Internet to check for updated application compatibility information and to share some or all of your compatibility information with others.

Review the updated compatibility information online by:

  • Identifying the role of the Microsoft Compatibility Exchange in analyzing application inventory results.

  • Configuring your infrastructure to support the Microsoft Compatibility Exchange.

  • Reviewing the updated information that the Microsoft Compatibility Exchange returned.

The Application Compatibility feature team can freely share compatibility data for retail software applications, but custom applications or applications with modification peculiar to the environment would not be beneficial to other organizations.

Identifying the Role of the Microsoft Compatibility Exchange

The Application Analyzer Lookup Component connects to the Web service, uploads a Lookup Log request file, and attempts to find any known issues filed against the list of applications contained in the Lookup Log. The list of applications sent to the Web service is identical in format and schema to the Collector Extensible Markup Language (XML) Log for your organization.

The ACT Community provides the following benefits:

  • Share compatibility data, including issues, severity level, and solutions, with other registered ACT users.

  • Receive the most complete issue and solution data, using both authoritative and user data sources.

  • View community data about specific software in the Application Compatibility Manager.

For more information, see the “Application Compatibility Toolkit Technical Reference” in the ACT Help and Documentation.

Configuring the Infrastructure to Support the Microsoft Compatibility Exchange

The Application Compatibility feature team must configure the organization’s infrastructure to support the Microsoft Compatibility Exchange while also protecting the organization’s intranet. To do so, allow the appropriate users on designated computers to access the Microsoft Web services through the security and network infrastructure.

To configure the infrastructure to support the Microsoft Compatibility Exchange

  1. Configure firewalls and URL scanners to allow access to the Microsoft Compatibility Exchange as follows:

    • If necessary to pass the firewall, enable access to the URL.

    • Allow outbound access from the computers running the Application Compatibility Manager for the standard Secure Sockets Layer (SSL) TCP port 443.

    • Restrict outbound access to the Microsoft service, and allow access only from designated computers within the organization.

    • Restrict outbound access to the Microsoft service and allow access only by designated users within your organization.

Reviewing Information Returned from the ACT Community

After the Application Compatibility feature team has configured the organization’s infrastructure to support the Microsoft Compatibility Exchange, the team can request updated application compatibility information directly from Microsoft. The process consists of the following steps:

  1. The request for updated information is sent to the online service at Microsoft.

  2. The service processes the request and returns a new log with updated issue data to an internal temporary share on the client.

    Note   The returned log is identical in format and schema to the Collector .xml files.

  3. The Merger retrieves the log from an internal temporary share on the client that initiated the request.

  4. The Merger merges the information in the log back into the ACT database.

  5. The new application compatibility issues are available to anyone running the Application Compatibility Manager.

Analyzing Logs in .xml Files

Most of the information that the compatibility evaluators report is stored in XML format. For example, the Inventory Collector, the Microsoft Compatibility Exchange, and the Access 2003 Conversion Toolkit all record information in .xml files, and then integrate the information into their own respective databases.

Analyzing Data in the SQL Server Databases

The Application Compatibility feature team performs most of the analysis by reviewing the application compatibility information recorded in the SQL Server databases. The SQL Server databases reflect the aggregated compatibility information gathered from the .xml files on the individual clients.

Depending on the methods selected for performing the application inventory, the Application Compatibility feature team must analyze data from the SQL Server database used by:

  • Application Compatibility Manager in ACT 5. Application Compatibility Manager automatically scans its SQL Server database to find applications with compatibility issues and offers mitigation suggestions when possible.

  • SMS 2003. View application inventory by using SMS Administrator. However, the Application Compatibility feature team typically performs the data analysis by reviewing the inventoried applications and manually comparing them against a list of applications with known issues.

Although not a Structured Query Language (SQL) database, the Access 2003 Conversion Toolkit stores application information in an Access database. The scanning tool and the reporting tool both use a centrally stored Access database.

Correlating the Inventory Results

Each application inventory method maintains a unique database. For each method included in the application inventory and analysis, correlate the results across all the databases. The goals in correlating these results are to:

  • Ensure a complete and accurate list of all applications within the organization. In many instances, the majority of applications are probably known. However, comparing and contrasting application inventory from multiple sources acts as a check and balance to ensure that the list is accurate.

  • Identify any gaps that one method may have discovered but another method missed. For example, one of the advantages of inventorying by using ACT instead of SMS is the system’s automatic compatibility mitigation suggestions. If the ACT inventory missed an application, consider troubleshooting the ACT inventory process so that ACT can identify the application and provide suggestions for mitigation.

Correlate the application inventory results by:

  1. Creating a database in SQL Server 2000 to act as a centralized repository of application inventory and compatibility information.

  2. Exporting information from the various databases into the centralized repository.

  3. Generating reports based on the centralized repository to help in creating an application portfolio later in the process.

Creating the Application Portfolio

The final deliverable of the application inventory and analysis is the creation of the organization’s application portfolio. The application portfolio is a list of all the applications and their compatibility status.

To create an application portfolio

  1. Gather application inventory from all the various sources (such as the ACT or SMS 2003).

  2. Identify any application missing from the inventory.

  3. Select specific versions of applications to be included in the deployment.

  4. Resolve Web application compatibility.

  5. Prioritize the applications that are at high risk to the deployment because of unresolved application compatibility.

Gathering the Application Inventory Results

At this point, all automated forms of application are complete. Earlier in the process, the Application Compatibility feature team correlated the application inventory into a centralized repository of application inventory and compatibility issues and resolutions (stored in the SQL Server 2000 database).

The Application Compatibility feature team can generate reports based on this centralized repository by using reporting tools such as Microsoft SQL Server 2000 Reporting Services Standard Edition or Access 2003. These reports are the foundation of the application portfolio.

Identifying the Applications Missing from the Inventory

One of the biggest challenges in creating an application portfolio is identifying the applications that the automated processes did not inventory. These applications may reside on portable computers or high-security systems that cannot be inventoried. In these situations, the Application Compatibility feature team must document its knowledge of these applications manually.

To help reduce the likelihood of any applications being omitted from the application portfolio

  1. Distribute the application portfolio that automated methods created to all team members who have knowledge of the applications running in the organization. It is also advisable to ask a group of pilot users to review the list of applications for accuracy.

  2. Request that all team members review the list for any errors in the existing portfolio.

  3. Review the feedback from team members to analyze the errors in the existing portfolio.

  4. Make the appropriate changes to the portfolio based on the review.

  5. Publish the revised application portfolio, and obtain stakeholder approval of the list and application compatibility status.

Selecting Specific Application Versions

One of the common scenarios in many organizations is users running multiple versions of the same application. For example, the Application Compatibility feature team may find that different users in the organization are running Microsoft Office Word 2003, Word XP, and Word 2000.

In addition, the team may discover that more than one application performs the same function. For example, the inventory may reveal that users view streaming video using Microsoft Windows Media® Player and a non-Microsoft application.

In these and other situations, select a set of applications that can meet the business requirements of the organization while minimizing the number of applications and versions supported. Optimize the current versions of the application portfolio by reducing the number of application versions in the portfolio.

Select the specific applications and versions by:

  • Identifying the importance of standardizing on a specific version.

  • Selecting the appropriate version of an application.

  • Selecting one application to perform a business function.

Standardizing on a Specific Version

To help reduce the long-term total cost of ownership (TCO), reduce the number of supported applications in the organization. For each application supported in the organization’s standard, allocate time, training, tools, and resources to plan, deploy, and support the application. Standardizing the list of supported applications helps reduce the amount of effort required to support the deployed computer configuration.

Selecting the Appropriate Version of an Application

When more than one version of the same application is deployed in the organization, standardize on one version of the application wherever possible.

To select the appropriate version of an application

  1. Identify the latest version of the application currently installed in the organization.

  2. Determine whether a newer version of the application is currently available. If so, include the newer version of the application in the analysis.

  3. Verify that there is vendor support for each version of an application.

  4. Identify the license availability and cost for each application.

  5. Select (from all the versions available) one version that is supported on all clients.

  6. Validate in the test environment that the selected version is compatible with the new operating system deployment standard.

Selecting One Application to Perform a Function

When more than one application can address the same business function for the organization, select one of the applications to include in the organization standard. Give preferential consideration to one of the applications when the application:

  • Is part of a suite of applications. Applications that are part of a suite (for example, Word 2003 in Microsoft Office 2003) are more difficult to eliminate from the portfolio, because the entire suite must be eliminated.

  • Is supported by the vendor on the new operating system. Identifying support options early can reduce costs later.

  • Adheres to the Designed for Windows logo program. Applications that display the current compatibility logo have met stringent guidelines for compatibility with the current version of Windows.

  • Provides an .msi package for deployment. If the application provides an .msi package, less time must be spent preparing the application for deployment.

  • Is Active Directory aware. Try to select applications that can be managed through the use of Group Policy.

  • Is newer than the other applications. Deploying a newer version helps ensure the long-term support of the application. Older applications are not as likely to be supported as newer applications.

  • Provides multilingual support. Multilingual support allows the organization to address more computers when coupled with multilingual support in the operating system (such as the multilingual support in Windows Vista). This feature helps eliminate localized versions of applications.

  • Provides a greater number of features. Applications that support a greater number of features are more likely to address the business needs of a larger number of users.

Resolving Web Application Compatibility

Use IECE to identify and help mitigate Web application compatibility. IECE analyzes Web application compatibility and records any incompatibilities in the Windows event logs. When possible, IECE creates registry updates that correspond to the Internet Explorer security settings.

Resolve Web application compatibility by:

  • Determining how IECE can identify Web application compatibility problems and suggesting possible mitigations to those problems.

  • Testing Web applications by using IECE.

  • Mitigating Web application compatibility by creating a grouping of registry modifications.

Identifying How IECE Works

IECE monitors the security-related behavior of Web sites within Internet Explorer 7. IECE detects these behaviors and records them in the Windows Application event log. The categories of security-related behaviors include:

  • Anti-Phishing

  • Automatic Download Blocking

  • Bad Certificate ActiveX Blocking

  • Binary Behaviors Restrictions

  • Cascading Style Sheet (CSS) Fixes

  • Cross-Domain Barrier and Redirect Mitigation

  • Cross-Domain Barrier and Script URL Mitigation

  • Cross-Frame Navigation

  • Internationalized Domain Names (IDN) Support

  • Local Machine Zone Lockdown (LMZL)

  • Manage Add-ons

  • MIME Handling Restrictions

  • Object Caching Protection

  • Pop-Up Blocking

  • Protected Mode

  • Secure Sockets Layer (SSL)

  • Window Restrictions

  • Zone Elevation Restrictions

In addition to detecting and recording the behaviors, IECE can suggest automatic mitigations to certain Internet Explorer compatibility issues.

Testing Web Applications

When IECE starts, all open Internet Explorer windows are closed and a new Internet Explorer window opens. Test a Web site by navigating to it and performing the typical user operations, such as reading text, clicking links, and navigating to different parts of the site. When an Internet Explorer security feature blocks an action, IECE creates an entry in the Windows Application event log.

Test the Web applications as users with administrator-level privileges and with Limited User Access (LUA). For more information, see “Protected Mode" in the ACT online Help system.

Mitigating Web Application Compatibility

IECE enables automatic mitigation of certain issues that are found in the test environment. If automatic mitigation is available, click Apply in the lower right-hand corner of the Test Log page. The Apply button automatically modifies the local registry to help resolve the Web application incompatibility.

After applying the automatic mitigation, test the Web application again to ensure the mitigation is successful. For more information, see “Internet Explorer Automatic Mitigation” in the ACT Help and Support Documentation.

Prioritizing the Application Compatibility Resolution

After the application portfolio is complete and the Application Compatibility feature team has identified the applications that have compatibility issues, prioritize the list of applications with compatibility issues. Prioritizing the list allows team members to address compatibility issues that have the greatest effect on core LOB functions. Then, continue to resolve compatibility issues with a lower priority until team members have found a resolution for all applications.

Prioritizing application compatibility resolution includes:

  • Identifying the order in which applications will be deployed.

  • Resolving application compatibility for applications with known issues.

  • Resolving application compatibility for applications with unknown issues.

Identifying the Order in Which to Deploy Applications

Prioritize applications by their importance within the deployment plan or daily usage. Place higher importance on the applications that are considered core functionality in the deployment scheme, programs that must be available on the user desktop when the operating system deployment is complete. Conversely, if a small group of users uses an application only occasionally, relegate it to a lower priority for testing and deployment.

Resolving Known Compatibility Issues

Applications with known compatibility issues are applications identified earlier in the process by using the appropriate application compatibility tool (such as the ACT, Windows Catalog, Windows Upgrade Advisor, or the Access 2003 Conversion Toolkit).

Prioritize applications with known compatibility issues by:

  • Determining the application compatibility status.

  • Selecting the appropriate mitigation method.

  • Identifying applications that share the same compatibility issue.

Determining the Application Compatibility Status

One of the easiest ways to prioritize resolutions is to determine the application compatibility status. Organize applications into the following categories:

  • Applications with known issues and known mitigations. Applications in this category represent a very low risk to the deployment project, because there are known mitigations. Assign these applications a status that indicates that mitigation is complete and the applications are ready to be deployed in the testing environment.

  • Applications with known issues but with no available mitigations. These applications represent a higher risk to the deployment project because in this case, the mitigations for the issues are unknown. Assign the applications a status that indicates further compatibility investigation is required.

  • Applications with an unknown compatibility status. These applications represent the highest risk to the deployment project because their status is unknown. Place the highest priority on testing these applications to determine their compatibility.

Selecting the Appropriate Mitigation Method

In some instances, several methods for mitigating application compatibility may be available. Some of the mitigation methods that are typically available include:

  • Applying updates or service packs to the application. When updates or service packs are available that make the application compatible, apply the updates or service packs. Then, test the updated application in the test environment to ensure that the compatibility issue is mitigated.

  • Modifying the configuration of the existing application. In some instances, resolve compatibility issues by modifying the configuration of the application (such as moving files to different folders, modifying registry entries, or changing file and folder permissions). For commercially available software, contact the software vendor to determine whether any workarounds are available for compatibility.

  • Upgrading the application to a compatible version. When a newer version of the application exists that is known to be compatible, upgrading to the newer version is the best long-term mitigation. Disadvantages to this approach include the financial impact of the cost to upgrade and the possibility of introducing a coexistence issue by having more than one version of the application.

  • Modifying the security configuration. Modify the security configuration in instances where the organization’s security requirements are uncompromised. Before selecting this method as a final mitigation solution, obtain consensus from the organization’s Security feature team regarding the modifications.

  • Modifying the application. When Application Compatibility feature team members have access to the application source code, they can modify the applications to mitigate the compatibility issues. Depending on the extent of the modifications, the project impact may be minimal or significant on the overall project timeline. If the modifications are too costly or cannot be completed within the project timeline, select another method.

  • Selecting another application that performs the same business function. When another application is available that is known to be compatible, select the other application. The disadvantages to this mitigation are:

    • The cost of the new application.

    • Any user and support training required to introduce the new application into the organization.

  • Using application compatibility tools. The application compatibility tools may also provide software updates to incompatible applications that mitigate the problems. For more information, see the ACT Help and Documentation.

  • Running the application in a virtualized environment. When all other methods are unavailable, run the application in an earlier version of Windows by using virtualization tools (such as Microsoft Virtual PC 2004 and Virtual Server 2005) or remote desktop tools (such as Terminal Services) running on an earlier Windows Server operating system). Although this method provides a good short-term solution, implement one of the other methods long term.

Identifying Applications That Share the Same Issue

In some instances, more than one application may share the same compatibility issue. In these instances, assign discovering these mitigations a higher priority than other mitigations, because they affect several applications.

Resolving Unknown Compatibility Issues

As discussed earlier, some applications may be incompatible, but the reasons for incompatibility are unknown. In these situations, investigate further to determine the cause of the incompatibility. The following steps can help develop mitigations for applications with unknown compatibility issues:

  1. Locate incident reports or issues identified in preliminary testing that indicate the application is incompatible.

    Before proceeding, the Application Compatibility feature team must have some preliminary information that can provide the test cases that cause application failure.

  2. Investigate further, and test to better understand the nature of the incompatibility.

  3. Run risk mitigation based on MSF recommendations to determine project risks.

    The MSF Risk Management Discipline advocates a proactive approach to dealing with this uncertainty, evaluates risks continuously, and uses them to influence decision-making throughout the life cycle. Download the white paper, “MSF Risk Management Discipline,” at https://www.microsoft.com/downloads/details.aspx?FamilyID=6c2f2c7e-ddbd-448c-a218-074d88240942&DisplayLang=en.

  4. Determine possible mitigations that do not require identifying the compatibility issue before project completion.

In some instances, the usual identification and mitigations cannot be completed before project completion. In these instances, select one of the following methods for identifying and mitigating compatibility issues:

  • Run applications in a virtualized environment (such as one that Virtual PC 2004 or Virtual Server 2005 provides). Because the Application Compatibility feature team is running the application in a guest operating system that the application supports, no identification of the compatibility issue is necessary. The disadvantage to this method is the cost of virtualization software and any additional hardware upgrades required. The advantage is that the client computer has only supported applications installed.

  • Run applications by using a remote desktop solution (such as a Terminal Services session) on earlier versions of the Windows Server operating system. Because the Application Compatibility feature team is running the application on an earlier version of Windows that the application supports, no identification of the compatibility issue is necessary. The disadvantage to this method is the cost of the remote desktop software and any additional hardware required. The advantage is that the client computer has only supported applications installed.

Note   Although these methods are appropriate as short-term solutions, identify the compatibility issues and select a long-term mitigation.

Milestone: Application Portfolio Created

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

At this milestone, shown in Table 4, the Application Compatibility feature team has taken an inventory and created the application portfolio. Additionally, all stakeholders have agreed to a mitigation plan.

Table 4. Planning Phase Deliverables

Planning Phase milestone

Deliverable description

Owner

Application Inventory Collected

The appropriate computers are identified to be included in the application inventory. The inventory is performed and collected into the appropriate databases.

Development

Application Inventory Results Analyzed

The collected inventory is analyzed, and application compatibility issues are identified.

Development

Application Portfolio Created

The list of applications to be supported in the deployment is stored in a centralized database.

Development

Consensus for Application Compatibility Plan Obtained

All stakeholders in the BDD 2007 project provide consensus for acting on the application compatibility plan 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