RobertWi

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

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.

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.

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.

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!

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.

Nein., ;) 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. "Abraten" ist nett formuliert, es ist unsupported. 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.) Habe ich auch nicht behaupte. Nur, dass ihr es falsch gemacht habt, bzw. Schritte nicht durchgeführt worden. 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). 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. 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

Nein, nur den Servernamen angeben- 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. Ehrlich: Es fällt mir schwer zu glauben, dass ihr Euch wirklich an Microsoft-Anleitungen gehalten habt. Beispiele: Exchange 2003 in einer virtuellen Umgebung ist unsupported. Das Recovery aus Snapshots ist hochradig verboten - die Resultat hast Du ja nun erlebt. Anstatt dann in blinden Aktionismus zu verfallen, hätte man an dieser Stelle erstmal analysieren können, warum der IS nicht mehr starten wollte. 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. 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? 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. 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?