none
Exchange Management Console startet nicht mehr - Kerberus-Authentifizierung schlägt fehl RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen.

    Nach nunmehr über 12 Stdunden des Suchens frage ich die Experten um Rat:

    Ein Kunde hat es irgendwie geschafft, seinen Exchange zu schrotten. Nun habe ich die DB soweit wieder, dass sie in der Powershell mittels Mount-Database ohne Fehler gemounted wird. Ich kann auch mit Get-MailboxStatistics den Inhalt sichten.

    Was nun aber nicht geht sind folgende Punkte:

    - Exchange Management Console schlägt fehl mit Initialisierungsfehker "Kerberus"

    Initialisierungsfehler

    Fehler beim Versuch mit XXX/Powershell mithilfe von "Kerberos"-Authentifizierung: Beim Verbinden mit dem Remoteserver ist folgender Fehler aufgetreten: Der WinRM-Client kann die Anforderung nicht verarbeiten. Der Inhaltstyp der HTTP-Antwort vom Zielcomputer kann nicht ermittelt werden. Der Inhaltstyp fehlt oder ist ungültig....

    - Companyweb funktioniert nicht -> 500.19 Internal Server Error

    - OWA funktioniert nicht -> 500 - Interner Server Fehler

    Was ich bisher gemacht habe:

    - Alle Anleitungen durchgearbeitet die ich zu diesen Themen gefunden habe

    - kerbauth.dll ist aufgeführt (registriert) aber NICHT aktiv in IIS-Modules -> Default WS

    - kerbauth.dll ist systemeigen und aktiv in IIS-Modules -> Default WS -> Powershell

    - WSMAN ist entsprechend geprüft und ok

    - Die einst geschrottete DB ist nun im Status: clean shutdown und lässt sich wie oben beschrieben sichten

    - Lt. Powershell ist der zugreifende User auch erlaubt (GET-User admin).RemotePowershellEnabled -> true

    Kann mir irgendjemand noch einen Tipp geben? Ich möchte es vermeiden den Server neu aufzusetzen...

    Vielen Dank im voraus...


    Sonntag, 30. Oktober 2016 21:45
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hi,

    hast Du die Datenbank mittels "eseutil" auch auf Fehler überprüft und ggf. korrigiert?

    Step 1 wäre auf jeden Fall, eine neue DB zu erstellen und alle Postfächer aus der defekten DB in die neue DB zu verschieben, um das Risiko eines irreparablen DB-Fehlers zu eliminieren.

    Ich würde nicht schon an den Innereien (IIS) usw. rumspielen. Nach dem DB-Umzug könntest Du als nächstes versuchen, die virtuellen Verzeichnisse neu zu erstellen:

    http://www.exchangeitpro.com/2013/04/24/reset-exchange-2010-virtual-directories-via-gui/

    Vorher solltest Du Dir aber auf jeden Fall die Einstellungen notieren, weil die nach dem Neuerstellen entsprechend auch wieder neu gesetzt werden müssen.

    Folgende Fragen noch:
    1. Auf welchem Stand ist der Exchange (2010 SP3 RU15 wäre aktuell)?
    2. Wurde auf dem Server evtl. der IE11 ausgerollt? In dem Zusammenhang gab es einen Fehler, der die Konsole immer abstürzen ließ, wurde aber zwischenzeitlich per Rollup gefixt. Das ist aber nicht ursächlich für den nicht mehr funktionierenden Webzugriff.

    Liebe Grüße

    Ben

    ____________________________

    MCSA Office 365

    MCSA SQL Server 2014

    MCITP Windows 7

    MCSA Windows 8/10

    MCSE Server Infrastructure

    ____________________________

    Wenn Dir meine Antwort hilft, markiere sie bitte entsprechend als Antwort. Danke! :-).

    Montag, 31. Oktober 2016 07:35
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Ben,

    ich habe bei der DB mit ESEUTIL die /P Variante laufen lassen und danach ein ISINTEG. Beides positiv.

    Mittels New-Virtual hab ich das Powershell-Verzeichnis neu erstellt..Vor der Reparatur habe ich natürlich das Mailbox Database -Verzeichnis wegkopiert.

    Gibt es eine vernünftige Lösung die alte DB in eine neue zu verwandlen? Hatte bisher noch nie so tief mit Exchange zu tun.

    BTW: Kunde meldete heute morgen dass nun sein Outlook Alle Daten neu zieht. Die DB scheint also wieder zu funktionieren (ich hatte natürlich damit gerechnet, dass Kunde wartet bis ein OK kommt...).

    Nun ist die DB wieder in Betrieb und bisher kam auch nichts mehr vom Kunden.

    Bis auf die drei nicht mehr "wollenden" Dinge: OWA (wird dringend benötigt), MEC (wäre schön wenns geht) und Companyweb (muss nicht - ist halt nur aufgefallen).

    Der Exchange hat 14.1 (Build 210.15) laut get-exchangeserver.

    Was aber gerade noch auffiel - Beim öffnen der Exchange-Shell kommt ebenfalls ein Fehler:

    AUSFÜHRLICH:

    Verbindung mit XXX.local wird hergestellt
    [XXX.local] Beim Verbinden mit dem Remoteserver ist folgender Fehler aufgetreten: Der WinRM-Client kann
    die Anforderung nicht verarbeiten. Der Inhaltstyp der HTTP-Antwort vom Zielcomputer kann nicht ermittelt werden. Der Inhaltstyp fehlt oder ist ungültig. Weitere Informationen ...
    + CategoryInfo: OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [],PSRemotingTransportException + FullyQualifiedErrorId: PSSessionOpenFailed
    Fehler beim Herstellen der Verbindung zu einem Exchange-Server am aktuellen Standort.
    Geben Sie den vollqualifizierten Domänennamen des Servers ein, zu dem eine Verbindung hergestellt werden soll.:

    Mir ist das bisher nicht aufgefallen weil ich die Snapins für Exchange (Support und E2010) in der Powershell habe...

    Montag, 31. Oktober 2016 11:55
    |
  • Question
    Anmelden
    0
    Anmelden

    Hi,

    uaaaarghh, beim Blick auf die Versionsnummer wird mir schlecht... ich kann die Buildnummer zwar im TechNet nicht exakt so finden, aber ich meine, das wäre gerade mal SP1 ohne irgendwelche Rollups...
    Wir sind inzwischen bei SP3 UR 15, das ist Lichtjahre davon entfernt.

    "Umwandeln" kann man die DB nicht. Du musst es so machen, wie ich es beschrieben habe: neue DB anlegen und dann alle Postfächer in die neue DB verschieben (geht alles über die grafische Oberfläche, wobei ich mir angesichts der Version nicht 100%ig sicher bin).
    Das MUSST Du machen, auch wenn die DB jetzt scheinbar wieder funktioniert - eigentlich dürfte sich das Ereignisprotokoll des Servers mit Meldungen füllen, dass die Daten dringend in eine neue DB verschoben werden sollten, da die aktuelle DB repariert wurde. Geh nicht das Risiko ein, dass die DB irgendwann mal wieder kaputtgeht, dann aber richtig. Dann ist nämlich alles weg, wenn Du kein vernünftiges Backup hast.

    Eigentlich würde ich Dir sogar empfehlen, den Exchange neu aufzusetzen (wer weiß, was da sonst noch im Argen liegt), allerdings müsstest Du dann eine Betriebssystemlizenz für einen separaten Server kaufen, weiß nicht, ob das im Budget ist. ;-)

    Bei den virtuellen Verzeichnissen: bist Du da nach der Anleitung vorgegangen und hast das virt. Verzeichnis jeweils erst entfernt und dann wieder hinzugefügt?

    Schau mal unter dem folgenden Link, da gibt es noch ein Troubleshooter-Tool, vielleicht findest Du darüber mehr raus?:

    https://blogs.technet.microsoft.com/exchange/2010/12/07/resolving-winrm-errors-and-exchange-2010-management-tools-startup-failures/

    Liebe Grüße

    Ben

    ____________________________

    MCSA Office 365

    MCSA SQL Server 2014

    MCITP Windows 7

    MCSA Windows 8/10

    MCSE Server Infrastructure

    ____________________________

    Wenn Dir meine Antwort hilft, markiere sie bitte entsprechend als Antwort. Danke! :-).

    Montag, 31. Oktober 2016 14:11
    |
  • Question
    Anmelden
    0
    Anmelden
    neue DB anlegen und dann alle Postfächer in die neue DB verschieben (geht alles über die grafische Oberfläche, wobei ich mir angesichts der Version nicht 100%ig sicher bin).

    Nun, eines der Probleme IST ja, dass die grafische Oberfläche nicht lädt ;-)

    Eigentlich würde ich Dir sogar empfehlen, den Exchange neu aufzusetzen (wer weiß, was da sonst noch im Argen liegt),

    Schon, aber die Erwähnung von "companyweb" deutet arg auf nen SBS hin, da isses nicht so einfach...

    Hier ist mal die offizielle Guidance zum IIS-Statuscode 500.19, einige der gelisteten Phänomene könnte ich mir bei Deinem Kunden durchaus vorstellen aufgrund der Schilderung: https://support.microsoft.com/de-de/kb/942055.

    Das Doofe ist: Wenn da tatsächlich web.config-Dateien oder Berechtigungen im IIS verbogen sind, würde ein Exchange-SP sie wieder richten. Bei den Artefakten, die Du hast, ist die Wahrscheinlichkeit aber recht groß, dass das Update nicht erfolgreich ist.

    Wenn der Kunde einen Tag Downtime des Gesamtsystems vertragen kann, könntest Du eine Swing Migration machen (http://www.sbsmigration.com/swing-migration).

    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (in German) -> http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Montag, 31. Oktober 2016 21:25
    |