RobertWi

Gibt meist mehr Lösungen. Aber nur mit den schwierigen Aufgaben wächst man. :) Wenn das mit den Logs funktioniert, ist das ein guter Lerneffekt, wenn mal wirklich Stress ist. Und wenn nicht, kann man immer noch umziehen.

Wenn man einmal hinter die Technik gestiegen ist (ich habe das da oben mit dem Log-Dateien löschen bestimmt schon 50 Mal bei Kunden und in Kursen live gezeigt), dann merkt man, dass die Entwickler auch nur mit Wasser kochen und Exchange zwar komplex, aber dennoch keine Raketentechnik ist. Trotzdem schadet eine gewisse Vorsicht nie. OK, dann nicht der Dienst, nur die Einbindung. Kommt ja aber am Ende auf das gleiche raus, die Benutzer werden getrennt. Gut, dann warte ich gespannt. :)

Und dann richtest Du POP3-Connectoren ein? Damit erzeugst Du ständig unnnötigen Traffic auf der Leitung. Dann mach wenigstens Weiterleitungen vom Provider zu Deinem Exchange. Das ist immer noch gebastelt und fehlerträchtig, erzeugt aber weniger Traffic und keinen Protokollbruch. Und zur urspünglichen Frage, siehe hier.

Das ist meistens besser, als einfach unbedarft drauflos löschen. Ja, kannst Du. Aus dem Kopf weiß ich allerdings nicht, ob die Änderung sofort wirksam wird oder nur nach einem Neustart des Informationsspeicher-Dienstes. Korrekt. Korrekt. Die defekte ist die Nummer 4, steht im Backup-Fehler. So wäre der Plan. Nein, sie läuft immer. Sobald eine Log-Datei nicht mehr benötigt wird, wir sie gelöscht. Nur beim ersten Mal kann ein Neustart des Dienstes erforderlich sein. Die Antwort lautet: Das kommt darauf an. Der Nachteil (der einzige!) der Umlaufprotkolllierung ist, dass man im Crash-Fall nur auf den Zeitpunkt der Sicherung kommt und alles danach ist verloren. Also gibt es zwei Gründe, die Umlaufprotokollierung zu nutzen (früher bei Ex 5.5. gab es noch einen dritten, kleine Festplatten): 1. man macht gar keine Backups. Ohne Backups werden die Log-Dateien nicht abgeschnitten und damit würde irgendwann die Platte volllaufen. 2. man hat irgendein Problem mit dem Backup oder den Log-Dateien und will/muss die loswerden. Korrekt. Schreibt ja auch Frank: "Zu empfehlen ist allerdings der Weg über die Sicherung, die Logfiles löscht man nur im äußersten Notfall. " Aber genau diesen Notfall haben wir ja hier. ;) Natürlich bin ich davon ausgegangen, dass Du nach der erfolgreichen Sicherung die Umlaufprotokollierung wieder deaktivierst. Ablauf: - Umlaufprotokollierung einschalten - Sichern (zum Test, muss erfolgreich sein) - Umlaufprotokollierung aschalten - noch mal sichern (weil dass die Basis für die nachfolgenden inkrementellen ist)

Eventuell verwechselst Du auch nur was: Das, was Du schreibst wäre bei der sog. "Umlaufprotokollierung" der Fall. Sobald die aktiv ist, werden alle Log-Dateien gelöscht, die nicht mehr benötigt werden. Die zu aktivieren könntest Du in Deinem Fall übrigens auch ausprobieren. Und wäre als erster Versuch mit weniger Risiko verbunden, als Dateien zu löschen. Das ist nur doppelte Sicherheit. Mit den Log-Dateien auf der Platte (auch den bereits erledigten) könntest Du mit der letzten Sicherung den aktuellen Stand wieder herstellen. In der Sicherung ist die EDB + unerledigte Logs, mit den noch vorhandenen kommt dann der aktuelle Stand. Das nennt sich "Rollforward" Recovery oder auch "Hard Recovery" bei eseutil. Bei der Umlaufprotokollierung dagegen hast Du im Crash nur noch die Sicherung. Veränderungen sind gelöscht. Die JRS-Dateien (Platzreservierer falls "Platte voll") und tmp.edb kannst Du auch löschen. Die tmp.edb könnte sogar beim Dienstanhalten automatischer verschwinden. Theoretisch ist am Ende wirklich nur noch die Datenbank.edb übrig (und der Ordner, weil das nicht die Datenbank sondern der FAST-Volltextindex ist). Wir sind gespannt.

