So many of us, clients as well as partners, always look for ways to improve the loadtime of all pages in a PWA environment. Thanks to Microsoft employee Brian Smith it is now clear that if the server hosting the PWA is not connected to the internet, you have to actively do something to avoid performance being impacted.
From Brian Smith:
———————————————
Thanks to a couple of my European support colleagues for sharing this one, which I know could also affect many of our customers world-wide if they are running servers that are not internet connected. Great work by Jorge Puig Altozano from our Project support team in Madrid, and special thanks (and all the credit – according to Jorge) to Hector Calvarro for the SharePoint team – also in Madrid. If Spanish is your preferred language then read on at http://blogs.technet.com/b/elfarodeprojectserver/archive/2012/02/22/project-server-2010-elevados-tiempos-de-respuesta-al-cargar-paginas-de-sitios-pwa.aspx and also Hector’s blog at http://blogs.technet.com/b/hablamoss/. Although we are just talking about PWA and SharePoint here – consideration also needs to be given to other 3rd Party assemblies that may be installed too – and this could affect the loading of PDPs.
On to the English description – translation thanks to Jorge, with some additional input from Catalin Olteanu from one of our partners, UMT, as they also experienced the same slow downs.
We had a Project Server 2010 server, with no Internet connection, that was returning high response times when we would try to load any PWA page – slow response was seen to be due specifically to the calls to SecurityCheckUserPagePermisison, and CheckUserProjectPermissions. We observed the information n the SharePoint Developer Dashboard, and decided to take a look at the Certificates behavior.
BriSmith note – I’m sure lots of analysis went into this decision by Hector – and for anyone interested in understanding more about the problem Catalin found the lookup for www.download.windowsupdate.com from a netmon trace, and the event viewer showing a 4102, and a couple of 4107 CAPI2 errors helped join the dots…
We disabled the timeouts for the certificates verification in the SharePoint server
On Windows Server , this component is on by default and , whenever an application is presented with a certificate that is not present in the trusted root store, it will attempt to contact Microsoft download servers to get the latest root chain.
The SharePoint OOB certificates can induce this as they are stored in a particular repository (SharePoint- Under Certificate management -Local Computer), as opposed to the trusted root. The decision not to have SharePoint code creating and installing a root cert in the Trusted Root store was taken for security reasons (ex if an application could install a certificate into the TRC store might compromise the security of the system).
Can this behavior be avoided? ( ie. bypass this check for subsequent validations).
Supported workarounds:
Disable automatic update of root certificates on SharePoint Servers
• Launch gpedit.msc as admin on the box
• Go to Computer Configuration –> Windows Settings ->Security settings ->Public Key Policies -> Certificate Path validation settings
• In Network retrieval tab -> Define the policy and uncheck “Automatically update certs from Microsoft root cert program”
• Run gpupdate /force for policy to take effect immediately.