Hide the Windows Explorer Button in SharePoint Libraries

 

Tested in SharePoint 2013, 2016 and SharePoint Online.

 

The Windows Explorer view of a SharePoint library has so many issues that I'm often asked to hide it. Turns out that this is pretty easy to do. Two solutions:

• Create a SharePoint Feature and deploy it to the desired site collections.
• Add CSS to your master page, or to selected view pages.

 

Create a SharePoint Feature and deploy it to the desired site collections

This is the best solution! And it's been documented elsewhere: https://blogs.msdn.microsoft.com/tejasr/2010/07/19/how-to-remove-open-with-windows-explorer-button-from-document-librarys-ribbon-menu/

I would only add one more step to this solution… make sure the WSP file does not include an unneeded DLL so the solution can be deployed to SharePoint Online. (No code allowed!) The one extra step: In the project's Properties panel click "Include Assembly in Package" and change it to False.

Once the Feature has been installed in the Site Collection, just visit each subsite and activate the feature. This will impact all libraries in the site.

 

Add CSS to your master page, or to selected view pages

Add one little piece of CSS to your master page, or open SharePoint Designer and edit the library's views to add a CSS block and the button will disappear. If added to the master page then this will impact every library in the site. If added to a view page, then it will impact only that view.

This CSS will not work with the SharePoint Online “New Library Experience”. But then the new “experience” does not currently include a link for Windows Explorer!

The CSS:

<style type="text/css">
  #Ribbon\.Library\.Actions\.OpenWithExplorer-Small {
    display: none;
  }
</style>

Note: The backslashes have been added to the ID due to the non-standard naming convention that uses periods.

If you would like site owners to still be able to see the button then wrap additional CSS in a SharePoint:SecurityTrimmedControl. Note that this control can only be added directly to a page, typically using SharePoint Designer. It will not work if added to a Content Editor Web Part.

<style type="text/css">
  #Ribbon\.Library\.Actions\.OpenWithExplorer-Small {
    display: none;
  }
</style>
<Sharepoint:SPSecurityTrimmedControl runat="server" PermissionsString="ManageWeb">
  <style type="text/css">
    #Ribbon\.Library\.Actions\.OpenWithExplorer-Small {
      display: inline;
    }
  </style>
</SharePoint:SPSecurityTrimmedControl>

 

.

SharePoint Folders Are Not EVIL!

 

It seems that everyday I run across another blog article, forum post or social media that says “Never Use Folders!” While one of the common analogies for SharePoint is the Swiss Army Knife, a better one might be a tool box, and one with a lot of tools. Saying “Never Use Folders” is kind of like saying never use an adjustable wrench because we have box wrenches. Tools are tools and you need to select the correct tool for the job.

The following is not an excuse to not create a formal taxonomy and use a pure metadata approach to content management. It is a description of one of your many SharePoint tools in your toolbox. Remember everything is not a nail, and your only tool is not just a hammer.

 

Sometimes You Just Can’t Afford Metadata

Not an excuse so much as a reality.

You just built your new SharePoint farm. You have hundreds of thousands of documents to migrate to SharePoint. Who’s going to add all of the metadata? You employees (in their free time?), summer interns, contractors?

If you maintain the folder structure during your migration from network shares then your users can still find content as they always have. And, when you have added all of your metadata you can then either hide the old folders in your views, or move the content into one giant folderless library.

 

Folders are metadata!

In fact, Folders are “instant metadata”. Just upload or drag the document to the right folder and everyone will know something about it. If it’s in the folder named “Chlamydoselachidae” then it must be something about “Frill Sharks”!

(I’ll give anybody at Microsoft a couple of dollars if they will add the folder name property to the available columns in a view. It would then be true metadata!)

Folders can have custom metadata

A folder is a Content Type. You can create new Content Types that inherit from Folder and then add metadata columns. While a search on the metadata does not return the files in the folder, it will return the folders.

Here’s an article I wrote back in 2007 that still applies to SharePoint 2010, 2013 and 2016: http://techtrainingnotes.blogspot.com/2007/08/sharepoint-how-to-create-links-from.html

  

  

  

 

Want really smart folders with metadata that shares their metadata with their contents?

Take a look at Document Sets. Not the out of the box example, but rather a custom one that you create by inheriting from the Document Set Content Type. If you add a Site Column named “Product Category” then every document in that Folder / Document Set will be findable from search on that property. If you move a document from one Document Set to another Document Set, the document’s inherited metadata is updated to match!

https://technet.microsoft.com/en-us/library/ff603637.aspx

https://support.office.com/en-us/article/Introduction-to-Document-Sets-C49C246D-31F1-4BFE-AFE2-E26698B47E05

