Merging SharePoint ULS Log Files from multiple servers

Troubleshooting a SharePoint issue and tracking a correlation ID becomes all of the more cumbersome when the underlying SharePoint topology is spread across multiple web and application servers.

Running the Powershell command ‘Merge-SPLogFile will indeed merge and wrap the latest ULS logs into a single file, although this can become very large depending on your Farm activity and ultimately, may difficult to open and work with.

Ideally, you should restart the SharePoint Tracing Service, which in turn generates a new log file, and then replicate the issue once more to regenerate a correlation ID. Once merged, these new, smaller log files will then easy to analyse.

The simple Powershell script below should be run from a SharePoint server with your Farm and can be used to restart the Tracing service and consolidate the logs. There is a 2 minute ‘sleep’ cycle following the restart of the Tracing service, and this is when you should replicate the problem. If replicating is convoluted and may exceed 2 minutes, edit the script accordingly.


Write-Host “Restarting SharePoint Tracing Service across all Servers”

$targetcomputers = (“SPserver01″, ” SPserver02″, ” SPserver03″, ” SPserver04″)

$targetcomputers | % { Restart-Service -InputObject $(Get-Service -Computer $_ -Name SPTraceV4) }

Write-Host “Replicate issue to generate correlation ID”

Start-Sleep -s 120

Write-Host “Merge Log Files and generate output”

Merge-SPLogFile -Path “e:\merged.log” -overwrite


Remove Web App IIS Application Pool

The Powershell command ‘Get-SPServiceApplication’ will only list IIS Applications related to SharePoint Service Applications across your Farm:

However, there may be a time when you want list the Web Application IIS Pools, and more importantly, delete one (once you’ve transferred any associated services).

There is no way to do this with Central Administration, so apply the following in Powershell:


  • $contentapppools = [Microsoft.SharePoint.Administration.SPWebService]::ContentService.ApplicationPools
  • $contentapppools


Now, find the GUID of the Application Pool and ‘remove’

  • $contentapppools.Remove(“GUID”)

SQL 2012 SP1 ‘breaks’ Cross-Farm SSRS Service Application

Establishing SQL Server Reporting Services in SharePoint Integrated mode was something of a burden until the release of SQL 2012. With SQL 2005 and SQL 2008 the majority of the configuration steps were manual and implementing delegation for Kerberos, meant editing a number of Reporting Services configuration files – it was quite cumbersome and pretty much open to failure if you didn’t follow all of the details.

The introduction of SQL 2012 improved things dramatically as SSRS could now be implemented as a conventional SharePoint Service Application. Recently I was working with a customer who were trying to publish SSRS reports across two SharePoint 2010 Farms and experience having issues – so much so, that it eventually led to engaging Microsoft. And it’s the outcome of this engagement which is the pertinent point of this blog.

The two SharePoint Farms we attempted to instantiate in a Trusting/Publishing service application set-up were identical in terms of patch-level, while the Publishing Farm was running SQL Server Reporting Services 2012 SP1 CU4 in SharePoint Integrated mode. The Publishing Farm was only recently patched to SP1 CU4 to facilitate the introduction of Power View (this is the minimum patch level requirement).

Steps for the required configuration are captured in the following article which we attempted to follow:

Establishing a trust between the Farms was not an issue and we passed this part of the configuration with flying colours:

