Read vs Restricted Read vs View Only Permission in SharePoint

I recently had a SharePoint admin assigning Restricted Read permissions to users and out of curiosity wanted to refresh my memory on what distinguishes Read from Restricted Read. While I was at it, I took a look at View Only as well.

Basically, Read and View Only are nearly identical. The only distinction is that Read can download documents, while View Only can only open them and view them in the browser.

Restricted Read is minimally permissive, and doesn’t include the ability to create alerts, view versions, download, or exercise some site abilities (see table below for specifics).

You’ll also notice in the table below that View Only can Open, but not Open Items like Read. According to documentation, the difference is this:

  • Open Items (list permission): “View the source of documents with server-side file handlers.” Requires Open permission:
  • Open (site permission): “Enables users to open a website, list, or folder to access items inside that container.”

In the table below, list permissions are blue and site permissions are red. Download Documents is not a listed permission, but added for clarity to distinguish Read and View Only.

View OnlyRestricted ReadRead
Browse User Information XX
Create Alerts XX
Download DocumentsX
OpenXXX
Open ItemsXX
Use Client Integration Features XX
Use Remote Interfaces XX
Use Self Service Site Creation XX
View Application PagesXX
View Items XXX
View Pages XXX
View Versions XX
Permissions comparison matrix for read, restricted read, and view only in SharePoint.

Source: https://docs.microsoft.com/en-us/sharepoint/sites/user-permissions-and-permission-levels

How to clear the SharePoint Server configuration cache using PowerShell

If you have several servers in your SharePoint Server (on-premises) farm, repeating the manual steps for clearing the configuration cache on each can be time consuming. PowerShell really shines in situations like these to help us be more productive and efficient.

The following PowerShell script can be used to clear the SharePoint configuration cache on a server. I’ve recently tested this on SharePoint 2019 servers with success. Just be sure to run it on each server for which you’re clearing the cache, then remember to go back to each and press “ENTER” in each PowerShell window as the script instructs you so that it restarts the timer service after all servers have had their cache cleared.

This script follows the same steps you’d perform manually. It loads the SP snap-in if needed, stops the timer service, deletes the xml files in the Config directory, sets the cache.ini file’s value to 1 to reset the cache, then restarts the timer service (once you press Enter).

Clear SharePoint configuration cache using PowerShell

  1. Run PowerShell as administrator (right-click, run as administrator).
  2. Copy and paste the following script, making no changes to its contents. It will work as-is.
  3. Hit Enter to run the script (unless using ISE, then click “Run”).
  4. Repeat steps 1-3 for each SharePoint server on which you’re clearing the cache.
  5. When this has run on all SharePoint servers you wish, go back to each and hit Enter in PowerShell to restart the timer service on each.

Microsoft Delve blogs to be retired; Existing Delve blogs to be deleted in 2020

Thanks to a tweet by Tim Milan of Omaha, I heard today that Microsoft Delve blogs are to be deleted in a few months.

Milan’s news came from Office 365 Premier Support in response to a ticket he’d submitted. The email is as follows:

Click to enlarge

Delve was first announced alongside the Office Graph in 2014 at SharePoint Conference. Even though it’s only been out for a little over five years, the retirement of Delve in general has been a topic of speculation for nearly two years now (and perhaps longer for others). Some have wondered whether to invest time learning and promoting the app anymore, and perhaps this news will help guide those decisions.

Important dates:

The following points are taken from the email body seen above.

  • Beginning December 18th, 2019, tenants can no longer create new Delve blogs.
  • Beginning January 18th, 2020, you can no longer create new posts in existing blogs
  • Beginning April 17th, 2020, existing Delve blogs will be deleted and removed from Delve profiles.

What now?

If you read this post and asked yourself, “What’s a Delve blog?” don’t worry about it. It was a convenient feature that allowed your average user to create and maintain a blog they could share in the organization.

If you read this post and realized you have hundreds of user and group blogs out there to manage and just a few months to figure it out, you have some choices to consider.

The email shown earlier in this post suggests creating communication sites and adding News, Yammer, and Stream web parts for engagement but this isn’t a good plan for all blogs as not all users can create sites for themselves. Even those that can create sites may find site creation and management a bit too complex or too large of a scope compared to running a simple blog.

You could consider creating WordPress or Blogger sites and migrating your posts there. Unfortunately, there is no RSS feed for Delve blogs to export. You’d be manually copying and pasting (or recreating) posts.

