Users of Office 2007 or Office 2010 on any client Operating System click a hyperlink that points to an Office document which is located in a SharePoint Server 2010 document library. The hyperlink itself is located in an Outlook email message. Instead of opening the document from the server in the Office client application, the document opens in the Office application from the Temporary Internet Files cache of the local machine. Therefore it is not treated as a server document. The following symptoms are seen by the user:
Word: There is no server bar with an "Edit Document" button
Excel: There is no server bar with an "Edit Workbook" button
PowerPoint: There is no server bar with an "Edit Presentation" button
Or, if the document library requires a check out:
Word: there is no server bar with a "Check out Document" button
Excel: There is no server bar with a "Check out Workbook" button
PowerPoint: There is no server bar with a "Check out Presentation" button
Additionally, the document cannot be saved back to the SharePoint site while it is open in the Office application. Users may be able to save changes, but the changes are being saved to the file in the Temporary Internet Files folder, not back to the SharePoint server.
Also, if the document is part of a workflow, the Edit this Task or Open this Task buttons and any other buttons associated with the workflow will be missing, causing the workflow not to be started. Typically users will receive workflow tasks in email and the email will contain a hyperlink to the document located on the SharePoint server.
This only occurs with the newer Office file formats: .docx, .pptx and .xlsx. It does not occur with the older, legacy Office file formats: .doc, .ppt and .xls. In addition, this only occurs when:
The server is a SharePoint server 2010 and
When the client computer is running Office 2007, the problem occurs with .docx, .dotx, .xlsx and .pptx documents or
When the client computer is running Office 2010, the problem occurs with .pptx documents.
This issue does not occur when the server is running Office SharePoint Server 2007 and the client computer is running Office 2007 or Office 2010.
NOTE: This only happens when opening the Office document BY CLICKING ON A HYPERLINK in an Outlook email message and the Office document is located in a SharePoint 2010 document library. If the user browses to the SharePoint 2010 document library and opens the file from there, this issue does not occur.
SharePoint 2010 implements a new security feature called 'Permissive or Strict browser file handling'. Each type of file delivered from a web server has an associated MIME type (also called a “content-type”) that describes the nature of the content (e.g. image, text, application, etc). Internet Explorer (IE) has a MIME-sniffing feature that will attempt to determine the content-type for each downloaded resource. For Office files, if the Content-Type sent by the server is not found in the MIME database in the registry of the client machine, IE "sniffs" the MIME content types to see if there is another similar MIME type in the client machine's MIME database and will open the file using the similar MIME type. However, Strict browser file handling is enabled on each web application in SharePoint 2010 by default and this disallows the sniffing of Content-Types, so if no exact match of the Content-Type sent in the server response is found in the client's MIME database in the registry, the file will open from the Temporary Internet Files of the client machine instead of being opened from the server. MIME-sniffing also can lead to security problems for servers hosting untrusted content. For example: When opening a .docx file from a hyperlink that points to a document located in a SharePoint 2010 document library, the Content Type sent by the SharePoint 2010 server in the response is "vnd.ms-word.document.12" along with a header "X-Content-Type-Options: nosniff" which looks like this:
HTTP/1.1 200 OK Content-Length: 108 Date: Day, [Date and Time] GMT Content-Type: vnd.ms-word.document.12 X-Content-Type-Options: nosniff
Since this exact content type is not present in the MIME area of the registry of the Office client computer and no MIME sniffing will be done, the document opens from the Temporary Internet files.
There may be other causes mentioned below in the More Information section.
Use one of the following solutions:
Eliminate the no-sniff header sent from SharePoint 2010
Browse to the Central Administration site, click Manage Web Applications under Application Management.
Select the web application and click onGeneral Settings from the ribbon
Scroll down to Browser File Handling, and choose Permissive instead of Strict.
NOTE: This reduces security. Browser File Handling specifies whether additional security headers are added to documents served to web browsers. These headers specify that a browser should show a download prompt for certain types of files (for example, .html) and to use the server’s specified MIME type for other types of files. "Permissive" specifies no headers are added, which provides a more compatible user experience. "Strict" adds headers that force the browser to download certain types of files. The forced download improves security for the server by disallowing the automatic execution of Web content that contributors upload.
Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
322756 How to back up and restore the registry in Windows.
Update the registry of the Office client computer to install the needed content types into the MIME database of the registry by using one of the following two methods. This registry update works on either Office 2007 or Office 2010.
To update the registry manually, copy the following to a text file, name it with a .reg extension and run it.
The Server read-only bar with the [Edit Document] or [Edit Workbook] or [Edit Presentation] button bar may be missing for other reasons when clicking on a hyperlink to a Office 2010 document stored on a SharePoint site for the first time. Subsequent clicks on the link will render the Server read-only bar.
To force the Server read-only bar to show on first click of the hyperlink, add the below registry key to the client machine.
If the the Server bar still does not appear with the [Edit Document] button even after the OptimisticBHO key is enabled, make sure that the "Office Document Cache Handler" Addon is Enabled in Internet Explorer's Tools>Manage Addons.
fixit fix it fixme; server read-only bar; server message bar; Office documents