“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.

Grundlage war ein neu aufgesetzter Windows 2003 Server mit einem GB Hauptspeicher sowie installiertem Outlook 2007. Nach erfolgter Installation von BES erfolgte die Anbindung an Exchange. Dazu wurden die Berechtigungen wie im Video beschrieben eingerichtet.

Nun tauchten aber schon die ersten Probleme auf. Es funktionierte zwar das Pushen von Emails auf die Geräte, der Versand von den Geräten zurück an den BES und dort über das Postfach des Anwenders klappte nicht. Die Emails verließen die Blackberrys einfach nicht sondern blieben mit einem roten Kreuz ”hängen”.

Erst als der Informationsspeicher des Exchange Servers durchgestartet – und somit die Berechtigungen für den BES Benutzer neu eingelesen – wurde lief auch der Versand über die Blackberry Geräte. Email, Kontakte, IT Richtlinien – nun schien alles glatt zu laufen.

Nur der Kalender wollte nicht so recht.

Der Tipp in zahlreichen Foren, die Datei

cdo.dll

mit dem Exchange-Server abzugleichen brachte ebenfalls kein brauchbares Ergebnis.

Durch Zufall stieß ich auf den Tipp, die Microsoft Exchange Systemverwaltungstools nachträglich auf dem BES-System zu installieren. Dazu musste vorher noch der Internetinformationsdienste-Manager sowie das Admin-Tools eingespielt werden.

Nach einem Reboot und der Anweisung

regsvr32 cdo.dll

wollte der BES zunächst nicht mehr starten, mit dem Verweis auf ein nicht zu ladendes MAPI Profil.

Ich hatte die Systemverwaltungstools von einer Exchange-CD ohne Servicepack eingespielt. Dieses Verhalten war erwartet worden, da unser Exchange selbst mit SP2 lief. Also spielte ich das Update ein und rebootete den BES-Server.

BES wollte noch immer nicht starten und hing dieses Mal mit der Meldung „failed to retrieve the Server DN“. Glücklicherweise gab es dazu auf der BlackBerry-Seite eine Hilfestellung.

Probehalber deinstallierte ich Outlook 2007 – leider ohne nennenswerten Effekt auf den BES. Um auszuschließen, dass es am MAPI Profil selbst lag, löschte ich wie von BlackBerry beschrieben die MAPIProfile und setzte sie mit den Bordmitteln des BES neu auf.

Anschließend startete ich den Server erneut durch. Nun lief wenigstens wieder der BES normal an.

Nur diese Termine… Immerhin tauchte nun im BES Log

Calender synchronization from device disabled

auf. Aha – weit konnte es also nicht mehr sein…

Und tatsächlich: In meinem Gerät stand zwar im Kalender unter “Drahtlose Synchronisation” ein “Ja”, auf der BES Konsole jedoch ein “Nein”. Also deaktivierte ich im Kalender auf dem BlackBerry die Drahtlose Synchroniszation und aktivierte sie anschließend wieder.

And guess what… it worked

Nach einigen erfolglosen Versuchen die Sache telefonisch zu klären, schickte er mir per Email eine Einladung für eine Remotedesktopsitzung. Verbunden, bemerkte ich, dass sein Outlook im Abgesicherten Modus lief.

Auf Nachfrage bekam ich zu hören, dass sein Outlook heute “abgestürzt” sei, und anschließend mit der Frage nach dem Abgesicherten Modus startete. Dieses wurde (wie üblich) mit “Ja” beantwortet.

Ein Neustart von Outlook brachte keine Besserung – Outlook kam immer im abgesicherten Modus hoch. Wie ließ sich dieser nun deaktivieren?

Ein Computer-Neustart behebt 98% aller Windows-Probleme heißt es. Gesagt getan – beim Herunterfahren des Computers hörte ich durch das Telefon ein Piep-Geräusch eines Windows Mobile PDA.

Da dämmerte es mir…

Unter Windows XP hält ActiveSync bei Anbindung eines Windows-Mobile Gerätes und bei Datenabgleich mit Outlook immer eine outlook.exe im Speicher. Diese Instanz muss verhindert haben, dass das zweite Outlook im normalen Modus hochfährt.

Um die zweite Instanz zu schließen gibt es im Prinzip zwei Möglichkeiten: Entweder man trennt den PDA vom PC oder man schmeißt alle “outlook.exe” Einträge über den Taskmanager raus. Letzteres kann aber bei Verwendung von PST Dateien oder OST Dateien zu Problemen führen da diese dann ggf. nicht sauber geschlossen werden.

Nach dem (nicht notwendigen) Computerneustart lief Outlook wieder normal an.

Der Abwesenheitsassistent war wieder vorhanden und der Urlaub gerettet

Die Verbindung zum Cisco-Router in der Geschäftsstelle lief über PuTTY. Von dort ging es dann per Telnet im VPN weiter. Insgesamt mussten 12 Standorte mit einem neuen PSK ausgestattet werden.

Die Aktion bestand aus zwei Teilen. Zuerst musste der aktuelle Schlüssel mit

no crypot isakmp key (alter_schlüssel) address (peer-ip) (subnetzmaske)

entfernt und anschließend der neue Schlüssel

crypot isakmp key (neuer_schlüssel) address (peer-ip) (subnetzmaske)

hinzugefügt werden.

Da der PSK nur für den Erstkontakt notwendig ist, verliert der entfernte Cisco-Router seine Verbindung zum VPN beim Wechsel des PSK nicht.

Anschließend wurde die Konfiguration gesichert. Nachdem alle Standorte und die Geschäftsstelle mit dem neuen PSK ausgestattet waren, wurde auf dem Router in der Geschäftsstelle ein Reload durchgeführt.

Mit

show dmvpn

überzeugte ich mich noch, dass alle Standorte wieder eingewählt waren. Wochenende gerettet

Ein Blick in das Ereignisprotokoll des betroffenen Computers brachte es ans Tageslicht:

Die RDP Protokollkomponente “DATA ENCRYPTION” hat einen Fehler im Protokollablauf festgestellt und die Clientverbindung getrennt.

Der erste Weg führte zu eventid.net. Dort gab es einen Hinweis auf den Registry-Zweig

HKLM \ System \ CurrentControlSet \ Services \ TermService \ Parameters

Ein Beitrag bezog sich auf die Microsoft Knowledgebase welche den Sachverhalt erklärte.

Einfache Lösung:

Im Registry-Zweig den Eintrag “Certificate”, und wenn vorhanden “X509 Certificate” sowie “X509 Certificate ID” löschen und den Computer neu starten.

Anschließend konnte sich mein Kollege wieder per RDP aufschalten.