Nach Totalausfall des Exchangeservers kein Restore möglich

[GuentherH 61]

Deswegen recovert er ja das ad

 

Ok, der ging in den vielen Schritten unter ;)

 

LG Günther

[lasseboo 10]

By the way . . .ein kurzer Kommentar von einem Allround - Techniker:

 

das sind sicher so manche unter uns ...

 

Ich würde (basierend auf Erfahrung, MCSEboard und anderen Quellen) folgenden Weg gehen:

 

-die VM mittels Shadowprotect in eine abgeschottete Umgebung recovern

-da die VM auch DC war sollte diese dann auch starten

 

genau so haben wir es gemacht!

 

-in der abgeschotteten Umgebung einen Client mit Outlook einbinden

-mit Outlook die Postfächer sowie die öff. Ordner sichern

 

... und diesen Schritt konnten wir schon nicht mehr gehen, da der Exchange ums Verrecken nicht den Informationsspeicher laden wollte. Übrigens trat dieser Fehler in letzter Zeit immer wieder auf, ohne erkennbare Fehler (Logs).

 

Der 2010er steht auch schon bereit, aber der Crash war schneller als wir; mal davon abgesehen, dass wir dem ganzen nicht besonders unruhig entgegengesehen haben - bis Montag nacht dachten wir ja auch noch, dass wir die Postfächer ohne grössere Probleme migrieren könnten.

 

grüsse

[djmaker 95]

Dann bleiben nur noch Ontrack oder die lokalen OST-Files auf den Clients. Wenn der IS in der VM nicht startet wird er es wohl auch nicht nach der Wiederherstellung in der tun.

 

Eventuell hilft ein Recovery des AD in einer abgeschotteten Umgebung und eine Installation des Exchange in einer neuen (und namenstechnisch korrekten VM). Anschließend schiebt ihr die DBs unter und hofft das der Fehler in der ursprünglichen Exchange-Installation und nicht in der DB lag.

[RobertWi 81]

... und diesen Schritt konnten wir schon nicht mehr gehen, da der Exchange ums Verrecken nicht den Informationsspeicher laden wollte. Übrigens trat dieser Fehler in letzter Zeit immer wieder auf, ohne erkennbare Fehler (Logs).

 

Das sehr ungewöhnlich. Normalerweise werden bei Starte (und bei Fehlstart) des IS immer drei bis fünf Einträge im Eventlog generiert. Es braucht nur ein wenig Erfahrung, da die richtigen Informationen draus abzuleiten.

[logicus 10]

spannendes Thema :)

 

mich würde interessieren wieviel DCs in deinem Produktivnetz laufen ? Wenns mehr als einer sein sollte und sich beide DCs NACH dem Recovern gesehen haben -> :mad:

 

gruss

logicus

[lasseboo 10]

Danke nochmal für eure Tipps!

 

Inzwischen bin ich halbwegs sicher, dass der Fehler primär gar nicht im Exchange lag / liegt, sondern am AD. das ist bereits über mehr als ein Jahrzehnt von diversen Administratoren und über alle möglichen Servergenerationen hinweg immer weitergeschleppt worden, und trotz DSRM und AD-recovery bekommen wir die Probleme mit AD ud Exchange (hauptsächlich mit dem IS-Fehler) nicht weg - mal davon abgesehen, dass die Installation von Exchange 2003 und auch 2010 (sind wir als letzte alternative jetzt drauf ausgewichen) noch nicht ein einziges mal sauber durchgelaufen ist, obwohl wir versucht haben, uns penibel an die bekannten anleitungen (Yusuf ;-), Microsoft) zu halten.

 

Zwischendurch ist dann erneut der FSMO abgeraucht, und mir fiel dann auf, dass es mit dem Informationsspeicherfehler in Exchange und einem zeitgleichen Ausfall des FSMO schon seit einiger Zeit so ging.

 

Nach einer Woche Mehr oder weniger Durcharbeitens mit jeweils kaum mehr als 4 stunden schlaf wissen wir im moment keinen anderen Ausweg mehr, als eine zweite Domäne aufzuziehen, dort ein sauberes 2008er ADS aufzusetzen und einen zweiten Memberserver mit Exchange drin zu installieren. Wenn man sich dann mit dem Server verbinden kann, importieren wir die Postfächer (OnTrack PowerControls ist wirklich ein geniales Produkt und deren Kundenorientierung ist absolut lobenswert!) und sehen zu, ob wir den Usern aus der alten Domäne per Trust Zugriff auf den Exchange gewähren können. Im Herbst migrieren wir dann alle Server sukzessive auf die neue Domain.

 

An Screenshots mit Problemen, die so alle bei der Installation in diesem Netzwerk aufgetreten sind, haben wir jedenfalls inzwischen Dutzende! :cry:

 

"gääähn!"

[RobertWi 81]

Ganz ehrlich: Würde ich auch so machen.

 