https://support.office.com/en-us/article/Create-and-configure-a-new-Document-Set-content-type-9DB6D6DC-C23A-4DCD-A359-3E4BBBC47FC1

 

Folders can be nested more than two levels deep

Using views and metadata you can create two levels of grouping. If you have SharePoint 2007 or 2010, you can use SharePoint Designer to create views that are up to 16 levels deep. But for SharePoint 2013 and 2016 they have changed (broken) SharePoint Designer so you can only group deeper than two levels by hand crafting XLST and HTML.

You can nest folders as much as needed, up to the maximum URL limits of Path to Library + Folders + Filename.

 

Folders are ideal for a rigid taxonomy

If the primary way of accessing content is by a single hierarchy then a folder structure may be the better choice. While still limited to the maximum length of a URL, it clearly supports more than the two levels offered by a grouped view.

  

Want a full crumb trail like we had in SharePoint 2007? See here: http://techtrainingnotes.blogspot.com/2015/11/add-crumb-trail-to-sharepoint-2013.html

 

Folders can be navigated using a Tree View

There are actually two tree views available, one out of the box, and one that is hidden.

The Quick Launch Tree View (Settings, Site Settings, Navigation Elements):

  

The hidden SharePoint 2010 “Navigate Up” button:

(See: http://techtrainingnotes.blogspot.com/2014/06/sharepoint-2013-restoring-2010-navigate.html)

  

Note: Currently neither Tree View is available in the “new library experience” for SharePoint Online, and one day for SharePoint 2016 on premises.

 

Metadata is not always searchable as a property

Unless you have created Site Columns, and configured them as friendly search Managed Properties, then as far as seach is concerned, all of those columns of metadata might have just been typed into a single “Keywords” column.

 

Search Likes Folders

Search includes several managed properties to make finding folders and content in folders easy to do. Unlike Site Columns, these folder properties do not require any Search Service setup to work.

Path:    path:https://yourServer/sites/site/library/folder
            path:"https://yourserver/sites/taxonomy/Fish/Agnatha and Lampreys/Myxini/Myxiniformes"

Searching with Path works, and is very precise, and returns all of the content in that path. The negative is typing the full path to the folder.

contenttype:folder     contenttype:folder Myxiniformes

contenttype finds all folders and all content types that inherit from Folder. (This will also return folders that have a column with the keywords being searched. In the example above you will get folders with “Myxiniformes” in the folder name and folders with a column with “Myxiniformes” in its name.)

IsContainer:true        IsContainer:true Myxiniformes

IsContainer returns Sites, Libraries and Folders that have the keyword in their name or metadata. IsContainer also returns Team Site Notebooks (OneNote files) and content stored in Asset libraries (The thing you click on in an Asset library is a folder, not the actual picture or video.) as they are represented as folders.

Library search box

The search box at the top of each library assumes you only want to search the content in the current folder! (You can then click “Some files might be hidden. Include these in your search” to search the rest of the library.)

  

 

Microsoft / SharePoint Really Likes Folders!

Take a look at OneDrive for Business… you can’t even add metadata columns or use Content Types. “Name”, “Modified”, “Modified by”, “File Size” and “Sharing” are all you get. The only “metadata” I can add is by using folders.

   
    (Yes, I really have a folder named “junk”!)

In my OneDrive I have to embed metadata in the filename and/or the folder structure. Kind of like network shares!

   

 

The New Library Experience likes folders!

The new library experience in Office 365 makes it easy to arrange and rearrange documents by folder. (Seems to encourage the use of folders!)

   

 

Sync Only Sync’s Folders

All three of the sync clients only sync folder structure, not metadata. If you want any obvious classification of your local sync of the content then you have to use folders. The only metadata you can add from client side is in the filename and the location/folder.

 

Security and Folders

Remember when Microsoft’ advise was to never use item level permissions? At least until SharePoint 2013 where they gave everybody a “Share” button. Now SharePoint 2013 and 2016 encourage users to break inheritance everywhere!

See here for what can happen with unlimited use of the Share buttons: http://techtrainingnotes.blogspot.com/2015/10/trick-or-treat-day-in-life-of.html

For a simple example consider:

1. We create a site for Sales Managers. We create a library for their files.
2. The sales managers start clicking the Share links on various documents, most to share with the “Summer Interns” group and the “Marketing Team” group. Over time there are 500 items with broken inheritance.
3. Management asks you to add Regional Sales Managers to the site, with their own group.
4. You create a SharePoint group and add the Sales Managers and grant it access to the site.
5. The Regional Managers visit the site and complain that they can’t find all of the files the Sales Managers have told them about.
6. You now have to:
   1. Find the 500 files with broken inheritance.
   2. Grant permissions to each of the files to the Regional Managers group.

So what can you do? Use folders for permissions.

1. Create the library.
2. Add a folder for “Everyone”. (Optional as the files in the root of the library will be available to everyone by default.)
3. Add a folder for “Sales Managers Only”. Break inheritance and grant permissions to the Sales Managers group.
4. Add a folder for “Visible to Marketing Team”. Break inheritance and grant permissions to the Sales Managers group and to the Marketing Team group.
5. Add a folder for “Visible to Interns”. Break inheritance and grant permissions to the Sales Managers group and to the Interns group.
6. Create a new view named “Sales Files”:
   1. Make it the default view.
   2. In the Folders section hide the folders.

Users will now see a single list of content, which can also be grouped using metadata, but they will only be able to see the content they should see. The users who maintain the content use the AllItems view so they can quickly upload documents into the correct folder, and automatically apply the correct permissions. (Now all you have to do is hide those pesky Share buttons! http://techtrainingnotes.blogspot.com/2015/08/hiding-evil-sharepoint-2013-share.html)

 

So which should you use?
  Folders or
    Metadata+Views or
      Folders+Metadata+Views?

Use the best tool for the job!

 

.

SharePoint 2013 and SharePoint Online Built-In Accounts

 

I’m often chasing one SharePoint rabbit or another down a rabbit hole and spending hours there when I only wanted to ask the rabbit one simple question. In this case the question was who is “Everyone” and are they related to “NT AUTHORITY\Authenticated Users”. A simple question, or so I had thought. In this rabbit hole I found all kinds of interesting accounts, so I thought that I’d take a few notes while I was there. As to “Everyone”, I’ll follow up with another blog article. I also got distracted by two Office 365 users hanging around the hole named “Guest Contributor” and “Guest Reader” that will also get their own article.

If you would like to dive into the rabbit hole, here’s a few tools to investigate user accounts:

• PowerShell on prem: 
  $site = Get-SPSite http://yourDomain/sites/yourSite
  $site2.RootWeb.AllUsers | FT –AutoSize
• PowerShell for Office 365:
  Get-SPOUser -Site http://yourDomain/sites/yourSite | Select DisplayName, LoginName
• In the browser:
  • Go to Settings (gear), Site Settings, People and Groups
  • Edit the URL and change the GroupId to 0    (“?MembershipGroupId=0”)
  • Click any interesting user name. If the user has a User Profile you will probably be redirected to their profile page. If not, you will be redirected to userdisp.aspx where you can see the user name and their internal Account property as listed in the table below.
• Third party security and auditing tools.

 

Claims Based Authentication

SharePoint 2013 and later uses Claims Based Authentication which can support more than one authentication source. This slightly complicates the UserLogin property as it must have both the user name and the claims source data in the property value. In a non-Claims system the user name might be as simple as contoso\msmith. In a Claims system you need to know where the user was authenticated, so you end up with UserLogins that might look like i:0#.w|contoso\msmith for a Windows AD user or i:0#.f|ContosoFBA|susan for a Forms Based Authentication user.

If you would like to learn more about the Claims identity codes (“c:0!.s”, etc.) see: http://social.technet.microsoft.com/wiki/contents/articles/13921.sharepoint-2013-claims-encoding-also-valuable-for-sharepoint-2010.aspx
and
http://www.wictorwilen.se/Post/How-Claims-encoding-works-in-SharePoint-2010.aspx

 

The Users

Who are all of these users? Well… I’m still negotiating with the rabbit for more details, but I’ll soon add these articles with what I have discovered:

• SharePoint: All Users vs. Everyone vs. Everyone But External vs. NT AUTHORITY\AUTHENTICATED USERS
• SharePoint Online “Guest Contributor” and “Guest Reader” - Who’s Guest Contributor,
  and what are they doing in my library?
• SharePoint internal and hidden accounts hiding in your Site Collection

For now:

• NT AUTHORITY\AUTHENTICATED USERS represents all of the users in your Active Directory, on prem or in the cloud.
• Everyone at the AD level is NT AUTHORITY\AUTHENTICATED USERS plus the Guest account. The Guest is disabled both by default and as a best practice. (You don’t see this one in SharePoint, but it is often listed as being the same as the SharePoint “Everyone”.)
• Everyone is defined at the SharePoint level and includes all users authenticated to SharePoint.
• Everyone except external users is found in SharePoint Online / Office 365 and is as named. External users are people not in your Active Directory, most likely not employees, who got their access from site members clicking the SHARE buttons.
• All Users (<somename>) is SharePoint defined and represents all of the users from a selected authentication provider. (If I created a Forms Based Authentication provider named “Vendors” then I would have “Everyone (Vendors)”
• All Users (windows) is SharePoint defined and is same as NT AUTHORITY\AUTHENTICATED USERS. After adding “All Users (windows)” to a site it is displayed as “All Users (windows)” in 2013 on prem and 2016 on prem, but is displayed as NT AUTHORITY\AUTHENTICATED USERS in Office 365.
• Guest Contributor and Guest Reader are at this time only found in SharePoint Online / Office 365 and represent users with anonymous / link access.

 

Best Practices

I was reviewing some training materials recently and ran across a statement to the effect you should put NT AUTHORITY\AUTHENTICATED USERS in all of your site Visitors groups so everyone can find content in SharePoint. Should you do this? Should everything in your SharePoint be freely accessible to everyone who can logon to your network? Contractors, vendors, summer co-ops, part timers? If you don’t already have a policy or governance on this, then you should be working on it.

SharePoint does not give us any way to prevent the use of the “Everyone” accounts, so you will need to deal with this through education and auditing.

UPDATE! Anders Rask responded to this post with info about a SharePoint Online cmdlet that can hide these “everyone” options in the people pickers. Turns out there are three options:

Set-SPOTenant -ShowEveryoneClaim $false
Set-SPOTenant -ShowEveryoneExceptExternalUsersClaim $false
Set-SPOTenant -ShowAllUsersClaim $false

The Set-SPOTenant cmdlet: https://technet.microsoft.com/en-us/library/fp161390.aspx 
Blog: https://blogs.office.com/2015/07/16/new-it-management-controls-added-to-onedrive-for-business/

 

Here’s a short list of best practices. The term “everyone” used here includes NT AUTHORITY\AUTHENTICATED USERS and any account that starts with “Everyone” or “All Users”.

• Educate your users on security, including the use of the “everyone” accounts.
• Do not use “everyone” accounts if a site contains non-public data.
• Document who “everyone” is. There’s more than one “everyone” group in SharePoint.
• Perform regular audits using PowerShell or 3rd party tools to track the usage of “everyone” groups.
• Document, audit and enforce your SharePoint content policies. Document what is allowed, and what is not allowed to be stored in SharePoint.
• If you do encourage the use of the “everyone” groups, add a banner to the top of every page that declares “Do not post confidential data in this SharePoint site! It can be seen by everyone with network access.”

 

The Built-In Accounts

While your SharePoint may vary… see the Notes column… here’s a list of the accounts that may include users other than those who you were expecting. This is not complete, so if you discover others please post a comment to this article.

DisplayName	UserLogin or SystemUserKeyProperty	Notes
All Users (membership)	c:0!.s|forms%3amembership	Only O365
All Users (windows)	c:0!.s|windows	Same as NT AUTHORITY\ authenticated users
All Users (yourFBAMembershipProviderName)	c:0!.s|forms%3aYourFBAMembershipProviderName	Form Based Authentication
Everyone	c:0(.s|true
Everyone except external users	c:0-.f|rolemanager|spo-grid-all-users/17b83262-5265-…	Only O365 (ID will vary)
NT AUTHORITY\ authenticated users	c:0!.s|windows
Guest Contributor	SHAREPOINT\writer_9e8a77849f89425c9cff6a6af5175…	ID varies with share
Guest Reader	SHAREPOINT\reader_cb6f6371456b4542ba0609638a4…
_SPOCacheFull	ylo001\_spocachefull	Only O365. Visible only from PowerShell
_SPOCacheRead	ylo001\_spocacheread	Only O365. Visible only from PowerShell
_spocrawler_17_3910	ylo001\_spocrawler_17_3910	Only O365 (ID will vary)
System Account	SHAREPOINT\system	Visible only from PowerShell
System Account	S-1-0-0	SystemUserKeyProperty
Company Administrator	s-1-5-21-1851826741-1401831065-3463747319-87287…	Only O365 (ID will vary)
Typical user (Sam Conklin)	samc@yourDomain.onmicrosoft.com	As seen in O365 PowerShell
Typical user (Sam Conklin)	i:0#.w|yourDomain\samc	As seen in On Prem PowerShell
Typical user (Sam Conklin)	i:0).w|s-1-5-21-2499188511-2905385804-3446143336-…	SystemUserKeyProperty
Typical FBA user (Susan)	i:0#.f|YourFBAMembershipProviderName|susan	Form Based Authentication

.

SharePoint PowerShell Training for Auditing and Site Content Administration

 

If you have followed this blog, you know that I’m kind of a SharePoint nut who’s also a PowerShell nut. Over the years I have created a lot of PowerShell scripts while working with SharePoint and answering questions in my classes and in the TechNet forums. There’s plenty of resources for installing and configuring SharePoint using PowerShell, but there’s little on dealing with all of the daily questions on premise admins get that can be quickly answered using PowerShell. I was just going to take my 100+ scripts and create something like a “cookbook”, but instead created a class. The class handout kind of ended up as the cookbook… 85 pages and 175 sample scripts, or maybe more like a giant PowerShell cheatsheet for SharePoint.

This class is for on-premise SharePoint 2010, 2013 and 2016 administrators. A SharePoint Online version is in the works, but not available yet.

If you would like to attend this class, delivered by the author (your’s turely!), we are offering it next Monday, March 14th, at MAX Technical Training in Cincinnati, Ohio. You can attend this class at MAX or remotely from anywhere. If you can’t attend this class, it is available from trainging centers all over the world.

March 14th class at MAX: SharePoint 2010 and 2013 Auditing and Site Content Administration using PowerShell

Search for this class at other training centers: https://www.bing.com/search?q=55095%20powershell

If you would like to see some of the other courses and books I’ve written, then click here.

 

55095 SharePoint 2010 and 2013 Auditing and Site Content Administration using PowerShell

This one day instructor-led class is designed for SharePoint 2010 and 2013 server administrators and auditors who need to query just about anything in SharePoint. The class handout is effectively a cheat sheet with over 175 PowerShell scripts plus the general patterns to create your own scripts. These scripts cover:

• using the SharePoint Management Shell and the ISE
• general tips for counting, reformatting and exporting results;
• drilling up and down the SharePoint object model
• getting lists / inventories of servers, services web applications, sites, webs, lists, libraries, items, fields, content types, users and much more
• finding lists by template type, content type and types of content
• finding files by user, content type, file extension, checked out status, size and age
• finding inactive sites
• finding and changing SharePoint Designer settings and finding and resetting customized pages
• inventorying and managing features
• deleting and recycling files and list items
• inventorying users and user permissions and finding out “who can access what”
• creating sites, lists and libraries
• uploading and downloading files
• and much more…

At Course Completion

After completing this course, students will be able to:

• Use PowerShell to query just about anything inside of SharePoint.
• Understand the core SharePoint object model and object hierarchy as seen from PowerShell.
• Format PowerShell output in to reports.
• Manage resources to limit the impact on production servers.
• Create and delete Site Collections, subsites, lists, libraries and content.

Prerequisites

Before attending this course, students must:

• Very good knowledge of SharePoint and its features.
• Good experience using PowerShell 2 or later or recent completion of a PowerShell class such as 10961 or 50414.

Course Outline

Module 1:  SharePoint and PowerShell

This module provides an introduction to the topics covered in the class, introduces SharePoint PowerShell terminology and provides a review of important PowerShell features.

Lessons:

• History of PowerShell in SharePoint
• PowerShell vs. Search
• PowerShell, SharePoint Management Shell and cmdlets
• Security and Permissions Needed
• Getting Started with PowerShell: Counting Items, Custom Columns, Reformatting Numbers, Saving Results to a File
• Changing and Updating Content: Creating SharePoint Objects, Changing Objects

Lab:

• Using PowerShell with SharePoint

After completing this module, students will be able to:

• Get started using PowerShell to inventory and update SharePoint.

Module 2: Working with SharePoint CMDLETs and Objects

This module introduces the SharePoint object model and some important terminology.

Lessons:

• GUIDs
• Sites vs. Webs
• The SharePoint Object Hierarchy

Lab:

• Get a list of all Site Collections and their GUIDs
• Get a list of all Webs in all Site Collections
• Given a web’s URL get its parent web and web application

After completing this module, students will be able to:

• Explore sites and webs using PowerShell.
• Retrieve important properties of common SharePoint objects

Module 3: Managing Memory and Limiting Performance Impact

This explores limiting impact on server memory usage and performance.

Lessons:

• Memory Management and Disposing Objects
• Limiting Impact on Production Servers

Lab:

• Exploring PowerShell’s use of system memory.
• Testing the impact of scripts on server performance

After completing this module, students will be able to:

• Recognize and manage the impact of PowerShell on a SharePoint server.

Module 4: Working with Content

This module explores SharePoint using PowerShell from the Farm down to individual list items.

Lessons:

• Getting Farm Information: version, services, services, features
• Getting Web Application information
• Exploring Site Collections: retrieve Site Collections, Site Collection Administrators, quotas
• Working with the Recycle Bins: finding items, getting file counts and bytes, deleted sites
• Exploring Webs: web templates, finding webs, finding webs based on template, Quick Launch and Top Link Bar navigation
• Exploring Lists and Libraries: finding all lists, lists by type, lists by Content Type, columns/fields, document count by web or library
• Exploring Content Types
• Finding documents: by a word in the title, file type, content type, size, date age, checked out status, approval status and many more…
• Deleting content
• Downloading and uploading files

Lab:

• Explore the farm.
• Inventory site collections.
• Create a recycle bin report.
• Finding all blog sites.
• Find all picture libraries.
• Find all PDF files over 5 MB.
• Delete all videos in a site collection.

After completing this module, students will be able to:

• Explorer, inventory and maintain SharePoint content using PowerShell.

Module 5: Users and Security

This module covers the use of PowerShell to explore and document SharePoint permissions.

Lessons:

• Users: find a user, get a list of all users, working with Active Directory groups
• SharePoint groups: Get lists of groups, get the members of a group, find all groups a user belongs to, find the groups associated with a web
• Expanding users lists that include Active Directory groups
• Documenting Broken Inheritance / Unique Permissions: webs, lists, libraries, folders, items
• Working with Role Assignments

Lab:

• Get a list of all users who have access to a Site Collection.
• Get a list of all groups in a Site Collection.
• Get a list of all groups a user belongs to.
• List all users who may have access to a SharePoint securable.
• Get a list of all securables with broken inheritance.

After completing this module, students will be able to:

• Explore and document users and user permissions.
• Explore and document SharePoint groups.
• Explore and document broken inheritance.

Module 6: Managing Sites

This module explorers Site Collection and Web management from PowerShell.

Lessons:

• Finding Inactive Webs
• Creating and Deleting Site Collections
• Getting Site Collection Data
• Creating and Deleting Subsites
• Working With SharePoint Designer Settings

Lab:

• Create a report for inactive sites.
• Create a site collection and subsites.
• Delete a site.
• Delete a site collection.
• Disable SharePoint Designer in all site collections.

After completing this module, students will be able to:

• Manage SharePoint Site Collections and webs from PowerShell.

Audience

• SharePoint server administrators.
• SharePoint auditors.
• Also valuable for SharePoint developers.

SharePoint 2013: Hide JSLink from Team Members

This article applies to SharePoint Online, SharePoint 2013 and 2016.

 

Let's start with a couple "did you knows"…

Did you know:

• All users with Edit and Contribute permission levels can edit the home page of your site?
• The same users can edit or delete any page in the Site Pages library.?
• They can also edit the web parts on that page? And use advanced options like JS Link?

As part of your SharePoint governance or best practices you may want to limit who can use some of the more advanced customization features of SharePoint 2013 and 2016. JS Link, is after all, JavaScript programming and it can cause issues for daily support and the upgrade to future versions of SharePoint.

Before we get into locking down just JS Link, let's address the "did you knows". You may want to think about changing the permissions of Site Pages, Site Assets and a few other libraries to read only for all users except for Site Owners. Those libraries really should not be open for all to edit.

 

About JS Link

JS Link is a really cool technology introduced with SharePoint 2013 to let us customize web parts, views and list forms without "un-ghosting" pages using SharePoint Designer. It lets us create a JavaScript text file, store it in a library, and then link it to a web part or a form. If you are a developer, you can also use JS Link with Site Columns and Site Content Types. One of the benefits of JS Link is that the customization file can be created once, stored in a library and then be linked into many web parts and forms. When you need a change in the future, you only need to edit a single JavaScript file and not dozens or hundreds of web parts.

For web parts, JS Link is added in the Miscellaneous section of the web part properties panel.

 

Hiding JS Link

As SharePoint does not have a "switch" where we can just turn off the use of JS Link, we will need to come up with a CSS or JavaScript solution. If you add the following CSS to your master page (lots of ways to do this) then the JS Link box will be hidden.

<style type="text/css">
  input[id$="_JSLink_EDITOR"] {
    display:none;
  }
  label[for$="_JSLink_EDITOR"] {
    display:none;
  }
</style>

 

While we are at it, you may also want to hide the XSL Link option too:

<style type="text/css">
  input[id$="_JSLink_EDITOR"] {
    display:none;
  }
  label[for$="_JSLink_EDITOR"] {
    display:none;
  }
  input[id$="_XslLink_EDITOR"] {
    display:none;
  }
  label[for$="_XslLink_EDITOR"] {
    display:none;
  }
</style>

 

But what about the Site Owner?

If you want some users to still be able to edit the JS Link and XSL Link options then we can give those back using a SharePoint Security Trimmed Control. You just need to pick a permission that is unique that that group of users such as Add and Customize Pages. In the example below we take away JS Link from all users, and then give it back to select users.

<style type="text/css">
  input[id$="_JSLink_EDITOR"] {
    display:none;
  }
  label[for$="_JSLink_EDITOR"] {
    display:none;
  }
  input[id$="_XslLink_EDITOR"] {
    display:none;
  }
  label[for$="_XslLink_EDITOR"] {
    display:none;
  }
</style>

<Sharepoint:SPSecurityTrimmedControl runat="server" 
  PermissionsString="AddAndCustomizePages">
  <!-- Let owners and designers see the JSLink options -->
  <style type="text/css">
    input[id$="_JSLink_EDITOR"] {
      display:inline;
    }
    label[for$="_JSLink_EDITOR"] {
      display:inline;
    }
    input[id$="_XslLink_EDITOR"] {
      display:inline;
    }
    label[for$="_XslLink_EDITOR"] {
      display:inline;
    }
  </style>
</SharePoint:SPSecurityTrimmedControl>

 

.

SharePoint Saturday Cincinnati - SharePoint 2013 Search Results Customization

 

SharePoint Saturday Cincinnati is almost here! In fact… it's tomorrow. I thought I'd do something a little different this time and put out a little teaser on my topic. To be fair though… there's 19 other cool topics planned for Saturday, just click here to see the schedule.  Register NOW!   http://bit.ly/1DAprtv

 

So a bit about my presentation…

SharePoint 2013 Search Results Customization

Let's start with a problem… Our users can't find a certain kind of document; for example, PowerPoint presentations about our R&D projects. And when they find them, they don't know which ones are highly confidential, and more than once they have shared them with the wrong people.

And then a solution…

• Create Site Columns for consistent metadata and to support Managed Property searches such as"ResearchGroup=aviation".
• Configure the search schema to support friendly property names and the ability to search using "<" and ">" on dates and numbers.
• Create a Content Type to ensure document classification and to collect important metadata.
• Create a Display Template to add useful information to the search results, and display our Governance policies for R&D documents. ("Warning… confidential content. Do not share!")
• Create a Result Type to map the Content Type to the Display Template.
• Create a user friendly and governance friendly search results page.

All in an hour! 

 

See you there!

 

.

SharePoint: Who can't you hide things from?

 

You just created a new subsite. You broke inheritance. You removed all of the inherited permissions. You gave only three people access.

Can anyone else see this site?

Yup…

• Your Site Collection Administrator.
• People granted Web Application level "super user" permission policies by the server administrators. These roles are often called "Auditors" and "Super Administrators".
• Server administrators who have granted themselves "super user" permissions.
• Any administrator using the farm service account. (Never a best practice.)
• Any one who your team members have "Shared" with!  (see below)
• The SQL Database Administrator. (we never directly query the tables… right?)

 

Site Collection Administrators

When a new Site Collection is created the server administrator can assign people to two roles named Primary Owner and Secondary Owner. These two users can see and change everything in site collection, unless some permission has been denied by Web Application level user policies.

These two Site Collection Administrators can add as many other people to the list of Site Collection Administrators as they like. Only the Primary and Secondary will receive site alert emails, all of these admins have Full Control over everything in the Site Collection. For more interesting things about these extra admins, see: http://techtrainingnotes.blogspot.com/2012/12/fun-and-games-with-site-collection.html.

 

Web Application Level "Super User" Permission Policies

Server administrators can define Web Application level policies and broadly give or remove permissions. These policies overrule anything done at the Site Collection or subsite levels. Here's a few examples:

• Remove the "Create Subsites" permission from all users.
• Remove the "Manage Lists" permission from everyone in the Active Directory Sales Managers group.
• Make a user an "Auditor" with rights to see everything in the entire Web Application. Yes, everything, including permissions and everything in the Site Settings page.
• Make a user a "Super Administrator" with the ability to change anything in the Site Collection, and even run in "stealth mode" with all changes listed as "by System Account".

 

Team Member Sharing – Members are security admins???

In SharePoint 2013 Online, users given the "Edit" permission level can share the site or anything in any list or library in the site where they have that permission level. All they have to do is click one of the many "Share" buttons or links. This one should really scare you! All they have to do is click the Share at the top of the page, and they have shared the entire site without site owner approval. If they click Share on a document or list item, then they have broken inheritance on that item, and then shared it!  The same user in SharePoint on-premises is only creating an "access request". See how to hide the share buttons here: http://techtrainingnotes.blogspot.com/2015/08/hiding-evil-sharepoint-2013-share.html

A bit odd, while the user with the "Edit" permission can "share" a full site or a single list item, then cannot share a list or library. If they guess the URL to "Permissions for this document library" they get "access denied".

SharePoint Online/Office 365 vs. On Premises:

	On Premises	Online
Member clicks the site level Share button	Creates an "access request" – site owner needs to approve	Adds new user to the Members group with usually has the Edit permission level
Member clicks the list or library item Share button	Creates an "access request" – site owner needs to approve. If approved, breaks inheritance and adds permissions for the new user.	Breaks inheritance and adds permissions for the new user.
Member guesses the URL to the People and Groups page…	Can only see the list of users in the groups.	Can remove users from groups!

So… Consider editing the "Edit" permission level and removing the "Manage Lists" permission!

 

 

 

.

Hiding the Evil SharePoint 2013 Share Buttons!

 

SharePoint introduced Share buttons to make it easy for users to quickly share a site, folder or document. This introduced several administration, security and governance problems for administrators. Mostly because the act of sharing a document breaks inheritance on the file. Whether this is "evil" or not depends on the way you need to use SharePoint. 

Here's a sample flow:

• We have a library for 100 sales documents. Currently the Sales Managers group and five other users have access to the library and its contents.
• Someone clicks the Share button on a document.
• If the user is not an owner and does not have the Manage Lists permission, then a request is added to the Site Owners. Site Owners, if they ever discover the request, can approve or reject it.
• Inheritance is broken on the document. Existing permissions are copied to the file. The user is added to the document's permissions list.
• Now the fun begins…
• A new user or group is given permissions to the library.
• They only see 99 documents! (The missing document has unique permissions and no longer inherits permissions from the library.)

After inheritance is broken you have to remember to manage the permissions of each individual broken inheritance document. Now think about 50 libraries, each with where the Share button has been clicked on a 1000 documents. Job security at the minimum!

 

Just how many Share buttons are there?  
(Let me count the ways…)

The Share the site button:

  

The Share a document button in the "QCB" (Quick Control Block?) bar:

  

The Share a document button in the FILES ribbon :

  

The Share a document button in the "…" pop out:

  

The Share a document link in the "… …" menu:

  

The INVITE PEOPLE button in create a new folder:

  

The Invite People button in the Shared With dialog box:

  

Did I miss any?

(I started on this article a few times, but each time I found yet another Share button!)

 

Disabling using Views

You can hide the Share button that's just above the library by switching to any other view style than"Default". This also hides all of the other links in the "QCB" (Quick Control Block?) bar.

The Share button will be grayed out in the FILE ribbon if you select a Style other than Default and Shaded, or disable "Tabular View - Allow individual item checkboxes".

Disadvantages? These styles do not display a checkbox, even if "Tabular View - Allow individual item checkboxes" is checked. Without the checkbox most of the options in the FILE ribbon are disabled.And… this approach only hides one of the Share buttons.

 

Disabling the Share buttons using CSS

The easiest way, at least until Microsoft gives us an option to turn them off, is to add CSS to the Master Page. Some of the buttons has convenient IDs while some can be found using a class. While you could merge all of the selectors into one line, I broke them out so you could choose which Share features you would like to hide or keep.

In my project I uploaded the CSS file to the Site Assets library. You could place the CSS file in any library where your users have at least read access, or in the layouts folder on the server. You would then link to the file something like this:

<link rel="stylesheet" type="text/css" 
href="https://yourServer/sites/yourSite/SiteAssets/nosharebuttons.css"></link>

Or maybe:

<link rel="stylesheet" type="text/css" href="/_layouts/nosharebuttons.css"></link>

 

The CSS:

/* CSS to hide the various Share buttons and links */
/* from TechTrainingNotes.blogspot.com             */
/* Use at your own risk. Batteries not included.   */

/* Hide Site Share button (page top right) */
#ctl00_site_share_button  {
 display:none !important;
}

/* Hide library toolbar (QCB) Share button */
.js-listview-qcbShareButton {
 display:none !important;
}

/* Hide the Share in the ... popout */
.js-callout-actionsMain span:nth-child(2) {
    display:none !important;
}


/* Hide the Share in the ... ... menu */
a[title="Share"] {
 display:none !important;
}


/* Hide the INVITE PEOPLE button in Create Folder */
#csfd_invitePeopleBtn {
 display:none !important;
}

/* Hide the Share button in the FILES ribbon */
#Ribbon\.Documents\.Share\.ShareItem-Large {
 display:none !important;
}

/* Hide the Invite People button in the Shared With dialog */
#lnkShrItem {
 display:none !important;
}

 

Here's the "one line" version:

/* CSS to hide the various Share buttons and links */
/* from TechTrainingNotes.blogspot.com             */
/* Use at your own risk. Batteries not included.   */


#ctl00_site_share_button, 
  .js-listview-qcbShareButton, 
  .js-callout-actionsMain span:nth-child(2), 
  a[title="Share"], 
  #csfd_invitePeopleBtn, 
  #Ribbon\.Documents\.Share\.ShareItem-Large, 
  #lnkShrItem 
{
 display:none !important;
}

 

.