Here is something I use when I want to perform an IISRESETacross an entire SharePoint farm. Its useful if you have a large SharePoint farm.
Oh – yea, this will take down your farm while the IISRESET is restarting the services, so its best to test this on a non production environment first. Ensure you have an outage/agreed maintenance window to perform this task on a production farm.

All you got to do is spin up PowerShell on any SharePoint server in the farm and run this:

Write-Host -ForegroundColor Blue "IIS will  be reset across the entire farm"
Add-PSSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue
[array]$servers= Get-SPServer | ? {$_.Role -eq "Application"}
foreach ($server in $servers)
     Write-Host -ForegroundColor Yellow "Attempting to reset IIS for $server"
        iisreset $server /noforce "\\"$_.Address
        iisreset $server /status "\\"$_.Address
        Write-Host -ForegroundColor Green "IIS has been reset for $server"
Write-Host -ForegroundColor Green "IIS has been reset across the SharePoint Farm"
Start-Sleep -Seconds 5


When troubleshooting SharePoint issues, the best way to filter out all the noise from your log files and sort it for easier troubleshooting is to use the ULS Log viewer tool.

Refer to my blog post on the ULS Log viewer comparison and verdict to get a feel for the other options and see how I got to my conclusion there.

However, this ULS Log viewer tool does not display logs from other servers in the SharePoint farm, unless obviously its a single server farm.

The way to help you with a multiserver farm is to run the Merge-SPLogFile command in the SharePoint management shell. This command “merges” all logs from other servers in the farm and combines them into one ULS log file on the local server. That file can then be opened in your favourite ULS log viewer for troubleshooting.

Note: this works in both SharePoint 2013 and SharePoint 2010.

So how do we use it?

Here is an example of how I use it to grab all logs between say 10AM and 10:30AM on the 23rd July 2013:

Merge-SPLogFile -Path "D:\Temp\MergedLog-20130723-1000-1030.log" -StartTime "23/07/2013 10:00:00" -EndTime "23/07/2013 10:30:00"

If I know the correlation ID, then I would recommend you run the following command after updating it to your correlation ID:

Merge-SPLogFile -Path D:\Temp\MergedLog-419ac99c-81b2-0077-378d-3c23767d2955.log -Correlation 419ac99c-81b2-0077-378d-3c23767d2955



Merge-SPLogFile looks across all the servers in the farm, aggregates the logs with the correlation ID and creates the aggregated .log file.
The merged log file containing only the  information you specified and require. In this case, a certain correlation ID.
The merged log file containing only the information you specified and require. In this case, a certain correlation ID.


Open the log file up in ULSViewer!
Open the log file up in ULSViewer!


There are a lot more examples of what you can do with Merge-SPLogFile you can get by typing this in the SharePoint management shell:

Get-help Merge-SPLogFile -examples 

This post is meant to give SharePoint Administrators an deeper look into the Distributed Cache along with some links to other resources on the internet.

SharePoint 2013 uses the AppFabric (Caching) by Microsoft. Read here for a background on AppFabric. AppFabric Caching stores serialised managed objects in a ‘cache cluster’. The cache cluster consists of one or more machines (Cache Hosts) that pool their available physical memory. This pooled memory is presented  and used by SharePoint as a single source of caching memory.

How is it used in SharePoint
SharePoint uses the Distributed Cache to store data for very fast retrieval across all entities. The Distributed Cache service provides in-memory caching services to several features in SharePoint Server 2013. Some of the features that use the Distributed Cache service include:
· Newsfeeds
· Authentication
· OneNote client access
· Security Trimming
· Page load performance

In SharePoint Server 2013, there are several caches that exist, all of which depend on the Distributed Cache service.
Different caches that depend on the Distributed Cache service as indicated in the following table:

