In vielen SharePoint 2010 Umgebungen trifft man auf das Problem, dass der erste Suchaufruf (egal ob Enterprise Search oder FAST) extrem lange dauert. Das heisst, es vergehen häufig über 30 Sekunden bis die ersten Ergebnisse auf der Resultatsseite angezeigt werden. Alle weiteren Suchanfragen werden in absolut akzeptablen Zeiten zurück gegeben.
Der erste Verdacht bei diesem Verhalten, lässt auf die Kompilierungsdauer der Resultatsseite schliessen, wie es generell bei allen zum ersten Mal aufgerufenen ASP Seiten der Fall ist (siehe auch WakeUp Thematik nach nächtlichem IIS-Recycling: Schneller Zugriff auf SharePoint Site Collections und Sites durch SPWakeUp). Doch bleibt das Problem bestehen, auch wenn z.B. im WakeUp Script explizit ein Suchaufruf eingebaut wurde. Somit kommt die Kompilierungsdauer nicht in Frage.

Besonders die Erkenntnis, dass dieses Verhalten nicht abhängig vom jeweiligen ApplicationPool auf dem Server, sondern jeweils einmal pro User – wenn dieser länger inaktiv war – auftritt, lenkt den Verdacht in Richtung Authentifizierung und Zertifikate.

Beim Blick in die ULS Logs tauchte häufig die folgende Meldung im Zeitraum des Suchanfrage auf:
w3wp.exe SharePoint Foundation Monitoring b4ly High Leaving Monitored Scope (SPCertificateValidator.Validate). Execution Time=13064.3434545353563

Was macht die Methode „SPCertificateValidator.Validate“? Sie überprüft die Validität des Zertifikats welches die Kommunikation mit dem Security Token Service (STS) verschlüsselt.

2013-01-09_173834

Da dieses aber von der „SharePoint Root Authority“ erstellt wurde und diese wiederum nicht zu den nativen Windows Trusted CAs gehört, versucht SharePoint diese nun jedes Mal aufs neue zu verifizieren (via Download von Trustliste von https://cert.microsoft.com).
Im SharePoint Umfeld tritt dies u.a. auf, wenn durch das Zertifikat signierte .net Assemblies (Authenticode signature) überprüft werden oder das Programm selber direkt eine Zertifikatsüberprüfung verlangt. Wenn aber der Server und somit auch der ApplicationPool (w3wp.exe) gar nicht mit dem Internet verbunden ist, dann läuft diese Überprüfung zusätzlich noch in einen TimeOut, was die Verzögerung noch um einige Sekunden verlängert.


Lösungsvariante 1

Das „SharePoint Root Authority Zertifikat“ wird in den Trusted Root Zertifikats Store aufgenommen
Durch das Exportieren des SharePoint Root Authority Zertifikats und den Import dieses in den Trusted Root Authorities Store ist das System in der Lage das Zertifikat lokal zu finden und versucht nicht mehr dieses über das Netzwerk zu erhalten.

Wie funktioniert das:
Exportieren des SharePoint Root Authority Zertifikats

  • Starte die SharePoint 2010 Management Shell als Administrator
  • $rootCert = (Get-SPCertificateAuthority).RootCertificate
  • $rootCert.Export(«Cert») | Set-Content C:\SharePointRootAuthority.cer -Encoding byte

Dann haben wir das Zertifikat als physikalische Datei am ausgewählten Speicherpfad vorliegen. (in diesem Fall unter C:\SharePointRootAuthority.cer)
Nun muss dieses via mmc.msc mit Certificates Snap-in in den Trusted Root Certifcation Store importiert werden.

2013-01-09_174010

  • Als Snap-in muss hierfür Certificate Computer Account ausgewählt werden.
  • Navigiere im erweiterten Certificates (Local Account) zu Trusted Root Certification Authorities
  • Rechtsklick auf Certificates im Trusted Root Certification Authorities und dann unter All tasks > Import wählen.
  • Nun wählen wir das zuvor exportierte Zertifikat (SharePointRootAuthority.cer) im Dateisystem aus. Fertig.


Lösungsvariante 2

Deaktivieren der automatischen Updates der Root Zertifikate auf den SharePoint Servern.
Falls man das SharePoint Zertifikat nicht wie oben beschrieben in den nativen Trusted Store aufnehmen will (z.B. aus Sicherheitsgründen, da dies ggf. die Sicherheitsrichlinien kompromittieren würde). Gibt es auch die Möglichkeit die Überprüfung via lokaler Gruppenrichtlinie oder direkt in der Registry zu deaktivieren.

Via lokale Gruppenrichtlinie

  • Ausführen von gpedit.msc als lokaler Administrator
  • Navigation zu Computer Configuration > Windows > Security settings > Public Key Policies > Certificate Path validation settings
  • Um Änderungen im Tab Network Retrieval zu machen, muss die Policy selbst definiert werden. Define policy auswählen und dann den Punkt Automatically update certificates in the Microsoft Root Certificate Program deselektieren.
  • Um die Änderung umgehend in Kraft treten zu lassen, muss abschliessend noch ein gpupdate /force durchgeführt werden.
    Hinweis von Microsoft zur Deaktivierung: Manuelle vierteljährliche Überprüfung auf etwaige Updates des Certification Trusts (KB 931125).

Oder in der Registry (regedit.exe) was aber einen anschliessenden Server Reboot erfordert.

  • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot
  • Der Wert von DisableRootAutoUpdate muss auf 1 gesetzt werden.
    (Wenn der Schlüssel nicht existiert, muss dieser noch erstellt werden)
    Name: DisableRootAutoUpdate
    Type: REG_DWORD
    Value: 1
  • Reboot des Servers

Meines Erachtens sollten die Lösungen des Zertifikatsimports (Lösungsvariante 1) oder die Deaktivierung der Überprüfung (Lösungsvariante 2) für die meisten Fälle ausreichend sein, jedenfalls hat dies bei unseren Umgebungen den erhofften Effekt gebracht.

Alternativ können auch diese Ansätze versucht werden:
„GeneratePublisherEvidence“ für .Net Framework Applikationen deaktivieren
http://support.microsoft.com/kb/936707/en-us
Developer Dashboard deaktivieren, falls aktiv
http://msdn.microsoft.com/en-us/library/ff512745(v=office.14).aspx

Weitere Informationen finden Sie hier:
http://support.microsoft.com/kb/2639348
http://support.microsoft.com/kb/936707/en-us
http://support.microsoft.com/kb/936707/en-us