SharePoint 2016 Feature Packs

Today at the Ignite conference in Atlanta, Microsoft shared more information about the vision for SharePoint. With SharePoint 2016, it is now possible for organizations to obtain and enable new features within their on-premises environments through the use of “Feature Packs”. In the past, we pretty much had to wait for Service Packs to be released before seeing new features make their way into the product. With Feature Packs, organizations can now activate new features directly into the on-premises product.

The first Feature Pack, scheduled to be made generally available in November of 2016, will introduce the following new features:

For IT Pros

  • Administrative logging: Allowing users to audit actions made in Central Administration;
  • MinRole Changes: Addition of new workloads to support small environments;
  • Unified Logging: Ability to combine logging from both on-premises and Office 365 environments;

For Users

  • OneDrive API Update: One Drive API 2.0 now available on-premises (allows for interaction with Drives and Items);

For Users

  • App Launcher Custom Tiles: Ability to add custom tiles to the App Launcher (waffle icon to left);
  • New OneDrive for Business UX: New User Experience in OneDrive for Business, matching the one introduced in Office 365 last year;
  • Hybrid Taxonomy: Allowing term stores to be unified between on-premises environments and Office 365;

box

Upload Random Documents to a SharePoint Environment

In my daily job I often need to kill a SharePoint farm and build a new one from scratch to match a client’s Production environment. When doing so, I also need to get rid of any test documents I had created in the previous environment, and need to start creating and uploading new documents from scratch for my new SharePoint environment. While working on a demo for one of my client, I need to demo a SharePoint migration, and also had to give them a live presentation of how the SharePoint 2013 Search Results will be displayed in the new environment.

Because of this requirement, I decided that I needed an automated way to upload thousands of documents, randomly, in my environment. Most of my dev SharePoint environments are single server farms (for simplicity and because it runs directly on Hyper-V on my work laptop). On these local farms, I always install the following software: Visual Studio, Office (2016 or 2013) and SharePoint Designer (yes I said it). The idea behind my automated script was that it should automatically generate Word documents, with random content in them, and upload them in a random site, somewhere in my environment, in the “Shared Documents” library that are included by default in Team Sites.

The first part of the script would have to rely on the Office Interop COM object, which means that ideally Office would have to be installed on the machine running the script. The first thing I did is create an array containing various nouns & verbs. Our script will randomly pick some of these words to populate the content of our Word documents.

$words = @("Cat", "Dog","Cow","Giraffe", "Ball", "Cube", "Sphere", "Document", "Paper", "Computer", "The", "Person", "Black", "Blue", "Red", "SharePoint", "Microsoft", "Red", "Search", "Create", "Delete", "Article", "Web", "HTML", "C#", "VB", "Microsoft", "Job", "Office", "Table", "Star", "Pen", "Pencil", "Arm", "Leg", "Doctor", "Student", "Education", "Defense", "Army", "Navy", "Boat", "Plane", "Jet", "Hockey", "Baseball", "Soccer", "Volley-Ball", "Swim", "Pool", "Lake", "Ocean", "Sea", "Bird", "Fly", "Sky", "Planet", "Space", "Pig", "Owl", "Night", "Day", "Morning", "Evening", "Delete", "Create", "Update", "Great", "Super", "Awesome", "Mark", "Check", "Report", "Minutes", "Decisions", "Technology","Software", "Hardware", "Server", "Database", "Application", "Game", "Keyboard", "Mouse", "Screen", "Tower", "Building", "Street", "Song", "Music", "Car", "Bus")

Next I will be prompting the users to ask them how many documents they wish to randomly upload across the environment. The script will then loop as many times as specified by the user, will generate a random document on each iteration, select a random SPWeb somewhere in the environment and upload the document in its Shared Documents library. Each document will be given a GUID as filename to make sure we don’t hit any conflicts.

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue

