RobertWi

Bitte alle Eventlog-Einträge in kompletter Länger posten. ;)

bei dem SRV-Eintrag habe ich gehört das es Probleme mit Active-Sync-kompatiblen Geräten gibt- kann dazu auch noch jemand was sagen?

Das kommt darauf an. ;) EAS-Clients sind Aufgabe des Herstellers des mobilen Gerätes. Es gibt also keine feste Vorhersage, was geht und was nicht geht. Und das nächste Update kann dann leider das Verhalten wieder verändern.

Aber wenn Du sichergehen willst, brauchst Du ein SAN-Zertifikat.

Welche Fehlermeldungen gibt es im Eventlog, wenn Du den Dienst startest?

Moin,

bei Autodiscover ist die "Grenze" der ABP erreicht. Das ist aber bewusst so, es ist nur eine Trennung der Adressbücher, Senden, Empfangen, URLs, etc. sind nicht wirklich getrennt.

Für das Zertifikat hast Du nun zwei Möglichkeiten:

- ein SAN-Zertifikat, dass alle notwendigen Namen behinhaltet

- ein SRV-Eintrag setzen, der Autodiscover von Domäne A auf den Eintrag von B umleitet (das gibt eine Warnung, die der User deaktivieren kann)

Gab es Fehler oder Warnungen, dass Log-Dateien fehlen oder fehlerhaft sind?

Wiviele Log-Dateien waren es?

Schon mal einen zweiten Versuch gestartet? Geht dann vermutlich schnell?

Vor Isinteg würde ich erstmal in Outlook nachschauen, ob sich was getan hat.

Seh ich wiedermal den Wald vor lauter Bäumen nicht?

lg

Ja. :)

Aus der Hilfe zu eseutil (mit Schalter /r):

ESEUTIL /r [b][i][u]<3-character logfile base name>[/u][/i][/b] [options]

-> Hinter /r muss noch das Datenbank-Prefix angegeben werden, z.B. E00, E01, E07. Das sind die ersten drei Zeichen der Log-Dateien.

Und bei den Pfaden darf zwischen Option und Pfad kein Leerzeichen sein. Aber auch das steht in der Hilfe... ;)

Moin,

"System Files" ist vor allem die *.chk-Datei und noch eventuell TEMP-Dateien.

Das ist dann Schalter "/s".

BTW: eseutil hat übrigens eine relativ vernünftige Hilfe. eseutil ohne Schalter starten, r drücke und die weiteren Optionen ansehen.

Moin,

soweit ok. Über "-IncludeAcceptedDomains" könnten noch andere Domänennamen reinkommen.

Aber wenn es eh nur intern ist, kannst Du autodiscover.meinefirma.local auch darin aufnehmen und notfalls mehrfach probieren. Das kostet nur ein wenig Zeit, aber kein Geld.

Hey,

 

Bist Du mittlerweile weiter gekommen oder kann man noch helfen?

 

Gruß Jan

Erstes: Bitte keine fremden Threads kapern.

Zweitens: Was gefällt Dir denn an der Lösung in Post #1, #2 und #3 nicht?

Moin,

was sagt "test-servicehealth"?

Habt ihr eventuell am SSL rumgespielt oder eine Umleitung von HTTPS auf HTTP falsch eingerichtet?

Vergleich mal die Einstellungen der beiden Server im IIS miteinander.

Das können wir auch nicht genau sagen. Was Norbert meint: Es ist müssig, über einen Fehler zu diskutieren, der eventuell in einem der vier Updates danach behoben wurde.

Sicher, das SP1 ist noch offiziell supported, aber solange es keine zwingenden Gründe gibt, fährt man meistens mit der aktuellen Version besser (und in diesem Fall sind keine echten Probleme bekannt).

Mit dem zweiten Absatz ist gemeint, dass Du sowieso eine neue OST-Datei brauchst und die Daten in der alten verlieren wirst. Es hat also keinen Sinn mehr, darüber nachzudenken, warum kein Sync in Richtung Exchange passiert (was es ja eh nicht gibt).

Die OST ist "hinfällig". Also alles rausziehen und eine neue anlegen.

Moin,

