Kürzlich hatte ein befreundetes IT-Systemhaus massive Probleme mit der AD-Replikation, nachdem sie einen Server aus der Domäne entfernt hatten – den hatten sie aber auf unser Anraten hin entfernt, weil er ständig Probleme machte. Microsofts Support hat ihnen dann noch geholfen, die Überreste des demoteten Servers aus dem AD zu entfernen (Stichwort repadmin).
Leider gab es seitdem Probleme mit dem OnPrem-Exchange – eingehende Mails blieben in der Mailqueue stecken mit solchen Fehlermeldungen:
LED=451 Target host responded with error (…) 550 5.7.53 SMTP; Command not autorized in current state
Die User konnten aber Mails verschicken, Autodiscover, Adressbücher, Kalender – alles funktionierte. Es kamen eben nur keine Mail an, weil diese nicht zugestellt werden konnten – offenbar aufgrund fehlender Berechtigungen; für den Admin, wohlgemerkt!
Ausserdem konnten am Empfangsconnector keine Änderungen vorgenommen werden – Fehlermeldung:
„Zugriff verweigert. Active Directoty-Antwort: 00000005: SecErr: (…) problem 4003 (INSUFF_ACCESS_RIGHTS) … „
Im eventvwr.msc fanden sich auch entsprechende Meldungen:
„The account (…) provided valid credentials, but it does not have submit permissions on SMTP Receive connector“
Naheliegend, dass im Active Directory etwas kaputt war. Als weitere Fehlermeldung konnten nämlich zwar neue Benutzerpostfächer im ECP angelegt werden, das wurde aber jedesmal mit einer Fehlermeldung quittiert:
„Object has been corrupted or isn’t compatible with Microsoft support (…) inconsistent state (…) too long“
Wenn man nach dieser Fehlermeldung plus „Exchange“ googelt, bekommt man übrigens eine (1) Seite als Suchergebnis 😉 Mithilfe dieses Blogs demnächst ja vielleicht zwei … hier stand übrigens auch der Name des (längst entfernten und demoteten) Servers / DCs in der Fehlermeldung. Der hätte aber nirgends mehr auftauchen dürfen, dcdiag, repadmin, nltest und so fort haben allesamt keinen Verweis mehr auf den alten Server ausgespuckt.
Interessant wiederum, dass diverse (kostenpflichtige!) Calls des Systemhauses sowohl zur AD- als auch Exchange-Supportabteilung von Microsoft keine Abhilfe brachten. AD- und Exchange-Experten haben stundenlang herumgesucht und -probiert und meinten dann jeweils, dass es am AD / Exchange läge, also jeweils nicht an ihrem Fachgebiet 
Wir haben ebenfalls einige Stunden herumgesucht, mit ADSI-Edit, PowerShell und Suche in den Logs versucht, das Problem erst einmal zu erklären und dann idealerweise zu beheben. Die Installation eines weiteren Exchange-Servers brachte nichts ausser denselben Meldungen … Mehr zufällig stiessen wir dann auf einen bereits mehrere Tage alten Logeintrag:
NtFrs – „nTDSConnection-Objekt (…) not found“
– so in etwa, dummerweise ist der Screenshot nichts geworden Aber es brachte uns auf die richtige Spur:
Active Directory-Standorte und -Dienste => Sites => Standardname-des-ersten-usw => Servers => <SERVERNAME> => NTDS-Settings.
Dort waren neben den Einträgen für die DCs (die ja da hingehören) zwei weitere Einträge mit vollkommen seltsamen Servernamen, also statt DOM-DC1 und DOM-EXC (bspw.) zusätzlich DOM-DC1CNF:247dec8… und DOM-EXCCNF:b57X…. Diese haben wir gelöscht, danach alles mal neu gestartet, dann konnte man schon mal den Connector bearbeiten. Mailqueue ging nach wie vor nicht und wir haben erstmal etwas ratlos aufgegeben. Dann kam einige Stunden später eine erfreute Nachricht des Kunden, dass die Mails ja wieder reinkämen 🙂 Wir waren also nur zu ungeduldig und hatten die Replikation nicht abgewartet. Änderungen im AD replizieren sich teilweise ja erst nach mehreren Stunden über alle Server einer Domäne hinweg.
Wir haben uns jedenfalls gefreut, der Kunde auch 🙂 Wie man einen wie hier unnötig installierten Exchange-Server deinstalliert, steht im nächsten Beitrag.
ITnotez 