You might consider disabling Delve if you’d like to prevent users from beginning something that’ll be removed soon. You can do this through the SharePoint admin center for all users (see directions here). Keep in mind this disables more than just blog creation – read the description before proceeding.

Click to enlarge

No matter what you choose, there’s no easy way forward. I would suggest getting your users involved in saving (print to PDF or copy/paste) posts of importance so that they can be posted as documents elsewhere, or recreated at a later time in another space.

Ready, set, change management!

SharePoint search results showing wrong title

I recently ran into the issue of a document appearing in search results that didn’t use the name field OR the title field. I was perplexed by this until checking the search schema for the “Title” field. In an attempt to be helpful, there’s a property called MetadataExtractorTitle that was given higher preference than the actual title field. To fix this, I simply had to bump it down the list a bit.

Scenario

The document in question is a SharePoint Governance meeting agenda named SP Governance – 2017-11-17.

It appeared correctly in its library, which is to be expected:

And a look at its properties revealed there was no Title value, meaning it would default to the document name.

However, when searching for “SP” I found the document listed as “Agenda.” This was used because the MetadataExtractorProperty found “Agenda” within the document as a potential title (as the first line of the document).

Solution

Note: You must be at least a site collection administrator.

Go to Site Settings at the top level of the site collection for the document library.

Choose “Search Schema” under Site Collection Administration (not just “Schema” under search – that’s only site level)

Search for title and edit the property

Move “MetadataExtractorTitle” down until it’s beneath ows_Title. Click OK when finished.

Click to enlarge

Checking your work

After fixing the schema, go back to the document library and re-index it to check. (Library Settings –> Advanced Settings –> Reindex Document Library)

This will have the library re-crawled during the next incremental crawl (interval depends on administrator settings). Alternatively, you could trigger it immediately or run a full crawl.

Once the crawl has run, try your search again. Your items should now have a correct title when appearing in search results.

Run Google Chrome as a different user to test

In an on-prem environment, it’s convenient to be able to run Chrome as a test user with general permissions instead of my admin permissions. This possibility makes it so I don’t need to remote to another machine or log out and in with another account just for a simple check.

Using Internet Explorer? Here’s how to do the same with that.

If you have a shortcut to Chrome on your desktop (not your task bar), skip ahead to step two.

1. Search “Chrome” from the start menu, right click and select “Open File Location”

2. Hold “Shift” on your keyboard and right-click the Internet Explorer icon. Select “run as different user”

3. Enter the credentials for the second user (your screen/prompt may look different) and click OK/Login. In some cases, you may be prompted to enter these more than once.

Chrome will now run as if the other user is logged in.

You can also use the “Check permissions” feature in SharePoint to see which groups a user belongs to for a site or resource, and which abilities/privileges they have.

Run Internet Explorer (IE) as a different user to test

It’s often helpful in our on-prem environment to be able to run IE as a test user with general permissions instead of my admin permissions. This possibility makes it so I don’t need to remote to another machine or log out and in with another account just for a simple check.

Using Google Chrome? Here’s how to do the same with that.

If you have a shortcut to IE on your desktop (not your task bar), skip ahead to step two.

  1. Search “IE” from the start menu, right click and select “Open File Location”

2. Hold “Shift” on your keyboard and right-click the Internet Explorer icon. Select “run as different user”

3. Enter the credentials for the second user (your screen/prompt may look different) and click OK/Login. In some cases, you may be prompted to enter these more than once.

IE will now run as if the other user is logged in.

You can also use the “Check permissions” feature in SharePoint to see which groups a user belongs to for a site or resource, and which abilities/privileges they have.

Check permissions for an individual or group in SharePoint

If you want to see which groups a user belongs to, or how an individual is granted (or restricted) access to a particular site or resource, use the “Check permissions” button in Site Settings –> Site Permissions (or any advanced permissions page).

SharePoint 2016 example of checking permissions
SharePoint Online example of checking permissions (see specific allowances)

Remove specific people from people search results in SharePoint

Note: Screenshots and steps from a 2016 environment

There may be times when you have AD accounts showing up in search results that you can’t delete, but need to hide from results. The following sections will guide you through removing specific profiles from your people search results.