mit Geld: z.B. GroupWise to Exchange Migration Solution from Quest Software

ohne Geld: z.B. via IMAP4 (Outlook, fetchmail, was auch immer)

6 GB weckt zumindest die Hoffnung, dass noch Daten drin sind, aber ich weiß nicht, wie Ontrack mit Whitespace umgeht.

Vor den Recover-Versuchen nimmst Du die EDB und alle Log-Dateien dieses Standes und macht mit eseutil /r Exx ein Softrecovery. Schau Dir mal die Hilfe von eseutil /r an, da gibt es Schalter für die Pfadangaben zu den Dateien (die ja bei Dir an anderer Stelle liegen) und Schalter, die fehlerhafte Daten überspringen.

Allerdings wäre es interessant zu erfahren, warum Exchange die wiederhergestellte Datenbank nicht mounten will.

Moin,

ich hab's befürchtet. Die Daten sind vermutlich gar nicht mehr in der EDB-Datei, nur die Referenzen waren noch vorhanden.

Na ja, das Problem ist, dass Du mit eseutil /p eine Reparatur mit Datenverlust durchgeführt hast. Die Daten in den Protokolldateien sind dabei verloren gegangen. Zuerst hätte man ein Softrecovery probiert um möglichst viele Daten zu retten.

Jetzt gibt es zwei Möglichkeiten: Die Datenbank ist wirklich nur für Exchange defekt, dann hilft Dir Ontrack. Oder die Daten sind wirklich weg, dann hilft auch kein Werkzeug mehr.

Eine Sicherung von vor den ganzen Rettungsaktionen hast Du nicht mehr?

Deswegen sollst Du die Daten ja auch vorher in eine PST-Datei exportieren, bevor die neue OST-Datei erzeugt wird. ;)

Und natürlich sollten da auch Termine, Kontakte, Kalender, etc. exportiert werden.

... 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.

Kommt der Screenshot aus einer offiziellen Doku?

Allerdings muss ich ganz ehrlich sagen, dass ich deutsche Dokus meistens vermeide. Da in Deutsch meistens kein Techniker Korrektur liest, sind solche Fehler vorprogrammiert.

In Redmond konnte ich mich mal mit einem PM des Customer Experience Teams von Exchange unterhalten, der zufällig auch einige der deutschen Übersetzungseskapaden kannte - z.B. "State -> Bundesland (sollte "Status" sein)" - "Show from -> Anzeigen aus (sollten "Von anzeigen" sein)" - "To: -> Bis: (sollte "An:" sein)" usw.

Aber das wird jetzt OT.

Berichte mal, wie es ausgegangen ist!

Autsch. Da bist du jetzt nicht ins Fettnäpfchen getreten, sondern in eine Riesentonne Schmieröl gefallen ;) :D

 

Bevor du Robert den Exchange Server erklärst, solltest du dir einmal seine Signatur ansehen ;)

Ach, habe ich keine Probleme mit. Es vergeht kaum ein Tag, an dem ich bei Exchange nicht noch was dazulerne und wenn mein Wissen falsch oder veraltet ist, dann bin ich sogar dankbar, wenn mich jemand auf den Fehler hinweist und ich mein Wissen korrigieren kann.

Da verwechselst du zwei Dinge!

Nein., ;)

Das Recovery eines DC ist nicht empfohlen - und zwar schlicht aus dem Grund, dass die ADDS-Datenbank inkonsistent wäre und wegen der Kerberosgeschichte (Timestamps!).

Das nennt sich dann USN Rollback und hat nichts mit Kerberos zu tun (obwohl die Kerberostickets natürlich auch ungültig werden), sondern es hat etwas mit der Replikation der AD-Objekte zu tun.

Und von dcpromo auf einem Exchange rät Microsoft ebenfalls ab.

"Abraten" ist nett formuliert, es ist unsupported.

Seit ein paar Jahren lässt Microsoft Virtualisierung des Exchange ausdrücklich zu, allerdings nur auf ihrem eigenen Hyper-V-Zeugs.

Mehrfach falsch. ;)