$words = @("Cat", "Dog","Cow","Giraffe", "Ball", "Cube", "Sphere", "Document", "Paper", "Computer", "The", "Person", "Black", "Blue", "Red", "SharePoint", "Microsoft", "Red", "Search", "Create", "Delete", "Article", "Web", "HTML", "C#", "VB", "Microsoft", "Job", "Office", "Table", "Star", "Pen", "Pencil", "Arm", "Leg", "Doctor", "Student", "Education", "Defense", "Army", "Navy", "Boat", "Plane", "Jet", "Hockey", "Baseball", "Soccer", "Volley-Ball", "Swim", "Pool", "Lake", "Ocean", "Sea", "Bird", "Fly", "Sky", "Planet", "Space", "Pig", "Owl", "Night", "Day", "Morning", "Evening", "Delete", "Create", "Update", "Great", "Super", "Awesome", "Mark", "Check", "Report", "Minutes", "Decisions", "Technology","Software", "Hardware", "Server", "Database", "Application", "Game", "Keyboard", "Mouse", "Screen", "Tower", "Building", "Street", "Song", "Music", "Car", "Bus")

$number = Read-Host "How many documents do you want to randomly upload to SharePoint?"

$allWebApps = Get-SPWebApplication

[ref]$SaveFormat = "Microsoft.Office.Interop.Word.WdSaveFormat" -as [type]
$word = New-Object -ComObject word.application
$word.visible = $false
for($i = 0; $i -lt $number; $i++)
{
    $filePath = "C:\DND\Documents\" + [guid]::NewGuid().ToString() + ".docx"
    
    $doc = $word.documents.add()

    $selection = $word.selection
    $result = $selection.WholeStory
    $selection.Style = "No Spacing"

    $rndNumberOfWords = Get-Random -Minimum 1 -Maximum 1000
    $sentence = ""
    for($j = 0; $j -le $rndNumberOfWords; $j++)
    {
        $sentence += $words[(Get-Random -Minimum 0 -Maximum ($words.Length))] + " "
    }

    $selection.font.size = 14
    $selection.font.bold = 1
    $selection.typeText($sentence)

    $result=$doc.saveas([ref] $filePath, [ref]$saveFormat::wdFormatDocument)
    $result = $doc.Close()

    $randomWebApp = $allWebApps[(Get-Random -Minimum 0 -Maximum $allWebApps.Length)]
    $randomSite = $randomWebApp.Sites[(Get-Random -Minimum 0 -Maximum ($randomWebApp.Sites.Count-1))]
    
    $url = $randomSite.Url
    Write-Host "Uploading a random document to"$url

    $spWeb = Get-SPWeb $url 
    $docLib = $spWeb.GetFolder("Shared Documents") 
    $allFiles = $docLib.Files 

    $fileName = $filePath.Substring($filePath.LastIndexOf("\")+1) 

    $fileObject = Get-ChildItem $filePath

    $stream = $fileObject.OpenRead()
    $result = $allFiles.Add("Shared Documents/" + $fileName, $stream, $false)
    $stream.Close()
    $fileObject = $null

    $spWeb.Dispose()
    Remove-Item $filePath -ErrorAction SilentlyContinue -Force
}
$word = $null

Upgrade from SharePoint 2010 to SharePoint 2016

In this blog, I will go through the process of upgrading your existing SharePoint 2010 farm to SharePoint 2016. Just like it has been the case with the last 3 product release cycles, there are no In-Place upgrade paths for SharePoint 2016. You basically have to build a new SharePoint 2016 SharePoint Farm, and then bring your content databases over. Throughout this article, we will focus solely on upgrading the SharePoint 2010 Content Databases (data), and not the Service Applications.

Background Information

The first thing you need to be aware of if you are planning an upgrade from SharePoint 2010 to SharePoint 2016, is that there are no direct upgrade path: you will have to upgrade your SharePoint 2010 content databases to SharePoint 2013 before going to SharePoint 2016. However, you do not have to build a complete SharePoint 2013 farm in order to accomplish this. All you need is a standalone SharePoint 2013 server (Single-Server Farm), that will be used as a stepping stone to upgrade the schemas of your SharePoint 2010 content databases to SharePoint 2013, and then move on to your new SharePoint 2016 farm.

Conceptually, the diagram below shows what high-level infrastructure is required for such an upgrade. The SharePoint 2010 section, shows our existing SharePoint farm. For our example, the farm will be made up of two Web Front-Ends, one Application server, and a single SQL Server. Then if we look at the SharePoint 2013 section, we can see that we have a single server farm, that has both the SQL and the SharePoint 2013 bits installed on it. This server will act as our stepping stone to SharePoint 2016. Its sole purpose is to upgrade our SharePoint 2010 content databases to SharePoint 2013 so that we can then move them over to SharePoint 2016. Then, in the SharePoint 2016 section, we see that we have replicated our SharePoint 2010 infrastructure (with new server names to avoid conflicts).

Diagram

At this point you could have decided to add more capacity to your SharePoint 2016 farm, but to keep things simple we did a one-to-one replica. Another option, depending on how long you can afford to have downtime for your SharePoint farm, would have been to move the content databases to the SharePoint 2013 Single server and upgrade them, to recycle the SharePoint 2010 infrastructure to install SharePoint 2016 on it, and to move the content databases over the newly recycled infrastructure once ready.

Step 1 – Upgrade your SharePoint 2010 content to SharePoint 2013

The first step in our SharePoint 2010 to SharePoint 2016 upgrade process, is to upgrade to SharePoint 2013.

a) Backup your SharePoint 2010 Content Database

  • Launch SQL Server Management Studio
  • Right-click on your Content Databases and select Tasks > Back Up…
    Back Up...
  • In the dialog window that opens, leave the default settings and click OK.
    InitiateBackup
  • Upon receiving a message to let you know that the backup succeeded, click OK to close it.
    CloseBackup

b) Copy the Backup Files Over to the SharePoint 2013 Single Server Farm

  • By default, the content database will have been backed up in the default SQL installation folder, under the Backup repository. In my case it was located at C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Backup.
    BackupFile
  • Take the .bak file and copy it locally onto the SharePoint 2013 Single server Farm.