Steps:

  1. Create a mapped property for user profiles
  2. Use the new property at least once
    • Start a full crawl of people source
  3. Create a managed property mapped to your new user property
    • Start a full crawl of site source
  4. Edit the query on the people search results page
  5. (optional) If you have “People Results” as “Promoted Results” or “Ranked Result Blocks”

1. Create a mapped property for user profiles

From Central admin, click on “Manage service applications”

Select “user profile service application”

Click “Manage User Properties” under “People”

Select “New Property”

Set the new properties settings as follows:

  • Name and display name: RemoveFromPeopleSearch
  • Policy Setting: Optional
  • Default Privacy Setting: Everyone
  • Search settings, Alias: checked
Click to enlarge

Click OK.

2. Use the new property at least once

For the rest to work, you’ll need to mark at least one user profile to not show up in search. I did this by adding a “1” to the property we just created for a user I wished to remove from results.

Back under “User profile service application” (Central admin –> Manage service applications –> “User profile service application”) click on “Manage user profiles.”

Search for and edit the profile of who you’d like to remove from search results.


Start a full crawl of your people content source.

3. Create a managed property mapped to your new user property

Once the crawl is complete, go back to Central Admin home and select “Manage service applications.”

Select “Search service application”

Select “Search schema” from the left under “Queries and Results”

Select “New managed property”

Name it RemoveFromPeopleSearch and check “Queryable” and “Retrievable”

Click to enlarge

Scroll down and click “Add a mapping,” search for “remove” and add our new user property.

Click to enlarge

Click OK

This time, start a full crawl of your SITE content source.

4. Edit the query on the people search results page

Once your crawl is finished (may take a while), you’ll want to go to your people search results page and “Edit page.”

Click to enlarge

Edit the “Results” web part

In the menu that appears on the right, select “Change Query.”

If you’re not in advanced mode, switch to advanced mode. Then expand the “property filter” dropdown and select “show all managed properties.”

Try the dropdown again, and now you’ll see your new property listed. Select it and click “OK

Set properties as follows and click “Add property filter”

Click OK

Click “Apply” on the web part menu

Click “Save” and publish (if checked out)

5. (optional) If you have “People Results” as “Promoted Results” or “Ranked Result Blocks”

If you have people results outside your regular people search (such as a promoted result block in Local SharePoint Results) you’ll just need to be sure to also add the RemoveFromPeopleSearch<>1 string to the end of your query rule’s query.

Query rules can be accessed through central admin (manage service applications –> search service application –> query rules) or from Site Settings –> Query rules depending on where you initially setup your query rules/promoted results.

Edit the query rule in question, click “edit” next to the result block that’s relevant, then “Launch Query Builder” to be able to add the RemoveFromPeopleSearch<>1 string to your query.

Manually start a full or incremental crawl of an on-prem content source in SharePoint

From central admin, click “Manage service applications” under “Application Management”

Select the “Search service application”

Select “Content sources” from the left under “Crawling”

Select the drop-down for the content source you’re crawling and choose either a full or incremental crawl.

Solution: “Database Connector has throttled the response” error on external list in SharePoint

Applies to SharePoint 2016, can be adapted for O365

If you’re connecting to an external list of significant size, you may run into the following error:

Database Connector has throttled the response. The response from database contains more than ‘2000’ rows. The maximum number of rows that can be read through Database Connector is ‘2000’. The limit can be changed via the ‘Set-SPBusinessDataCatalogThrottleConfig’ cmdlet.

1. Log into your SharePoint server

2. Open your SharePoint 2016 Management Shell as administrator (right-click, run as administrator)

3. Connect to your site

Connect-Site -url https://sharepoint.contoso.com

4. Get ALL service application Proxy IDs (you’ll need this in a later step)

Get-SPServiceApplicationProxy

5. Note the ID of the “Business Data Con…” application

6. Set a new variable “$serviceapp” to that app using the ID you noted as its identity

$serviceapp = Get-SPServiceApplicationProxy -Identity a12b3cf4-d12j...

7. Run the following cmdlet to increase the throttle limit

Get-SPBusinessDataCatalogThrottleConfig -Scope Database -ThrottleType Items -ServiceApplicationProxy $serviceapp | Set-SPBusinessDataCatalogThrottleConfig -Maximum 1000000000 -Default 500000

Your external list will now load correctly!

More info:
https://docs.microsoft.com/en-us/powershell/module/sharepoint-server/get-spbusinessdatacatalogthrottleconfig?view=sharepoint-ps