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.

Ok, ich werde nun "mutiger" mit der Thematik weil das gefährliche Halbwissen langsam weicht ;-)

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.

Wenn ich jetzt die Umlaufprotokollierung aktiviere, sagt mir das System, dass das erst aktiv wird, wenn ich die Datenbank erneut eingebunden habe. Ich solle die Einbindung der Datenbank aufheben und neu einbinden.

OK, dann nicht der Dienst, nur die Einbindung. Kommt ja aber am Ende auf das gleiche raus, die Benutzer werden getrennt.

Ok, grundsätzlich ja kein Problem, nur aktuell wird noch damit gearbeitet und ich würde den Kunden nur ungerne stören. Ich warte damit noch etwas und mache dann weiter....

Gut, dann warte ich gespannt. :)

@Dukel

Der Exchange soll nciht von außen erreichbar gemacht sein, außerdem bin ich bei unserer momentanen Internetanbindung über jeden Traffik froh, der nicht über unsere Leitung läuft.

Und dann richtest Du POP3-Connectoren ein? Damit erzeugst Du ständig unnnötigen Traffic auf der Leitung.

@h-d.

Zu der Problematik mit der Internetleitung schwört mein Chef auf den Spamfilter des Providers (Hier gab es noch nie Probleme, warum sollten wir das Risiko eingehen und den Spamfilter ablösen...).

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.

ich bin jetzt grade sehr vorsichtig...

Das ist meistens besser, als einfach unbedarft drauflos löschen.

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

 

... bin grade remote auf dem besagten System drauf und sehe den Punkt - kann ich den jetzt, im laufenden Betrieb und ohne eine "Sicherung" zu haben, diesen Haken einfach setzen?

Ja, kannst Du. Aus dem Kopf weiß ich allerdings nicht, ob die Änderung sofort wirksam wird oder nur nach einem Neustart des Informationsspeicher-Dienstes.

Habe ich das so verstanden, dass er dann selbständig, nur durch das Setzen des Hakens, die nicht mehr benötigten LOG Dateien entfernen würde?

Korrekt.

Und die Hoffnung ist, dass die "Defekte" dabei ist?

Korrekt. Die defekte ist die Nummer 4, steht im Backup-Fehler.

Also ich aktiviere die Umlaufprotokollierung, lasse ihn "rödeln" und versuche mich heute Abend dann erst einmal einfach an der Windows Sicherung. Schlägt die fehl, mache ich mit dem ursprünglichem Plan weiter...

So wäre der Plan.

EDIT - auch die Umlaufprotokollierung läuft dann nur zu den angegebenen Zeiten, ja?

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.

Und noch ein EDIT:

 

http://www.frankysweb.de/exchange-2010-partitionfestplatte-der-datenbank-vollgelaufen-was-tun/

 

Hier (und auf diversen anderen Seiten) steht, dass man die Umlaufprotokollierung eigentlich besser (grundsätzlich) nicht aktivieren sollte.

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.

Aber wenn man, wie wir hier vorhaben, die ganzen LOG Dateien rauslöschen will, dann "soll" man diese wohl (temporär?!) aktivieren, damit Exchange die LOGs nicht "vermisst"...?! Kannst du dazu etwas sagen?

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)

Ok, war wohl mal wieder mein gefährliches Halbwissen am Start. Dachte bisher halt immer, dass, so lange die LOG Dateien noch "da" sind, diese Informationen nicht in der Datenbank stehen.

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.

Als "Beweis" dann das Verschwinden besagter Dateien bei einer Sicherung ;-)

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.

 Nur um noch einmal sicher zu gehen:

 

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

 

Ich habe dort im Ordner die die besagten Dateien. Darüber hinaus habe ich aber auch .JRS Dateien (E00res0000A.jrs und aufsteigend). Auch weg? Und ich habe neben meiner "Mailbox.edb" auch noch eine "tmp.edb" (2 Mbyte) - die bleibt auch erhalten, ja?

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

Ich werde dann versuchen, dass heute Abend umzusetzen. Natürlich gebe ich dann hier Feedback.

Wir sind gespannt.

