Using OMPM Part 3 – Are there other uses for OMPM?

Brought to you by our compatibility guru Curtis Sawin.

Still using OMPM? Give Office Telemetry Dashboard a try!

Overview

The primary use for OMPM is to provide details about document conversion issues, and it helps answer the question, “What’s my risk of converting my binary Office file(s) to the Open XML file format?” However, we find that many people use OMPM to help answer the question “What’s my risk of opening my binary Office file(s) in an Office 2010 application?” The result is that we see some people use OMPM for the wrong question, spending significant time, effort, and money using a good tool to provide the wrong information.

Identifying pre-deployment and post-deployment tasks

For any compatibility project, regardless of platform, you should separate your compatibility tasks into pre-deployment and post-deployment tasks. Meaning, prior to migrating to your new platform (such as Office 2010, Windows 7, or Internet Explorer 9), you should focus your efforts only on tasks that enable you to deploy the new platform. Such tasks should have a clear and direct impact on the ability to deploy your platform. This is why pre-deployment tasks are considered deployment enabling tasks.

Post-deployment tasks are ones that allow you to realize the benefits of your new platform, which could include increased productivity (did I mention Paste Preview?), and lowered costs. Further, post-deployment tasks can position you for future platform migrations. Such tasks are considered environment optimization tasks.

For example, updating deprecated macro code is a post-deployment task, because object model items that have been identified as deprecated from previous versions of Office will still compile, but might not be available in future versions of Office. In other words, the deprecated macro code doesn’t actually block Office deployments. So after you’ve deployed Office 2010, updating your deprecated code will position you to migrate to future version of Office.

Converting documents is also a post-deployment task, because doing so allows you reduce your network storage needs and helps optimize your environment.

So what’s the appropriate use for OMPM?

As we mentioned earlier, OMPM identifies document conversion issues, not document issues. Meaning, for a specific document, OMPM can help tell you “will it convert” to the latest file format, but it does not tell you “will it work” in Office 2010.

Using OMPM in a pre-deployment manner to help figure out “will my documents work when I open them in Office 2010?” is a common misuse of OMPM. There are a couple reasons for this:

• The tool has the word “Planning” and “Migration” in the title. So it should be used when planning to migrate, correct? (Ugh…unfortunately, no)
• The tool provides results that identify “red,” “yellow,” and “green” issues. Data that’s red, yellow, and green is easy to understand. Green = good. Red = bad. Yellow = not so good (but not that bad).
• Most importantly…the tool provides data that IT organizations wouldn’t otherwise have. It can scan your entire environment and tell you easy-to-understand status of all of documents it found. Many IT orgs feel that having something is better than nothing.

The last bullet is the killer. OMPM provides data for IT Pros to grasp. Often, what we are seeing is customers using OMPM to find document conversion issues, and then focus their testing only on documents with “red” issues. This is an easy way to rationalize an enormous volume of data into something more manageable. “Red” documents are often 5-20% of the total inventory. Rationalizing my inventory to only 5% of what was discovered sounds like an excellent use of my discovery process!

However, this approach has several flaws. As we’ve noted, the most important flaw is that OMPM provides conversion issues, and does not provide information that will help you determine if a red document will work in Office 2010. Additionally, focusing on “red” documents ignores the importance of the document, and treats all red documents as equally important (i.e., docs that must be tested). Thus, while you think you’re saving time, you’re actually wasting time, potentially focusing on documents that have conversion issues, but don’t add value to the business. Lastly, using OMPM in this manner provides a false sense of security. While you can say you’ve focused your testing efforts on documents that have been reported to have only red issues, you can’t say that you’ve gotten closer to determining “will my stuff work” in Office 2010.

We are finding that companies spend 12-18 months in getting ready to deploy Office 2010. Meaning, once the decision is made to deploy, it could be up to a year and a half until your end-users are using the new version of Office. Most of this time is eaten up by lengthy (and costly) document assessment using OMPM. In fact, we’re finding that people who do NOT use OMPM prior to an Office 2010 upgrade are deploying faster, cheaper, and without any additional risk.

OMPM and macro issues

A new feature of the 2010 version of OMPM is that the tool identifies “macro issues.” In short, it will provide two data points: a count of all potential object model issues, and a count of all potential 64-bit compatibility issues.

The object model issues, listed as Functionality Issue Count in the OMPM reporting tool, summarizes the total number of items in macro code that have been removed, changed, or deprecated from previous versions of Office. The 64-Bit issues, listed as x64 Compatibility Issue Count, lists the sum of all macro code declarations that are not explicitly listed as “safe for 64 bit Office.”

With this improved functionality, many feel that this insight is invaluable and must be uncovered prior to deployment. For instance, you wouldn’t want to use a document in Office 2010 that had 88 functionality issues and 3 x64 Compatibility issues, would you? That depends on:

