Intermittant slowdown issues for SharePoint (Pt 3/3) – Resolving

1 Local certificate installation

The SharePoint root certificate can be added to the Trusted Root Certificate Authorities store on the SharePoint servers. This removes the need to CRL check over the internet.

The following Microsoft support KB details the issue with the SharePoint root certificate and details adding the certificate to the local store. This should be applied on all the SharePoint servers in the farm.

• Site Slowness due to SharePoint STS Certificate CRL Checking
  http://support.microsoft.com/kb/2625048

2 Local CRL installation

Common Microsoft CRLs can be installed locally, removing the need to download them via the internet.

The following TechNet article is aiming at BizTalk on Windows Server 2003, but covers the issue as an operating system optimisation:

• Optimizing Operating System Performance
  http://msdn.microsoft.com/en-us/library/cc615012(v=bts.10).aspx

3 current resolution

On the system I’ve been working on, I’ve had to apply both fixes to solve the issue.

I found the following certificates were required on the SharePoint system here to complete the fix (found by checking the CAPI2 event log)

1. http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl
2. http://crl.microsoft.com/pki/crl/products/CodeSignPCA2.crl
3. http://crl.microsoft.com/pki/crl/products/CSPCA.crl

The certificates were installed locally from the command line with certutil certutil

-addstore CA CodeSignPCA.crl

certutil -addstore CA CodeSignPCA2.crl

certutil -addstore CA CSPCA.crl

Intermittant slowdown issues for SharePoint (Pt 2/3) – Debugging

the slowdown issues can be observer using the developer dashboard in SharePoint.

A component will take just over 15 seconds to process – a definite sign that a web connection timeout has happened.

For example, when FAST search is experiencing the issue I’ve noted that the Search Best Bets OnPreRender action takes just over 15s (+16648.52ms) – this instance of the slowdown issue happened to be caused by the CRL checking.

To explore the issue fully, the following TechNet article gives a full description of enabling Windows CAPI2 event logging and debugging the output. It’s aimed at Windows Vista, but applies to Windows Server 2008 / R2 as well just as well.

• Troubleshooting PKI Problems on Windows Vista
  http://technet.microsoft.com/en-us/library/cc749296(WS.10).aspx#BKMK_RevocationCheck

Intermittant slowdown issues for SharePoint (Pt 1/3)

A SharePoint server that does not have internet access can experience intermittent slowdown issues. I’ve been experiencing this in the following situations

• Long page load times on initial site access.
• Long search times.

Note that in both these cases, after the initial slow page load, a user will not experience problems until their IIS session expires – they’ll have the problem again the first time they use SharePoint after that.

There appears to be two related causes for these issues – both caused by the server not being able to communicate with the internet.

STS Certificate authentication

This appears to be an issue when using claims-based authentication. The SharePoint Security Token Service (STS) uses certificates – the validity of the certificate has to be verified on a periodic basis to ensure that the certificate has not been revoked.

By default, the CRL check for the certificate is performed over the internet (http://crm.microsoft.com/). If the online CRL server cannot be reached from the SharePoint server, the operation times out after 15 seconds by default. Even if the CRL validation fails after 15 seconds, the SharePoint page may still be rendered after the delay.

Certificate Revocation List (CRL) checking

When starting a .NET application, the .NET Framework will attempt to download the Certificate Revocation list (CRL) for any signed assembly. If the server does not have access to the Internet, or is restricted from accessing the Microsoft.com domain, this may delay loading of the assemblies.

PowerShell and setting the location

I’ve got a bunch of build scripts and sometimes they are run in a batch (from a master script) and sometimes they need to run independantly. So, the very useful line of script here:

Set-Location (Split-Path -Path:$MyInvocation.MyCommand.Path -Parent:$true)

sets the current (working) folder to the location the current script is running in. useful where scripts are referencing other scripts or files and just want to use .\ to call it in the same folder as the script.

 

RecordsRepository.SubmitFile

If you’re calling the OfficialFile.asmx web service from code and the result returned is

<ResultCode>NotFound</ResultCode>

Then, it’s probably because the user isn’t a member of the ‘Records Center Web Service Submitters’ group. By default this site group does not have any members, preventing anyone from using the SubmitFile method.

Silverlight service reference endpoints

So, when you add a service reference to Silverlight, a config file is added to your project – ServiceReferences.clientConfig that contains the endpoint / url for the service. You can add new ones to this for different environments, or to set the end points in code, do this:

BasicHttpBinding binding = new BasicHttpBinding(BasicHttpSecurityMode.None); 
EndpointAddress endpoint = new EndpointAddress(uri); 
ServiceSoapClient client = new ServiceSoapClient(binding, endpoint);

 

 

That issue on a single server farm…

When it can’t call webservices in the local farm (access denied). Just had this with a Nintex web service call, it’s the loopback check in Windows Server 2008 as the services are all on the same server. It’s fixed with a registry edit, as detailed in the KB at http://support.microsoft.com/kb/896861.

 

PDF ifilter in SharePoint 2010

yadda, yadda, yadda, here’s the KB article http://support.microsoft.com/kb/2293357

Update site locales…

Quick bit of script to set the locale for all the SPWebs in a web application:

Get-SPWebApplication <url> | 

Get-SPSite |

Get-SPWeb | % {
 
  Write-Host $_.Locale.DisplayName' '$_.Title
 
  if ($_.Locale.LCID -eq 1033) {
  
    Write-Host 'updating to en-AU'
  
    $_.Locale = [System.Globalization.CultureInfo]::CreateSpecificCulture('en-AU')
  
    $_.Update()
 
  }  

}

 

The object has been updated by another user since it was last fetched

I’ve got some taxonomy field that I’ve pulled into Visual Studio as part of a content type that’s being deployed. But, after deploying it, trying to edit the field definition gives the error in the title.

And that’s caused by the elements xml – the Version attribute for the field is brought across which confuses SharePoint in the newly published field definition. So, the fix is to remove the Version attribute completely and then you’re golden.