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.
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:
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)
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
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.
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.
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.
If you’re calling the OfficialFile.asmx web service from code and the result returned is
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.
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);
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.