RobertWi

Könnte es sein, dass die Liste deutsch "Alle Benutzer" heißt?

Moin, Du hast also eine Mischumgebung. Dann leg auf dem Ex 2013 einen neues Postfach als Admin an oder verschieb Dein Admin-Postfach vom 2007 auf den 2013 (via Shell auf dem 2013). Die Anmeldung merkt, dass Dein Postfach noch auf 2007 liegt und will Dich da rüber schieben. Da gibt es natürlich noch kein EAC.

Hmmmm.... Das CU2 hat ohne Dein Zutun einfach einfach so das Berechtigungskonzept geändert? Oder war das eventuell von Anfang an mit geteilten Berechtigungen installiert und Du hast vergessen, dass dann der Exchange Admin nicht automatisch auch AD-Admin ist und umgekehrt?

Moin, es ist zumindest auffällig, wobei man natürlich nicht sieht, ob ein Senden vom normalen Konto in diesem Augenblick nicht auch fehlgeschlagen wäre. Du kannst mal hierein schauen, ob Du zu dem betreffenden Zeitpunkt irgendwas merkwürdiges findest: C:\Program Files\Microsoft\Exchange Server\V14\Logging\RPC Client Access Und, wenn ich so darüber nachdenke: Wenn ich den Fehler sehe, ist er zu bestimmt 90% bei zusätzlichen Konten in Outlook und nicht im Hauptpostfach. Eventuell schlummert hier auch ein Bug (eher Outlook, als Exchange)

Windows - Start -> Herunterfahren.... Oder: Shutdown.exe Oder: Im Hyper-V-Menü "Herunterfahren"...." :) Nö, passt so. Wenn der Witness-Server nicht läuft, wirst Du das vermutlich auch nicht bemerken. DAGs sind sehr stabil und verzeihen viele Fehler. Wahrscheinlich machst Du Dir da überhaupt zu viele Gedanken. Falls auch die DC betroffen sind: Denk daran, dass diese vorher laufen müssen und erst nachher runtergefahren werden.

Nach seiner Beschreibung ziemlich sicher. Der pumpt die Signaturen ins Profil und das hat sich zwischen Ol 2010 und 2013 nicht verändert. Exchange spielt dabei gar keine Rolle. Dass es mit Ol 2013 läuft, schreibt er auch in Post #6.

Outlook verwendet insgesamt drei URLs: - Autodiscover - OAB - EWS (ok, UM noch, spielt meist aber keine Rolle). Es muss ja nicht zwingend Autodiscover sein, auch eine der anderen URL kann verkehrt sein. Und ansonsten werfe ich mal die Glaskugel an und sagen: Im Client ist ein Proxy und diese Domäne oder Exchange ist dort nicht als Ausnahme deklariert.

Ok, dann kann man das vermutlich in einem Forum nicht gut klären und eigene Logs oder so gibt es dazu nicht. Nur im Eventlog kann man eventuell Fehler hierbei sehen. In der Technik ist es so, dass beim Senden der Informationsspeicherdienst die Mail in den Postausgang verschiebt und einen weiteren Dienst (Mailübergabe) triggert. Dieser holt die Mails aus dem Postausgang ab und kümmert sich um die Zustellung. Und wenn bei dem zweiten Schritt irgendein Problem (Netzwerk, Latenz, Performance, etc.) auftritt, war's da. Für den IS ist die Mail getriggert, der Nachfolger hat sie aber nicht bekommen. Manchmal verschwindet sie mit, wenn man eine neue, weitere Mail verschickt (der Mail-Übergedienst sieht dann vermutlich beide, obwohl er nur eine abholen soll). Aber leider gibt es auch immer wieder Fälle, wo man die Mail löschen und neu erstellen muss.

Je nach gesetzter TTL kann es problemlos mehrere Tage dauern, bis die neuen Einträge im Internet gefunden und benutzt werden. Nachtrag: Ein Tool zum Testen von Extern findest Du hier: http://mxtoolbox.com/

Was genau war an meinen Erklären so unverständlich, dass Du zum Holzhammer ADSIEDIT greifen musstest? Das wüsste ich gerne, dann könnte ich das das nächste mal auch so beschreiben, dass man es befolgen kann.

Und an den gehen, der die Anforderung gestellt hat, und im klar machen, dass das ohne zweite öffentliche IP nicht funktioniert.

Moin, außer Autodiscover gibst Du alle URLs selbst in den jeweiliegen VDirs vor.

Aus Interesse: Und wie genau kommen die Signaturen dann in die Mail. Zu diesem Prozess hast Du nichts gesagt.