c) Restore the SharePoint 2010 Content Database on the SharePoint 2013 server

  • Open SQL Server Management Server on the SharePoint 2013 Single Server Farm.
  • In the Object Explorer panel, right click on the Databases folder and select Restore Database…
    SelectRestoreDB
  • In the Restore Database dialog, select Device from the top radio choices and click on the “…”
    selectrestorebackup
  • Keep the “Backup media type” set to File, click on the Add button and browse for the .bak file we’ve copied over.
    SelectBackupFile
  • Click OK on both windows.
  • This will initiate the Database Restore operation. Once completed, you will get a confirmation letting you know that the restore operation succeeded. Click OK to close it.
    Successrestore

d) Create a New SharePoint 2013 Web Application

In order to upgrade our SharePoint 2010 content databases to SharePoint 2013, we need to associate them with a SharePoint 2013 Web Application.

  • Open Central Administration and navigate to Application Management > Manage web applications
  • In the ribbon, click on New
    NewwebAppl
  • Create a new Web Application on port 80, without a Host Header. By default, if this is the first Web Application you create on your SharePoint 2013 Single Server Farm, the creation interface should automatically default to a new Port 80 web application. Give the Web Application the name Stepping Stone and leave the default options there, and simply click on OK to initiate the creation of the new Web Application.
    NewWebApp

e) Mount the Content Databases to SharePoint 2013

  • Open a new PowerShell session as administrator
  • Run the following lines of PowerShell. Whis will actually initiate the Upgrade operation on your SharePoint 2010 Content Database.
    Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
    
    Mount-SPContentDatabase "Intranet-Content-1" -WebApplication "Stepping Stone"
    

    Where Intranet-Content-1 is the name of my SharePoint 2010 Content Database and Stepping Stone is the name of the SharePoint 2013 Web Application we’ve just created in the previous section

    SP2013Upgraded

  • At this point, you have successfully upgraded your SharePoint 2010 content to SharePoint 2013. In my case, my Content Databases contained 2 site collections, respectively located at /sites/TeamA and /sites/TeamB. Therefore, by navigating to http://<server name>/sites/TeamA I should be able to view my content.
    Sp2013-2010look

Step 2 – Upgrade the Experience to SharePoint 2013

