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

Advertisements

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

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:

http://support.microsoft.com/kb/2810059

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. (http://support.microsoft.com/kb/2810059). 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 (http://support.microsoft.com/kb/2775353). 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://support.microsoft.com/kb/2810059) 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); 





CustomUpdateFormDigest(); 

</Script>

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.

 

 


 

Excel Services & SharePoint 2010 = Confusion!

Over the past few weeks I have received some calls regarding issues with Excel Services and namely, rendering from the browser. Let’s not forget that Excel Services in SharePoint is a whole lot more than the ability to be able to publish and open a workbook without requiring a native client. Business Intelligence scenario’s which allow complex workbooks to connect with external resources and update dynamically, are now becoming fundamental in the corporate workplace and Microsoft have invested a lot of time and effort ensuring Excel Services is still a major reason for investing in SharePoint. (and there’s more offerings to come in SharePoint 2013)

The Excel Services SharePoint 2010 Service Application in its most basic, simplistic and perhaps convention role, allows users to open a workbook in a browser – no great shakes there. However, it doesn’t work OOTB, and therefore in this blog I will show you what to look for if you receive errors when you choose the ‘open in browser’ option.

  • Create ‘Excel Services’ Service Application (ESA)

This can be achieved via Central Admin or Powershell. Remember to start the service once created. If you don’t have an ESA provisioned, you will receive the following error when you attempt to render from a browser:

 

And if you haven’t started the ‘Excel Calculation Services’ from within ‘Manage Services on Server’, you receive the following:

 

  • Grant IIS App Identity SQL access to Content Database

As a best practice, the IIS application pool identity of your Excel Services Application should be a domain/service account. If this is the case (and it should be), this service account needs to be granted SQL ‘dbo’ permissions against the Content Database of your Site Collection(s). This setting is not applied automatically even when you provision Excel Services and determine which proxy group it becomes a member of. If you miss this step, you will see the following error:

Which corresponds to the following in the ULS logs:

Microsoft.Office.Excel.Server.CalculationServer.Proxy.ServerSessionException: The workbook cannot be opened. at Microsoft.Office.Excel.Server.CalculationServer.Proxy.ServerSession.ExecuteWebMethodCore(WebMethodType webMethodType, WebMethodBehaviorAttribute webMethodBehavior, CommandParameter parameter, CoreWebMethod coreWebMethod)     at Microsoft.Office.Excel.Server.CalculationServer.Proxy.ServerSession.ExecuteWebMethod(WebMethodType webMethodType, WebMethodBehaviorAttribute webMethodBehavior, CommandParameter parameter, CoreWebMethod coreWebMethod)     

Excel Services should now be your default option for open Excel workbooks, although this can be changed on a per Document Library basis if there is a requirement to use a local Excel client instead.

Document Library > Library Settings > Advanced Settings > Default open behaviour for browser-enabled documents: – ‘Open in the client application’


The screenshot above is the default OOTB option, although there is a SharePoint Feature which changes the third option ‘Use the server default (Open in the browser), to ‘Use the server default (Open in the client application) Once activated, all Document Libraries will open in the Client unless directed otherwise



  • And don’t get confused with the Office Web Apps suite!

Remember, if you want to use the Office ribbon to compliment browser rendering, you will have to purchase an ‘Office Web Apps’ license and provision as a convention Service Application: