EMC startet nicht

Heute hatte ich (mal wieder) das Problem, dass sich die Exchange 2010 Console nicht sauber öffnen ließ:

Das ist nicht komplett ungewöhnlich und es gibt sehr viele Gründe dafür. Das Exchange Team hat eigens einen Blog Artikel dafür verfasst sogar und extra ein Tool für die Diagnose gebaut.

Diesmal war die Lage aber etwas anders, ich selbst war nicht ganz unschuldig an diesem Problem . Nun, es musste der primäre DNS Suffix des (einzigen) Exchange Servers in einer LAB-Umgebung umgenannt werden. Exchange mag das nicht und es hat mich viel Schweiß gekostet, die Console wieder zum Starten zu kriegen. Und das kam so:

Nachdem ich den primären DNS Suffix des Exchange Servers geändert hatte, ließ sich die EMC nicht mehr starten. Der genaue Verbindgunsfehler lautete:

Aus dem Fehler konnte ich erkennen, dass sich die EMC immer noch mit dem alten Namen verbinden will (dem alten DNS Suffix). Also musste der alte DNS Suffix irgendwo auftauchen. Meine erste Idee war, das .msc File der EMC in Notepad zu betrachten. Allerdings musste ich feststellen, dass dieses File seit der Installation nicht mehr verändert wurde und darin keine benutzerspezifischen Werte zu finden waren. (Nebenbei bemerkt  registriert sich Notepad sofort für alle .msc Endungen wenn man ein .msc File damit öffnet ! – Muss man also auch wieder hinbiegen).

Als nächstes habe ich dann den Process Monitor angeworfen, um zu sehen, ob die EMC eventuell auf eine andere Config Datei zugreift und daraus, den alten (falschen) Namen des Exchange Servers liest. Auch das brachte keinen Erfolg. Um ganz sicher zu gehen, habe ich mit der Windows Suche das komplette Filesystem durchsucht (auch in den Files) und auch dort nichts gefunden.

Ok: dann gings in die Registry. Aber auch hier war nichts zu finden, was auf den alten Namen deutete. Daraus schloss ich, dass dieser Wert entweder nicht im Cleartext lokal vorliegt oder eben gar nicht lokal vorliegt. Also startete ich den Netzwerk Monitor und schnitt die Verbindungen während des Starts der EMC mit. Tatsächlich tauchte hierbei der falsche DNS Suffix zweimal auf. Einmal bei der Anfrage für ein Kerberos Ticket (ServicePrincipleName = Falscher DNS Name des Exchange Servers) und einmal bei der Rückmeldung des KDCs –> Falscher Service Principle Name. Ach ne! Das brachte mich also auch nicht weiter. Irgendwo musste der Name doch stecken!

Um das Active Directory komplett auszuschließen, habe ich beschlossen mit LDIFDE einen Dump des selbigen zu ziehen:

Ldifde –d DN –f c:\meinexport.txt

“DN” muss man hier entsprechend anpassen. Ich habe zum einen die komplette Configuration Partition durchsucht und auch den Default Naming Context. Tatsächlich bin ich hier an einigen Stellen fündig geworden. Ich habe alles angepasst und anschließend erwartungsfroh die EMC geöffnet – nur um mir wieder den selben Fehler anschauen zu müssen.

Auch ein Reboot brachte kein Glück. Dann fiel mir noch ein, dass die EMC einen Cache schreibt. Das macht sie unter:

C:\Users\userName\AppData\Roaming\Microsoft\MMC

Die darin liegenende Datei hab ich gelöscht und danach sicherheitshalber nochmal gebootet. Und wieder kein Erfolg.

Na gut, dachte ich mir – dann eben auf die harte Tour –> ich habe dann die CAS Rolle deinstalliert und zusätzlich noch den IIS runtergeworfen.
Danach wieder IIS und CAS installiert. Dann hatte ich noch zusätzlich die Probleme die im Ehlo Artikel beschrieben sind: das Kerberos Modul war als “managed” installiert und nicht als “native” (und kein Pfad zeigte zur entsprechenden DLL) und das gleiche galt für das WSMan Modul.
Beides wieder in Ordnung gebracht, reboot – nix tut.

Frustriert berichtete ich einem Freund von meinen Problemen mit der EMC. Der gab mir den Tipp einfach mal das komplette Profil des Admin-Users mit dem ich die EMC öffnete zu löschen (also c:\users\Username).

Gesagt – getan. Und siehe da – ERFOLG !

Mittlerweile konnte ich das Problem noch weiter eingrenzen –> NTUSER.DAT !

Es genügt diese zu löschen, um dem Problem Herr zu werden und die EMC wieder in strahlendem Orange zu sehen.