RobertWi

Richtig. Nur wird Dir in der Outlook-Meldung nach Deinem bekunden ein falscher angezeigt und ich habe Dir die Stelle gezeigt, wo der Fehler herkommt. Das ist mich schon klar. Das Problem ist, dass man das Konzept mit den Zertifikaten, Domänennamen, Autodiscover, usw. nicht in einem Forum erklären kann. Hierbei gibt es keine: "Das ist die Lösung", sondern verschiedene Varianten, wo einen Domänennamen bis X Namen im Zertifikat. Was steht genau im Zertifikat für ein Name (die echte Dom-Name ist egal, aber DU musst in der Lage seine, das korrekt zu übersetzen)? Welchen Domänen-Namen meckern die Clients an? Sind das externe oder interne Clients? Wenn extern: Wie sind die angebunden (Outlook Anywhere oder VPN)?

Da Du Deine Domänen verschleierst, kann ich natürlich nicht die richtigen einsetzen. Du musst die Platzhalter schon mit Deinen korrekten Angaben ergänzen.

Moin, die interne URL kannst Du mit: Get-ClientAccessServer | ft Name,Autodiscoverserviceinternaluri -AutoSize auslesen. Die neue wird dann gesetzt mit: Set-ClientAccessServer NAME -Autodiscoverserviceinternaluri URL Die neue URL muss nach dem FQDN genauso aussehen, wie die alte.

Moin, Du musst die Partitionen sichern, auf den sich die die VM befinden, zumindest bei 2008 R2. Und bei den erweiterten Einstellungen auswählen, dass Du eine vollständige Sicherung machen willst (keine Kopiesicherung). Das Windows Backup-Programm ist da ein wenig simpel gestrickt.

Moin, die entscheidende Frage ist, ob "autodiscover.doma" denn auch in Deinem Zertifikat enthalten ist?

Moin, Hyper-V kannst Du auch schon mind. im 2008 R2 sichern - mache ich bei meinen eigenen Servern. Wenn die Integrationsdienste drin sind, dann bekommt Exchange in der VM die Sicherung mit. Eine Rücksicherung musste ich noch nicht machen, aber da die Sicherung in Hyper-V supported ist, sollte es auch die Rücksicherung sein. :)

Schaust Du hier: Re-create Discovery and Other System Mailboxes in Exchange 2010: Exchange 2010 Help

Ach, wenn schon die Mailabfrage nicht geht, dann sieht das eher wie ein Problem beim Popcon bzw. dem Provider aus. Denn diese Mail kommt ja gar nicht bis zum Exchange, die kann schon gar nicht vom Pop abgeholt werden. (Und wieder ein Eintrag in der Liste der Problem, die man ohne POP-Connector nicht hätte.)

Wie genau siehst Du denn, dass es nicht geht? Fehlermeldung? Woher?

Wenn Du eine DAG einrichtest, weißt Du, was das ist und dann weißt Du auch wofür das CNO steht. ;)

Der wichtigste Tipp: Die Installationsvoraussetzungen genau beachten! Da sind manche Dinge von Hand zu machen (z.B. ein CNO für DAG einrichten), die man nicht gewohnt sind.

Wer nicht weißt, was in dem Fall Interim updates sind, hat auch keine installiert. :) Das sind Updates, die Du nur in konkreten Problemfällen installierst (QFE oder Hotfix) und Dir hierfür speziell über den MSFT-Support anforderst.

Allerdings würde ich die betreffenden Dienste nicht deaktivieren, sondern nur auf manuell setzen. Forefront hat Norbert schon geschrieben, geht am besten via fscutility.

Moin, eine offizielle Einbindung dürfte es schon aufgrund des Prinzipes des Vertrauens nicht geben. Eventuell kann man die Mails per POP abholen oder irgendwie weiterleiten. Dann bleibt aber immer noch das Problem des Versendens und das es in Exchange kein Sender-based Routing gibt. Im Prinzip kannst Du es also in Exchange so einbinden, wie in Outlook.

Die zeit für den Check hängt natürlich von der Performance des Plattensystems ab. Ich würde 1 bis 2 Stunden erwarten. Wenn Du wirklich mal nebenbei ein Check machen willst, steuere diskshadow manuell. Du legst Dir damit eine Schattenkopie an, die kannst Du wegkopieren und an anderer Stelle dann mit eseutil bearbeiten (dann musst die Du absoluten Pfade mit den passenden Schaltern mit angeben!). Beispiel siehe hier: 245. Exchange 2007 Backup auf Windows Server 2008 mit Bordmitteln (reloaded) « Wolfgang on the Road

