Enterprise Search / FAST Search: Erster Suchaufruf extrem langsam
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.
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.
- 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
SharePoint 2013: Keine Verbindung zum SQL Server 2012 Express
Für Testzwecke habe ich kürzlich einen SharePoint Server 2013 mit einem SQL Server 2012 Express aufgesetzt. Trotz stimmigen Berechtigungen erhielt ich folgende Fehlermeldung:
Cannot connect to database master at SQL Server at SERVERNAME. The database might not exist, or the current user does not have permission to connect to it.
Wie sich schlussendlich herausstellte, ist beim SQL Server 2012 Express - im Gegensatz zu den vorherigen Versionen - nicht mehr standardmässig TCP/IP aktiviert. Dies kann einfach behoben werden:
Öffnen Sie den SQL Server Configuration Manager, navigieren Sie zum Punkt SQL Server Network Configuration > Protocols for und aktivieren Sie dort TCP/IP.
Weiter sollte überprüft werden, ob der SQL Server Browser Dienst läuft. Diesen finden Sie ebenfalls im SQL Server Configuration Manager unter SQL Server Services.
Zum Schluss sollte, sofern SharePoint und SQL nicht auf dem gleichen Server laufen, geprüft werden, ob die (Windows-)Firewall-Einstellungen richtig gesetzt sind. Die Konfiguration ist hier beschrieben: Windows Firewall für den SQL Server Zugriff konfigurieren
Windows Firewall für den SQL Server Zugriff konfigurieren
Ist auf den SharePoint und SQL Servern die Windows Firewall aktiviert, so ist es zumindest auf dem SQL Server nicht ganz einfach, die Kommunikation zwischen SQL und SharePoint einwandfrei zum Laufen zu bringen. So habe ich bereits das eine oder andere Mal die Erfahrung gemacht, dass die manuelle Freischaltung der Ports (im Zusammenspiel mit SharePoint und SQL) auf der Windows Firewall nur eingeschränkt funktioniert.
Dies zeigt sich oftmals beim Versuch, eine neue SharePoint Farm zu erstellen. Es wird dann folgende Fehlermeldung angezeigt:
Cannot connect to database master at SQL Server at SERVERNAME. The database might not exist, or the current user does not have permission to connect to it.
Als Workaround konfiguriere ich die Windows Firewall auf dem SQL Server seither folgendermassen:
Öffnen Sie im Control Panel resp. in den Settings die Windows Firewall und klicken Sie dort auf Allow an app or feature through Windows Firewall.
Klicken Sie hier auf Allow another app...
Klicken Sie auf Browse... um nach einer, nicht in der Liste enthaltenen, Applikation zu suchen.
Navigieren Sie nach C:\Program Files\Microsoft SQL Server\MSSQL11.<SQLInstanceName>\MSSQL\Binn und wählen Sie sqlservr.exe aus. Klicken Sie Open.
Wählen Sie den neu hinzugefügten SQL Server Windows NT - 64 Bit aus und fügen Sie ihn mit Add hinzu.
Wiederholen Sie auf diesen Vorgang für die zweite Applikation. Klicken Sie hier auf Allow another app...
Klicken Sie auf Browse... um nach einer, nicht in der Liste enthaltenen, Applikation zu suchen.
Navigieren Sie nach C:\Program Files (x86)\Microsoft SQL Server\90\Shared und wählen Sie sqlbrowser.exe aus. Klicken Sie Open.
Wählen Sie den neu hinzugefügten SQL Browser Service EXE aus und fügen Sie ihn mit Add hinzu.
Unter den Allowed Apps sollten nun SQL Browser Service EXE und SQL Server Windows NT - 64 Bit für das Domain Profil zugelassen sein. Diese beiden sind je nach Umgebung und Einstellungen zusätzlich für Private und Public zu aktivieren.
Die Ports für weitere Services finden Sie hier:
Configure the Windows Firewall to Allow SQL Server Access
http://msdn.microsoft.com/en-us/library/cc646023.aspx