By default, when upgrading content databases from SharePoint 2010 to SharePoint 2013, site collections will continue to use the SharePoint 2010 experience, meaning that the user interface will continue to look just like it was in SharePoint 2010, even though the engine under the cover is all SharePoint 2013. However, before upgrading to SharePoint 2016, the user experience has to be upgraded to the SharePoint 2013 experience. If you try to upgrade a SharePoint 2013 content database that contains site collections with the SharePoint 2010 experience to SharePoint 2016 the upgrade operation will fail and you will get the following error in the upgrade logs: ERROR Please upgrade sites using SharePoint 2010 experience in database Intranet-Content-1 to SharePoint 2013 before proceeding..

a) Automate the Upgrade Process

  • While you could manually upgrade all site collections to the SharePoint 2013 experience, we will automate the process with PowerShell. The following PowerShell script will loop through all Web Applications in the SharePoint 2013 Single server Farm and will upgrading all site collections to the SharePoint 2013 experience:

    Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
    
    $webApps = Get-SPWebApplication
    foreach($webApp in $webApps)
    {
        $sites = $webApp.Sites
        foreach($site in $sites)
        {
            Upgrade-SPSite $site.RootWeb.Url -VersionUpgrade -Unthrottled
            $site.Dispose()
        }
    }
    

    * Executing this script will likely take a long time since it synchronously upgrades each site collection one at a time. If you wish to do it in an asynchronous fashion you can use the -QueueOnly switch which will simply put the upgrade request in a queue and will let the timer job get to it at some point in time.

  • To ensure that the experience was properly upgraded, you can navigate back to your site to ensure it now has the SharePoint 2013 look and feel applied to it.
    SP2013 look

Step 3 – Upgrade to SharePoint 2016

The only step remaining is now to migrate our SharePoint 2013 upgraded content to SharePoint 2016. To do so, we will simply repeat step 1, but this time we will bring the data from the SharePoint 2013 Single Server farm onto the newly built SharePoint 2016 farm. I will not be covering the step-by-step procedure to achieve this. Just know that it is exactly the same as what we did to get the content upgraded from SharePoint 2010 to SharePoint 2010. The one difference would be at Step 1-d, where I would off course not recommend creating a Web Application named “Stepping Stone” on your SharePoint 2016 server. You should be mounting your SharePoint 2013 content database against a Production ready Web Application (Step 1-e).

Once the upgrade to SharePoint 2016 is completed, you can navigate back to your site collection to ensure it is properly loading.

sp2016

Upgrade SharePoint 2010 Host Header Web Application to SharePoint 2013 Host-Named Site Collections

A customer of mine is upgrading their SharePoint 2010 farm to SharePoint 2013. As part of the upgrade process they also wish to convert their existing Host Header Web Application to Host-Named Site Collection. The client has 2 to 3 content databases per Web Application in their SharePoint 2010 environment. It is imperative that the URLs used to access the content do not change. The client also wants to keep the SharePoint 2010 look for the migrated sites, at least for a month after migration. Therefore the Host Header Web Appplication to Host Name Site Collection move is simply for administrative purposes.

Also, the client is not using the current root of their Host Header Web Application. So for example, there is no content if users were to browse to http://intranet.contoso.com. Content only exists in site collections under managed paths such as http://intranet.contoso.com/sites/TeamA. The present article covers the process you are required to follow if you wish to accomplish this migration.

Background Information

The current SharePoint 2010 farm hierarchy is as follow:

Web Application: http://intranet.contoso.com
Content Databases:

  • Intranet-Content-1
      Site Collections:

    • http://intranet.contoso.com/sites/Team A
    • http://intranet.contoso.com/sites/Team B
  • Intranet-Content-2
      Site Collections:

    • http://intranet.contoso.com/sites/Team C

In summary, the Host Header Web Application is located at “http://intranet.contoso.com”. This Web Application is servered by two content databases: Intranet-Content-1 which contains two site collections and Intranet-Content-2 which only contains 1 site collection.

***This article assumed you have a plain vanilla SharePoint 2013 server setup and ready to receive the 2010 content.