Ich auch. Korrekt. Die Sicherung ist Dirty Shutdown, die EBD nach dem Aufheben der Bereitstellung sollte "Clean Shutdown" sein (Einschränkung wie oben, sehr viele Log-Dateien). Wenn Du eine Datenbank im Dirty Shutdown sehen willst, musst Du die store.exe im Taskmanager abschießen (don't do this at home.... :)). Ja, darum sollte das auch nur im Notfall angewendet werden: - DB ist Clean Shutdown, hat aber Fehler - DB ist Dirty Shutdown und die Log-Dateien fehlen Bei einer Reparatur werden keine Log-Dateien eingearbeitet und daher gibt es damit eventuell einen Datenverlust. /r arbeitet die offenen Log-Dateien ein. Das geht aber nur, wenn die auch noch da sind und intakt sind. Sollten sie verloren gegangen sein, bleibt nur /p für eine Reparatur. Aber dann hat man den Datenverlust sowieso. Das ist jetzt schwierig zu sagen. Eventuell hilft es, wenn Du das Backup an einem anderen Ziel-Ort neu einrichtest.

Moin, wenn die Datenbank erfolgreich gemounted wurde, dann wurde dabei automatisch ein Softrecovery-Vorgang gestartet. Du solltest beim Start des Server Informations-Einträge im Eventlog sehen, die sinngemäß etwas mit "Wiederherstellung wurde gestartet" und "Wiederherstellung wurde erfolgreich beendet" beeinhalten ("Wiederherstellung ist hier eine unglückliche ober wörtlich korrekte Übersetzung von "Recovery"). Exchange führt Softrecovery immer beim Start durch, wenn es die Datenbank im Dirty Shutdown-Status vorfindet (was normalerweise nicht der Fall ist, da die Datenbank beim Runterfahren schon bereinigt werden). Nur in wenigen Ausnahmefällen, wenn z.B. sehr viele Log-Dateien vorliegen, die innerhalb eines gewissen Zeitrahmens nicht eingearbeitet werden können, wird der Recovery-Vorgang abgebrochen. Wenn Du Deine oberen Schritte ausführst, ist die Datenbank "Dirty Shutdown", weil eine Sicherung diese immer so sichert und die fehlenden Log-Dateien mitnimmt. Du gewinnst also keine Aussagekraft. Wenn Du wirklich Angst um die Datei hast, dann nimm sie offline und führe im Offline-Zustand eine Prüfung "/g" und eine Defragmentierung "/d" durch. Danach löschst Du alle Log- und CHK-Dateien und kannst sicher sein, dass alles ok ist. Eine Reparatur würde man dann mit "/p" durchführen. Ich persönlich würde aber erstmal GAR nichts machen und das Event-Log beobachten. Mit sehr hoher Wahrscheinlichkeit ist alles ok. Datenbankfehler treten fast nur noch bei Storage-Fehlern auf, aber sehr sehr selten bei Stromausfällen.

Das ist die Größe des Postfaches. Im Postfach können aber auch Größenbeschränkungen für Mails gemacht werden. Einstellungsort kann ich nicht mehr sagen, habe kein Ex 2003 mehr.

Moin, die musst Du nicht bewegen. Falls sie nicht mehr vorhanden sind, legt Exchange automatisch neue an.

So natürlich:

Moin, da Du mit einem Pop-Connector arbeitest und damit keine gute Fehlermeldung siehst: Bist Du SICHER, dass es sich um die Größenbegrenzung handelt? Im Postfach könnte auch noch eine Größenbeschränkung geben.

Moin, ist IPv6 aktiviert`(und funktionsfähig) oder richtig über Regkey deinstalliert?

Bei Ex 2003 gab es noch etwas, dass sich Frontend / Backend nannte. Ja nach Anwendungsfall könnte auch das das Gewünschte sein. MSXFAQ.DE - Frontend/Backend Konstellation

Moin, die ExBPA-Meldung ist ok, das ist ein Übersetzungs-Fehler im ExBPA. Dienste laufen auch alle. Das Symantec daran schhuld war, glaube ich auch. Ich würde als erstes Mal die Bindungen im IIS überprüfen. Ansonsten hilft danach eventuell ein IIS-Reset: Reset Client Access Virtual Directories: Exchange 2010 Help

Na ja, aus dem oben lese ich nur, dass der externe DNS-Name nicht aufgelöst werden kann. Mit den wenigen Infos (kein Vorwurf, Du hast ja nicht mehr), wird das aus einem Forum nicht lösbar sein. Das muss sich dann jemand mit Ahnung vor Ort direkt ansehen. Hast Du Fehlermeldungen im Eventlog? Gibt der ExBPA was aus? Meldet "test-servicehealth" fehlende Exchange-Dienste?