Exchange 2010 - interne E-Mail Weiterleitung funktioniert nicht

[Smidddi 3]

Hallo zusammen,

 

Ausgangssituation:

- SBS 2011 -> Exchange 2010 (alle Wizards bei Erstinstallation ordnungsgemäß durchlaufen)

- Kaspersky verschiebt Exchange DB Transaktionsprotokolle in Quarantäne

- Server wird (nicht von mir) hart neu gestartet

-> Exchange Datenbank defekt.

-> Reparaturversuche mit ESEUTIL, ISINT und Powershell CMDLets scheitern

- Neue Exchange Datenbank wird erstellt (Datensicherung ebenfalls korrupt, Fehler scheint also schon länger bestanden zu haben)

- Postfächer werden, sofern möglich, in die neue Datenbank migriert. Nicht migrierbare Postfächer werden am Client (zum Glück Caching-Modus an) exportiert, deaktiviert, neu erstellt und am Client wieder importiert

 

Soweit so gut. Das Verfassen externer E-Mails bereitet keinerlei Probleme. Der Empfang funktioniert auch wieder störungsfrei (ganz merkwürdige Verhaltensmuster bei einigen Postfächern...)

Über die WebApp funktioniert ebenfalls soweit alles.

 

Problemstellung aktuell im Outlook der Mitarbeiter:

- interne E-Mail Weiterleitungen laufen in einen Unzustellbarkeitsbericht

- interne E-Mails laufen in einen Unzustellbarkeitsbericht

 

Habe ich vergessen, etwas in der Exchange Konfiguration auf die neue Datenbank umzustellen?

 

Was ich noch nicht getestet habe, gleich aber noch tun werde, ist die manuelle Synchronisierung des Exchange Adressbuchs auf Client-Seite. Falls auch das keine Besserung bringt führe ich die SBS Assistenten nochmals durch (wobei ich das Problem eher auf Client-Seite sehe).

Hallo zusammen,

 

die Fehlerursache lag tatsächlich auf Client-Seite:

Outlook -> Datei -> Optionen -> E-Mail -> AutoVervollständigen-Liste leeren -> OK -> Outlook neu starten

 

Scheinbar passen die IDs der Postfächer, auch nach Migration in eine neue Datenbank, nicht mehr...

[RobertWi 81]

- Kaspersky verschiebt Exchange DB Transaktionsprotokolle in Quarantäne

 