Vereinfacht ausgedrückt, stimmt das. Genauer betrachtet ist es eigentlich komplett falsch. In einem anderen Forum erlebt jemand gerade, dass bei einem "unbenutzten" Server wochenlang Log-Dateien nicht in der EBD gelandet sind, sondern noch im RAM sind. Korrekt. Und wenn alles geklappt hat, ist die EDB danach "Clean Shutdown" und genau dann werden die Log-Dateien nicht mehr benötigt und können gelöscht werden. Und damit wird dann auch die defekte Log-Datei obsolet und kann weg und muss nicht mehr gesichert werden. Jein. In der Praxis werden nur die Log-Dateien gelöscht, die auf der Platte in der EDB sind. Genau das ist das Problem in den anderen Forum: Es werden GAR KEINE Log-Dateien entfernt, weil noch gar keine in der EDB-Datei sind. Das ist auch nur über die Sicherung aufgefallen, weil keine Logs abgeschnitten wurden. In der Praxis sind niemals alle Log-Dateien enthalten und die, die noch fehlen, werden mitgesichert. Die EDB-Datei ist in einem Backup daher immer "Dirty Shutdown" (= es fehlen noch Logs). In diesem Fall sind alle Logs enthalten und damit würden alle abgeschnitten. Da aber mindestens eine davon fehlerhaft ist, löscht man die einfach vorher. Da Exchange dann bei "0" mit dem Logs beginnt, meckert das Backup auch nicht. Das einzige, was man beachten muss: Man muss nun unbedingt ein Fullbackup machen, weil ein inkrementelles aus Prinzip nicht mehr funktionieren kann.

Also erstes solltest Du damit beginnen, Dir Grundlagenwissen über die Funktion von Exchange anzueignen. Man kann nicht alles wissen, aber Exchange ist ein komplexes Produkt mit tiefer Integration in AD. Das fährst man schneller gegen die Wand, als einem lieb ist. Zum Beispiel löscht man niemals Objekte in AD, wenn diese noch eine Entsprechung in Exchange haben, ohne vorher genau zu wissen, was und warum man das tut. Die Auswirkungen siehst Du da noch ja. Also musst Du zuerst den inkonsistenten Zustand behaben: EMS öffnen: Get-Mailboxdatabase | fl name Die Namen notieren, kopieren, merken, etc. Set-Mailbox Administrator -Database NAME_VON_OBEN Danach 30 Sekunden AD-Replikation abwarten. Danach solltest Du das Admin-Postfach ganz normal im EAC sehen (eventuell Ansicht aktualisieren) und kannst es nun löschen/verschieben/etc.

Moin, welche Exchange- und Outlook-Version? Was verstehst Du unter "verlinken"?

Moin, Wenn ich das richtig sehe, ist nicht die Datenbank inkonsistent, sondern nur ein Log-File. Das funktioniert zwar (wenn man weiß, was man macht), ist aber keine Sicherung. Sinnvoller wäre es, das Problem zu löse. - Hebe die Bereitstellung der Datenbank auf (alle Benutzer werden getrennt!!!) - Stoppe den Dienst "Microsoft Exchange Information Store" - Wechsel in den Pfad "c:\Program Files\Microsoft\Exchange Server\V15\Mailbox\Mailbox Database 2137044815\" Prüfe den "State" der EDB-Date mit "eseutil /mh". Der State muss auf "Clean Shutdown" stehen. Wenn ja: Lösche alle Datei in dem o.g. Ordner, bis auf den Unterordner mit der GUID und die EDB-Datei, als besonders die E00.log, E00xxxxxxxx.log und E00.chk. Starte den Dienst wieder. Wenn alles ok ist, sollten die gelöschten Dateien mit Zähler "0" wieder neu angelegt worden sein und die Datenbank ist bereitgestellt. Wenn das der Fall ist, probiere eine erneute Vollsicherung aus. Die sollte nun fehlerfrei sein. WICHTIG: Alle Arbeiten auf eigene Gewähr! Falschbedienung kann zum Datenverlust führen! Wenn Du Dir nicht sicher bist, hol Dir jemanden ins Haus, der Dir hilft. Vor dem löschen schadet es nicht, einfach mal den Inhalt des Ordner zu kopieren. Ach ja: Und wenn das Backup läuft, wäre das ein guter Zeitpunkt, die Datenbank von der C-Platte auf eine andere Platte/Partition zu bewegen. Das ist ein bekanntes Problem im MSIE 11. Nimm einen anderen Browser, dann geht auch einfügen.