Virtualisierung ist ab Ex 2007 offiziell erlaubt (nicht für Ex 2003 wie bei dir!) und es sind alle zertifizierten Hypervisor-Techniken erlaubt, u.a. Hyper-V, Vmware, Xen und noch ein paar andere.

(Wobei ich zugebe, dass Ex2003 bei mir nicht mehr den höchsten Stellenwert hat und sollte sich das Supportverhalten virtualisierter Ex2003 in den letzten Zeiten verändert haben, habe ich das mangels Notwendigkeit vielleicht nicht mehr registriert.)

Eine Datenbank aus einem gesicherten Exchange zu ziehen ist meines Wissens nicht verboten - aber ich kenne auch nicht das gesamte ***-Kompendium.

Habe ich auch nicht behaupte. Nur, dass ihr es falsch gemacht habt, bzw. Schritte nicht durchgeführt worden.

Zwei Tage und Nächte intensiver Fehlersuche würde ich jetzt nicht als blinden Aktionismus bezeichnen; aber es war natürlich noch nicht genug Fehlersuche, da hast Du sicher Recht ...

Wenn ich zwei Tage und Nächte einen Fehlersuche und nicht finde, ist irgendwann der Zeitpunkt erreicht, wo ich mir professionelle Hilfe dazuhole (ja, sogar bei Exchange, denn niemand weiß alles).

Jetzt muss ICH mal fragen, ob du dich jemals auf den Microsoft-Supportseiten herumgetrieben hast und das von mir angeführte Dokument kennst ... Tipp: such mal einfach nach "exchange adsiedit" bei *** und wundere dich ...

Du musst mir nichts über die Support-Seiten von MSFT sagen. Geh einfach davon aus, dass ich 60 Stunden die Woche nichts anderes, als Exchange mache. ;)

Ich habe mir Dein Dokument angesehen und KEINEN Hinweis auf das Löschen eines Computerkontos gefunden.

Auch das findest Du (Microsofts Supportsuche ist dein Freund) - allerdings verbunden mit einer deutlichen Warnung davor, es in einer Produktivumgebug zu tun. Produktiv ist unser Exchange aber schon seit einiger Zeit NICHT mehr ... :-\

Worüber reden wir dann eigentlich?

Aber falls es beruhigt: Wie man "richtig" Recovert und wichtig bei Ex2003 der LegacyDN ist, habe ich auch nur durch Schmerzen gelernt und bin sehr froh, dass das bei Ex2007 nicht mehr so schwierig ist. :D

- StartDagServerMaintenance.ps1

- StopDagServerMaintenance.ps1

 

müssen die enstprechen auf die jeweilige Infrastruktur angepasst werden,

Nein, nur den Servernamen angeben-

wenn nun das script start*.ps1 ausgeführt wird, anschliessend nach dem Patchen

dass stop*.ps1 sript zum Einsatz kommt, ist meine aktiv/ passiv Zuordnung wie vor dem patchen, oder muss ich dann von Hand tätig werden?

Siehe meinen Post zwei darüber: Redistribute-Script ausführen, um die Datenbanken wieder nach Präferenz auf die Server zu verteilen.

Ja, so würde ich das auch interpretieren: Da läuft noch ein Backup (aus Sicht von Exchange).

Kannst Du auch über die Shell mal verifizieren: get-mailboxdatabase -status | fl *backup*

Eventuell muss Du den ganzen Server einmal neustarten.

Also zusammengefasst bleiben Euch nur zwei Varianten:

- AD recovern

- Exchange sauber darin aufbauen oder sauber recovern

- Datenbank wieder zurückspielen

Oder:

- EDB-Dateien mit Fremdtools auslesen

- AD wegwerfen und AD und Exchange komplett neu aufbauen

Wenn ihr jetzt weiter rumbastelt, werde ihr die Auswirkungen noch in Jahren bemerken, weile jede Exchange-Version dann immer wieder auf irgendwelche Fehler stoßen wird.

Moin,

bei Exchange 2003 funktioniert der Restore einer Datenbank nur, wenn der Name der Exchange Organisation, des Servers, der Administrativen Gruppe und der Speichergruppe identisch zum Backup ist. Sonst weigert sich Exchange, die Datenbank zu mounten.