Name Cache name
Login Token Cache DistributedLogonTokenCache
Feed Cache DistributedActivityFeedCache This cache stores activities and conversations for use by the feeds on a user’s My Site.
Last Modified Time Cache DistributedActivityFeedLMTCache This cache stores time stamp information for all Feed Cache entities
OneNote Throttling DistributedBouncerCache
Access Cache DistributedAccessCache
Search Query Web Part DistributedSearchCache
Security Trimming Cache DistributedSecurityTrimmingCache
App Token Cache DistributedServerToAppServerAccessTokenCache
View State Cache DistributedViewStateCache
Default Cache DistributedDefaultCache This cache can be used by any feature.


AppFabric is a required component for SharePoint 2013 and is installed as part of the prerequisite installer. Thus each server automatically becomes part of the ‘cache cluster’. There is nothing to configure here as SharePoint does this automatically.

Farm Architecture – modes
Here is some terminology that will be useful when talking SharePoint architecture and topology:
There are two ‘modes’ for Distributed Cache – A collocated mode or a dedicated mode. The Distributed Cache is started and run on all WFE and APP servers by default. If you have over 10000 users, you should look into a dedicated server (dedicated mode) Distributed Cache. Dedicated Mode simply means all other services are turned off and more memory is allocated to the Distributed Cache.

Farm design
While designing your topology, could consider starting the Distributed Cache service on your WFE servers (for redundancy) and stop the Distributed Cache Service on the APP server if you are concerned with ‘overhead’ caused by all the other services running on the APP server. You can consider a scale up plan if you are low on resources or scale out (by starting the Distributed Cache on other servers in the farm).
Finally it boils down to memory allocation at the end of the day. By default, the Distributed memory allocation size defaults to a value of 10 percent of total physical memory when SharePoint Server 2013 installs. You can change the memory allocation with the Update-SPDistributedCacheSize cmdlet.

Here is a link that may help on the ‘right approach’: (note the ‘Capacity planning for the Distributed Cache service’ section).

The Distributed Cache service can be stopped or started via the Central Administration or via PowerShell.

Servers can be added or removed from the ‘Cache cluster’ too. When removing the server, the Distributed Cache service is stopped, then unregistered from the server. Unregistering the Distributed Cache service means that you will not see the Distributed Cache service listed on the Services on Server page in Central Administration. Adding a server means that you will see the Distributed Cache service listed on Services on Server page in Central Administration.

To add a server and start the service in PowerShell: Add-SPDistributedCacheServiceInstance

To remove a server and stop the service in PowerShell:

To stop (not remove) the Distributed Cache service by using Central Administration: In Central Administration, click Application Management. In Service Applications, click Manage Services on Server. On the Services on Server page, locate the Distributed Cache service. If the Distributed Cache service is started and you want to stop the service, under Action, click Stop.

To stop (not remove) the Distributed Cache service by using Windows PowerShell: At the Windows PowerShell command prompt, run the following command: $instanceName =”SPDistributedCacheService Name=AppFabricCachingService” $serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring()) -eq $instanceName -and ($ -eq $env:computername} $serviceInstance.Unprovision()

To check existing memory allocation of the Distributed Cache Host:
Get-AFCacheHostConfiguration -ComputerName ComputerName -CachePort “22233”

To reconfigure the cache size of the Distributed Cache Service:
Update-SPDistributedCacheSize -CacheSizeInMB CacheSize

Firewall configuration considerations

The Distributed Cache service uses the following communication ports:

The Distributed Cache can be monitored using below performance counters in Perfmon:

SharePoint Distributed Cache Counters
Cache Data Transferred Per Sec
Cache Hit Count
Cache Hit Ratio
Cache Miss Count
Cache Read Requests per sec
Cache Write Requests per sec
Total Cache Read Requests
Total Cache Write Requests

Additionally, there are three groups of ‘AppFabric’ counters available. Note there are multiple instances – indicating the different caches present in the Distributed Cache.
AppFabric Caching:Cache
AppFabric Caching:Host
AppFabric Caching:Secondary Host

