Overview and background
This post is intended to show and explain why you see the intermittent (and annoying) “To start seeing previews, please log on by opening the document.” message when using previews from Office Web Apps Server 2013 (WAC) with SharePoint 2013. Unfortunately I do not have the magic bullet (yet) on how to solve it completely, this post is more on why you get it and how you can avoid seeing it too often.
SharePoint 2013 allows you to view and edit Office documents in the browser using the Office Web Apps Server 2013. You also have the benefit that you can see previews of these documents in for instance Document Libraries and Search Results. Sometimes, in some farms more than others, the end users get a message that says “To start seeing previews, please log on by opening the document.”. Most often you resolve the issue by clicking on the link in the message – but this is not a waterproof solution.
Why this message?
First of all I need to say – the message have nothing to do with Office Web Apps Server 2013, it’s a SharePoint 2013 implementation issue, and there are two major reasons why this can happen. The message can only happen in these previews (InteractivePreview in WOPI speak) – and if you pay extra attention to the link in the message you will see that the link takes you to another display mode – the view mode (View in WOPI).
This is the URL that shows the message:
https://team.contoso.com/_layouts/15/WopiFrame.aspx?sourcedoc=%2FDocuments%2Ftest%2Edocx&action=interactivepreview&wdSmallView=1
This is the URL in the link:
https://team.contoso.com/_layouts/15/WopiFrame.aspx?sourcedoc=%2FDocuments%2Ftest%2Edocx&action=View&wdSmallView=1
Anonymous Access enabled on the Web Application
The first reason for this to happen is when you have enable Anonymous Access on the Web Application that hosts the document AND that the current site has not enabled any anonymous access (AnonymousState on the SPWeb is set to Disabled) . This is a hardcoded setting and you cannot work around it. I don’t have the whole background to it, but I do think it’s a security measure to prohibit anonymous users accessing content they should not have access to. One of the reasons behind this thinking is that the WopiFrame.aspx page is actually inheriting from the UnsecuredLayoutsPageBase – a specific class used for Layout/Application pages that does not need any authentication. This of course is a requirement if you would like to show previews on an anonymous site. Unfortunately this issue hits you if you have the need to have something partly anonymous and partly authenticated such as in an extranet.
The user is not authenticated!
The second, and by far most common, issue is that the message very randomly appears. SharePoint 2013 has hardcoded the logic, so that if you are not authenticated you should of course see this message – nothing wrong with that. The problem is that we’re using the WopiFrame.aspx page – which can accept anonymous requests.
Since we’re using Claims Mode authentication for the Web Application (a requirement for WAC) the end users will eventually be un-authenticated when their tokens time out and they need to re-authenticate. The WopiFrame.aspx will not do that for us – it will just say sorry you’re anonymous and show the message.
Note: A non functional Distributed Cache or not using session affinity can make this problem worse, making the message appear more frequently.
And now we come to something that I find very peculiar. There is actually another layouts page – the WopiFrame2.aspx file. This one inherits from the LayoutsPageBase which will force us to authenticate and at least check that the user has view and open permissions on the site. This page is not used at all (except in one specific case where the user is not authenticated as above, we’re in interactive preview mode, there is no HTTP context and/or some other crazy stuff – basically you’re not hitting it).
It’s not much we can do about this either – I think it is partly a logic problem in the SharePoint code base and partly a result of the nature of Claims authentication.
Summary
Unfortunately there is not much we can do about this problem at present, and I do hope that something with that logic could be improved in future releases of SharePoint (I tested it with 2013 June CU this time). The best option would be to always use WopiFrame2.aspx when Anonymous Access is not enabled – but that is just my thought…
If anyone on the SharePoint Team responsible for the WOPI stuff could chime in I would appreciate it.