Danke für die Info. Ist schon interessant, denn das Update soll ja eigentlich genau einen solchen Fehler beheben.

Moin, der Ansatz ist richtig. Einen SRV-Eintrag kann man machen, muss aber nicht. Da der Benutzer ja mit der externen Adresse korrekt gefunden werden soll, benötigst Du innen Split DNS, d.h. Du legst die externen DNS-Einträge innen noch mal an, nur mit interner IP-Adresse. Split DNS ist eh die empfohlene Vorgehensweise und macht viele Dinge deutlich einfacher. Außerdem darf es keinen Zertifikatsfehler geben, den musst Du also noch beheben.

Moin, natürlich ist das möglich. Ich sitze hier gerade an einem Nicht-Domänen-Mitglied, der sich mit dem Exchange am gleiche Switch verbindet. Nennt sich "Outlook Anywhere" und muss korrekt für externen Zugriff konfiguriert sein und möglichst mit funktionierendem Autodiscover, inkl. korrekten DNS-Einträgen.

Und nur, falls es Stress gibt, kannst Du Mittwald gerne darauf hinweisen, dass das, was Exchange da macht, RFC-konform ist: http://robertwilleswelt.wordpress.com/2008/09/11/ex-2007-abwesenheitsnachrichten-haben-keinen-absender/

Moin, wenn Du, wie eingangs beschrieben, keine externe Domäne eingerichtet hast, funktioniert Dein Outlook Anywhere außerhalb der Domäne nicht. Die Formulierung "externe Domäne" ist ein wenig irreführend, weil da mit nicht "extern" im Sinne von "draußen", sondern im Sinne von "nicht im AD" gemeint ist. Intern und Extern meint also, Domänen-Clients und Nicht-Domänen-Clients. Wo die stehen, ist egal.

Merkwürdig. Bei mir (gestern) bot mir Microsoft auch einen TXT-Eintrag in der Form "MS=msxxxxxxx" an. Darauf würde ich mich allerdings nicht verlassen, es reicht schon ein kleiner "Schluckauf" und der Absender nimmt den anderen Server.

Moin, vorab: Bei Office 365 kauft man den Support mit -> Du solltest ihn auch nutzen. Und außerdem gibt es zu quasi jeder Funktion im Portal auch den passenden Hilfelink gleich daneben. ;) Das mit der Bestätigung der Domäne hat im ersten Schritt keine Außenwirkung, Du bestätigst nur den Besitz. Hierzu bekommst Du von Assistenten einen speziellen DNS-Eintrag. Den trägst Du im DNS ein und wenn Microsoft den findet, wird die Domäne in Office 365 aktiviert. Erst, wenn Du die Benutzer eingerichtet hast und alles fertig konfiguriert ist, stellst Du im DNS die MX-Server von Microsoft ein. Bis dahin landen alle Mails bei Deinem Kunden und ab dann im Online-Postfach. Wie Du danach die Bestandsdaten rüberbekommst, ist freilich eine andere Geschichte, aber neues Mails sollten nicht verloren gehen. Klick mich für die lange Hilfe von MSFT

Das ist die Theorie. In der Praxis wird das aber nicht überprüft. Das sich gute Mailserver daran halten, wissen die schlechten und Spammer benutzen daher bevorzugt die Einlieferung beim MX mit niedrigerer Prio. Und auch WANN der Fallback auf einen anderen MX erfolgt, ist nicht klar geregelt. Aber wie die anderen denke ich, dass Du das Problem einfach falsch angehst. Anstell die Ursache zu beseitigen (= unzuverlässiger Provider), schraubst Du mit einer Bastellösung an der Wirkung rum.

