Grant Access to a Document within a SharePoint Document Set

Assume the following scenario: “You wish to break inheritance on a document contained within a SharePoint document set and grant access to it to a specific user”. In other words, the user you are trying to grant access to the document to does not have access at the site level, at the library level, nor at the Document Set level, but is granted explicit contribute rights at the document level. So in this case, if the user tries to access the document directly by its URL he should have access to view and edit the document.

However, if you have the SharePoint server Publishing Infrastructure site collection feature activated, you may run into a case where the user receives an access denied error, even though he’s been granted implicit access to the document. This is because by default, the moment you activate the Publishing Infrastructure feature, SharePoint also activates a second site collection feature named Limited-access user permission lockdown mode.


This feature serves a specific purpose: Prevents anonymous users or users having Limited Access from accessing a folder on your site. This makes sense since the Publishing Infrastructure feature is used whenever you are creating a public internet site using SharePoint. Basically, whenever this feature is activated, users will get an access denied the moment they hit a folder on which they have Limited Access in the URL. Let me clarify, assume the path to your document within the document set is the following:

The user has limited access to every part of the URL that is underlined above (site, the document library and the document set). The moment SharePoint tries to resolve a part of the URL to which the user has Limited Access, it will return an access denied error.

The solution to this is to simply disable the Limited-access user permission lockdown mode feature at the site collection level. You however need to understand the possible consequences of turning this off if your SharePoint site allows anonymous access, you potentially open the dorr for them to access application pages for your lists and document libraries, which you probably don’t want to have happen.

For more information on the Limited-access user permission lockdown mode, please refer to the following Office Support article (scroll down to the last section).

Can’t Create a SharePoint Publishing Catalog Connection

I encountered a weird issue while working at a client’s site this week, where we were trying to update the catalog url of some SharePoint Publishing Catalog Connections after we restored the content database from a different farm. The client in question has three SharePoint environments: a Dev one, a Quality Assurance (QA) one and off course, a Production one. Each of these environments had been given a different url. Ex:

Quality Assurance

The client’s SharePoint environment is entirely based on Cross-Site Publishing to display content. They wanted to refresh their Dev environment with a copy of the content from production. So we went ahead and proceeded to refreshing their content database and their Managed Metadata Service database. Because the content was taken from a different environment, the Catalog connections listed still exhibited a Url that pointed to, so we needed to change this to reflect the dev url.


So to keep things simple, we decided to simply go and delete all existing Connections, and recreate them using PowerShell, but this time having them pointing to the url. Upon executing our PowerShell we got the following weird error:

Exception calling “Update” with “0” argument(s): “The object you are trying to create or modify has the same name as another object.

This error seemed to indicate that somehow there was already a catalog connection that existed and that had the same name as the one we were trying to create. However, there were no connections showing up on the Manage Connection page.

One thing I’ve learned from troubleshooting this issue is that SharePoint automatically creates a Search Results Source for every Catalog Connection you define. These Result Sources will be given the name of your Catalog Connection, followed by the word “Results”.

Normally, if you delete a catalog connection, its associated Result Source is also automatically deleted. However, in our case, when we brought back a copy of the production database, somehow a link got broken in the background, and when we deleted the Catalog Connection, the Result Source was still existing. So the solution to our problem was to go ahead and to delete the orphan Result Source at the Site Collection level using PowerShell.

$site = Get-SPSite ""
$ssa = Get-SPEnterpriseSearchServiceApplication;
$fedManager = New-Object Microsoft.Office.Server.Search.Administration.Query.FederationManager($ssa)
$owner = New-Object Microsoft.Office.Server.Search.Administration.SearchObjectOwner([Microsoft.Office.Server.Search.Administration.SearchObjectLevel]::SPSite, $site.RootWeb)
$resultSource = $fedManager.GetSourceByName("Home - Products Results",$owner)

* Credits for this PowerShell snippet goes to Sathish Nadarajan

Once the Result Source was properly deleted, we managed to execute our PowerShell to recreate the Catalog Connections without a problem.