Ein SCOM-Update bricht mit Fehler 1603 ab, der SDK-Dienst startet nicht mehr. Die Ursache war eine Zertifikatsperrlistenprüfung, die auf Servern ohne Internetzugang ins Leere lief.
Beim Upgrade einer Operations-Manager-Umgebung von SP1 auf R2 mit kumulativem Update 5 brach die Installation ab:
Update "System Center Operations Manager 2007 R2 Cumulative Update 5 (KB2495674)"
konnte nicht installiert werden. Fehlercode 1603.Im Ereignisprotokoll fanden sich zusätzlich Warnungen über user registry handles leaked durch den Konfigurationsdienst. Während des Updates meldeten Dateien, sie seien noch von einem anderen Prozess geöffnet, und anschließend ließ sich der SDK-Dienst nicht mehr starten.
Die Ursache
Signierte .NET-Anwendungen prüfen beim Start standardmäßig die Herausgeber-Signatur (Publisher Evidence) ihrer Assemblies. Dazu gehört der Abruf von Zertifikatsperrlisten (CRL) aus dem Internet. Hat der Server keinen Internetzugang, wartet jeder Prüfversuch auf ein Timeout. Dienste starten dadurch so langsam, dass der Dienststeuerungs-Manager sie als fehlgeschlagen betrachtet – und Installationsroutinen, die Dienste stoppen und starten, scheitern.
Die Lösung
In den Konfigurationsdateien der betroffenen Dienste wird die Prüfung deaktiviert. Für SCOM 2007 R2 waren das im Installationsverzeichnis:
Microsoft.Mom.Sdk.ServiceHost.exe.configMicrosoft.Mom.ConfigServiceHost.exe.config
Innerhalb des vorhandenen <runtime>-Abschnitts wird eine Zeile ergänzt:
<runtime>
<generatePublisherEvidence enabled="false"/>
<!-- bestehende Einträge bleiben erhalten -->
</runtime>Nach einem Neustart der Dienste laufen Start und Update wieder normal durch.
Allgemeingültige Lehre
Das Muster begegnet einem bei vielen Produkten auf abgeschotteten Servern – nicht nur bei SCOM:
- Dienste starten sehr langsam oder mit Timeout (Ereignis 7000/7009 im Systemprotokoll),
- Konsolen öffnen sich erst nach 15 bis 30 Sekunden,
- Installationen und Updates schlagen sporadisch fehl.
Statt jede Anwendung einzeln anzupassen, ist es oft sinnvoller, die Infrastruktur zu klären: Entweder erhalten Server gezielten Zugriff auf die CRL-Verteilungspunkte (etwa über einen Proxy), oder die automatische Aktualisierung der Stammzertifikate wird per Gruppenrichtlinie so konfiguriert, dass keine Timeouts entstehen.
Heute
SCOM 2007 R2 ist lange außer Support. Die Ursache – blockierte Zertifikatsperrlistenprüfungen auf Servern ohne Internetzugang – tritt aber nach wie vor auf. Die Einstellung generatePublisherEvidence ist bei aktuellen .NET-Versionen standardmäßig weniger relevant; die Netzwerkfreigabe für CRL-Abrufe bleibt die sauberere Lösung.