Moin, na, wenn Du schon weißt, dass das hier mehrfach durchgekaut wurde, weißt Du auch, was die allgemeine Antwort auf die Frage ist: Das kommt darauf an. ;) Schau Dir die Vor- und Nachteile der beiden Lösungen an und entscheide, war Dir besser gefällt. Wenn ich Deinen letzten Satz nehme, würde ich spontan sagen, dass ein freigegebenes Postfach besser geeignet ist, weil man in einem ÖO nicht sehen kann, ob eine Mail schon von jemand anders gelesen wurde und für die Zuordnung der gesendeten Mail ein Dritt-Anbieter-Tools oder Handarbeit angesagt ist.

Moin, und hier noch schön aufbereitet von Frank, warum ein Backup MX in kleinen Firmen mehr schadet, als nutzt: http://www.msxfaq.de/internet/backupmx.htm

Wie gesagt: Dieser Fehler ist "by Design" und wird im Augenblick nicht korrigiert. Entweder ignorierst Du die Meldung oder schaltest sie ab, wobei Du dann auch andere, eventuell wichtige Meldungen deaktivierst.

Hast Du meine Links gelesen? Offiziell gibt es keine Möglichkeit, außer dieser: http://blogs.technet.com/b/exchange/archive/2013/08/13/customizing-managed-availability.aspx Inoffiziell gibt es noch diese: http://ficility.net/2013/07/08/how-to-disable-managed-availability-in-exchange-2013

Der Support-Artikel beschreibt andere Fehler, als die, die Du darunter zitierst. Aber wenn die nicht auch noch sind, ist das ok. Keinen. Wenn Du Store Limits oder Throtteling eingreifen, wird das von alleine protokolliert. Das ist für Dein Problem erstmal unerheblich. Ohne Fehlermeldung weißt Du aber gar nicht, welche Limits eingreifen. Und ohne das Limit zu kennen, weißt Du auch nicht, was Du erhöhen musst.

Moin, 40 GB sind für C: zu wenig, wenn darauf Exchange installiert ist. Exchange braucht mindestens 30 GB für sich alleine und das steht auch nicht umsonst so in den System Requirements! Den Grund hast Du gefunden -> es wird sehr viel protokolliert. Siehe auch hier: http://blogs.technet.com/b/rischwen/archive/2013/02/21/exchange-2013-logging-and-space-requirements.aspx http://windowsitpro.com/blog/exchange-2013-diagnostic-and-performance-log-files Wenn Du aufräumen willst, hilft das hier, empfohlen ist es aber nicht und eventuell im Problemfall sogar unsupportet: http://social.technet.microsoft.com/Forums/exchange/en-US/5b9dd872-5803-4dae-83d1-584424b7bd94/exchange-2013-system-logs-disk-getting-full?forum=exchangesvradmin

Moin, ohne genaue Fehlerbeschreibung ist das alles nur Kaffeesatzleserei, zumal es gerade in einem solchen Fall wichtig ist, die echten Domänen und echten Server zu kennen. Das die in einem Forum nicht übermittelt werden, ist ok, macht aber die Suche nicht einfacher. Auch solltest Du mal einen Blick in die SMTP-Protokollierung und das Messagetracking werfen. Ich hatte z. B. mal einen Kunden, da wäre ich ohne echte DNS Namen nie darauf gekommen, dass zwei A-Einträge vorhanden waren (sog. Round Robin), der zweite Eintrag auf einen vollkommen falschen Server zeigte. Ergebnis: Ungefähr die hälfte der Mails (natürlich nur sehr schwer nachzuvollziehen, weil das ja externe Absender sind) ging unzustellbar zurück. Halt immer die, die den falschen DNS-Eintrag bekamen.

Bei der Fehlermeldung oben tippe ich eher auf die Store-Limits, als Throtteling. Aber im Endeffekt wissen wir das erst verbindlich, wenn wir die Fehlermeldung sehen. Update sind immer wichtig, aber gerade bei den Synchronisationmeldungen gibt es einige, die bei 2010 nicht behoben werden. Am Ende bleibt fast immer nur ignorieren übrig.