As an addition to my previous post, I found a blogpost where I found numerous other options to speed up the stsadm process.
Symptoms for STSADM:
- You start STSADM without any parameters
- There is a delay of about 30 seconds
- While you are waiting, and tearing your hair out because your deployment script has about 60 STSADM commands, there is no CPU activity, swapping or significant network traffic.
Symptoms for SharePoint sites:
- You make the first request of the day, or the first request after recycling the app pool because you are developing assemblies that sit in the GAC.
- There is a delay of about 2 minutes
- While you are waiting, and tearing your remaining hair out because you know you have to do this at least 50 times today, there is no CPU activity, swapping or significant network traffic.
The cause:
The problem is that when loading signed assemblies the .net Framework checks the Internet based Certificate Revocation List. As our servers have, like most secure environments, no outgoing connections to the public Internet, the connection to crl.microsoft.com times out after what appears to be 30 seconds. It probably does this a couple of times in succession, causing a 2 minute wait when spinning up SharePoint.
The solution:
- As described in my previous post: Add the following xml to your machine.config
<configuration>
<runtime>
<generatePublisherEvidence enabled=”false”/>
</runtime>
</configuration>
The solutions below are from the blogpost i mentioned in the beginning of my post
- Add crl.microsoft.com to your hosts file and point it to your local machine. Some people have reported success with this, but it didn't work for me.
- Allow your servers to directly connect to crl.microsoft.com. If your environment dictates the use of a proxy server, configure it using proxycfg.
- Disable the CRL check by modifying the registry for all user accounts that use STSADM and all service accounts used by SharePoint. Find yourself a group policy wizard or run the vbscript at the end of this posting to help you out. Alternatively you can manually modify the registry for each account:
[HKEY_USERS\<userid>\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing]
"State"=dword:00023e00
- Download the CRLs and add them to the server manually (I haven't tested this, but it may work):
- Download: http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl
http://crl.microsoft.com/pki/crl/products/CodeSignPCA2.crl
- Add them:
certutil -addstore CA CodeSignPCA.crl
certutil -addstore CA CodeSignPCA2.crl
- Mark Russinovich has written a detailed post about this problem and provides a 5th option, which involves a manual change to each web application’s web.config file.
- Brett Waring pointed me to an article that describes how to reduce the timeout using a group policy.
VBScript to apply registry change:
The following script applies the registry change to all users on a server. This will solve the spin-up time for the service accounts, interactive users and new users.
const HKEY_USERS = &H80000003
strComputer = "."
Set objReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" _
& strComputer & "\root\default:StdRegProv")
strKeyPath = ""
objReg.EnumKey HKEY_USERS, strKeyPath, arrSubKeys
strKeyPath = "\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing"
For Each subkey In arrSubKeys
objReg.SetDWORDValue HKEY_USERS, subkey & strKeyPath, "State", 146944
Next
With thanks to Nik Shaw for the script.
Please note that this information come's from Muhimbi's SharePoint blog!