Tag Archives: SharePoint 2016

Automating a tedious task: Testing SharePoint page performance

Here’s a quick and dirty PowerShell script that hits a supplied SharePoint-related URL and outputs the correlation ID so you can check the ULS logs to further investigate why the page took longer than expected to load.

The script takes three parameters:

  1. SharePointUrl: The URL to test. Can be a SharePoint site collection, site, list, library, page. A resource in SharePoint.
  2. numTries: The number of times to try hitting the URL. Default is 1000
  3. unnaceptableTime – how long you deem is “too long” — milliseconds (i.e. 1000 = 1 second)

When you run the script, it will try connecting to the SharePoint site repeatedly and output attempts that take too long.

When SharePoint receives requests from users, it times how long it takes to process the request and returns this time in the SPRequestDuration HTTP header (in milliseconds). This script compares the returned SPRequestDuration to the unacceptableTime parameter and if the request took longer, it will output the SPRequestGUID which you can then use with Merge-SPLogFile to pull the ULS logs for the request.

param (
	$SharePointUrl = "https://yoursharepoint.example.com/demo/TypicalSharePointSite/SitePages/SomePageToTest.aspx",
	# Number of times to try hitting the page
	$numTries = 1000,
	# Number of milliseconds we'll say is too long for the page to return
	$unacceptableTime = 8000	

$timesTooLong = 0

# Repeat the number of times specified by $numTries
for ($i = 0; $i -lt $numTries; $i++) {

	# Build our URL to query SharePoint
	# We're going to abuse the rev parameter to trick our session into not caching the results from each query
	$requestUri = $SharePointUrl + "?rev=$i"
	# Issue our request to the fine SharePoint Server
	$Request = Invoke-WebRequest -Uri $requestUri -UseDefaultCredentials
	# The request took too long so send out the details
	if ([int]$Request.Headers["SPRequestDuration"] -gt $unacceptableTime) {
		Write-Output "$($Request.Headers["SPRequestGuid"]) $($Request.Headers["SPRequestDuration"])ms $requestUri"

Write-Output "$timesTooLong request(s) took longer than $($unacceptableTime)ms"
Share Button

Clear the Configuration Cache in a SharePoint 2010, 2013, or 2016 farm

Here is a script that will clear the SharePoint Configuration Cache on all servers in the farm. This is a more compact script than the one I previously released.

Simply copy to one of the servers and run in an elevated PowerShell window. The script will determine where the configuration cache is stored on all servers in the farm, stop the timer services, clear the cache, reset the counter, and start the timer services again.

This script is provided as-is.

Clear the Configuration Cache in a SharePoint 2010, 2013, or 2016 farm
Clear-SPConfigCache.ps1 will:
 1. Stop the SharePoint Timer Service on all servers in the farm
 2. Delete all xml files in the configuration cache folder on all servers in the farm
 3. Copy the existing cache.ini files as a backup
 4. Clear the cache.ini files and reset them to a value of 1
 5. Start the SharePoint Timer Service on all servers in the farm

Clear-SPConfigCache.ps1 will work in either single-server and multi-server farms.

Run in an elevated SharePoint Management Shell

Author: Jason Warren

 http://jasonwarren.ca/ClearSPConfigCache ClearSPConfigCache.ps1
None. Clear-SPConfigCache.ps1 does not take any input.

Text output that describes the current task being performed.


Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction Stop
$farm = Get-SPFarm
$ConfigDB = Get-SPDatabase | where {$_.Name -eq $Farm.Name}

# Configuration Cache is stored in %PROGRAMDATA\Microsoft\SharePoint\Config\[Config ID GUID]
# %PROGRAMDATA% is C:\ProgramData by default, it is assumed it's in the same location on all servers in the farm
#	i.e. if it's X:\ProgramData on one server, it will be X:\ProgramData on the others
# We'll be connecting via UNC paths, so we'll also change the returned DRIVE: to DRIVE$
$ConfigPath = "$(($env:PROGRAMDATA).Replace(':','$'))\Microsoft\SharePoint\Config\$($ConfigDB.Id.Guid)"

# Stop the timer service on all farm servers
$TimerServiceName = "SPTimerV4"
foreach ($server in $farm.TimerService.Instances.Server) {
	Write-Output "Stopping $TimerServiceName on $($server.Address)..."
	$service = Get-Service -ComputerName $server.Address -Name $TimerServiceName
	Stop-Service -InputObject $service -Verbose
} # Foreach server

$TimeStamp = Get-Date -Format "yyyymmddhhmmssms"

# Clear and reset the cache on each server in the farm
foreach ($server in $farm.TimerService.Instances.Server) {

	Write-Output $server.Address
	# build the UNC path e.g. \\server\X$\ProgramData\Microsoft\SharePoint\Config\00000000-0000-0000-0000-000000000000
	$ServerConfigPath = "\\$($server.Address)\$($ConfigPath)"
	# Delete the XML files
	Write-Output "Remove XML files: $ServerConfigPath..."
	Remove-Item -Path "$ServerConfigPath\*.xml"
	# Backup the old cache.ini
	Write-Output "Backup $ServerConfigPath\cache.ini..."
	Copy-Item -Path "$ServerConfigPath\cache.ini" -Destination "$ServerConfigPath\cache.ini.$TimeStamp"
	# Save the value of "1" to cache.ini
	Write-Output "Set cache.ini to '1'..."
	"1" | Out-File -PSPath "$ServerConfigPath\cache.ini"

	Write-Output ""
} #foreach server

#Start the timer service on all farm servers
foreach ($server in $farm.TimerService.Instances.Server) {
	Write-Output "Starting $TimerServiceName on $($server.Address)..."
	$service = Get-Service -ComputerName $server.Address -Name $TimerServiceName
	Start-Service -InputObject $service -Verbose
Share Button

Allow users to edit values for this property is disabled

In SharePoint Server 2016 and using AD Import to sync your user profiles, when you add a custom property the Allow users to edit values for this property setting is disabled:


Never fear. Save the property and edit it again. The setting is now enabled and you can check it:


Share Button

Ignite 2015 Summary: What’s New in SharePoint 2016 for IT Professionals

Update May 12, 2015: Bill Baer has a post up, What’s new in SharePoint Server 2016 Installation and Deployment, talking about what’s new in SharePoint 2016 that details all of this more “officially.” Check out too the UserVoice Customer Feedback site for SharePoint which has discussion on features suggested from the community. As well, I do wish to point out everything presented in the session and reported here is information as we know today. Any of it is subject to change at Microsoft’s discretion.

SP2016-TheaterBill Baer delivered a non-stop 75 minute overview Wednesday morning of the new things to look for in SharePoint 2016 relevant to IT pros. In this post I’m going to summarize the session with the items that I was able to note. There’s a lot of info here (and sadly I know I missed some things) so grab a snack or save for later. Also, just a warning that the photos included are not archive quality and were taken with an actual potato.


Roadmap and Where We are Today

SharePoint 2016 RTM is about a year away. Today Bill was showing off build 16.0.4021.1201. I don’t know if there is an official name for this build so I’ll just call it the Ignite Preview. The codebase used for SharePoint 2016 combines code from SharePoint 2013 and SharePoint Online.


Generally the requirements for SharePoint 2016 are similar to SharePoint 2013. When it comes to hardware the specs appear the same and with the software you’ll see the same prerequisites and requirements for the latest versions of Windows and SQL Server.


The hardware requirements are similar to SharePoint 2013.

Topology Memory Processors Disk
Single Server 16-24 GB x64, 4-cores 80 GB system
Farm Server 12-16 GB x64, 4-cores 80 GB system

We didn’t get any info about network requirements. It’s probably safe to assume it’s the same as 2013: 1 Gbps link with < 1 ms latency between servers. No word on stretched farms though we know Microsoft advises against them so if they are supported I expect similar guidance to 2013.

Operating Systems

For the SharePoint 2016 servers currently only the latest version as well as the next version are supported:

  • Windows Server 2012 R2
  • Windows Server 10 (or is it Windows Server 2016?)


The prerequisite software is similar to what was required in SharePoint 2013:

  • Windows Management Framework 3.0
  • Application Server Role
  • Web Server (IIS) Role
  • Microsoft .NET Framework 4.5.2
  • Update for .NET Framework 4 (KB 2898850)
  • Microsoft SQL Server 2012 Native Client
  • Microsoft Identity Extensions
  • Microsoft Sync Framework Runtime v1.0 SP1 x64
  • Windows Server AppFabric 1.1
  • Windows Identity Foundation v1.1
  • Microsoft Information Protection and Control Client (MSIPC)
  • Microsoft WCF Data Services

SQL Server

SharePoint 2016 will work with the latest current version of SQL Server: SQL Server 2014 64-bit with Service Pack 1. As well, Microsoft is planning to support any future SQL Server 201x 64-bit version.


SharePoint 2016 SharePoint 2016 will provide the ability for administrators to specify the server’s role when joining it to the farm. Selecting a role installs only the bits needed to run the services needed by the role. This will keep installations to a minimum. I think this is what is meant by “MinRole”. This step is performed using the SharePoint Products Configuration Wizard (pictured left), PSCONFIG.EXE, and presumably the New-SPConfigurationDatabase and Connect-SPConfigurationDatabase cmdlets. SharePoint servers can run as one of the following 6 roles:

  • Web front end (user services)
  • Search
  • Application (robot services)
  • Distributed Cache (caching services)
  • Special Load (the “2013 way”)
  • Single Server Farm (not standalone!)

Web Front End

The web front end role is for servers that physically deliver services to the user (user services), such as page rendering, sync client, OneNote, Excel Services, user profiles, sandbox code, Project, and Subscription Settings.


You have the ability to dedicate search serivices to a single server. I feel this will encourage behaviours that existed with SharePoint 2007, though I think this is really for farms that are scaled out. With SharePoint 2013 the best practice for medium farms was to put the query component on the WFE servers to minimize the network traffic needed to execute a search. With this dedicated role I’m not sure if the guidance will change. Expect more on this in the coming year.


Services that do not interact directly with end users fall into this role. Microsoft is calling these services “robot services” and includes provisioning services, timer jobs, and search (I’m going off the slide and it says search).

Distributed Cache

Microsoft is driving the point home that as a best practice you need dedicated distributed cache servers by making it a role that is assigned to the server. When selected you can’t run other services.

Special Load

Special Load allows you to configure the server like you did in SharePoint 2013 — all of the bits are present and you select which services it will run. This role is required on a server that runs a custom service application and for scenarios where you want to run services from different roles. For example if you wanted to run distributed cache on a web front end server in a small farm you would use the Special Load.

Single Server

Microsoft has removed the ability to create a standalone farm (finally!). MSDE and SQL Express are no longer supported database systems. You still have the ability to create a single-server farm running SharePoint and SQL Server in scenarios like development or small environments. For these instances use the Single Server role.

Specifying the role using the command line

Bill showed us the experience of selecting the role using the configuration wizard and confirmed that both PSCONFIG.EXE and existing PowerShell cmdlets (my guess is New-SPConfigurationDatabase and Connect-SPConfigurationDatabase) will have a new parameter that you can use to specify the MinRole. When (if) the 2016 hands-on lab is available I’d like to take a look at this.

MinRole Health Analyzer Rule

SP2016-Servers-in-FarmSharePoint 2016 will have health analyzer rules that run daily to enforce the selected MinRole of the server.  The rule will compare the services installed on the server to the expected configuration. If it’s not in compliance administrators will receive the alert. This rule does not run on servers that are assigned the Special Load MinRole. This information is also (as of now) surfaced in the Servers in the Farm page in Central Administration (pictured, left).

Distributed Cache Service

Distributed Cache will still be present in SharePoint 2016 and as mentioned it’s one of the MinRoles you can select when joining the server to the farm. Distributed Cache will use and Microsoft will support AppFabric even though the Windows Server team has deprecated and announced the end of life for this caching product. I’m assuming the prerequisites will be a later CU so as to not encounter the distributed cache bug that was present in SharePoint 2013 farms running AppFabric CUs earlier than CU3. There are performance changes that will allow for more connections and the service can be configured to be available 99.99% of the time.

Boundaries and Limits

Some significant increases in the boundaries and limits since 2013:

Content Database Size Site Collections per Content Database List Threshold Maximum File Size Indexed Items
In the range of TBs 100,000 > 5,000 10 GB and removed character restrictions 500 million items

When Bill revealed the content database size, list threshold, and max file size increases the crowd went nuts.

SAML Authentication is the Default

Whether your credentials live in Active Directory, Azure AD, Office 365, another LDAP directory store, a custom source, or the users are external to your organization,  you’ll be using claims-based authentication in SharePoint 2016. Microsoft is moving away from domain-based credentials and towards authentication that uses SAML claims. Windows authentication will still work, though it sounds like it’s going the way of classic auth in SharePoint 2013: available only through PowerShell.


SharePoint 2016 supports upgrades from SharePoint 2013. Microsoft was considering incorporating the ability to upgrade from SharePoint 2010 and even solicited feedback from the public, but this won’t happen. The upgrade process is the same as it was for 2010 to 2013: Database attach and third-party tools. Sites running in 2010 (14) compatibility mode need to be upgraded to 2013 (15) compatibility mode before the upgrade will work.

Performance and Availability

Taking direction from Microsoft’s learning of running SharePoint at scale with Office 365 there are a number of improvements: Distributed cache connections (noted above), BITS protocol support for file transfers and fast site creation leveraging SPSite.Copy (I think this is new because I can’t find it on MSDN) of an existing site collection rather than programmatically creating from scratch.

User Profile Synchronization

The User Profile Synchronization Service will not appear in SharePoint 2016. In its place a full install of FIM is required for bidirectional sync, and for unidirectional support the AD Sync that was present in SharePoint 2007 and 2013 (AD Import).

Project Server

SP2016-Project I didn’t catch. Here’s the slide. Hopefully someone can fill in the blanks for me.



CUs sound like they’ll be a thing of the past. The update model is changing and will allow for farms to remain online while being patched. The updates will no longer rival the size of the original media or require spanning additional CAB files due to the +2 GB size. Microsoft is claiming updates will be painless. If this is true I will be very happy however I am not holding my breath (if only to not get my hopes up).

Durable Links

Since the dawn of HTTP and HTML broken links have plagued this great planet. SharePoint 2016 will end this once and for all with Durable Links — URLs will have a resource ID (I’m assuming a GUID) that will persist whether the item the URL refers to is renamed or moved. I’m not sure if this will play nice with records and look forward to seeing it in action.

Telemetry (Analytics)

Real-time telemetry similar to what you see in Azure and Office 365. The photos I took are so bad it looks like there was an octopus on the screen. From what I remember what I saw looked pretty nice and will be pleasing to people who missed analytics in 2013.


There are improvements to discovery features including the ability to reach out to Office 365 in eDiscovery.

Cloud Search Service Application

For every company that wanted to implement or did implement hybrid search, this service is for you. The Cloud Search Service Application unifies the search experience for SharePoint Server 2016 and SharePoint Online and provides a single result set that contains items from both locations. Every customer who balked at having two results sets on the page and didn’t implement hybrid search will want SharePoint 2016 immediately.

Hybrid Scenario Picker

There is now a wizard that will configure hybrid scenarios for you. Hybrid search, OneDrive for Business, BCS. Instead of manually setting DNS entries, running obscure PowerShell cmdlets, decyphering TechNet articles, and installing SSL certificates, in SharePoint 2016 you will be able to run a wizard and have a beer.

Pre-release availability

While not discussed in the session, Microsoft has provided a pre-release version of SharePoint 2016 to customers in the TAP program. I’m not in the TAP so I can’t comment on this version, not that I could anyway since it likely comes with an NDA. This version is pre-alpha software and still has a long way to go. From what I hear it has brought with it some cloud concepts. It’s too early to tell how it is, all I can say for now is what Microsoft is saying: SharePoint 2016 will be the most tested version of SharePoint before it hits RTM.


My Summary

There was a ton of info we got today, and as I look at it all I have more questions now then when I went in. To me there are lots of new features to like: Cloud Search Service Application, Durable Links, similar requirements to 2013, and the hybrid implementation. Honestly the MinRole feature confuses me given that was the way Microsoft was heading in the past. I remember SETUP.EXE for SharePoint 2003 and 2007 had the option to select the role of the server. It’s likely different but I’m not seeing it. I’m expecting many customers will simply select Special Load for all their servers. The new update model sounds interesting and if Microsoft pulls it off it will make every SharePoint administrator’s day.

There’s still a year before RTM so there’s still lots of time to reveal new features, remove features, and change features. I’m looking forward to it, maybe RTM will be announced at Ignite 2016? 🙂

Share Button