Just a quick post today because I’ve recently re-encountered an error I first had a run-in with back in 2011. I’ve seen it happen a number of times and it does seem to occur in environments where profile management tools are in use more than others, but I really can’t speculate on the actual root cause.
What normally happens is you will see a particular document type for a particular Office application begin throwing errors when opening documents directly from Windows Explorer. Last instance of it I had, it was affecting .xlsx files in Excel 2010 and .rtf files in Word 2007. If you double-clicked one of these files from a Windows Explorer window, the handler application would launch but the file would fail to open with the error shown below.
Once this fails, though, browsing through the application to the file’s location and opening it from within the app works just fine. This isn’t a viable workaround, though – users will soon get very frustrated with having to do this.
Firstly, you need to identify the particular file extension(s) and application(s) you’re having a problem with. This shouldn’t take too long – just recreate the error you (or the user) is having and find out which file extensions and Office applications that it is occurring on. Usually it’s just one, although I have seen it affecting up to three in some cases. In the last example I had of it, it was Excel 2010 .xlsx files and Word 2007 .rtf files.
Next, marry up the file type extension with a file type handler. For instance, the .xlsx extension maps to Excel.Sheet.12, whereas the old .xls extension from 2003-2007 versions (although still very much supported) maps to Excel.Sheet.8. Sadly, the numbers in these handlers don’t map to Office versions (that would be too easy!), so sometimes it is a case of educated guesswork. The .rtf extension in Word maps to Word.RTF.8, so most of the time they are pretty easy to spot. Make a note of these as you will need them. As a guide, older file types (from 2003 to 2007 Office versions) generally resolve to 8s, the open formats from 2010 onwards resolve to 12s, and there are a few 16s kicking about for new file formats in the latest Office versions.
Now we need to do some Registry editing, preferably on-the-fly. We need to remove and edit a bunch of HKLM entries before the user completes login, so you could use Group Policy Preferences, or a script, or Citrix WEM, or Ivanti DesktopNow or RES (which are now part of the same company, still not got used to that), or any one of a bunch of third -party tools. You could simply do it once to resolve, but in my experience this error has a habit of reappearing after a period of time, so best to keep it applied somehow.
Just for easiness, we will quickly run through how to do it in Group Policy Preferences. This will go in Computer | Preferences | Windows Settings | Registry. We will use the example above, so we are wanting to reset the settings for Excel.Sheet.12 and Word.RTF.8. Change the target Registry values and file paths as necessary for the problematic file type and application
Firstly you need to set up Delete rules as below. Delete these KEYS completely
and delete these VALUES (not the entire key as in the above two lines)
KEY HKLM\Software\Classes\Excel.Sheet.12\shell\open\command VALUE command
KEY HKLM\Software\Classes\Word.RTF.8\shell\open\command VALUE command
Then we need to Replace some settings within these keys as well. Set the (DEFAULT) value in these keys to that specified. The value needs to point at the right numerical path for the version of Office you’re opening the file type in – usually 2003 (11), 2007 (12), 2010 (14), 2013 (15) and 2016 (16). Note they missed out 13!
Key HKLM\Software\Classes\Excel.Sheet.12\shell\open\command VALUE (Default) DATA “C:\Program Files (x86)\Microsoft Office\Office14\EXCEL.EXE” “%1”
Key HKLM\Software\Classes\Word.RTF.8\shell\open\command VALUE (Default) DATA “C:\Program Files (x86)\Microsoft Office\Office12\WINWORD.EXE” “%1”
Just for posterity, here’s a list of the settings in the Group Policy Preference that would handle this. Don’t forget the two REPLACE actions in here are operating on the (DEFAULT) value, even though it appears as blank
Once you’ve got this in place, you should see that your problems opening certain file types from the Windows Explorer interface are gone forever. This can also occasionally manifest when trying to open links or attachments from email, so it does have the potential to be a pretty major pain in the proverbials. It’s easily enough worked around, but it’s not a great mitigation, and it really interrupts user experience and increases frustration.
More posts coming soon as we finish our adventures in Citrix Cloud Land – in fact, we might have a bit of a series on the go. Stay tuned.