3

I would like to disable the "Open with Explorer" option in my SharePoint 2010 sites based on user permissions.

Basically only those users with Full Control should have the option of using the "Open with Explorer" feature. I ran across something that said OwE was dependant on the "Browse Directories" permission, but after disabling that permission for Contributers OwE was still working for them.

Is there a way to restrict the use of "Open with Explorer" with permissions?

Edit: This blog post has a detailed explanation of how to change the permission that Open with Explorer needs. This is pretty much exactly what I want, since I can reassign OwE to use a permission that only Owners have. So now I have a new question in addition to the previous one: Is making changes in the 14 hive like this safe enough to carry out on a production server?

Improve this question
3
  • 1
    Visit following area and see if there are any option. Central Admin site -> Manage Web Applications -> select the web application in which those two problematic document libraries reside -> click User Permissions on the ribbon -> ensure that the permissions “Use Remote Interfaces” & “Use Client Integration Features” are enabled.
    – Maria Burton
    Mar 20, 2012 at 14:03
  • Since I found the information that answered the question in the title I posted it below. If anyone can answer the question in my Edit asking if there's a safe way to make this change I will mark that as the answer for points.
    – newuser
    Mar 21, 2012 at 19:31
  • 1
    The problem with changing configuration files in the 14 hive is everytime you make a change in the Central Admin console those changes will be overwritten. If you won't be using the Console then no problems, just back up your files somewhere, but then if you do make changes you may lose something.
    – MichaelF
    Mar 21, 2012 at 20:29

4 Answers 4

Reset to default
3

First off: you really should create a new question!

Regarding your question, it is never a good idea to change "Microsoft" files. Every time you patch your farm you risk your customisation is overwritten, and usually this kind of customisations is unsupported.

You could use custom actions to remove the original link/button to open with explorer (much like described here for Open in Windows DataSheet View) instead though

Improve this answer
5
  • Yeah, it kind of took on a life of its own as I did my own research. I'll reorganize the questions if you really want me to. In regards to the link you posted, I don't want to remove the button for Open with Explorer entirely, I want users with Owner or Full Access to be able to use it. That is why the example you posted wouldn't satisfy what I need.
    – newuser
    Mar 21, 2012 at 20:41
  • 2
    you could set permissions on the new button/link you replace the existing with?
    – Anders Rask
    Mar 22, 2012 at 8:51
  • You mean disable the OOB OwE button and then create a new one that relies on a permission of my choosing? That would actually be perfect, and if I understand correctly both actions would be performed with farm features which means I wouldn't have to worry about my changes being overwritten by updates, right?
    – newuser
    Mar 22, 2012 at 12:41
  • 1
    thats it exactly :-)
    – Anders Rask
    Mar 23, 2012 at 8:15
  • Awesome. If you have an example question in mind could you please post a link which will cover creating a new button like that? I'll be in and out of meetings all day today and won't have a chance to do any research of my own, haha. If not, don't sweat it. Thanks!
    – newuser
    Mar 23, 2012 at 12:28
1

You can put in an audience targeted (permissions) script editor web part in your page. The script editor web part will be a css injection on the page. So you can find the css class that is responsible for the open with explorer button and apply the display none property to it.

Here is a a list of the css classes for the ribbon: http://sharepointexperience.com/csschart/csschart.html

Improve this answer
1
  • I just hid the whole Connect & Export on the views: <style type="text/css"> #Ribbon\.Library\.Actions { display: none !important; } </style>
    – Marker
    May 5, 2017 at 17:31
0

Since I framed the question this way, the answer is that the button in the Library ribbon for "Open with Explorer" is dependent on the permission:

Use Client Integration Features
Use features which launch client applications. Without this permission, users will have to work on documents locally and upload their changes.

The file C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\CONTROLTEMPLATES\DefaultTemplates.ascx contains the information which indicates what permission that button needs in order to be active.

I found this out by reading this blog post.

Improve this answer
8
  • Ok, that is using a sledgehammer to kill a fly, it seems to me that blog post went about things the wrong way when you can set things up so that users can see only the items they create. What we really need to know is WHY are you even trying to do this? Basically what you are suggesting would disable Dav for these users. Office integration goes out the window for these users AT THE SITE COLLECTION LEVEL! What you are suggesting would not allow them to open a document in Excel or word and save it directly to the library. This will cripple SharePoint for these users.
    – Robert Kaucher
    Mar 21, 2012 at 20:35
  • So again, why do you want to do this?
    – Robert Kaucher
    Mar 21, 2012 at 20:36
  • I don't think you read my question very well. My first sentence states that I want to control who can use the Open with Explorer button based on permissions. The steps outlined in the blog post I linked do not remove user's permissions, they simply tell the Open with Explorer button to check for a different permission that only Owner and Full Access users have by default.
    – newuser
    Mar 21, 2012 at 20:44
  • I don't think you understood what I was asking. You keep talking about what you want to do, not why you want to do it. Why do you want to control this permission?
    – Robert Kaucher
    Mar 21, 2012 at 20:55
  • 2
    Robert, in general we try to stick to the topic of the question rather than debating the broader reasoning behind the requirement, which in any case the original poster might not be able to share. On the other hand, if you have a better solution to his problem please feel free to post another answer. Thanks.
    – SPDoctor
    Mar 21, 2012 at 22:37
0

I have made my case that your proposed solution of disabling Client Integration is too heavy handed. I will make a few suggestions for you that you may consider to mitigate the chance of accidental deletion. In my company's sites we have a policy that only site owners have delete permissions. Other people who need contribute permissions are granted a special "contribute-no delete" permission set. We do have a few lists and libraries that are mission critical where the owners have requested that we put a policy to prevent accidental deletion. To do this we created a check box column called "Allow Delete" and attached an event receiver that specifically checks that the field is checked before allowing deletion. This field is hidden in all the views except for a special one called "Delete Items". The site owners then have to take three steps to deliberately delete items. The have to select the view, check the "allow delete" field save the changes to the field (inline editing is enabled) and then select the items and delete them.

I promise you that if you disable Client Integration on an entire site collection you will drive down user acceptance and users will find ways around using SharePoint. If you do not feel comfortable with implementing any of these suggestions I would be more than willing to give you a hand to the best of my ability.

Improve this answer
3
  • My only question about the method you've suggested is what if a user without delete rights clicks the OwE button and then tries to delete a file? Does SP block the delete even though the folder is being viewed in explorer? And changing the permission that OwE requires does not involve disabling Client Integration, which is what I was trying to get at before. I tested the steps at the link I provided earlier and UseClientIntegration remained active for all users who had it previously, but the button for Open with Explorer was greyed out for everyone except for Owner and Full Access users.
    – newuser
    Mar 22, 2012 at 12:39
  • If that is true then it seems you have found a solution. The implication of your own answer though is that you are revoking the Use Client Integration Features rights. Which is crazy. I still believe that what you really need to do is set permissions properly. If a user cannot delete something in the SharePoint interface they cannot delete it via Explorer view. In addition to permissions there are the recycle bins. If I delete an item via Explorer View it does go to the site recycle bin from where it can easily be restored.
    – Robert Kaucher
    Mar 22, 2012 at 13:18
  • 1
    Even if a user then deletes it from that recycle bin there is another recycle bin that admins can use to restore the files. Hiding a legitimately useful feature from users is no replacement for proper systems administration.
    – Robert Kaucher
    Mar 22, 2012 at 13:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.