Und wie findet der absendende Server Deinen Exchange, wenn Du keine DNS-Einträge gesetzt hast? Kein Wunder, dass keine Mails ankommen, oder?

Moin, finden denn die Mails von extern überhaupt den Weg zu Euch, sprich sind die DNS-Einträge entsprechend gesetzt?

Moin, Du legst das gemeinsame PF an und vergibst Vollzugriff und Senden Als. Beim Einbinden in Outlook kannst Du dann aber keine Autokonfig nehmen, sondern muss das gemeinsame Postfach manuell einrichten. Mehr sollte nicht zu tun sein. Außerdem würde ich das AD-Konto des gemeinsamen Postfaches deaktivieren, damit man sich damit nicht anmelden kann.

Moin, wenn die Pfad existieren, stell die Datenbanken einfach bereit. Exchange legt dann automatisch die Dateien neu an. Wenn die Pfad anders sein sollen, hast Du zwei Möglichkeiten: - Du löschst die alten DB und legst neue an. Anschließend ordnest Du die ja noch existierenden Postfächer der neuen Datenbank zu (Set-Mailbox XXX - Database XXX). - Du stellst die neuen Pfade in die vorhandenen Datenbank ein (Set-Mailboxdatabase und Set-Publicfolderdatabase). Für die PF-DB wirst Du das vermutlich eh machen müssen, weil Exchange die nicht löschen will.

Warum läuft das alles auf dem Host, wenn Du virtualisierst? Bei meinen Virtualisierungen läuft auf dem Hypervisor genau nichts weiter. Kein Wunder, wenn Du Probleme mit den Ressourcen bekommst, wenn der Hyper-V und ein SQL-Server sich um die Ressourcen streiten müssen. Wenn alles virtualisiert ist, kannst Du die Ressourcen sauber zuordnen. Aber so läuft der gesamte Hyper-V langsamer, wenn der SQL gerade was tun will.

Moin, das wirst Du nur über eine zweite öffentliche IP-Adresse oder einen Revers Proxy sauber hinbekommen. Ich kenne Sophos hier nicht gut genug, aber je nach Version sollte die in der Lage sein, HTTP-Verzeichnis auf verschiedene Geräte zu bringen. Dann schiebst Du die Exchange-Verzeichnisse auf den Exchange durch, den Rest auf DA. Ich habe DA bei 2012 noch nicht in Betrieb gesehen (und bei 2008 wegen IPv6-Zwang auch sehr selten), es kann also sein, dass auch die nur eine Verzeichnis benutzen, und man dieses Umlenken kann. Der Betrieb von Exchange auf anderen Ports als 443 ist nicht supported und bei manchen Protokollen (EAS) beim Client oft auch gar nicht möglich.

Und eine Blick ins SMTP-Protokoll hilft vermutlich, die Ursache zu finden.

StartDagServerMaintenance lädt die Exchange-Module alleine, wenn sie nicht vorhanden sind. Ich stelle ergänzend zu den anderen die Frage: Warum willst Du eine so tiefgreifende Aktion ohne Kontrolle via Taskplaner machen? Das Script ist eigentlich nicht für automatischen Betrieb gedacht.

Moin, auch, wenn Du was anderes sagst: Ich denke, dass da nicht alle Dienste laufen. Was sagt "test-servicehealth" in der EMS?

Moin, da hat der Request vermutlich das falsche Format (DER anstelle von BASE64). Kannst Du mit certutil konvertieren: certutil -encode filenamebin.cer filename64.cer

Nein, Du musst bei jedem normalen Backup und dem daraus erfolgendt "Point-In-Time"-Recovery anschließend einen Hard Recovery durchführen. Machst Du das nicht, hast Du immer einen Datenverlust, bzw. nur den Datenbestand der Sicherung. Testen ist immer gut. Gerade die verschiedenen Wiederherstellungsszenarieren sollte man ausprobiert haben, solange noch kein Crash eingetreten ist. Im Fehlerfall hat mein meist weder Zeit noch Nerven für Experimente.

Hätte das Recoverykonzept geklappt, müsstest Du hier nicht fragen, oder. ;) Wenn die Transaktion-Protokoll noch da sein, führe ein Hard Recovery aus: http://www.msxfaq.de/notfall/dbrecover.htm Wie man das macht, gehört übrigens genau dokumentiert (am besten mit Screenshots) ins Konzept bzw. die Doku. Wenn Du das noch nie gemachst hast, lass Dir am besten von einem Fachmann helfen, denn es droht sonst richtiger Datenverlust!