26
Fehleranalyse bei grober Exchange Störungen
Hallo,
bei einer Exchange 2010 Installation auf einem SBS 2011 Standard, steh ich gerade vor einem "kleinen" Problem.
Wurde gerufen weil kein Zugriff mehr über die Exchange Management Console möglich ist. versucht man darin den Exchange zu öffnen kommt der Hinweis
"Fehler beim Versuch, eine Verbindung mit dem angegebenen Exchange-Server herzustellen.
Fehler beim Verbindungsversuch mithilfe von "Kerberos"-Authentifizierung..."
Daraufhin habe ich eine erste Exchange Analyse durchlaufen lassen, um erst einmal einen groben Überblick zu bekommen, was da los ist und diese gibt mir einige kritische Fehler zurück. Kann mir aus der Fülle der Fehlermeldungen im Bezug auf ihren Ursprung nicht wirklich einen Reim machen, und bräuchte nun etwas Hilfe wo ich am besten anfange um das Ding wieder ans laufen zu bekommen.
Also die Clients haben weiterhin Zugriff darauf, von Clientseite ist also "alles ok", allerdings geht wie erwähnt die Managment Console nicht, und die Fülle an in der Analsyse zu Tage geförderten Fehlern zeigt ja, dass hier ein ernstes Problem besteht.
bei einer Exchange 2010 Installation auf einem SBS 2011 Standard, steh ich gerade vor einem "kleinen" Problem.
Wurde gerufen weil kein Zugriff mehr über die Exchange Management Console möglich ist. versucht man darin den Exchange zu öffnen kommt der Hinweis
"Fehler beim Versuch, eine Verbindung mit dem angegebenen Exchange-Server herzustellen.
Fehler beim Verbindungsversuch mithilfe von "Kerberos"-Authentifizierung..."
Daraufhin habe ich eine erste Exchange Analyse durchlaufen lassen, um erst einmal einen groben Überblick zu bekommen, was da los ist und diese gibt mir einige kritische Fehler zurück. Kann mir aus der Fülle der Fehlermeldungen im Bezug auf ihren Ursprung nicht wirklich einen Reim machen, und bräuchte nun etwas Hilfe wo ich am besten anfange um das Ding wieder ans laufen zu bekommen.
Also die Clients haben weiterhin Zugriff darauf, von Clientseite ist also "alles ok", allerdings geht wie erwähnt die Managment Console nicht, und die Fülle an in der Analsyse zu Tage geförderten Fehlern zeigt ja, dass hier ein ernstes Problem besteht.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 180885
Url: https://administrator.de/contentid/180885
Ausgedruckt am: 25.11.2024 um 14:11 Uhr
26 Kommentare
Neuester Kommentar
Hallo.
Du brauchst dir nur um den Punkt Datensicherung Sorgen machen, alle anderen Punkt kannst du ignorieren. Diese werden nur auf einem deutschsprachigen System angezeigt.
LG Günther
Du brauchst dir nur um den Punkt Datensicherung Sorgen machen, alle anderen Punkt kannst du ignorieren. Diese werden nur auf einem deutschsprachigen System angezeigt.
LG Günther
Also Du willst damit sagen, die sind ein kosmetischer Effekt und entsprechen nicht den Tatsachen? Aber irgendeinen Grund muss es ja dafür geben, dass man mit oben erwähnter Fehlermeldung nicht mehr in die Managment Console rein kommt. Ideen?
Was die Datensicherung angeht diese läuft über Drittanbieter Software und funktioniert. Mir macht der nicht mehr vorhandene Zugriff über die Managment Console Sorgen.
Was die Datensicherung angeht diese läuft über Drittanbieter Software und funktioniert. Mir macht der nicht mehr vorhandene Zugriff über die Managment Console Sorgen.
Hallo elknipso,
hast du zufällig Internet Explorer 9 auf dem Server installiert?
Wenn ja diesen wieder deinstallieren.
MfG Andi
hast du zufällig Internet Explorer 9 auf dem Server installiert?
Wenn ja diesen wieder deinstallieren.
MfG Andi
Hallo,
diese Fehlermeldungen, haben (soweit ich weiß) nichts mit dem Fehler, in der Management-Console zutun.
Der Fehler, hängt vermutlich mit der kerbauth.dll, dem WIN-RM IIS Extensions oder
mit einer fehlerhaften IIS-Konfiguration zusammen.
Lies dir mal diesen Thread durch, vielleicht bringt dich das weiter: Exchange Server 2010 - Verwaltungskonsole - Initialisierungsfehler
Gruß Daniel
diese Fehlermeldungen, haben (soweit ich weiß) nichts mit dem Fehler, in der Management-Console zutun.
Der Fehler, hängt vermutlich mit der kerbauth.dll, dem WIN-RM IIS Extensions oder
mit einer fehlerhaften IIS-Konfiguration zusammen.
Lies dir mal diesen Thread durch, vielleicht bringt dich das weiter: Exchange Server 2010 - Verwaltungskonsole - Initialisierungsfehler
Gruß Daniel
Hi.
Nein, das ist ein kosmetischer Effekt, sondern ein reines Sprachproblem des BPA. Der BPA erwartet die englische Bezeichung der betreffenden User und die lauten auf einem deutschsprachigen Windows nun einmal anders.
Sorry, aber darauf würde ich mich nicht verlassen. Der Exchange erkennt, ob er mit einem korrekten Agent gesichert wurde. Wenn hier also steht, dass er nicht gesichert wurde, dann wurde der Exchange auch nie korrekt gesichert.
LG Günther
Also Du willst damit sagen, die sind ein kosmetischer Effekt und entsprechen nicht den Tatsachen?
Nein, das ist ein kosmetischer Effekt, sondern ein reines Sprachproblem des BPA. Der BPA erwartet die englische Bezeichung der betreffenden User und die lauten auf einem deutschsprachigen Windows nun einmal anders.
Was die Datensicherung angeht diese läuft über Drittanbieter Software und funktioniert
Sorry, aber darauf würde ich mich nicht verlassen. Der Exchange erkennt, ob er mit einem korrekten Agent gesichert wurde. Wenn hier also steht, dass er nicht gesichert wurde, dann wurde der Exchange auch nie korrekt gesichert.
LG Günther
Habe mir den Thread durchgelesen und die Vorschläge überprüft. Leider hat das nicht zum Ziel geführt.
Der Windows-Remoteverwaltung (WS Verwaltung) Dienst läuft, wo kann ich noch genau nach der Ursache für das Problem suchen?
Wenn ich mir im IIS das Modul der Powershell anschauen will kommt folgendes:
Der Windows-Remoteverwaltung (WS Verwaltung) Dienst läuft, wo kann ich noch genau nach der Ursache für das Problem suchen?
Wenn ich mir im IIS das Modul der Powershell anschauen will kommt folgendes:
Keiner noch eine Idee?
Anscheinend hast du kerbauth einmal mit Vererbung und einmal durch direktes hinzufügen auf
das PowerShell-Dir zugewiesen. Die Vererbung musst du aber rausnehmen.
das PowerShell-Dir zugewiesen. Die Vererbung musst du aber rausnehmen.
Ich wäre Dir sehr dankbar, wenn Du den Punkt etwas genauer ausführen könntest. Also wo ich das wie genau mache?
Tut mir leid, war gestern etwas kurz angebunden 
Schau dir am besten mal, diesen Beitrag an. Dort wird es eigentlich ganz gut beschrieben:
http://www.mcseboard.de/ms-exchange-forum-80/initialisierungsfehler-bei ...
Du solltest also zuerst einmal prüfen ob die Kerbauth.dll unter Module geladen wurde.
Das Module, muss ganz oben im IIS unter Module als Systemeigenes Modul gelistet sein und darf nicht auf untergeordnete Web-Dir´s vererbt werden.
Nur auf dem Powershell-Dir muss das Modul hinzugefügt werden.
Schau dir am besten mal, diesen Beitrag an. Dort wird es eigentlich ganz gut beschrieben:
http://www.mcseboard.de/ms-exchange-forum-80/initialisierungsfehler-bei ...
Du solltest also zuerst einmal prüfen ob die Kerbauth.dll unter Module geladen wurde.
Das Module, muss ganz oben im IIS unter Module als Systemeigenes Modul gelistet sein und darf nicht auf untergeordnete Web-Dir´s vererbt werden.
Nur auf dem Powershell-Dir muss das Modul hinzugefügt werden.
Danke schon mal, auf den Link bin ich mit Google auch gestoßen, müsste an dem Punkt aber genau wissen wo man hier was machen muss. Das geht leider nicht so 100% deutlich aus dem Beitrag heraus.
Ok, du gehst einfach in den IIS, auf deinen Server (ganz oben, unter Startseite).
unter Module -> Systemeigene Module muss kerbauth registriert sein (nur registriert, keine aktivierte Checkbox).
Wenns nicht registriert ist, dann auf registrieren:
Name: kerbauth
Pfad: C:\Program Files\Microsoft\Exchange Server\V14\Bin\kerbauth.dll
Dann gehst du (im IIS) auf Powershell -> Module -> Systemeigene Module konfigurieren und aktivierst die Checkbox für Kerbauth.
Solltest du dort, immernoch den Fehler mit dem doppelten Modul-Eintrag bekommen, musst du deine web.config bearbeiten (vorher sichern)
und mal eine Registrierung (kerbauth-Modul) rausnehmen.
unter Module -> Systemeigene Module muss kerbauth registriert sein (nur registriert, keine aktivierte Checkbox).
Wenns nicht registriert ist, dann auf registrieren:
Name: kerbauth
Pfad: C:\Program Files\Microsoft\Exchange Server\V14\Bin\kerbauth.dll
Dann gehst du (im IIS) auf Powershell -> Module -> Systemeigene Module konfigurieren und aktivierst die Checkbox für Kerbauth.
Solltest du dort, immernoch den Fehler mit dem doppelten Modul-Eintrag bekommen, musst du deine web.config bearbeiten (vorher sichern)
und mal eine Registrierung (kerbauth-Modul) rausnehmen.
Danke schon mal soweit. Habe das an der Stelle kontrolliert und da war tatsächlich ein doppelter Eintrag. Habe das korrigiert und ich komme nun wieder in den Punkt Powershell. Ich sehe dort allerdings nicht den Punkt "Systemeigene Module konfigurieren". Siehe Screenshot. Bin ich irgendwo falsch "abgebogen"?
Du musst auch noch auf Module klicken 
Verdammt, dann kommt wieder die gleiche Fehlermeldung...
Was ich nicht ganz verstehe, vielleicht liegt da ja auch schon der Fehler, wenn ich ganz oben auf den Eintrag des Servers gehe (direkt der Eintrag unter "Startseite") und hier unter Module, dann taucht der Eintrag "kerbauth" in der langen Liste der Module auf, steht aber nicht in der Liste wenn ich oben rechts an der Stelle auf "Systemeigene Module konfigurieren..." klicke. Ist hier vielleicht schon das Problem?
Was ich nicht ganz verstehe, vielleicht liegt da ja auch schon der Fehler, wenn ich ganz oben auf den Eintrag des Servers gehe (direkt der Eintrag unter "Startseite") und hier unter Module, dann taucht der Eintrag "kerbauth" in der langen Liste der Module auf, steht aber nicht in der Liste wenn ich oben rechts an der Stelle auf "Systemeigene Module konfigurieren..." klicke. Ist hier vielleicht schon das Problem?
Ja, das sieht ganz danach aus
Was muss ich denn jetzt an der Stelle machen? Was mich wundert, klicke ich in der Liste auf den "kerbauth" Eintrag steht darüber, dass dies ein systemeigenes Modul sei:
Klicke ich aber oben rechts auf "Systemeigene Module konfigurieren..." taucht der Eintrag nicht auf:
Also was ist hier jetzt zu tun, damit die Geschichte wieder rund läuft?
Klicke ich aber oben rechts auf "Systemeigene Module konfigurieren..." taucht der Eintrag nicht auf:
Also was ist hier jetzt zu tun, damit die Geschichte wieder rund läuft?
Du musst das Modul dort entfernen (Bild 1). Dann taucht es auch in der Liste (Bild 2) auf.
Danach kerbauth auf das Powershell-Dir unter Module zuweisen.
Danach kerbauth auf das Powershell-Dir unter Module zuweisen.
Habe ich genau so gemacht, was nun auch funktioniert hat. Danach taucht der Eintrag in der Liste auch auf, siehe Screenshot.
Allerdings funktioniert die Exchange Managment Console immer noch nicht, gleiche Fehlermeldung... Bin für Ideen immer noch offen und sehr dankbar.
Allerdings funktioniert die Exchange Managment Console immer noch nicht, gleiche Fehlermeldung... Bin für Ideen immer noch offen und sehr dankbar.
Ist die Fehlermeldung, genau die gleiche geblieben?
Sind die WinRM-Erweiterungen installiert?
Sind die WinRM-Erweiterungen installiert?
Ja die Fehlermeldung ist exakt die gleiche, und ja die sind installiert.
Ein WinRM Quickconfig gibt auch zurück, dass alles richtig konfiguriert sei.
Folgendes steht noch im Ereignisprotokoll. Also Quelle ist "Security-Kerberos" aufgeführt:
Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "Clientname1$" empfangen. Der verwendete Zielname war RPCSS/büro.firmendomäne.local. Dies deutet darauf hin, dass der Zielserver das vom Client bereitgestellte Token nicht entschlüsseln konnte. Dies kann auftreten, wenn der Ziel-Serverprinzipalname (SPN) nicht bei dem Konto registriert ist, dass der Zieldienst verwendet. Stellen Sie sicher, dass der Ziel-SPN bei dem Konto registriert ist, das vom Server verwendet wird, und zwar ausschließlich bei diesem Konto. Dieser Fehler kann auch auftreten, wenn der Zieldienst ein anderes Kennwort für das Zieldienstkonto verwendet als das Kennwort, das vom Kerberos-KDC (Key Distribution Center) für das Zieldienstkonto verwendet wird. Stellen Sie sicher, dass der Dienst auf dem Server und im KDC beide für die Verwendung des aktuellen Kennworts aktualisiert wurden. Wenn der Servername nicht vollqualifiziert ist und sich die Zieldomäne (firmendomäne.LOCAL) von der Clientdomäne (firmendomäne.LOCAL) unterscheidet, prüfen Sie, ob sich in diesen beiden Domänen Serverkonten mit gleichem Namen befinden, oder verwenden Sie den vollqualifizierten Namen, um den Server zu identifizieren.
Ein WinRM Quickconfig gibt auch zurück, dass alles richtig konfiguriert sei.
Folgendes steht noch im Ereignisprotokoll. Also Quelle ist "Security-Kerberos" aufgeführt:
Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "Clientname1$" empfangen. Der verwendete Zielname war RPCSS/büro.firmendomäne.local. Dies deutet darauf hin, dass der Zielserver das vom Client bereitgestellte Token nicht entschlüsseln konnte. Dies kann auftreten, wenn der Ziel-Serverprinzipalname (SPN) nicht bei dem Konto registriert ist, dass der Zieldienst verwendet. Stellen Sie sicher, dass der Ziel-SPN bei dem Konto registriert ist, das vom Server verwendet wird, und zwar ausschließlich bei diesem Konto. Dieser Fehler kann auch auftreten, wenn der Zieldienst ein anderes Kennwort für das Zieldienstkonto verwendet als das Kennwort, das vom Kerberos-KDC (Key Distribution Center) für das Zieldienstkonto verwendet wird. Stellen Sie sicher, dass der Dienst auf dem Server und im KDC beide für die Verwendung des aktuellen Kennworts aktualisiert wurden. Wenn der Servername nicht vollqualifiziert ist und sich die Zieldomäne (firmendomäne.LOCAL) von der Clientdomäne (firmendomäne.LOCAL) unterscheidet, prüfen Sie, ob sich in diesen beiden Domänen Serverkonten mit gleichem Namen befinden, oder verwenden Sie den vollqualifizierten Namen, um den Server zu identifizieren.
Hm, also mir fällt dazu nichtmehr allzuviel ein.
Was du noch probieren könntest, wäre:
- WinRM neu installieren
- ClientAccess-Role und IIS neu installieren
- nochmal im Internet nach anderen Hinweisen suchen
Leg aber vorher, ein Backup an.
Was du noch probieren könntest, wäre:
- WinRM neu installieren
- ClientAccess-Role und IIS neu installieren
- nochmal im Internet nach anderen Hinweisen suchen
Leg aber vorher, ein Backup an.
Bleibt wohl nicht viel anderes übrig. Werde mir mal ein Image von dem System ziehen und dann WinRM neu installieren und den IIS neu installieren....
Alternativ im IIS-Manager unter "Anwendungspool" alle Einträge die mit MSE zu tun haben die Identität auf "LocalSystem" stellen. Keine saubere Lösung, sollte aber den Fehler beheben.
Hi,
habe selbiges Drama gerade während einer Migration von SBS 2003 zu Server 2008 R2 und Exchange 2010.
Gestern zum Feierabend lief alles rund, heute wollte ich etwas weiter machen und stelle fest, dass ich mit selbigem Fehler nicht in die Ex-Konsole/-Shell komme.
Habe dank Google-Orakel bereits die Zeit-Einstellungen geprüft, winrm quickconfig durchgeführt und auch im IIS ist unter "PowerShell" das kerberos-Modul eingetragen.
Allerdings nicht unter Servername-Module. Wenn ich es dort hinzufügen will, bekomme ich die Meldung, dass es bereits vorhanden ist.
Kann ich das evtl per PowerShell/CMD entfernen und neun registrieren? Wie ist dann der Befehl?
Grüße
habe selbiges Drama gerade während einer Migration von SBS 2003 zu Server 2008 R2 und Exchange 2010.
Gestern zum Feierabend lief alles rund, heute wollte ich etwas weiter machen und stelle fest, dass ich mit selbigem Fehler nicht in die Ex-Konsole/-Shell komme.
Habe dank Google-Orakel bereits die Zeit-Einstellungen geprüft, winrm quickconfig durchgeführt und auch im IIS ist unter "PowerShell" das kerberos-Modul eingetragen.
Allerdings nicht unter Servername-Module. Wenn ich es dort hinzufügen will, bekomme ich die Meldung, dass es bereits vorhanden ist.
Kann ich das evtl per PowerShell/CMD entfernen und neun registrieren? Wie ist dann der Befehl?
Grüße
Ok, seltsamerweise hat's bei mir der dritte Reboot der gesamten Umgebung gebracht...