However, as soon as I tried to browse Cross-Farm to the library which contained the SSRS Reports on the Publishing Farm from the Consuming one, I was hit by an error. To reach this stage I would add the Report Viewer Web Part to the page (this Web Part is available once you’ve installed the SSRS Add-in to your Farm and activated the ‘Report Server Integration Feature’.


But as soon as a copied the direct link to the report in the ‘Report’ section, or even browsed for the Publishing Farm, I received the error below:

The item http://<publishingfarm>/site/report.rdl cannot be found –> Microsoft.ReportingServices.Diagnostic.Utilities.ItemNotFoundException

Interestingly, the inability to connect to remote SSRS reports was not evident if used the ‘Page Viewer’ Web Part – this worked absolutely fine. However, this web part is not really fit for purpose when trying to display SSRS Reports as it’s not dynamic in its resizing capabilities. For the business requirement, this wasn’t a workaround.

After spending a fair amount of time searching forums and hunting through the ULS Logs for a resolution, I turned to Microsoft for assistance and asked them to quantify whether any steps from the blog article were incorrect or missing?

As things transpired following a number of calls and WebEx sessions, MS came to the conclusion that the behaviour I was witnessing was caused by a code change introduced with SQL 2012 SP1. The Reporting Services product group have assessed the possibility of implementing a fix which should be addressed in the next SQL Service Pack.

So, the lesson to be learnt is stay with SQL 2012 RTM if you want to leverage SSRS as cross-Farm shared Service Application.





Export-SPWeb fails – ‘lack of disk space’

The ‘Export-SPWeb’ cmdlet provides a simple way of moving SharePoint content between sites. This command essentially exports all of your content into a series of .cmp files which can subsequently be re-imported to suit your requirements. If you want to dig deeper, you can even rename the files to .cab to expose the key Manifest.xml.

Last week I was exporting an entire site collection (don’t even ask why!) and the content database was around 85GB in size. The drive I was exporting too was 135GB but during the operation, it failed with Powershell reporting that there was ‘not enough space on disk’.

Having done some digging, I realised that the system drive was out of disk space due to that fact that during the export, all of the content appears to be copied to the ‘%USERPROFILE%\AppData\Local\Temp’ directory – which happened to be my system drive with only 40GB of space.

The fix is to remap the %Temp% variable to a drive with suitable space (restart is required)

And now I was able to successfully export the SharePoint content


Gantt Chart Web Part error

I recently came across an issue where I was unable to open ‘Site Actions‘ on one particular SharePoint 2010 page – I was halted by the following error:

An error has occurred with the data fetch. Please refresh the page and retry’

The page in question contained a number of Web Parts, and through a method of elimination, I soon discovered that it was the ‘Gantt Chart’ Web Part view which was causing what was seemingly a Javascript error message.

A quick, simple fix was to remove the Gantt Chart Web Part from the page, then re-add and the problem was solved. But what has caused this issue?

The SharePoint 2010 Farm I was working against was fully patched to February 2012 CU, but had recently been updated with the April 2013 SharePoint Foundation security update:

I raised this with MS who were unaware of this issue, but successfully replicated the problem to one of their test environments. (which is always a relief as you’re otherwise left pondering ‘why me’?)

Patching the SharePoint Farm to the full April 2013 CU patch level permanently resolves the problem.

The perils of the SharePoint Cumulative Updates

There has always been trade-off when it comes to applying Cumulative Updates to your SharePoint Farm. You want to keep your Farm stable, secure and up-to-date, but there’s always the concern that an over-aggressive CU may cause some functionality issues for your end user. The recommended stance when it comes to CU’s is to only apply them to your Farm if there’s a compelling reason to do so – it fixes something!

Generally, SharePoint Service Packs are released by Microsoft having undergone a far more vigorous testing cycle in comparison to CU’s, and if there’s anyone out there still running SharePoint 2010 RTM and not SP1 I’d ask the question ‘why’?

Patching SharePoint is pretty simple; download the patch, apply it to every SharePoint Server in your Farm (excluding SQL or FAST), and then run PSConfig (starting with the Server(s) which are running Central Administration).

Despite this simplicity, I recently came across a SharePoint Farm where the build version wasn’t what I expected. The Farm had been manually patched to February 2012 CU but the build version was displaying April 2013 CU – the culprit, a SharePoint 2010 Foundation patch had been deployed, mistaken as a Windows Security patch. ( PSConfig had also been run as the databases had been showing the ‘Upgrade is required’ warning, and this has caused the Farm build version to iterate.

Unfortunately there is no roll-back option with SharePoint patches and therefore the only valid approach was to install what was essentially a year’s worth of SharePoint Server patches to bring the Farm comprehensively up to April 2013 CU ( And this is where the fun (actually pain) begun.

When I attempted to run the April 2013 CU SharePoint Server patch, I was stopped in my tracks by the following message:

SharePoint believed that the patches were already installed, so the way to circumvent this was to change the following registry value (on all the servers) to reflect the former build version (in this instance, Feb 2012 CU)

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14.0

14.0.06117 (Feb CU 2012)


Then, if I pass a switch below to the patch updater executable, we bypass the version check which is causing the update to fail:

ubersrv2010-kb2767793-fullfile-x64-glb.exe PACKAGE.BYPASS.DETECTION.CHECK=1




RSS Viewer Web Part failing after installing KB2810059

I was recently troubleshooting against a SharePoint 2010 Farm where users were suddenly reporting that the RSS Web Part was not loading when it was active on a page which also had the Content Editor Web Part deployed. So, what’s changed?

I soon discovered that although the Farm had only been patched from a SharePoint Server perspective to February 2012 CU, the build number was reflecting 14.0.6137.5002 – which is April 2013 CU. Further investigation led to me discovering that a SharePoint Foundation patch (ttp:// had been deployed by mistake as it was perceived to be a Windows Security patch. Subsequently, any SharePoint site which had Publishing turned on was failing to load the RSS Viewer when it shared a page with the CEWP.

Having consulted Microsoft about this issue, I was pleased to hear that this has been recognised as a bug…….although it won’t be fixed until either June 2013 CU, or Service Pack 2 – whichever is released first.

The suggested workaround was to either ‘Disable Web Page Security Validation’ at the Web App level (OK, it works, but it’s not recommended due to the security concern)

Or, apply the following Javascript:

)      Page Level: Adding a Content Web Part to the page that is having the problem, and using a custom script with it.

a)     Save the following JavaScript to a .txt file and upload the file to any document library in the root of the site. 

<Script Type=”text/javascript”> 

function CustomUpdateFormDigest() 

if(window._spPageContextInfo != null) 

var $v_2 = window._spPageContextInfo; 

var $v_3 = $v_2.webServerRelativeUrl; 

var $v_4 = window._spFormDigestRefreshInterval; 

UpdateFormDigest($v_3, $v_4); 



b)    Add a “Content Editor” web part from “Media and Content” web parts category to the page not rendering web parts.

c)     Edit the “Content Editor” web part and link its content to the .txt file path we created and uploaded in Step 1 using the “Content Link” field.

d)    Hide the web part by checking “Hidden” under “Layout”.

e)     Save and publish the page.