Important Distributed Cache resource
Manage the Distributed Cache service in SharePoint Server 2013
Plan for feeds and the Distributed Cache service in SharePoint Server 2013

The above link shows how you can:

  • Change the memory allocation of the Distributed Cache service
  • Add or remove a server in a Distributed Cache cluster
  • Perform a graceful shutdown of the Distributed Cache service
  • Change the service account
  • Repair a cache host

Further reading
5 Minute Cheat Sheet on SharePoint 2013 Distribution Cache
Leveraging AppFabric for custom caching in SharePoint 2013
AppFabric Distributed Caching and SharePoint 2013
AppFabric Caching and SharePoint: Concepts and Examples (Part 1)
AppFabric Caching (and SharePoint): Configuration and Deployment (Part 2)
How to get Distributed Cache size (SharePoint 2013)
Leveraging AppFabric for custom caching in SharePoint 2013
Cache cluster is down, restart the cache cluster and Retry

Here is a summary of the steps to create a new Host Named Site Collection (HNSC)

  • Create a new Web Application – default Web App on port 80 or use an existing Web Application.  I chose http://HNSCWebApp as my Web Application – the default Web App listening on port 80 on all my Web servers in the farm.
  • Note – HNSC can be created on a non default Web Application but you’ll need to add bindings in IIS for your HNSC as the Web Application isn’t listening to all port 80 requests and would need to know about the HNSC it hosts. Thats why a lot of blogs usually specify HNSCs on default web apps, because adding IIS bindings can get messy. But its worth a note in this post.
  • Decide what your new Site Collection unique URL should be. I chose http://test and http://teamsite to run off a Team Site template.
  • Run the following in the SharePoint Management Shell:
$w = Get-SPWebApplication http://hnscwebapp
New-SPSite http://test -OwnerAlias "testdomain\testowner" -HostHeaderWebApplication $w -Name "test" -Template "STS#0"
New-SPSite http://teamsite -OwnerAlias "testdomain\testowner" -HostHeaderWebApplication $w -Name "teamsite" -Template "STS#0"
  • Ensure that you create a dummy ‘root’ site collection with a site template http://hnscwebapp. Its required for Search & Send to Other location.
  • Configure kerberos for your Host Name site collection.
  • Create a Managed Path if required (New-SPManagedPath)
  • You can create new zones for HNSC so that it can be accessible via a different name.


My recommended links for you to read:

Wicto Wilen – Clearing up the confusion with Host Named site collections and Path Based site collections

Marko Rosberg – For more information on creating Host Named Site Collections  and App host configuration:

Kirk Evans – Host Named Sited Collection in SharePoint 2010 (applies to SharePoint 2013):

Technet – Host-named site collection architecture and deployment (SharePoint 2013):

Brian Farnhill – Multiple zones for host named site collections in SP2013

A few recent migrations I worked on required me to export and import all Farm Solutions from one SharePoint farm to another SharePoint farm. There are a few blogs and tools available to get this done.

However, I came across Shane Young’s brilliant one line PowerShell command to get the job done!


Export all of the Solutions from your farm:

(Get-SPFarm).Solutions | ForEach-Object{$var = (Get-Location).Path + "\" + $_.Name; $_.SolutionFile.SaveAs($var)}


Import all of the Solution into another farm

Get-ChildItem | ForEach-Object{Add-SPSolution -LiteralPath $_.Fullname}

Note: Shane’s blogpost has the third step to deploy all these solutions. Not all Web Applications may need to have farm solutions deployed to them. So – you might want to plan this one, rather than deploy all these solutions in one go.


Check out Shane’s blogpost:

A good practice is to move IIS off the system drive to another such as D:

Ok, so you tell your Server guys but they miss out on an important step such as updating the registry to the new D:\inetpub… location. You dont check this since you think they know what they are doing and go ahead and install SharePoint and once you are done, you realise that your Central Admin website has been installed and its virtual directory is located on C: – the system drive.

What now?