Genauer gesagt, die Transaktionen werden dauernd in die Datenbank geschrieben (nicht nur beim Shutdown oder Backup).

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.

Bei einem Shutdown werden nur alle fehlenden Transaktionen in die Datenbank geschrieben.

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.

Und bei einem Log oder Full Backup werden eben diese Protokolle gelöscht (da alle in der Datenbank eingearbeitet sind).

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.

Nun ist die Frage ja ganz easy, was kann ich machen, ohne direkt die gesamte Domäne neu aufzusetzen, da das doch ein wenig überzogen wäre? :schreck:

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,

http://www.mcseboard.de/topic/197397-integrierte-windows-server-2012-sicherung-läuft-nicht/
 
Wie sich wohl herausstellte, habe ich speziell ein Exchange Problem, genauer scheint meine Datenbank wohl inkonsistent zu sein, weswegen die Sicherung nicht läuft. Ist ein Server 2012 Standard mit Exchange 2013 SP1 - alles soweit auf dem neuesten Stand.

Wenn ich das richtig sehe, ist nicht die Datenbank inkonsistent, sondern nur ein Log-File.

Da ich über die integrierte Windows Server Sicherung keine Sicherung hinbekomme (siehe ursprüngliches Thema), ist die erste Frage natürlich, wie ich dann manuell meinen Exchange Server sichern kann. Einfach auf Dateiebene alles in "Mailbox" kopieren? Reicht das?

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.

ps. liegt das an meinem Browser (IExplorer 11 => mcseboard.de als "vertrauenswürdige Seite" eingefügt), dass ich hier nichts "einfügen" (STRG + V) kann?! Auch die drei "einfüge" Buttons in der Maske oben scheinen keine Funktion zu haben, es passiert nichts. Nur wenn ich in den "BBCode Modus" wechsel, bekomme ich hier etwas eingefügt. Das aber nur am Rande - weil es das Schreiben hier deutlich erschwert.

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.

 

Hat sich erledigt ...

Mir ging es nicht um die alten Emails, nur um den Besitz zu verifizieren und da wollte er ja schon einen MX Eintrag zu anlegen ...

Merkwürdig. Bei mir (gestern) bot mir Microsoft auch einen TXT-Eintrag in der Form "MS=msxxxxxxx" an.

Aber es hat auch mit einer niedrigeren Prio als der Provider funktioniert. Danke

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

Bei mir ist es genau anders herum. Der primäre MX ist beim Provider und der sekundäre soll auf meinen eigenen Server zeigen. Ich dachte bisher immer, dass die Mails grundsätzlich den ersten MX nehmen und nur wenn dieser nicht annimmt, den zweiten versuchen.

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

@Robert

 

mir sind eigentlich nur zwei Fehler bewusst gewesen, danke

Der Support-Artikel beschreibt andere Fehler, als die, die Du darunter zitierst. Aber wenn die nicht auch noch sind, ist das ok.

Ich habe im Eventlog leider keine Einträge zu den Sync Fehlern gefunden, welchen Eintrag muss ich in der Diagnoseprotokollierung anpassen damit mehr Fehler angezeigt werden?

Keinen. Wenn Du Store Limits oder Throtteling eingreifen, wird das von alleine protokolliert.

Aktuell habe ich diese Fehler hier bei allen Usern, an die Zertifikate hatte ich natürlich nicht gedacht -.- > http://www.directupload.net/file/d/3579/naytejfm_png.htm

Das ist für Dein Problem erstmal unerheblich.

Der betreffende User, bei dem es mir aufgefallen ist, hat ein 12 GB Postfach mit 8 eingebunden Verteilern.

Die Limits schau ich mir mal an danke

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.

1. Da gibt es entsprechende Limits im Exchange Server, die es bei Exchange 2003 noch nicht gab. Kann man entsprechend anpassen. Gefährlich sind vor allem große Ordnerstrukturen und mehere eingebunde Postfächer.

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.

2. Aktuelles Service Pack und Rollup für den Server und aktuelles Service Pack auf Outlook installieren. Das war ein bekanntes Problem, wurde aber vor längerem behoben. Ich weiß nicht mehr weilche Version, da schon verdammt lang her.

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.