Böser Fehler... :( Unbedingt abstellen.

 

- Server wird (nicht von mir) hart neu gestartet

-> Exchange Datenbank defekt.

 

Daran war sicher nicht der Reboot schuld, sondern fehlende Transaktionsprotokolle.

 

-> Reparaturversuche mit ESEUTIL, ISINT und Powershell CMDLets scheitern

 

Wildes Rumdoktoren ist meist kein guter Weg - besonders bei so einem kapitalen Ausfall.

 

- Postfächer werden, sofern möglich, in die neue Datenbank migriert.

 

Wie geht das, wenn man die alte DB nicht gemoundet bekommt?

 

die Fehlerursache lag tatsächlich auf Client-Seite:

Outlook -> Datei -> Optionen -> E-Mail -> AutoVervollständigen-Liste leeren -> OK -> Outlook neu starten

 

Scheinbar passen die IDs der Postfächer, auch nach Migration in eine neue Datenbank, nicht mehr...

 

Das Problem hierbei ist nicht die Mailbox-GUID, sondern "LegacyExchangeDN". Das merkt sich Outlook in den Vorschlägen und das hat sich durch Deine Import verändert. Dafür gibt es auch keine andere Lösung, als die von Dir beschriebene. PST-Import dürfen halt immer nur die allerletzte Lösung sein, davor muss man alles tun, eine saubere Rettung zu erreichen.

[Daniel -MSFT- 129]

Das Problem hierbei ist nicht die Mailbox-GUID, sondern "LegacyExchangeDN". Das merkt sich Outlook in den Vorschlägen und das hat sich durch Deine Import verändert. Dafür gibt es auch keine andere Lösung, als die von Dir beschriebene. PST-Import dürfen halt immer nur die allerletzte Lösung sein, davor muss man alles tun, eine saubere Rettung zu erreichen.

 

Man könnte den alten LegacyExchangeDN aus dem NDR herausnehmen und als X500-Adresse der neuen Mailbox hinzufügen: http://community.office365.com/de-de/forums/116/p/210660/644934.aspx

 

@Smiddi: An Deiner Stelle würde ich das als Warnung nehmen, die IT-Infrastruktur grundlegend zu überprüfen. In dem Virenscanner gehören Ausnahmen definiert: http://blogs.technet.com/b/dmelanchthon/archive/2009/11/13/was-virenscanner-nicht-scannen-sollten.aspx. Weiterhin frage ich mich, wer das Backup bisher kontrolliert hat. Da gehört ein Restore-Test dazu.

 

Wie wird das Backup denn genau gemacht? Lies Dir mal https://www.mcseboard.de/topic/197098-neue-konzepte-f%C3%BCr-sbs-kunden/?p=1223089 durch. Das war gerade heute dran.

 

Have fun!

Daniel

[Smidddi 3]

Böser Fehler... :( Unbedingt abstellen.

 

 

Daran war sicher nicht der Reboot schuld, sondern fehlende Transaktionsprotokolle.

 

 

Wildes Rumdoktoren ist meist kein guter Weg - besonders bei so einem kapitalen Ausfall.

 

 

Wie geht das, wenn man die alte DB nicht gemoundet bekommt?

 

 

Das Problem hierbei ist nicht die Mailbox-GUID, sondern "LegacyExchangeDN". Das merkt sich Outlook in den Vorschlägen und das hat sich durch Deine Import verändert. Dafür gibt es auch keine andere Lösung, als die von Dir beschriebene. PST-Import dürfen halt immer nur die allerletzte Lösung sein, davor muss man alles tun, eine saubere Rettung zu erreichen.

 

zu 1. Ja ist richtig. kA, wer den Kaspersky dort eingerichtet hat (leider wird man bei soetwas ja immer zu spät dazugerufen...). Ausnahmen sind bereits konfiguriert.

zu 2. Wodurch der Defekt letztendlich entstanden ist, kann ich nicht nachvollziehen. Wenn ich das richtig verstehe sorgen fehlende / unvollständige Transaktionsprotokolle ja erstmal nicht für eine defekte Datenbank, sondern einen defekten Datenbestand?

zu 3. Bei den Reparaturversuchen wurde, meiner Meinung nach, nicht wild rumgedoktort sondern an Hand diverser Technet Artikel Anweisungen befolgt, die auf Grund der aufgetretenen Fehlermeldungen als hilfreich betrachtet hätten werden können.

zu 4. mein Fehler in der Kommunikation, die Datenbank konnte gemountet werden, allerdings ist der Informationsspeicher bei jedem Zugriff auf eines der defekten Postfächer abgestürzt.

zu 5. Danke für die Korrektur, ist einleuchtend. Und der PST Import war leider der letzte Weg, ohne funktionierende Datensicherung

 

 

 

Man könnte den alten LegacyExchangeDN aus dem NDR herausnehmen und als X500-Adresse der neuen Mailbox hinzufügen: http://community.office365.com/de-de/forums/116/p/210660/644934.aspx

 

@Smiddi: An Deiner Stelle würde ich das als Warnung nehmen, die IT-Infrastruktur grundlegend zu überprüfen. In dem Virenscanner gehören Ausnahmen definiert: http://blogs.technet.com/b/dmelanchthon/archive/2009/11/13/was-virenscanner-nicht-scannen-sollten.aspx. Weiterhin frage ich mich, wer das Backup bisher kontrolliert hat. Da gehört ein Restore-Test dazu.

 

Wie wird das Backup denn genau gemacht? Lies Dir mal https://www.mcseboard.de/topic/197098-neue-konzepte-f%C3%BCr-sbs-kunden/?p=1223089 durch. Das war gerade heute dran.

 

Have fun!

Daniel

 

Die Infrastruktur wird aktuell geprüft. Die Ausnahmen im Virenscanner sind bereits definiert. Das Monitoring und Testen der Datensicherung wurde bislang nicht durchgeführt. Das Backup selbst erfolgt via WBAdmin.

Danke für den Link, das Thema werde ich mir bei Erstellung eines entsprechenden Konzepts nach Prüfung der Infrastruktur zur Brust nehmen. Gerade der Punkt Inkonsistenzen in Datenbanken und so :-)

[NorbertFe 1.840]

zu 3. Bei den Reparaturversuchen wurde, meiner Meinung nach, nicht wild rumgedoktort sondern an Hand diverser Technet Artikel Anweisungen befolgt, die auf Grund der aufgetretenen Fehlermeldungen als hilfreich betrachtet hätten werden können.

Hilft zwar hinterher nix mehr, aber wenn die logs in der Quarantäne lagen... ;)

