When Troubleshooting Also Means Breaking Stuff


The following blog post described how I spent nearly 3 days trying to solve an issue I had with the Office Web Apps not wanting to work for Word and PowerPoint files.


I decided it was time to upgrade our SharePoint 2010 farm to Service Pack 1. While we were at it, I’ve also decided to roll out the Office Web Apps in order for our organization to leverage the Office Document Thumbnail feature in the Enterprise Search result page. The installation went smoothly, but the Office Web Apps gave us errors whenever we were trying to view a Word of PowerPoint file in Browser. Excel files were displayed without any problems, only .docx and pptx files weren’t working. Whenever we tried to open them, SharePoint would throw an exception with only “File Not Found” as a message. The ULS logs did not give me any more help, displaying the following error:

Cannot complete this action. Please try again.<nativehr>0x80004005</nativehr><nativestack></nativestack>


The exact same error was reproduced on our Production server copies in our Development, Integration, and Test environments. However, it was working fine on my developer’s machine, which led me to believe that a configuration setting on our production server was the source of the problem. I went and make sure that all the Services in Central Admin were correctly started, that the Service Applications were correctly started, and that the Office Web Apps feature was activated on my site collection. Still, nothing was working, and the same error persisted

I then went ahead and try to match every settings and permissions from my dev box onto our copy of the production server. I made sure the account running the app pool for the Word Viewing service was local admin, and part of the WSS_ADMIN_WPG local group. I compared every single setting for both app pools in IIS and both were the same. It seemed like no matter what I tried, I couldn’t get the other server to work like the other one.


Then this idea popped up in my head, what if instead of trying to make the server that had the error work like the other one, I tried to break the one that worked so that it gets the same error as the other one. I decided to start off by copying the faulty server’s web.config file onto the working server. There it was! On first attempt, I managed to get the working server to throw the same “File Not Found Error”, I had a culprit. After downloading WinMerge to compare the 2 web.config, I quickly identified the line that was different from the two machines:

<add name=”PointFire2010″ type=”PointFire2010.PFHttpModule, PointFire2010, Version=, Culture=neutral, PublicKeyToken=aa723fd590a9b1d4″ />

An entry for a custom component we use to do our translation, and handle other multilingual operations on our site. Removing that entry automatically solved the Office Web Apps problem, and documents started opening in the Browser!


Thanks to Todd Klindt (@ToddKlindt) for helping me out on his own time with this issue!


Official OWA Forum Thread – http://social.technet.microsoft.com/Forums/en-US/officewebappssetup/thread/2ba3e50d-9f9d-465a-a60c-4ec8237acbfd?prof=required

Todd’s Blog – http://toddklindt.com/blog

Leave a Reply

Your email address will not be published. Required fields are marked *