Dir wird also nichts übrig bleiben, als so viel wie möglich vom Original wiederherzustellen, bevor Du die Datenbank mounten kannst. Also erst AD recovern, dann Exchange, dann die Datenbanken.

Vermutlich ist es aber einfacher, Du kaufst ein Fremdtool (z.B. von Ontrack), dass Dir die Daten aus den EDB-Dateien extrahiert und baust die Exchange-Umgebung sauber neu auf.

Das kostet zwar Geld (wobei Deine Arbeitsleistung ja auch nicht kostenlos ist, hoffe ich), dürfte aber deutlich schneller gehen.

By the way: wie hättest du´s denn gemacht, so dass es besser funktioniert hätte bzw. welche waren denn unsere gravierendsten Fehler aus deiner Sicht ... ? Wir haben ziemlich strikt versucht, nach Microsofts Anleitungen vorzugehen - und sind erst dann den inoffiziellen Tipps mit "Datenbank neuem Server unterschieben" und dergleichen gefolgt; alles erfolglos.

Ehrlich: Es fällt mir schwer zu glauben, dass ihr Euch wirklich an Microsoft-Anleitungen gehalten habt.

Beispiele:

VMWare-Maschine, die nicht mehr startete. Als wir die Maschine aus dem ShadowProtect wiederhergestellt hatten, liess sich der Informationsspeicher nicht mehr starten.

Exchange 2003 in einer virtuellen Umgebung ist unsupported. Das Recovery aus Snapshots ist hochradig verboten - die Resultat hast Du ja nun erlebt.

liess sich der Informationsspeicher nicht mehr starten.

Anstatt dann in blinden Aktionismus zu verfallen, hätte man an dieser Stelle erstmal analysieren können, warum der IS nicht mehr starten wollte.

Im AD DS die Exchangeeinträge gelöscht,

Ich kenne keine MSFT-Anleitung, die das Löschen von Exchangeeinträgen beschreibt (wobei ja nicht klar ist, WELCHE Exchangeeinträge Du überhaupt meinst), außer, wenn man Exchange wirklich loswerden will.

Im Gegenteil, lautet die Microsoft Empfehlung, NICHTS zu löschen, von dem man nicht genau weiß, dass es weg darf.

Also haben wir das Computerkonto stumpf gelöscht.

Das ist so ziemlich das schlimmste, was man machen kann. Am Computerkonto hängen Berechtigungen, Gruppen und hunderte andere Einstellungen, die man damit unwiederbringlich verloren hat. Das Umbennen (!) eines Computers mit Exchange drauf ist unsupported. Was meinst Du wohl, wie MSFT über das Löschen eines Computer mit Exchange denkt?

(rüberkopierten) Datenbanken aus der Sicherung möglich.

Es würde mich wundern, wenn es eine Anleitung von Microsoft gibt, in der "Rüberkopieren" reicht. Bach einem Restore ist IMMER ein Soft- oder Hardrecovery erforderlich, so das rüberkopieren schon technisch nicht reicht.

wir haben versucht, den Namen mit adsiedit und dann mit LegacyDN zu ändern - das schlug immer fehl

Wie ich oben schon schrieb, müssen die Namen identisch sein. Und das man mit ADSIEdit die Namen nachträglich ändern kann, wirst Du in keiner Microsoft Anleitung finden, schon weil der LegacyDN gefühlt 100x in verschiedenen Objekten steht. Es gibt eine Anleitung, aber da wird mit LDIFDE ein Export gemacht, manuell geändert und dann wieder importiert (Zum Ändern des Attributs LegacyExchangeDN im einheitlichen Modus ADSI-Bearbeitung).

Hier muss ich aufhören, weil im Forum pro Post nur 4000 Zeichen erlaubt sind. ;)

Moin,

man, das ist soviel schiefgelaufen, mein Zähler hat wirklich schon zweistellige Bereiche erreicht.

Ich bezweifle, dass man das in einem Forum sinnvoll besprechen kann. Das muss sich vermutlich jemand vor Ort ansehen.

Mal unabhängig von den vielen Fehlern, die ihr gemacht habt, WAS ist denn nun der aktuelle Stand? Und über welche Exchange-Server-Version reden wir denn überhaupt?