Monthly Archives: February 2013

So today I get a ticket about a user being unable to open a Word document in a SharePoint library. When I go to investigate, I see there are around ten documents in there, and all but two of them open just fine in Word Web Apps for viewing. The other two documents return the following:

“Word Web App cannot open this document for viewing because of an unexpected error. To view this document, open it in Microsoft Word.”

I could edit both documents in the browser, and I could definitely open both in Word. But for some reason, viewing in the browser was a no-go.

I did some searching, and it seems like all the questions/answers around this problem focused on solutions that assumed that *all* Word documents in the SharePoint environment were behaving in this fashion. But in my case, it’s only a small number in a particular library and site.

I downloaded copies of the documents, and I was able to “fix” one by saving it as Word 97/2003 format, saving it again in Word 2010, and then uploading it. But the other was resisting all attempts to “fix” it. I say “fix” as I really don’t know what made those two documents any different than the others that worked fine. Nothing stood out, and my searching wasn’t turning up any answers.

I finally figured it was OK just to cheat for a solution… I created a blank Word document on my computer, gave it a slightly different name, copied the content from the “broken” document, and then saved/uploaded the new version to the library. Voilà… everything works, and the problem is “solved”.

Part of me feels bad for not finding an actual answer. But when you’re facing a continual flow of projects and questions, sometimes it’s easier (and more efficient) to just take the cheater’s way out.

Oh, but I still need to post it here, as I know by this time next month, I’ll be thinking “I remember seeing that error before, but what did I do to fix it…”

When the page being requested has never been published…

I’ve run into this twice in the last two weeks. Someone has a site page, and they’re trying to get it all pretty-fied for some go-live event. They set the default access to reader, and a smaller number of people to contribute. The contributors can see the person’s online work just fine. Yet, all the people who come in as readers get access denied.

In both of my cases, it was because the page destination in question had never been published to the site as a major version. Looking at the page history, it started as .1, and was up as high as .15, but never was there a 1.0 of the page. As such, people with read access were meant to revert back to viewing the last major published version. Except here… where there *was* no major version to revert to.

The answer was to have the page editor go ahead and publish something out there so that everyone would get the default level of access they should have. Then once they get the page finally cleaned up, they could then publish a major version (version 2.0) that everyone would start seeing.

The whole situation makes sense, once you figure it out. But if you’re simply looking at permissions (and even more so if you’re an admin and can see the draft pages with no issues), it take take a short while to finally figure out why the behavior of the page access seems a bit off.