Still using OMPM? Give Office Telemetry Dashboard a try!
Office Migration Planning Manager (OMPM) continues to be a popular tool with our Office IT Pro customers. We still get comments and questions about it from our blog readers and even from our own Microsoft consultants. Our frequent guest blogger and compatibility guru, Curtis Sawin, has been working tirelessly to help our customers understand what OMPM is good for (determining how well your documents will convert to the OpenXML format) and, more importantly, what it's not good for (determining how well your documents will work in Office 2010). He's got a great 3-part blog series and video on the subject if you haven't seen them yet.
Until recently, we didn't have an alternative tool to recommend to help you assess document compatibility. Now that Office 2013 Preview is released, we can tell you all about Office Telemetry Dashboard and how it fits into what we call the "modern" Office compatibility process. Makoto Yamagishi kicked off a new blog series about using Telemetry Dashboard, and we've all got many more blog posts and articles to come. In the meantime, I'll give you an overview of how OMPM and Telemetry Dashboard compare so that you can apply what you know about OMPM and get ramped up quickly on Telemetry Dashboard.
OK, before I continue, I know what you're thinking--"But I'm still planning my Office 2010 migration. What good is a tool for Office 2013?" Well, I've got good news: Telemetry Dashboard isn't just for Office 2013 Preview customers. It also monitors client computers that run Office 2010, Office 2007, and Office 2003. Yes, you'll still need Excel 2013 Preview to view the dashboard, but Office 2013 is free during the preview, and you’ll get Excel 2013 Preview and Telemetry Dashboard as part of that download. So, before you embark on an exhaustive scan of Office documents using OMPM, I hope you'll consider using Telemetry Dashboard instead.
Here's a table that compares OMPM with Telemetry Dashboard to help you learn the key differences.
OMPM |
Telemetry Dashboard |
|
Where to download |
||
Components |
|
|
Where compatibility and inventory data is stored |
SQL database |
SQL database |
How the data is collected |
|
|
What's collected |
OMPM collects lists of binary documents on the sources that it scans. See the full list on TechNet.
OMPM doesn't collect data about add-ins or solutions. You'll need Office Environment Assessment Tool (OEAT) for that. |
Telemetry Dashboard collects:
See the full list on TechNet.
|
As you can see from the previous table, there are many differences between the two tools. One of the fundamental differences is that Telemetry Dashboard uses an agent component installed on each client to periodically collect inventory and compatibility data about documents and add-ins that have been recently used by the client. With OMPM, you manually run a scan against different kinds of data sources (clients, shared folders, and websites). We changed the scanning method intentionally because we believe that documents and add-ins that get used often and by multiple users are more business critical than documents and add-ins that haven't been used in awhile. By monitoring only the documents that are being used, you'll save time in your Office deployment planning and piloting.
Another fundamental difference between OMPM and Telemetry Dashboard is that certain Office 2013 Preview applications are designed to report compatibility events, such as application crashes and long load times, to the agent. Not only that, the agent is actually built into Office 2013 Preview clients, so you don’t have to deploy it separately. And, should you want to monitor these events real-time, you can do so from any Office 2013 Preview client by using Office Telemetry Log. (Telemetry Log allows you to view what events have taken place on the local client, compared to Telemetry Dashboard, which consolidates events that occur across all monitored clients into a single dashboard.)
OK, so the built-in agent and compatibility events in Office 2013 Preview won't necessarily help you with your Office 2010 deployments. But by deploying the agent to your Office clients now instead of running exhaustive scans using OMPM, you'll save time in planning your Office 2010 deployment, and you'll have a head start identifying business-critical documents and add-ins. And when the time comes for you to start piloting Office 2013, agent reporting will already be enabled so that you can monitor for compatibility events when your users open their existing documents in Office 2013. And with new support for running Office 2013 side-by-side with earlier versions of Office, user acceptance testing is much easier.
Want to give Telemetry Dashboard a try? See our deployment guidance and subscribe to our blog to see new blog posts.
Jill
Comments
Anonymous
January 01, 2003
Could you confirm that you set HKEY_CURRENT_USERSoftwarePoliciesMicrosoftOffice15.0osm::AgentInitWait to 1? Without that, msoia waits for 10 minutes after launch. Command prompt returns immediately but the process of msoia.exe is still running. You can see that in Task Manager. Please wait until the process exits.Anonymous
January 01, 2003
Thanks for getting back to us. We've looked into this issue further and here is what we found: A standard user can’t launch the agent from Task Scheduler because it tries to run a scan for all users, and the user doesn’t have permission to run a scan for the admin user. Please try one of these workarounds: --Log off the user and log in again. (Not lock and unlock.) Msoia.exe should run on the user’s logon. or --Open the Command Prompt and make the directory where msoia.exe exists current. Run the following command: msoia scan upload After you do one of these workarounds, open Explorer and verify that .tbl files are created under %LOCALAPPDATA%MicrosoftOffice15.0Telemetry.Anonymous
January 01, 2003
Completet my testing setup for Office Telemetry Dashboard (SQL Express 2012, installation Temetry Processor, installation/deploy Telemtry Agent + REG-Key, setup fileshare for uploading the reports. Problem: I only get results/reports from my admin/installation (domain-User), the agent seems not to for my "standard" users, even if i trigger it manuelly by executing "msoia.exe scan upload". If run the scan manually or via scheduled tasks, the process does not show up in task manager. What I am doing wrong? P.S. Is there any forum for tlemetry dashboard, hard to find information outside of microsoft...Anonymous
January 01, 2003
Definitely HKEY_CURRENT_USER! If I add my (standard)user to the administrators group, msoia.exe is running in task manager. Could it be, that the standard user needs a superior right for msoia.exe? I have testet around with my useraccount (no admin , which starts msoia.exe via scheduled tasks. If I want to run the task with my standard domain user, is says: you need the right for batch processing --> I already added this right for my standard user, but nothing changes. Or do I have to use the Office 12 adm-templates for our domain, so the scan runs also for standard user accounts? At the moment I just wanted to thetest the thing without implamenting a new domain rule.Anonymous
January 01, 2003
Already tried the two workarounds in advance. No chance for standard user. Just one last thought. Is it possible, that the agent only runs, if I iplement the appropiate admx files, so it runs with domain admin account while the standard user logs in? One last question: I will soon deploy Office 2010. Should I realy use Office Telemetry instead of OMPM for 2010?Anonymous
January 01, 2003
tommacdeployswin7, I've asked your question to our Telemetry Dashboard experts and will post their response. You can also ask questions in our Application Compatibility forum at social.technet.microsoft.com/.../threads.Anonymous
January 01, 2003
Our experts say that logging should work fine for a standard user. Can you confirm that the EnableLogging regkey is enabled for the user? (HKEY_CURRENT_USERSoftware PoliciesMicrosoftOffice15.0OSM)Anonymous
September 18, 2012
Like Jill said, set the AgentInitWait to 1 (DWORD) and also set AgentRandomDelay to 0 (DWORD). Check outtechnet.microsoft.com/.../jj219431(v=office.15).aspx for more detail about these two settings. Enabling these two settings will enable you to logon and immediately see the results (without having to run the scheduled task). Also...I STRONGLY recommend using the Telemetry Dashboard instead of OMPM. If you're migrating to Office 2010, Telemetry helps answer the question "What do I need?" by helping you determine what is used the most. OMPM helps answer the question "What do I have?" by helping you find all Office documents. Also, OMPM finds document conversion issues...not document issues. The most common misuse of OMPM is to try to answer the question "Will my stuff work in Office 2010?" OMPM doesn't answer that. Check out blogs.technet.com/.../using-ompm-part-3-are-there-other-uses-for-ompm.aspx for more or my thoughts on OMPM. Hope this helps!Anonymous
July 25, 2013
I have been testing the OMPM tool (ofc.exe) to convert Office 2003 files in bulk to the Office 2007 format (XML). The problem I encounter is that we convert the files and OFC places them in a specific directory that follows the same structure of the source path. But we end up with the original files plus other non Office files in the source path, and now a target path that contains all the converted files. How can we remove the files that were successfully converted? Assuming I have a media copy or a backup of the original files, I feel I can discard the converted files. Another option would be to move the converted files out of the source path into a separate folder, and place the XML version in their place. This way, we are not detaching the Office files from other documents that belong together.Anonymous
July 14, 2015
Has anyone had problems with ofc.exe on windows 2008 server? works great on 2003. on 2008 it just hangs.Anonymous
November 10, 2015
Hi Jill,
Can I please get your view on a gap I have identified for using OMPM & Telemetry for large migration assessments.
- 2010 Sp1 OMPM offscan is useful as it can scan ALL doc/xls/ppt documents on a file share. While we can add docx/xlsx etc to Exts in offscan.ini, it doesn't do deep scan on the XML based files.
- Office 2013 Telemetry reports more performance metrics and usage for the "touched/opened" documents.
How can we deep scan ALL xml based files on a share?
I thought of writing a Powershell script to open/close the files on a share from a Telemetry client. But that is quite invasive.
We almost need a Powershell script that will just Open and inspect the metadata of the xml based office documents.
Do you know of any tools/scripts ? Are there improvements on this in 2016 Telemetry ?
Please drop in few lines about how you would approach this.
Regards
Frank