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.
Browse User Information
Use Client Integration Features
Use Remote Interfaces
Use Self Service Site Creation
View Application Pages
Permissions comparison matrix for read, restricted read, and view only in SharePoint.
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
Run PowerShell as administrator (right-click, run as administrator).
Copy and paste the following script, making no changes to its contents. It will work as-is.
Hit Enter to run the script (unless using ISE, then click “Run”).
Repeat steps 1-3 for each SharePoint server on which you’re clearing the cache.
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.
•December 18th, 2019, tenants will not have the ability to create new Delve blogs. •January 18th, 2020 the ability to create new posts will be disabled. •Beginning April 17th, 2020, existing Delve blogs will be deleted#Microsoft
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.
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.
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.
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.
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).
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.
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)
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.
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.
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).
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.
Create a mapped property for user profiles
Use the new property at least once
Start a full crawl of people source
Create a managed property mapped to your new user property
Start a full crawl of site source
Edit the query on the people search results page
(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
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.
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.”
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 “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.
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)
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