AD ist die fundamentale Grundlage für Exchange und viele andere Produkte. Wenn ich zu einem Kunden gehe und Exchange "einführe", dann analysiere ich zuerst AD und beginne mit Exchange erst, wenn AD nachweislich sauber läuft.

 

Solange Du AD-Probleme hast, wirst Du mit Exchange vermutlich nie auf einen grünen Zweig kommen.

 

Und irgendwann wird es dann eine Frage des Geldes: Wie lange will man noch suchen und was kostet das und wie lange braucht es, das Ding sauber neu aufzubauen.

 

Viel Glück auf jeden Fall und Ontrack wird sicher eine gute Hilfe sein!

[lasseboo 10]

Vielen Dank!

 

Einen letzten Versuch starten wir gerade noch, verzweifeln dabei aber daran, dass wir beim Erstellen eines Postfachs auf dem Exchange 2010 nur wenige Benutzer aus dem AD sehen. Legen wir bspw. das Postfach "Meier" trotzdem an, gibt es logischerweise eine Warnmeldung, weil Meier eben doch schon im AD vorhanden ist.

 

Der direkte Import der PSTs aus OnTrack per Exchange ManagementKonsole schlägt fehl. Unserem Adminaccount haben wir per Konsole die Berechtigungen zum Import/Export zugewiesen. Es gibt aber die Meldung:

 

Datenbank für Postfach 'Meier' konnte nicht ermittelt werden.
   + CategoryInfo          : InvalidArgument: (empfang-hdd:MailboxOrMailUserIdParameter) [New-MailboxImportRequest]
  MailboxLacksDatabasePermanentException
   + FullyQualifiedErrorId : 7BC839AE,Microsoft.Exchange.Management.RecipientTasks.NewMailboxImportRequest

 

Wir haben die PSTs lokal und auf einem Share abgelegt, beides geht nicht. Die Berechtigung für das "Exchange Trusted Subsystem" würden wir gerne hinzufügen, aber das gibt es gar nicht im AD ...

 

Falls da jemand noch eine zündende Idee hat ...

[NorbertFe 2.045]

Das dürfte daran liegen, dass die Nutzer logischerweise alle noch als "Mailaktiviert" vom "versaubeutelten" Exchange 2003 drin stehen. Da müßte man also die Exchange Relevanten AD Attribute erstmal bereinigen.

 

Bye

Norbert

[lasseboo 10]

das klingt logisch ... :mad:

 

Und auch, wenn das was von Glaskugel-Aussagewert hat: würdest Du, ins Blaue geraten, dem Bereinigen der Attribute oder dem Aufbauen einer neuen Domäne schnellere Verwirklichung zusprechen ... ?! ;)

[RobertWi 81]

Bei Usern, die bereits auf Ex2010 waren, wäre eine Korrektur relativ einfach, das hebt set-mailbox mit.

 

Bei Usern, die noch nicht migriert waren, wird eine Korrektur sehr aufwendig. Pro Userobjekt sind es einige Attribute, aber dann sind noch die sehr vielen Attribute, über die man via ADSIEdit kommt.

 

Das einzige wo ich sicher bin: Bei einer neuen Struktur wird man später weniger Probleme haben.

[lasseboo 10]

Das einzige wo ich sicher bin: Bei einer neuen Struktur wird man später weniger Probleme haben.

 

OK ... :rolleyes:

 

Einen noch: für geben ja ungern auf und sehen inzwischen die User alle im Exchange 2010-Management unter "Empfänger", aber beim Import kommt noch immer folgendes:

 

"Datenbank für Postfach 'Administrator' konnte nicht ermittelt werden.

MailboxLacksDatabasePermanentException"

 

Und zu "MailboxLacksDatabasePermanentException" finden sich bei Google ganze 5 Einträge ... :confused:

 

Ich hab das Gefühl, dass wir nicht mehr weit weg sind, wenigstens die alten Postfächer zum Laufen zu bekommen, dann könnten wir die neue Domäne in Ruhe aufziehen ...

[NorbertFe 2.045]

Ich stimme da Robert zu. Wenn das inzwischen so verfahren ist, würde ich zu einem ordentlichen Neuaufbau tendieren.

 

Bye

Norbert

[lasseboo 10]

ja! Aber ich habe so ein bisschen die Befürchtung, dass wir, wenn wir eine neue Domäne aufziehen und per Vertrauensstellung anbinden, dieselben Fehlermeldungen erhalten :-\

 

Frag mich nicht, warum! :cool:

 

Ich such nochmal ein bisschen nach meinem Import-Mailbox-Fehler ...

[NorbertFe 2.045]

Bereinigen unter Exchange 2003 geht relativ einfach. Du brauchst nur die ESM Tools installieren und dann bei den Usern per Rechtsklick in dsa.msc Exchangeattribute entfernen auswählen. ;)

 

Bye

Norbert