Article
07/22/2014

Office 2010 application compatibility guide

Applies to: Office 2010

Topic Last Modified: 2011-02-02

The application compatibility testing and remediation process for Microsoft Office 2010 deployments identifies compatibility issues and helps you develop plans to fix them. This information is useful primarily to IT professionals who evaluate and mitigate application compatibility issues. Developers who are upgrading Office applications might also find this information useful. After completing the process that is described in this article, administrators and developers will have a better understanding of which add-ins and applications interact with Office and how to migrate them to Office 2010.

This article does not cover document compatibility, conversion, or migration. For information about converting legacy Office files and using compatibility mode, see Document compatibility for Office 2010.

In this article:

Introduction to application compatibility in Office 2010
The application compatibility assessment and remediation process
Plan for compatibility testing
Assess the environment
Test and remediate compatibility issues

Introduction to application compatibility in Office 2010

Developers and expert users have been writing code to extend Office since the first Office products were introduced. As Office has evolved with feature changes, feature removals, and changes to file formats, so too has the likelihood that older add-ins and customizations might not work correctly when they are used with Office 2010. Not surprisingly, the topic of application compatibility can be challenging for organizations that have Office files dating back a decade or more.

Office 2010 has many product improvements and other changes that might affect compatibility with existing files, macros, add-ins, and Microsoft Visual Studio solutions. The following list describes some of those changes.

Features that have been removed Add-ins and applications can break when they have dependencies on features (and their corresponding object models) that have been removed from Office 2010.
Feature changes Updated features and their object models can cause add-ins and applications not to operate as expected. Sometimes these changes are obvious, and other times they are only discovered after thorough testing.
64-bit incompatibilities Office 2010 is available in both 32-bit and 64-bit versions. The 64-bit version is designed for users who need more memory capacity when they work with complex Microsoft Excel spreadsheets or Microsoft Project files. If you plan to deploy the 64-bit version of Office, you must consider that ActiveX controls, add-ins, and Microsoft Visual Basic for Applications (VBA) solutions created to work on 32-bit client computers might not work with the 64-bit versions of Office 2010.

Several tools and solutions are available to assess and remediate application compatibility issues with Office 2010. For IT administrators, the new Office Environment Assessment Tool (OEAT) can help to identify add-ins and applications that interact with Office. Developers can perform additional testing by using the new Microsoft Office 2010 Code Compatibility Inspector tool to pinpoint potentially incompatible code within VBA projects or Visual Studio code. In cases where applications cannot be fixed, administrators can use solutions such as Remote Desktop Services (Terminal Services), parallel installations, and the new Microsoft Application Virtualization (App-V) to maintain the previous, compatible Office environment alongside Office 2010.

The following sections briefly describe the Office 2010 application compatibility assessment tools.

Office Environment Assessment Tool (OEAT) OEAT is a new scanning tool for Office 2010 that identifies add-ins that are installed on users’ computers. OEAT collects and reports add-in information for Microsoft Office 97, Microsoft Office 2000, Microsoft Office XP, Microsoft Office 2003, and the 2007 Microsoft Office system. OEAT also compares the list of discovered third-party add-ins to a list of compatible add-ins that is tracked by the Independent Software Vendor (ISV) Application Compatibility Visibility Program.

