Sharepoint and Office Integration: Lets Remove It!

Sharepoint’s ability to work seamlessly with Office 2007 and newer can be a great feature – when it works. Click to download and open a Word document, edit then save directly back to the Sharepoint site or using the Explorer View to bulk move files are both examples of integration features that can boost productivity.

The problem is that it requires that the site and all users connecting are within the same domain, the Sharepoint site is added to Internet Properties –> Intranet Sites (Security group),  and all users access the site with Internet Explorer…oh and as noted above Office is 2007 or newer. Otherwise client integration just doesn’t work well or fails completely greatly reducing productivity and frustrating users (as well as those supporting them).

Our Sharepoint site needed to work similarly for a range of browsers (Firefox,Chrome,Safari) and the majority of our user are outside the local Intranet in a trusted domain(s).

Here are the steps I used to remove the integration features to get a more consistent experience for our users. Collaboration on documents requires a few more steps (add saving locally and then uploading) but it works…

Change #1:

Sharepoint Central Management –> Application Management –> Authentication Providers –> Enable Client Integration (No) edit client integration

Change #2:

Disable Edit in Office Application via changes in \Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\Template\Xml\Docicon.xml as outlined in KB912492

This should remove the “Edit in Word” “New Document” “Explorer View” and similar features related to Office Integration and Sharepoint.  Note: side issue that after doing the above or maybe any change I was getting a Time Job not clearing “Provisioning Web Application”. If I made a subsequent change Central Admin would throw an unfriendly error – even though the config change appeared to execute. Click the Time Job delete,TimerJob_stuck Might be specific to the fact that one of our WFE sites is offline or might be something else but appears minor.

Change #3:

Client Integration is also a permissions setting within Sharepoint access groups. Can’t be changed for “Full” access group but could be changed on a per group basis for others:edit permissions level client integration

Now all the extra Integration features are removed. No “Edit Document” etc…  but the simple click on document link is STILL trying to do the integration thing.

Change #4 from KB2019105 (near end of article):

Disable support of the OPTIONS and PROPFIND verbs –  For instance, to accomplish this with Windows SharePoint Services the site should be configured to not enable Client Integration and/or the OPTIONS and PROPFIND verb should be inhibited (on IIS6, remove the verbs from the <httpHandlers> registration line in the web.config file; on IIS7, use the HTTP Verbs tab of the Request Filtering feature to deny the verbs).

Another posts discussed the removing of OPTIONS and PROPFIND from web.config file but I was seeing no change in the integration behavior after doing these changes. That’s explained above – IIS7 you have to do this *ALSO* in a different place.

First check that “Request Filtering” is installed for IIS7…

Admin Tools –> Server Manager –> Roles –> IIS7

For me it was installed but I wasn’t finding it in the IIS7 Manager interface. The above link to www.iis.net help and give link to install an Administration Pack add-on to have the Request Filter module be visible. Install it from here: http://www.iis.net/download/AdministrationPackrequest_filter

request_filter_set

Whew! After adding the Deny Verbs for OPTIONS and PROPFIND looks like finally when a logged-in IE user on Sharepoint clicks a Word/Excel/Powerpoint file they are able to just open for viewing without extra prompts.

Interestingly I’ve tested re-enabling Client Integration for site but disabled for specific access groups and attempting this is basically a waste of time:

  • User Access Group disabled Client Integration: Click Document link and it just opens, Edit dropdown no “Edit Document” offered, no Explorer View. Exact behavior we want – nice.
  • User Access Group enabled Client Integration: Click Document link and prompted for Read or Edit – if you select Edit nothing happens, select Read and Word launches and prompt to login again. If Cancel then document never opens. Edit dropdown offers “Edit Document” but clicking does nothing. Explorer View offered but selecting just seem to create endless loop of communication between you and site. Basically a complete failure all around.
  • User Access Group enabled Client Integration and Site is added to your Intranet Security Group: Integration doesn’t fail to open documents but they are only opened locally not really as expected but not a failure either. Explorer View is a basic failure.

Revisiting this when I needed to re-enable some of the client integration so a user could use the Explorer View in a Document Library to upload a 1000 or so files. The Explorer View isn’t fast but lets you drag and drop between folders and creates subfolders as needed too. To re-enable I just reversed changes #1/#4.

Thanks to these references for help in successfully disabling client integration:

https://sharepoint.washington.edu/windows/Lists/Posts/Post.aspx?ID=44
http://blogs.objectsharp.com/CS/blogs/max/archive/2008/04/21/sharepoint-public-facing-website-and-microsoft-office-documents.aspx
http://support.microsoft.com/kb/899927
http://support.microsoft.com/kb/912492
http://support.microsoft.com/kb/2019105
http://www.iis.net/ConfigReference/system.webServer/security/requestFiltering
http://www.iis.net/download/AdministrationPack

5 thoughts on “Sharepoint and Office Integration: Lets Remove It!

  1. Leon

    All worked well on Employee site until IE10 snuck in. Then it all fell apart again and reverted back to asking for login again and now can’t open the document without righ click –> Save As…
    Any one else having issues with IE 10?

  2. David Grayston Post author

    @Leon – hard to say without knowing more of your setup. IE10 hasn’t been an issue for our Sharepoint sites. Also depends on which version of Sharepoint you are using – this is an old post and Sharepoint it a bit better about Client Integration in Sharepoint Foundation Services 2010. I’ve not yet had a chance to migrate to v2013 but we’re close do doing so.

    You might see if the behavior changes by adding the Sharepoint site to the list of Intranet sites.
    IE ->Tools -> Internet Options -> Security -> Local Intranet sites -> Advanced -> added the Sharepoint site. That might remove additional login prompts.

  3. Rob

    Hi,

    We have SP2010 with FBA implementation that we will share with external users. We dont want SharePoint to store the authentication/session (FEDAUTH) cookie as a persistent cookie on disk. The reason is our content is very private and cant have usage in airport public terminal that someone jumps on another session for example. We have shifted back to in memory cookies. The problem is that it breaks Office integration (which we can live with). But even when turn off client integration at server level – we cant open office docs from std sharepoint library view without a login control coming up. Have you ever seen this before? We are Office 2010 and SharePoint 2010.

    Many thanks… Rob

  4. Kathy

    We have an FBA site on the extranet. Client integration disabled on web app. Site Collections set to open in client. Libraries set to open in client. removed xlsx from excelservices mapping. Followed the instructions above and it seems to only work for Word and PowerPoint. xlsx and xls still display the additional prompt. Any suggestions?

  5. David Grayston Post author

    No reason that Excel is acting differently that I know of – should be same for any Office application. But these instructions are written for Sharepoint 2007 and may not fully work in Sharepoint 2010/2013. For my work now that I’ve upgraded to Sharepoint 2013 we have kept Integration turned on – Sharepoint seems slightly better when users are using other browsers or aren’t members of the local domain.

Comments are closed.