“Die automatische Zertifikatregistrierung für “lokaler Computer” konnte ein Zertifikat “Domänencontroller” (0×800706ba) nicht registrieren. Der RPC-Server ist nicht verfügbar.”

Auf der Maschine ist neben dem DC auch ein ISA Firewallserver installiert.

OK, das war vielleicht nicht die beste Idee aber wer kennt das Problem knapper IT Budgets nicht?

EventID.net – sonst immer Quell guter Problembehebungsideen hatte nix passendes und so fing die Suche an. Der ISA protokollierte nix ungewöhnliches, die CA ließ sich pingen, die Namensauflösung stimmte vorwärts wie rückwärts und andere DCs hatten sich vorher auch schon ein eigenes Zertifikat abgeholt.

Dann der entscheidende Hinweis…

Laut eines Kommentars auf eventid.net läuft die Kommunikation des DCs mit der CA offenbar über DCOM.

Ein Forumsposting erzählte mir dann, man müsse im ISA temporär das RPC Filtermodul deaktivieren. Und so findet sich in den RPC Filteroptionen auch tatsächlich der Hinweis, wenn man den Filter aktiviert lasse, also die strikte RPC Einhaltung erzwinge, ständen einige Protokolltypen wie z.B. auch DCOM nicht zur Verfügung.

Deaktiviert man nun den ganzen Filter, muss anschließend die Firewall neu gestartet werden was im laufenden Betrieb in der Regel das Trennen jeglicher Verbindungen von und über die Firewall zur Folge hat.

Das würde im Umkehrschluss bedeuten: Aktiviere ich den RPC Filter wieder, könnte der DC nie wieder sein eigenes Zertifikat erneuern.

Glücklicherweise hat aber Microsoft auch hier eine Lösung:

Bei der Kommunikation zwischen DC und CA kommt die Systemrichtlinie 22 “RPC von ISA Server an vertrauenswürdige Server zulassen” zum Einsatz. Für diese kann man ebenfalls die strikte RPC Einhaltung abschalten. Dazu öffnet man den Systemrichtlinien-Editor, wählt den Punkt “Active Directory” und deaktiviert den Punkt “Strickte RPC-Einhaltung erzwingen”.

Nun musste ich nur noch den Domänencontroller (in diesem Fall einer untergeordneten Domäne) in die Gruppe CERTSVC_DCOM_ACCESS (in der Hauptdomäne, wo die CA “steht”) einfügen und die CA selbst durchstarten.

Anschließend sind der DC und die CA wieder Freunde.

Ein netter Umstand meines Jobs ist es, das ich viel herum komme, Leute spreche und Dinge sehe. So geschehen vor ein paar Tagen: Aus (m)einem puren menschlichen Egoismus Bedürfnis musste ich meinen zuvor konsumierten Kaffee entsorgen und bemerkte zu meiner Belustigung folgenden Spruch an der Innenseite der Klo-Tür.

Schnell war klar, dass es etwas mit Javascript zu tun haben musste denn Windows-Update lädt am Anfang gleich ein Javascript ein von dem aus die Besucher weiter geschubst werden. Genau das aber funktionierte nicht mehr.

Die Internet Explorer Sicherheitszonen auf Standardstufe zurücksetzen, die Einstellungen des Browsers zurückzusetzen oder gar den IE 8 neu zu installieren brachte auch keine Besserung.

In einem Forum fand ich dann die Lösung:

Als Administrator öffnet man eine Shell im Verzeichnis “%SYSTEMROOT%\SYSTEM32″, tippt die Befehle

regsvr32 vbscript.dll
regsvr32 jscript.dll

ein, startet den Browser neu und schon geht es wieder.

Der Frust wächst in das unermessliche. Schlechte Ampelschaltungen, daraus resultierender Stau, unübersichtliche Verkehrssituationen und gestresste Autofahrer. Zwischendrin Fahrradfahrer, Motorradfahrer und Fußgänger, welche zwischen den stehenden und rollenden Autos hin und her wuseln.

Auf die schlecht geplanten Ampelphasen kommt zu allem Überfluss noch ein Flickwerk an Baustellen, welche wöchentlich andere Straßen treffen. Da werden Vollsperrungen auf Hauptverkehrsstraßen in Kauf genommen das es nur so kracht. Und wer mal genau hinschaut stellt fest, dass es oft nur kleine Flicken sind, die in die Straße gekloppt werden. Anstatt die Asphaltdecke komplett zu tauschen werden hier mal drei Quadratmeter gebuddelt und gestopft, nächste Woche sind es drei Quadratmeter fünf Meter weiter die Straße runter.

Zusammenfassend kann man sagen, dass die Stadtplaner von Hannover derzeit ein absolutes Rad abhaben. Diese Leute fahren nicht auf den Straßen, die sie planen.