To download OEAT, see Office 2010 Tool: Office Environment Assessment Tool (https://go.microsoft.com/fwlink?linkid=171092).

ISV Application Compatibility Visibility Program This new program tracks independent software vendors (ISVs) who pledge that their products are compatible with Office 2010. ISVs submit information about their products through a special ISV portal, and Microsoft publishes this list to the Compatibility for Microsoft Office 2010 Resource Center (https://go.microsoft.com/fwlink/?LinkId=186766). OEAT also uses this list to highlight known compatible add-ins in the summary report.

To view the current list of ISVs that participate in this program, see Compatibility for Microsoft Office 2010 (https://go.microsoft.com/fwlink/?LinkId=186766).

Microsoft Office 2010 Code Compatibility Inspector (OCCI) The Microsoft Office 2010 Code Compatibility Inspector compares existing VBA, Visual Basic .NET, and C# source code for object model API calls that are incompatible with Office 2010. The tool integrates with both Microsoft Visual Basic for Applications 7.0 (VBA 7) and Microsoft Visual Studio 2008 or Microsoft Visual Studio 2010 and includes a basic scanner. When an inspector tool finds code that is incompatible with Office 2010, the tool adds a comment to the code for the developer to reference and fix later. The inspector tool also scans code for Declare statements and references to DLLs used by ActiveX controls that need to be updated to be compatible with 64-bit Office 2010.

To download OCCI, see Office 2010 Tool: Compatibility Inspector (https://go.microsoft.com/fwlink?linkid=181874).

The following table describes the kinds of Office-based customizations that many organizations will encounter and the tool that is used to assess each customization. Because some of these customizations were common for earlier versions of Office, the links to additional information often point to developer documentation for Office 2003 and earlier.

Type of customization	Description	Assessment tool
Automation add-ins (.xll or .wll)	Automation add-ins let developers incorporate an existing Office 2010 application’s functionality into custom applications. An example of an Office Automation add-in is a CRM application that writes customer’s billing data to a Microsoft Excel worksheet. For more information about Automation add-ins, see Excel COM add-ins and Automation add-ins (https://go.microsoft.com/fwlink/?LinkId=186622).	OEAT
COM add-in (Windows .dll)	Introduced as part of Microsoft Office 2000, COM add-ins let developers use the programming language and environment of their choice when they create Office-based solutions. After a COM add-in is written, it is then compiled as a .dll file. The .dll file can be loaded by one or more Office applications and can interact with Office object models. For more information about COM add-ins, see What Is a COM Add-in? (https://go.microsoft.com/fwlink/?LinkId=186623).	OEAT
Office 97–2003 format VBA add-ins (.dot, .wll, .xla, .xll, .ppa) Office 2007–2010 format VBA add-ins (.dotm, .xlam, .ppam)	VBA template add-ins are created by using Microsoft Visual Basic for Applications (VBA). For more information about VBA add-ins, see Getting Started with VBA in Office 2010 (https://go.microsoft.com/fwlink/?LinkId=186624). For clarification about the differences between Microsoft Word templates and add-ins, see Word Document Templates vs. Word Add-ins (Global Templates) (https://go.microsoft.com/fwlink/?LinkId=186625).	OEAT and OCCI
Office 2007–2010 format VBA macro-enabled files (.docm, .xlsm, .pptm)	These files contain VBA macro code but are not saved as add-ins. OEAT will detect macro-enabled Word and Excel files that are stored in the Startup folder or that are loaded as global templates. OEAT will not discover macro-enabled files that are stored in other locations, nor will OEAT discover macro-enabled PowerPoint files in any location. For more information about macro-enabled files, see File formats supported in Office 2010.	OEAT and OCCI
Office add-ins created by using Visual Studio	Office add-ins created by using Visual Studio let organizations customize Office applications to add specific features that are needed for business processes. Visual Studio supports two kinds of solutions that might be used in your organization: Document-level customizations These customizations consist of an assembly that is associated with a single document, workbook, or template in Microsoft Word or Microsoft Excel. Features in document-level customizations are available only when the associated document is open. These customizations cannot make application-wide changes, such as displaying a new menu item or ribbon tab when any document is open. Application-level add-ins These add-ins consist of an assembly that is associated with an Office application. The add-in can call into the object model to automate and extend the application, and it can use any of the classes in the Microsoft .NET Framework. OEAT can be used to detect application-level add-ins only. For more information about Office add-ins created by using Visual Studio, see Office Solutions Development Overview (https://go.microsoft.com/fwlink/?LinkId=188380).	OEAT and OCCI

The application compatibility assessment and remediation process

The following figure shows a summary of the application compatibility assessment and remediation process. Each task defined in this figure has a corresponding section in this article.

The application compatibility process

Note

This guide does not cover document compatibility, conversion, or migration. For information about converting legacy Office files and using compatibility mode, see Document compatibility for Office 2010.

Plan for compatibility testing

Planning for the assessment, remediation, and piloting of add-ins and applications is an important first step in the overall process of application compatibility testing. Although it might be tempting to rely on previous results of the 2007 Office system compatibility testing, we do not recommend this and it will only delay a successful deployment.

Plan for assessment

The following sections describe planning tasks that will help you prepare to assess the add-ins and applications in your organization.

Create central repository for assessment documentation and results

To help manage the assessment and remediation process, we recommend that you build a central repository of discovered applications and their status. A solution such as Microsoft SharePoint Server 2010 can help keep all project members up-to-date and the project itself on track.

Identify stakeholders

Stakeholders are the people or groups who approve and allocate resources to the project. By identifying stakeholders early in the planning process, the application compatibility project team can communicate and validate the project deliverables to those that have a vested interest.

The following table describes the typical stakeholder roles in an application compatibility project.

Role	Responsibility
Application Owner	Ensures that the business process done by using the previous Office version continues uninterrupted after the upgrade.
Project Sponsor	Promotes the success of the Office upgrade and positive publicity within the organization.

Assign roles for the project participants

The following table describes possible roles and their respective responsibilities that have to be filled in an application compatibility project.

Role	Responsibility
Project manager	Ensures the overall flow of the project, and manages overall resources, metrics, and risks.
Compatibility validation tester	Follows the test plan and tests Office components for any potential incompatibility issues, including file format, macros, add-ins, or Office Automation.
OEAT operator	Understands and performs setup and configuration of OEAT.
Remediation lead	Performs the actions that resolve compatibility issues on Office customizations.
Regression tester	Ensures that the remediation performed on an Office object is successful. This role is often filled by the remediation lead.
User acceptance tester	Representative of an affected business unit who determines that the remediation of an application was successful and that it does not interfere with other customizations or actions. This should never be the person who performs the remediation or regression testing.
Business analyst or owner	Owns the code and documentation of the applications and add-ins that are critical to the business unit.
Deployment group lead	Owns and tracks the timeliness of the complete technical process. Might delegate some reporting or administration activities.
Application packaging group	Owns the Office 2010 installation package.
Client (Desktop) team	Owns the deployment of the Office 2010 package via the organization’s configuration management tool, such as Systems Center Configuration Manager (SCCM).
Service desk	Provides functional support of Office for the testers and, when the migration is complete, the users.

Identify and interview business units

The next step in assessment planning is to identify your departmental or business unit groupings and interview their representatives to understand how the current set of add-ins is fulfilling their business needs. Knowing the importance of each add-in, its purpose, why it was made, what it does, and who made it are all important in making an informed decision about how to remediate the add-in and correct issues as they are found.

Some add-ins for Office applications might have been created informally within your organization. Therefore, you might need to do some investigative work to track down an owner and the original source code, if it still exists.

You can use the following form as a template for an interview questionnaire.

Application information

Business unit

Application name

Application contact/owner

AppID

Version

Priority

Tier

Office 2010 compatibility status if known (Pass, Fail)

Compatibility issue description if available

Number of users

Office version used by the application (XP, 2003, 2007, 2010, and so on)

Describe the kind of usage (for example, exports an Office document, add-in to Office application, and so on)

Office suite components used by the application

Word

Excel

Access

PowerPoint

Other

Does this application use complex Office objects such as charts, PivotTable reports, or drawing art?

Is this a data entry or front-end application? If yes, provide details.

Which language(s) does the application support?

Identify client computers to scan

After you determine the different business units that need their client computers scanned, you can start the process of identifying a statistically relevant sampling of client computers for each business unit. Not every client computer in your organization needs to be scanned. However, in some cases (depending on the size of the organization), scanning the entire environment or an entire group or organizational unit (OU) might be less restrictive (or easier) than delineating separate client computers to participate. A statistically relevant sampling of no more than 20 percent should provide enough information to successfully assess and remediate the compatibility issues in your Office 2010 environment.

Important

All client computers that run OEAT must have Microsoft .NET Framework 2.0 or later installed. For more information about OEAT requirements, see Office Environment Assessment Tool (OEAT) user's guide for Office 2010.

If your organization lacks an up-to-date client inventory, consider running the Microsoft Assessment and Planning (MAP) Toolkit to generate a client inventory and assess Office 2010 readiness. From this inventory, you can work with business group leaders to select a subset of client computers for assessment by using OEAT. For more information about the MAP Toolkit, see Microsoft Assessment and Planning Toolkit (https://go.microsoft.com/fwlink/?LinkId=149448).

Plan for remediation

The following sections will help you establish baseline criteria to classify and remediate incompatible applications. Coming to an agreement early in the planning process will help you avoid disagreements or other delays after the assessment and testing results are available.

Determine how applications will be classified and prioritized

Enterprises develop, deploy, and maintain a variety of Office-based applications and add-ins, all of which might have significantly different values to the organization. Therefore, it is important to organize applications into classes or tiers based on the value of the application to the business. A simple method is to classify an application as either mission-critical or not. Additional classifications to consider are as follows:

In-house and third-party applications
Departmental applications
Unmanaged solutions, such as templates, add-ins, and macros that are created by end-users
Number of users of the application
Use of the application by executives
Expected lifetime of the application

The following table describes how an organization might classify and prioritize different kinds of Office customizations.

Customization	Mission critical	Non-mission critical
Automation add-ins	Proactive OEAT scan, test, and remediation	React to user discovered
COM add-ins	Proactive OEAT scan, test, and remediation	React to user discovered
VBA add-ins	Proactive OEAT and OCCI scan, test, and remediation	React to user discovered

To further help prioritize mission-critical applications, you can classify them as Tier 1, Tier 2, or Tier 3. Sample classification guidance for each tier is as follows:

Tier 1: Mission Critical Failure of mission-critical applications is damaging to business continuity or revenue of the organization. Any application that is used by executives should be considered mission-critical, regardless of the number of users or business priority of the application. This tier also includes applications that are used by more than 10 percent of the organization’s users.
Tier 2: Business Critical These applications are business-critical or are used by 10 percent or more of the organization’s users. This tier can also include applications that are used by 1 to 10 percent of the organization’s users and be of any business priority. These are not mission-critical or revenue affecting applications. However, they could indirectly increase expenses or reduce revenues by affecting productivity.
Tier 3: Business Applications These applications are not mission-critical and can affect as few as 10 employees or up to 1 percent of the organization. They are usually tools that help small tasks and that have a low impact on the business.

Identify remediation strategies

After you define criteria to classify applications, you should identify potential remediation strategies. Although the actual remediation work is difficult to plan, you can establish generic strategies that can guide the resolution of issues for each kind of customization. The following table provides suggested remediation strategies based on the kind of application and its expected lifetime.

Type	Potential strategy
In-house application that has a limited lifetime	Retire the application and find a new process.
In-house application that has a long lifetime	Rewrite or rework the code to fit the new object model.
Third-party application that has a limited lifetime	Retire the application and find a new process.
Third-party application that has a long lifetime	Contact the vendor for update or replacement.
Application is not working	Reinstall the application with a new directory structure or create a virtual environment for the application.

As you remediate the applications, you might find that their priority can change from your initial assessment. You should put a strict process in place for remediation assessments to only allow an application to move up in tier (but not down). For information about how Microsoft IT categorized and prioritized applications, see Deploying the 2007 Office System at Microsoft (https://go.microsoft.com/fwlink/?LinkId=178278).

Microsoft also has prescriptive information on TechNet about known issues that occur when you migrate Office customizations. For more information, see Product and feature changes in Office 2010 (for IT pros). There are also Microsoft partners who have tools that help the remediation process.

Plan for piloting

The project team must consider how add-ins and applications will be piloted. Specifically, the team should identify the following:

Which users will participate in the pilot.
How users in the pilot will report issues.
Whether helpdesk employees will assist in the pilot and, if so, how they will be trained.
When the pilot will begin. For example, some organizations begin pilot testing early, during the planning phase, to obtain early feedback as they move through the process.

The following resources are available to help you plan for piloting. These resources are not specific to Office 2010 compatibility testing. However, many of the principles covered in these resources still apply.

Assess the environment

During the assessment phase, you collect an inventory of add-ins and applications by running OEAT against a statistically relevant subset of client computers. After you analyze the results and prioritize applications, you will be ready for the testing and remediation phase.

Run OEAT

OEAT can be run from a network share or distributed to users. OEAT scans client computers and then saves the results of the scans to a designated location, usually a network share. After the scans are completed, you can use OEAT to compile the results into a Microsoft Excel spreadsheet for use during the remediation process.

Depending on your environment, you can deploy OEAT in one of the following ways:

Active Directory environments Deploy OEAT by using an Active Directory Login script. As users log in, OEAT is executed automatically and the results are saved to the designated location.
Managed environments Deploy OEAT by using a management solution such as Systems Management Server (SMS) or System Center Configuration Manager (SCCM).
Unmanaged or non-centralized IT environments Create a share for OEAT and provide instructions to users on how to manually run a scan.

For information about how to deploy and use OEAT, see Office Environment Assessment Tool (OEAT) user's guide for Office 2010. To download OEAT, see Office 2010 Tool: Office Environment Assessment Tool (https://go.microsoft.com/fwlink?linkid=171092).

Review OEAT results

When the client computer scans are complete, use the Compile results option in OEAT to create a spreadsheet that summarizes the results of all client computers that were scanned. The spreadsheet contains multiple worksheets, including the following:

SummaryReport This worksheet contains summary information that will help you determine whether your scanned client computers are ready for Office 2010. The worksheet includes data on average free space, processors, computer manufacturers, Windows installations (including service pack levels), and Office installations. The resulting data could be interesting from a configuration management perspective in that client computers might not be running the versions of Office or Windows that you expect.
MicrosoftOfficeAddins This worksheet contains a list of all add-ins that are included with Office.
AddinsNotShippedWithOffice This worksheet contains a list of all add-ins that are not included with Office. Much of your assessment and planning will come from this report. You can sort the list by application, view the last accessed or modified dates, and view the number of client computers on which the add-in was detected. You can also compare version numbers of the same add-ins to determine whether some subsets of the client computers are out-of-date, which could indicate an issue with configuration management processes in your organization.

On the AddinsNotShippedWithOffice worksheet, start with the Compatibility column to see the compatibility status of each add-in. OEAT generates the data for this column by comparing the discovered add-ins with the list of compatible add-ins that are tracked by the ISV Compatibility Program. The possible compatibility status results are as follows:

UNKNOWN The add-in is currently not in the Microsoft vendor list of Office 2010-compatible add-ins. Therefore, the status of this add-in is unknown. Note that this status could change as new vendor data is made available to OEAT. Each time that you compile the spreadsheet, you have the option to download new vendor data.
PARTIAL MATCH OEAT reports this status in two cases: OEAT found a match for the vendor name only. Or, OEAT found a match for the vendor name and product name, but the version number did not match. Use the link provided in the URL column to check the vendor list for compatible add-ins from the vendor.
EXACT MATCH This status is shown when the vendor name matches, the product name matches, and the version number of the add-in is equal to or greater than the version that was reported by the vendor.

Important

The Compatibility column is not shown if you choose not to download compatibility data when prompted in the final version of OEAT, or if you are using the beta version of OEAT. You can download the final version of OEAT from the Microsoft Download Center.

Finalize remediation plans

At this point, you are ready to correlate OEAT results with the prioritization criteria that you established during the planning phase. When you set a schedule for this work, make sure that you allow additional time to investigate and prioritize add-ins that were not identified during the business unit interviews. To understand the scope of incompatibilities of VBA add-ins and Visual Studio add-ins, the development team can run OCCI during this phase to understand how much of the underlying code will need to be changed.

Test and remediate compatibility issues

During this phase, you and your development team will start to test mission-critical and other high-priority add-ins and applications to find specific compatibility issues with Office 2010. After the incompatibilities are identified, the development team will begin remediating incompatible add-ins and applications based on the work that you did in the planning phase.

As multiple applications and add-ins are remediated, you cannot assume that these remediations will function together. You have to test all remediations together and then pilot these in a real-world scenario. Each step is important in validating the remediations, stabilizing the overall deployment of Office 2010, and ultimately creating a more successful migration.

Test add-ins and applications

The following flowcharts provide general guidance for developers who are testing different kinds of applications to identify incompatibilities with Office 2010. For additional guidance, see the following resources:

General application testing

The following flowchart provides a high-level view of application testing. Subsequent flowcharts in this section describe the testing process for specific kinds of Office applications, such as add-ins, macros and scripts, and Office Automation testing.

Application testing flowchart

Office add-in testing

Office add-in testing flowchart

Macros and scripts testing

Macro testing flowchart

Office Automation testing

Office automatic testing flowchart

Run Office Code Compatibility Inspector tool

As part of the overall testing process, developers can run the OCCI tool to scan for known changes or deprecations to object model members. OCCI also scans VBA Declare statements and references to DLLs used by ActiveX controls that need to be updated to be compatible with 64-bit Office 2010. When the tool encounters potential compatibility issues, it adds a comment in the code to bring the issue to the developer’s attention.

Each time that an Inspector scan is complete, a summary and detailed report of what was found in the project is provided. Items that are scanned include the following:

Changes Any syntactical change to an object model member is flagged. OCCI detects usage of any object model member that has changed since Office 97.
Deprecations Any usage of a deprecated object model member is flagged. OCCI detects usage of any object model member that has been deprecated since Office 97.

For more information about how to use OCCI, see the Microsoft Office Code Compatibility Inspector user's guide. For application-specific development resources, such as details about object model changes since earlier versions of Office, see Microsoft Office 2010 (https://go.microsoft.com/fwlink/?LinkId=206197).

Remediate add-ins and applications

There are several approaches to correct an application or add-in that has a compatibility issue with Office 2010. The following sections briefly describe remediation options.

Get updates from vendors

OEAT reports provide links to add-ins known to be compatible. However, some applications might not be on this list. In this case, you have to contact the vendor directly. Be prepared to develop temporary workarounds if the updated add-in will not be available in time for your migration, or if the add-in will not be updated (or the vendor is no longer in business). If a temporary workaround is not available, consider virtualization or a parallel installation.

Update internal applications

When you have the source code and understand how the add-in or application functions, or you have documentation and the original development team is still active or can be consulted, you have an ideal situation to update an internal application. The process of updating internal applications is greatly simplified with the use of OCCI, which identifies incompatible functions within the source code. The development team will still need to perform the necessary fixes themselves. However, they will have a much easier time locating the incompatible code by using OCCI.

Note

If the platform for writing the internal application is very old (such as Visual Basic 6, or earlier versions), we recommend that you consider a complete rewrite of the tool by using the .NET Framework.

The following guidance is useful for developers who need to update internal applications.

Add-ins created by using Visual Studio

The runtime components for Office 2010 were created so that Microsoft Visual Studio Tools for Applications (VSTA) and Visual Studio 2008 .NET add-ins, document solutions, and spreadsheet solutions will all run on 64-bit Office 2010. These runtime components are installed with Office 2010. Therefore, an administrator does not have to include a separate installation for this runtime. However, there are other considerations that are needed.

In a Visual Studio project, C# or Visual Basic code can be compiled into Microsoft Intermediate language (MSIL) when the Any CPU option is used. At runtime, the MSIL is Just in Time (JIT) compiled to the correct chip set, either AMD or Intel 32-bit or 64-bit. However, this technology does not apply to the .NET Framework in versions 1.0 and 1.1. These versions do not enable this 64-bit transformation.

Even conforming .NET Framework 2.0 code must be reviewed because any calls to a process invoke (p/invoke) in your code are native (processor architecture specific). If you try to call native API methods by using p/invoke, you can have issues with your VSTO solution running correctly on 64-bit Office 2010.

Issues can also occur if the code makes deliberate calls to a Win32 API that does not have exactly the same signature (method name, parameter list, and DLL name) of an equivalent Win64 API. This is true for any solution, whether it is an Office solution or Windows-based solution.

For more information about how to author solutions for 64-bit Office 2010, see 64-bit Applications for Visual Studio 2005 (https://go.microsoft.com/fwlink/?LinkId=178279) and 64-bit Applications for Visual Studio 2010 (https://go.microsoft.com/fwlink/?LinkId=152431) in the MSDN technical library.

VBA solutions and macros

Solutions and macros that are created by using Visual Basic for Applications (VBA) will function as long as they interface with the Office 2010 object model. However, certain calls might be deprecated and will no longer function. If VBA code uses Windows API calls, these calls are likely to 32-bit DLLs. A simple fix is to update the code so that the Declare statements use the PtrSafe keyword. OCCI can be used to identify these Declare statements. For more information about VBA 64-bit compatibility, see Compatibility Between the 32-bit and 64-bit Versions of Office 2010 (https://go.microsoft.com/fwlink/?LinkId=186639).

ActiveX controls

ActiveX controls that are native 32-bit controls (which are likely to be any controls that are compatible with the 2007 Office system and previous Office versions) are not supported in 64-bit Office 2010. Remediation for any of these controls will require a recompile (if the source code is available), asking or waiting for a vendor update, or using a virtualization method. Again, for more information about VBA 64-bit compatibility, see Compatibility Between the 32-bit and 64-bit Versions of Office 2010 (https://go.microsoft.com/fwlink/?LinkId=186639).

Outlook applications

Outlook 2010 enforces a new fast shutdown process for add-ins. The new shutdown process prevents add-ins from causing long delays by holding on to resources after the user exits Outlook. Although this change could adversely affect some existing add-ins, add-in vendors and IT administrators can resolve those effects by forcing Outlook to revert to the standard add-in shutdown process. For more information about the new shutdown process, see Shutdown Changes for Outlook 2010 (https://go.microsoft.com/fwlink/?LinkId=203255).

Exchange Client Extensions (ECEs) do not load in Outlook 2010. Some third-party applications, such as archiving or security solutions, use ECEs and must be updated for Outlook 2010. For more information, see Announcing the deprecation of Exchange Client Extensions (https://go.microsoft.com/fwlink/?LinkId=203888).

If you are installing 64-bit Outlook 2010, you must update 32-bit MAPI applications, add-ins, and macros for Outlook to 64-bit. For more information, see 64-bit editions of Office 2010, Building MAPI Applications on 32-Bit and 64-Bit Platforms (https://go.microsoft.com/fwlink/?LinkId=203889), and Developing Outlook 2010 Solutions for 32-Bit and 64-Bit Systems (https://go.microsoft.com/fwlink/?LinkId=208699).

Use parallel installations or virtualization

When there is no practical recode or rewrite solution, there are additional options that can assist you in finding a solution to a compatibility issue.

If you are waiting for vendor updates for an add-in that might be delivered at some date past your deployment date, you can opt to install Office 2003 or earlier in parallel with Office 2010 (or just the specific applications that are waiting for vendor updates, for example, such as Office Excel 2003).

Note

If you are moving to a 64-bit version of Office 2010, you cannot have a parallel installation of the 2007 Office system (or earlier version) installed at the same time. All previous versions are available only in 32-bit versions.
If you are running Windows 7, you can install a parallel installation of Office 2003 (or earlier) in Windows XP compatibility mode, or if you are on an older version of Office, you can install it in a virtual computing environment.
Use App-V (formally known as SoftGrid). For more information about App-V, see Microsoft Application Virtualization 4.6 (https://go.microsoft.com/fwlink/?LinkId=143973).
Use Windows Terminal Services and perform one of two options:
- If you have Windows Server 2003, you can use Windows Terminal Services to provide desktop computers that can run these solutions remotely with an earlier version of Office.
- If you have Windows Server 2008, you can install RemoteApp. This will give users the feeling of the legacy application and the legacy version of Office on their client computers. For more information about RemoteApp, see Deploy Windows Server 2008 Terminal Services RemoteApp (https://go.microsoft.com/fwlink/?LinkId=178280).

Pilot remediated add-ins and applications

Conducting the pilot is the last major step before deployment of Office 2010. The pilot is the ultimate proving ground for the remediated options, and it should be part of the project team’s role to remain involved throughout the piloting of Office 2010 to capture and correct any problems that occur. During the pilot, your release management team monitors a controlled environment in which users perform their typical business tasks by using the new features, including remediated applications and add-ins that interact with Office 2010. This demonstrates that the remediations function as expected and that the organization’s business requirements are met.

As issues are reported in the pilot, an iterative approach should be taken to remediate the problems found, design a new test case, perform tests, and then deploy the updated applications back into the pilot for additional review. Specific focus should be given to how well these options work, user feedback, and any issues that limit the scope or functionality of the add-in or application that was remediated.

For more information about how to stabilize and pilot applications, see Stabilize Service Management Function (https://go.microsoft.com/fwlink/?LinkId=115624) in Microsoft Operations Framework 4.0 in the TechNet technical library.

Share via