• Am I deploying 64-bit Office 2010?
• Are the issues impactful or harmless?
• Most importantly, is the document critical to the business?

If you’re not deploying 64-bit Office 2010, you can ignore all the data in the x64 Compatibility Issue Count column in the OMPM reporting tool. It doesn’t provide value in this situation, and is just noise.

The Functionality Issue Count data is a summary of removed, changed, or deprecated object model items. Most of these items are not impactful, but some of them may be impactful. How can you tell? Unfortunately, OMPM doesn’t make this distinction. So looking at the data doesn’t give you much to go on. Check out the article Understanding potentially impactful changes in the Office 2010 object model for more details about how object model changes may affect macros.

Lastly, while OMPM can tell you which documents have the most functionality or x64 macro issues, OMPM cannot tell you if the document/macro is important to the business. It would be a waste of time to spend testing and remediation cycles on documents that don’t provide business value. So using the volume of macro issues to help rationalize which documents should be tested often leads to inefficiencies.

Recommended approach to Office document discovery

Much of this article has described what not to do…which by itself is not so helpful. So if using OMPM for discovery documents and macros is bad…what is good? Start with the end-users. Canvas your customers. A major benefit (and challenge) of Office is that end-users can build their own solutions using Office, and that Office solutions are not managed by the IT organization. Further, many companies do not have the IT organization manage their Office documents, so the IT department has little insight into what Office documents are important to run the business.

You’ll find it is MUCH faster to partner with project managers, relationship managers, or designated business leads to identify what documents are critical to the business than it is to use OMPM to scan your entire environment and focus on the (gulp) wrong data. This partnering can also be leveraged for other IT initiatives and projects and help make enacting change in your environment more agile.

Most compatibility projects, regardless of platform, use the flow of “Inventory, Rationalize, Test, and Remediate” and with Office, it seems logical to use OMPM for the discovery, rationalize by filtering the “yellows” or “reds,” and testing and remediating your smaller subset. What this is inadvertently doing is rationalizing your list based on the wrong criteria. It’s kinda like car shopping based on color first. “Honey, here is a list of all the blue cars that you can pick from.” When you’re focusing your testing/remediation on the wrong set of data, you’re not reducing your risk. If fact, you’re increasing your risk by not focusing on the correct data.

Working with the business areas first to identify critical documents/solutions will provide an efficient means to perform the discovery and rationalization at the same time, as the business is validating the data as its being generated. The result is increased efficiency (which reduces time/cost) and lowered risk (by focusing on the right data). 

Summary

OMPM is an excellent tool to perform a specific task. Using OMPM to find document conversion issues, and using that data to determine if there’s a business justification for converting your documents after your Office 2010 deployment is completed is a great way to obtain value out of your investment, and realize potential savings. Using OMPM to answer the wrong question will lead to a costly and inefficient upgrade project that will hinder your business’s agility and delay the productivity benefits that Office 2010 brings to your customers.

For more information

The concepts in this article are explained in more detail in this 1-hour video Solving Office Compatibility to Accelerate Office Deployments, recorded from the Microsoft SharePoint Conference in Anaheim, CA. Below is an intro to the video:

Office file and solution compatibility causes concern for organizations when they begin planning for an Office upgrade. This typically leads to extended deployment projects delaying the realization of the new version value. The key to keeping your deployment project on track is utilizing the right process and leveraging tools appropriately to understand the potential risks. This session will demonstrate how the right approach will address the expensive/long assessments, fear of the unknown, and increased costs. Meet the Office Compat team and learn how to leverage the programs and resources to expedite Office 2010 or Office 365 client deployments.

Links

Using OMPM Part 1 - Identifying Document Conversion Candidates and Estimating Storage Savings
Using OMPM Part 2 – Performing Bulk Conversion

Comments

• Anonymous
  June 10, 2012
  The comment has been removed

• Anonymous
  November 05, 2012
  Hi Question regarding offscan.exe.  Can multiple instances of this be run from the same workstation without issue if you had for example c:ompmscan, c:ompm2scan, c:ompm3scan each with the required files and the offscan ini in them? Many thanks for your help in answering this. Andy

• Anonymous
  November 07, 2012
  I've opted to distribute amongst multile admin machines rather than attempting to run more than one instance of ompm from a single machine.  More processors and more network connections made more sense. Thanks.

• Anonymous
  November 08, 2012
  @Andy You can run multiple instances of offscan.exe. Each folder must contain the required files and an offscan.ini with a unique RunID and unique DestinationPath.

• Anonymous
  November 13, 2012
  Me again.  I keep getting the following error on one set of folders I am scanning HRESULT = 0x80070008 Can anyone shed any light onto what might be the cause?  I have stopped the scan and restarted from another machine but this started again. Any ideas? Thanks