Step 1 – Create a Placeholder Web Application in SharePoint 2013

In order to bring our SharePoint 2010 Web Applications over SharePoint 2013 and convert them to Host-Named Site Collections, we first need to create a new Web Application without a Host Header that will act as a container for these Host Name Site Collections. This web application will not be serving any web request properly speaking, meaning that it’s root will never be accessed by our clients via the browser. We will also be creating a root site collection in this Web Application. This root site collection will never be used by users, it is simply there to ensure the requests to the server are properly processed. This “no host header” web application is also required for you to be able to properly run SharePoint add-ins (another topic for another day)..

The new Web application we will be creating will be running on port 80 and won’t be configured using a Host Header. Even if you have another Web Application running on port 80 in your SharePoint 2013 environment, that root Web Application has to be created without a host header and on port 80. I will be giving our new Web Application the name “Host Name Site Collections Container”.

To create our new Web Application, I will be using the following PowerShell line of code:

New-SPWebApplication -Name "Host Name Site Collections Container" -Port 80 -ApplicationPool "HNSC" -ApplicationPoolAccount (Get-SPManagedAccount "contoso\sp_farm")

container webapp

***Notice that our Web Application is created using Classic Authentication mode which is deprecated in SharePoint 2013. Do not worry, as part of our complete upgrade process, once all the Host Name Site Collections have been properly created, we will convert our Web Application to Claims Based Authentication. The convertion process will be covered in an upcoming blog post.

Step 2 – Migrate the SharePoint 2010 Content Databases to SharePoint 2013

The nextstep is to bring the SharePoint 2010 Content Databases over to your SharePoint 2013 server. In order to do this, we will be copying both the .MDF and .LDF files of our two content databases (Intranet-Content-1 and Intranet-Content-2) over the 2013 server. You can choose to copy a backup of the files, but in my case, I want to ensure no one can access the content from the SharePoint 2010 server while I’m in the process of doing the migration, so I will simply be dataching the databases from the SharePoint 2010 SQL server and closing all existing connections to it.

a) Detach the SharePoint 2010 Content Databases
Open SQL Server Management Studio and navigate to your Content Databases. Right click on the Intranet-Content-1 database and select Tasks > Detach.
DetachDB
When the dialog box appears, make sure you check the Drop Connections box, then click OK.
DBDrop
Repeat the process for all other content databases, in my case for Intranet-Content-2.

b) Copy the .MDF and .LDF Files
Now that our databases have been detached from our live SQL Server, we can move their associated files over to the SharePoint 2013 server. Find the path to your files, in my case they were located under “C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA“. Grab both the .mdf and .ldf file for each content database.
SelectDBFiles
Copy the files over to the SharePoint 2013 SQL server (in my case to C:\Data).
Files Copied

c) Attach the SharePoint 2010 Content Databases to the SharePoint 2013 SQL Server
Now that the files have been moved over to the SharePoint 2013 SQL Server, we need to attach them to it. Open SQL Server Management Server on the SharePoint 2013 SQL Server. In the Object Explorer panel, right-click on the Databases folder, and select “Attach…”.
AttachDB
In the “Attach Database” window that pops-up, click on the Add… button and browse to the Intranet-Content-1.mdf file we’ve copied over in the previous step. Select the .mdf file and click OK.
selectattachdb
Repeat the same process for all content databases, in my case for Intranet-Content-2. Once completed, you should see the content databases listed in the “Databases to attach:” section of the “Attach Databases” window. Ensure all the proper databases are listed and click “OK”.List attachdb
You should now see the SharePoint 2010 databases listed in the Object Explorer panel.
DBListedOE

d) Upgrade the SharePoint 2010 Content Databases to SharePoint 2013
Simply attaching the content databases to SQL Server is not enough fopr SharePoint to recognize these as content databases. We need to do a mount operation on our content databases in order for SharePoint to upgrade their schema to SharePoint 2013 and associate them with our temporary Web Application created at Step 1 above. To mount a content database onto a SharePoint 2013 farm, we need to use the following line of PowerShell code. Running the command will take a few minutes to complete, and PowerShell will display the upgrade percentage as it does the upgrade of the Database schema.