zu 5. Danke für die Korrektur, ist einleuchtend. Und der PST Import war leider der letzte Weg, ohne funktionierende Datensicherung

Wurden die Postfächer denn neu angelegt? Denn nur weil man was aus einer pst in ein bestehendes Postfach importiert, hat man doch nicht solche Fehler.

 

Bye

Norbert

[RobertWi 81]

zu 2. Wodurch der Defekt letztendlich entstanden ist, kann ich nicht nachvollziehen. Wenn ich das richtig verstehe sorgen fehlende / unvollständige Transaktionsprotokolle ja erstmal nicht für eine defekte Datenbank, sondern einen defekten Datenbestand?

 

Das ist korrekt. Die darunterliegende "SQL"-Engine arbeitet Transaktionsbasiert mit Commit und Rollback. Fehlende Logdateien sollten daher zu fehlenden Daten, aber nicht defekten Datenbank fühlen.

 

zu 3. Bei den Reparaturversuchen wurde, meiner Meinung nach, nicht wild rumgedoktort sondern an Hand diverser Technet Artikel Anweisungen befolgt, die auf Grund der aufgetretenen Fehlermeldungen als hilfreich betrachtet hätten werden können.

 

Das Problem bei Korrekturen an der EDB ist, dass man sehr viel Erfahrung und Kenntnisse über die Struktur braucht. Technet-Artikel können prinzipbedingt nur an der Oberfläche kratzen und sie gehen vor allem nicht auf alle möglichkeiten ein.

 

ich kenne zum Beispiel Artikel, die eseutl /r und eseutil /p zeigen. Aber um zu verstehen, was dabei passiert, braucht man mehr Infos als im Technet. Und eine gute Erklärung, was die Ausgaben bei /mh oder /ml bedeuten, habe ich schon lange nicht mehr gesehen.

 

Bitte versteh meine Aussage daher nicht als Angriff, sondern nur als Hinweis, dass man trotz aller Technet-Artikel bei so heiklen Dingen gut beraten ist, einen Fachmann hinzuziehen.

 

zu 4. mein Fehler in der Kommunikation, die Datenbank konnte gemountet werden, allerdings ist der Informationsspeicher bei jedem Zugriff auf eines der defekten Postfächer abgestürzt.

 

Das deutet eventuell daraufhin, dass Kaspersky hier nicht nur Logs, sondern auch Teile der EDB beschädigt hat.

[Smidddi 3]

@ Norbert: In der neuen Exchange Datenbank wurden die Postfächer, die sich aus der alten nicht migrieren ließen, neu angelegt. Jo. Dabei kam es auch nicht zu Problemen, sondern lediglich beim Zugriff auf eines der defekten Postfächer, sei es nun durch Migrationsversuche oder Clientzugriff.

 

@ Robert: Ich kann die Grundaussage schon nachvollziehen :-) Steht leider viel zu viel Schund im Netz. Ich selbst würde mich, mit mittlerweile knapp 8 Jahren Exchange Erfahrung, nicht als unerfahren bezeichnen und habe bislang auch schon die ein oder andere Reparatur, falls erforderlich, durchgeführt. Nur diesen Status der Datenbank hatte ich so eben noch nicht, das war schon recht heftig...Darum wurde auch als erstes eine Kopie der DB erstellt und erst dann "wild rumgedoktort" :-P

 

 

Das deutet eventuell daraufhin, dass Kaspersky hier nicht nur Logs, sondern auch Teile der EDB beschädigt hat.

 

 

Nicht ausgeschlossen, damit wird nächste Woche der Kaspersky Support konfrontiert, da wir dieses Produkt nicht nur bei einem Kunden einsetzen...

bearbeitet 27. Februar 2014 von Smidddi

[RobertWi 81]

Wobei Kaspersky dabei unschuldig ist. Natürlich wäre es schön, wenn Kaspersky das selbst erkennen würde, aber die korrekten Ausnahmen bei den Suchen einzustellen, ist normalerweise Aufgabe des Admins.