Freitag, 25. April 2008

stsadm langsam, Publisher's CRL

Es gibt MOSS Server die haben keine Internet zugriff, auch nicht über einen Proxy. So wird der ganze MOSS Server sehr langsam. Am besten ist der Effekt mit stsadm zu sehen. Nur der Aufruf ohne Parameter dauert 30s.
Wenn die SharePoint DLL's geladen werden versucht der SharePoint im Internet auf http://crl.microsoft.com/ oder http://crl.verisign.com/ zu zugreifen. Tja, und ohne Internet Verbindung wartet der SharePoint auf den Timeout.

Es gibt verschiedene Workarounds dies zu Lösen:
  1. Host Eintrag setzen auf 127.0.0.1 für die zwei URL's. (Funktioniert nicht immer)
  2. Proxy Server einsetzten und mit proxycfg -p 192.168.0.1:8080 konfigurieren
  3. Disable im IE Tools>Internet Options>Advanced>Check for Publisher's certificate revocation.
  4. Die CRL's downloaden und Importieren
    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

Wir haben uns für Variante 3 entschieden, so haben wir auch mit weiteren Applikationen zB. SQL Management Studio keine Probleme.

Da ja MOSS meistens unter einem Service Account betrieben wird, ist es wichtigs dass auch diese die CRL (Client Revocation List) nicht übers Internet prüfen wollen. Da die Einstellungen für den IE nur für den Aktiven User gelten habe ich ein Script erstellt, dass die Settings auf allen Usern auf dem Server setzt.

Const HKEY_USERS = &H80000003
SetAllUsersRegKey
"Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software
Publishing\State",146944,"REG_DWORD"
Sub SetAllUsersRegKey(sKeyName,sData,sType)
Dim oShell, sKey, oReg,
sSubKey,aRegKeys,aDesktopKeys

Set oShell = CreateObject("Wscript.Shell")

Set oReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")
oReg.EnumKey HKEY_USERS, "", aRegKeys

For Each sSubkey In aRegKeys oReg.EnumKey
HKEY_USERS, sSubkey & "\Control Panel\Desktop", aDesktopKeys

If Not IsNull(aDesktopKeys) Then

Wscript.Echo sSubkey & "\" & sKeyName,sData,sType
oShell.RegWrite "HKEY_USERS\" & sSubkey & "\" & sKeyName,sData,sType

End If

Next
End Sub

Hier weiter Blogeinträge zu diesem Thema:
http://paulhorsfall.co.uk/archive/2007/05/27/Stsadm.exe-and-iisreset-Slow-Behind-Proxy-on-SharePoint.aspx

http://jritmeijer.spaces.live.com/blog/cns!8A48A27460FB898A!965.entry


Donnerstag, 17. April 2008

AddSchedulingJobDefinitions failed beim Site erstellen

Wir haben eine neue Web Application erstellt mit eigenem Service Account und Custom Features und Layouts. Im Templatepicker haben wir unser Template gewählt und OK. Das Template wurde gesetzt aber es folgte die Meldung Access denied. In den ULS war der folgende Eintrag.

AddSchedulingJobDefinitions failed. System.Security.SecurityException: Access denied. at
Microsoft.SharePoint.Administration.SPPersistedObject.Update()
....

Da der Application Pool nicht unter dem Central Administration Pool Accout konfiguriert ist, hat der Account keine Rechte den Job zu erstellen für die Features zu aktivieren. Da dies nur einmal beim erstellen aktiviert wird kann dies mit einem Workaround gelöst werden.

  1. Im IIS Admin properties der Web Application öffnen
  2. Im Home Directory den Application Pool auf den Central Administration Pool setzten
  3. iisreset
  4. Site Template wählen (features aktivieren)
  5. Den Application Pool wieder zurück setzten

Ähnliches Problem habe ich hier gefunden, sprich die Lösung:

http://msmvps.com/blogs/obts/archive/2007/01/30/528982.aspx