Mount-SPContentDatabase -Name "Intranet-Content-1" -WebApplication "Host Name Site Collections Container"

mountpercentage

Once the mounting process has completed, you’ll need to run the above PowerShell line of code for all other Content Databases, in my case for Intranet-Content-2.
UpgradedSites

Once completed, we end up with an upgraded SharePoint Web Application. Our site collections are available by navigating under our “Container” web application. For my environment, site collections can be accessed following this link: http://sp2013/sites/TeamA

However, these are not Host Name Site Collections, and more importantly, the URL to access them is not the same as it was in SharePoint 2010 which was one of our requirement for the upgrade.

3 – Create Root Site for our Host Name Site Collection

Remember that the client is never accessing the root of what used to be its SharePoint 2010 Host Header Web Application (http://intranet.contoso.com). In the 2013 world however, we need to create yet another “empty container”, this time a site collection, that will be a Host Name Site Collection serving the URL that used to belong to our Web Application http://intranet.contoso.com. This new site collection will be created directly at the following url: http://intranet.contoso.com

To create this new empty Host Name Site Collection, we will execute the following PowerShell lines of code:

$webApp = Get-SPWebApplication "Host Name Site Collections Container"
New-SPSite -Url "http://intranet.contoso.com" -HostHeaderWebApplication $webApp -OwnerAlias "contoso\sp_farm"

2010lookNew-HNSC

You may be wondering why is it you need to have a Site Collection created at the root of the http://intranet.contoso.com if I mentionned earlier that the client will never browse to this location. The reason for this empty site collection to exist is to be able to properly serve server resources to sites collections located under one of its managed path (e.g. http://intranet.contoso.com/sites/TeamsA). If this site does not exist, you will encounter an error that mentions that a site has to exist at the root when trying to create “sub-site collections” (under /sites).
NeedRoot

4 – Convert the Upgraded Site Collections to Host-Named Site Collections

a) Rename the Site Collection
Back in February 2015, Microsoft released a Cummulative Update for SharePoint 2013 that modifies the behavior of the SPSite.Rename method within the object model. This method can now be used to change the URL of a site collection to a host-header one. In order to be able to leverage this new change, your SharePoint 2013 requires you to be at least on build 15.0.4693.1001. For more information regarding this change, you can read the following Knowledge Base article https://support.microsoft.com/en-us/kb/2910928 (thanks to my colleague Roger Cormier for the info).

Now that we’ve made sure we have the proper patch level applied to our farm, we can go ahead and rename our site’s URL from being http://sp2013/sites/TeamA to being http://intranet.contoso.com/sites/TeamA. In order to achieve this, we will use the following lines of PowerShell code:

$site = Get-SPSite "http://sp2013/sites/TeamA"
$site.Rename("http://intranet.contoso.com/sites/TeamA")
IISReset

*** Note that the code above will cause an outage. Ideally, if you have multiple sites to rename at once you can proceed with the renaming and then simply run IISReset once.

a-2) Backup Path Based Site Collections
Another, less prefered option is to convert the upgraded site collections to Host Name Site Collection by doing a backup our site, and then importing it back in as a Host-Named Site Collection. To backup the sites, I will be using the Backup-SPSite PowerShell cmdlets and will be backing up my data in the c:\Data folder of my server.

Backup-SPSite http://sp2013/sites/TeamA -Path C:\Data\TeamsA.bak

Backup

b-2) Restore the Site Collections as a Host Name Site Collection
We are now down to the last step of our migration process, restoring the backed up site collection as host-named site collections. This is achieve by calling the following line of PowerShell code:

Restore-SPSite http://intranet.contoso.com/sites/TeamA -Path "C:\Data\TeamsA.bak" -HostHeaderWebApplication http://sp2013

Restore

c) Navigate to your New Host-Named Site Collection
You are now done. Open your browser and navigate to your new Host-Named Site Collection to ensure everything is working as expected.
Browse

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.

LALD

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:

    http://prod.contoso.com/sites/Technology/DocLibrary/MyDocSet/MyDocument.docx

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).