RobertWi

Je nachdem, um welche Art von "Non Profit" es sich handelt, lohnt ein Blick hierauf: http://www.stifter-helfen.de/ Aber: - keine Kirchen, Parteien, bestimmte Bildungseinrichtungen - keine "zentrale IT" - begrenzte Anzahl (50 aus dem Desktop-Bereich, 5 aus dem Server-Bereich, innerhalb von 2 Jahren) Aber z. B. für Sportvereine mit einer kleinen Verwaltung dürfte das die günstigste Möglichkeit sein.

2013 SP 1 und 2010 SP 3 RU 5 kommen endlich auch mit DFL/FFL 2012 R2 offiziell klar. 2007 und 2003 nicht.

Das ist korrekt. Die darunterliegende "SQL"-Engine arbeitet Transaktionsbasiert mit Commit und Rollback. Fehlende Logdateien sollten daher zu fehlenden Daten, aber nicht defekten Datenbank fühlen. Das Problem bei Korrekturen an der EDB ist, dass man sehr viel Erfahrung und Kenntnisse über die Struktur braucht. Technet-Artikel können prinzipbedingt nur an der Oberfläche kratzen und sie gehen vor allem nicht auf alle möglichkeiten ein. ich kenne zum Beispiel Artikel, die eseutl /r und eseutil /p zeigen. Aber um zu verstehen, was dabei passiert, braucht man mehr Infos als im Technet. Und eine gute Erklärung, was die Ausgaben bei /mh oder /ml bedeuten, habe ich schon lange nicht mehr gesehen. Bitte versteh meine Aussage daher nicht als Angriff, sondern nur als Hinweis, dass man trotz aller Technet-Artikel bei so heiklen Dingen gut beraten ist, einen Fachmann hinzuziehen. Das deutet eventuell daraufhin, dass Kaspersky hier nicht nur Logs, sondern auch Teile der EDB beschädigt hat.

Ich kenne die Texte. Aber Papier ist geduldig. Wenn Du Dich mit einem Exchange Problem an den CSS wendest, un sich dieses Problem nicht als Bedienfehler herauskristallisiert, dann wird Dir der CSS etwas von "Best Effort" erklären und Dir erst dann weiterhelfen, wenn Du nachweislich das letzte RU installiert hast. Du musst MIR nichts über den Vorteil erzählen. Erzähl ihn den PGs, die das nicht so machen - und das ist leider die Mehrheit. Ich ärgere mich vor allem über die Zählweise. Und egal, wie gut das System von Exchange ist - innerhalb des Microsoft-Biotops ist es eine Ausnahme. Und alles, was von der Regel abweicht, irritiert und führt zu Fehlern. Office Click2Run spielt nach meiner Erfahrung im größeren Firmenumfeld gar keine Rolle und auch kleinere Firmen sind nicht begeistert, dass man Office C2R nicht via WSUS updaten kann.

Jein. Nach dieser Policy wäre RTM ja dann weiterhin supported und es müsste eine CU x für RTM und ein CU y für SP 1 geben. Das ist durch die CU-Technik aber gar nicht notwendig, denn mit CU 5 kann ich von jedem Stand, egal ob RTM oder SP 1 auf den aktuellen kommen. Folglich lautet die Policy, dass nur der letzte und der vorletzte Stand supported ist. Und außerdem ist ja bei Ex 2010 auch nicht der Stand "SP x" supported, sondern der Stand "SP x + RU y". Das, was mich an der Servicing Policy bei Exchange stört, ist das sie so vollkommen anders zu allen anderen Produkten ist. Normalerweise weiß ein Admin: Es gibt RTM, SP 1, SP 2, SP x und dazwischen entweder jede Menge Einzelupdate (BS) oder RU (SQL, TMG, und diverse andere). Und mit dem nächsten SP geht es wieder bei "0" los. Nur bei Exchange ist es anders. Nicht unbedingt schlechter, aber es passt eben nicht in die Erfahrung rein. Das mit den Versionangaben ist leider auch verschlechter worden. Konnte ich bei 2007 und 2010 aus der Versionsnummer wenigstens noch sofort den SP-Stand ablesen, muss ich bei 2013 nun in der Tabelle nachschauen, weil sich potentiell, wie bei CU2v2 passiert, nur die allerletzte Stelle der Build-Nummer ändert (dafür sehe ich das jetzt endlich in der GUI). Aber falls es interessiert: Wir haben das schon ausführlich intern diskutiert und die MVPs haben aus Ihrer Erfahrung genügend Bedenken geäußert. Die Entscheidung lag hier aber nicht unbedingt nur auf der technischen Ebene. Hier spielt auch das "Rolling Update"-Konzept von Office 365 eine Rolle, das solche Meilensteine für "Service Packs" gar nicht mehr kennt.

Böser Fehler... :( Unbedingt abstellen. Daran war sicher nicht der Reboot schuld, sondern fehlende Transaktionsprotokolle. Wildes Rumdoktoren ist meist kein guter Weg - besonders bei so einem kapitalen Ausfall. Wie geht das, wenn man die alte DB nicht gemoundet bekommt? Das Problem hierbei ist nicht die Mailbox-GUID, sondern "LegacyExchangeDN". Das merkt sich Outlook in den Vorschlägen und das hat sich durch Deine Import verändert. Dafür gibt es auch keine andere Lösung, als die von Dir beschriebene. PST-Import dürfen halt immer nur die allerletzte Lösung sein, davor muss man alles tun, eine saubere Rettung zu erreichen.

Jo. Klingt schon irgendwie lustig: RTM CU1 CU2 CU3 SP 1 CU5 CU6 CU7 SP2 CU9 BTW: Aus den Details des Download "This update rollup is highly recommended for all Exchange Server 2013 customers."

Genau. Ist für mich reines Marketing. Das einzige, was das SP von den vorherigen CU wirklich unterscheidet, ist die Fülle an neuen Funktionen: Edge, MAPI/HTTP, Command Logging, usw.

Sicher. Das nächste Update "RTM CU5" zu nennen, wird aber alle Verwirren, die SP 1 einsetzen. Der größte Vorteil hierbei ist, dass man für dem CU5 halt kein SP1 vorher mehr installieren muss. Ich fürchte aber, dass die Verwirrung durch die Umbenennung größer sein wird.

Was ist denn eigentlich ein neuer "Domänen Name"? "Domänen Name" ist innerhalb von Exchange nicht eindeutig. Neuer Forest -> geht nicht gleicher Forest, anderer AD-Name -> geht gleicher Forest, andere Mail-Domain -> geht Zumindest für die Mailbox-DB, bei der Public Folder DB geht keiner der Schritte.

Ist nur schade, dass der Transport-Dienst-Bug wieder da zu sein scheint. Zwar schreibt Microsoft in den Release Notes, dass man nach dem Update den Server neustarten soll, aber einen ähnlichen Bug gar es schon mal im RTM. Hoffentlich läuft der Dienst dann im Betrieb stabil und man braucht nicht wie früher ein Script, dass den prophylaktisch mal alle Stunde neustartet. Und das nächste Verständnischaos steht dann an, wenn das folgende Update den Namen "CU 5" trägt. Ich hoffe nur, das diese "Strategie" dann auch nicht nur zu vielen Fragen im Forum sondern auch zu entsprechenden Anfragen beim Support führt.

Und da ist das SP 1 für Exchange 2013: http://blogs.technet.com/b/exchange/archive/2014/02/25/exchange-server-2013-service-pack-1-available.aspx WICHTIG: Nach der Installation unbedingt den Server neustarten. Sonst kann es sein, dass der Transport-Dienst zwar läuft, aber nicht reagiert. Steht daher auch in den Release Notes drin. Und bevor MAPI/HTTP eingesetzt wird, unbedingt den Technet-Artikel lesen!

Moin, Das sieht komisch aus. Soll das erste "Search-Mailbox" eventuell eine "Get-Mailbox" sein? Außerdem könnte es sein, dass die Variable am Ende Probleme macht und "scheinbar" nicht aufgelöst wird. Dann nicht wundern, das kommt manchmal (aber nicht immer) in der EMS vor. Wenn Du das 100% genau haben willst, wirst Du das mit einem Einzeiler nicht hinbekommen. Du könntest - Search-Mailbox mit dem Schalter "EstimateResultOnly" verwenden -> Schätzung - vorher und nachher Get-MailboxStatistics ausführen -> ungenau, weil auch andere Änderungen möglich sind - die betreffenden Mails wie EWS suchen -> ungenau, weil auch andere Änderungen möglich sind - alles mit "TargetMailbox" in eine Zielmailbox kopieren und in dieser dann die Elemente zählen - mit "-LogOnly" nichts tun, nur Zählen lassen Alles mehr oder weniger ungenau.

Dachte ich bis zu diesem Satz hier auch: "Daraufhin habe ich die Warteschlange angehalten und siehe da, die Mail an die unbekannten Absender tauschen auf. Jedoch weiß ich nicht wo die "Lücke" zu suchen ist!" Aber wenn die Mails, die an die unbekannten Absender rausgeschickt werden sollen, in der Warteschlange stehen, müssen sie ja irgendwo herkommen. Bei Backscatter gäbe es nur den NDR auf diese Mails.

Moin, ein gehackter Exchange wäre eigentlich eher unwahrscheinlich. - erlaube auf der Firewall Port 25 ausgehend ausschließlich von Exchange - teste mit Telnet auf ein offenes Relay: http://support.microsoft.com/kb/324958/de (nur der erste Abschnitt, der Rest ist Ex 2003) - kontrolliere die SMTP-Logs, ob die Mails über welchen Connector/Client die Mails eingeliefert werden - kontrolliere die Einstellungen der Empfangs-Connectoren, wo Du anonymes Relay zugelassen hast (http://technet.microsoft.com/de-de/library/bb232021(v=exchg.141).aspx) -> sollte es nicht geben

Ja, aber es würde da auch stehen, mit welchem MAIL FROM er das getan hat. Mein Verdacht war, dass hier die BATV Signatur verloren geht. Beim Nachlesen habe ich aber bemerkt, dass das bei OOF egal ist. Diese gehen als MDN nicht an den MAIL FROM zurück, da dieser an der Stelle des Erzeugens gar nicht mehr bekannt sein muss.

Ja, kann ich nachvollziehen. Ich habe das bisher auch sehr selten irgendwo im Einsatz gesehen, daher muss ich mich immer wieder erst in die Besonderheiten von DSN und MDN einlesen.

Nein, da in Deiner Aufzeichnung eine Lücke ist: G DATA -> Exchange. Ein Auszug aus dem SMTP-Protokoll des Exchange wäre noch interessant. Aber grundsätzlich kannst dem Empfänger an diesem Beispiel nur die Probleme von BATV aufzeigen, die dadurch entstehen, dass es sich bei BATV nicht um einen Standard handelt ("Entwurfs-Stadium") und daher nicht damit gerechnet werden, dass die gegenüberliegenden Seite sich wirklich daran hält. Er wird aber vermutlich nicht an seiner Meinung ändern, dass das Problem bei Exchange ist. Nachtrag: Eigentlich braucht es das Exchange SMTP-Protokoll nicht mehr, weil die wichtigen Infos hier eh nicht drin stehen. Die würden im Header der Mail stehen, auf den die OOF erfolgt (den könntest Du nochmal posten) Nach dem ich mich durch ein paar RFC gelesen habe, ist ziemlich klar: BATV funktioniert für normale DSN laut RFC 3461 prinzipbedingt, weil diese als Envelop-To den String aus MAIL FROM einsetzen müssen, dieser an der Stelle bekannt ist und damit die BATV-Signatur tragen. BATV funktioniert prinzipbedingt nicht für MDN laut RFC 3798, weil diese als Envelop-To keinen alten MAIL FROM mehr kennen und ihn daher auch nicht einsetzen können. MDN können immer nur an Disposition-Notification-To Header gehen oder an "From", falls der nicht gesetzt ist. Wer BATV nutzt, wird also grundsätzlich keine Standard-konformen OOF erhalten und er wird auch keine anderen MDN bekommen, z.B. Lesebestätigungen. Ich wüsste nicht, was Du daran sinnvoll ändern kannst, das ist eine der Schwachstellen von BATV. Schick das dem anderen Admin, eventuell ändert er was. Ich denke das aber eher nicht.

Moin, da kann ich Norbert nur zustimmen. Auch empfiehlt Microsoft mittlerweile nicht mehr dedizierte Rollen, sondern Multi-Role-Server mit LB davor. Schau Dir das Rollen-Konzept von Exchange an: Bis auf die Öffentlichen Ordner ist der Endpunkt immer die CAS-Rolle. Wenn Deine neuen Server also MBX sind und die Du Postfächer verschiebst, kannst Du anschließend auf dem alten Server die MBX-Rolle deinstallieren, ohne das jemand was merken sollte.

Moin, nein, es gibt keine Möglichkeit, das Verhalten zu ändern. Warum auch, es ist so RFC-Konform.

Mal davon abgesehen, dass die Lösung von testperson besser ist: Du musst eine INTERNE Relaydomäne konfigurieren. Die Beschriftung ist hier eine wenig irreführend, weil das nicht das Ziel meint, sondern wer das Relay durchführt. Intern = Hubtransport; Extern = Edge Transport.

Gleich in der ersten Antwort habe ich Dir die gewünschte Infos mit ihren Nachteilen auf der Seite von Frank verlinkt.

Oder notfalls mit einem Kontakt und mit diesem weiterleiten. Aber nur für eine Adresse Backscatter und sonstiges Stress riskieren, finde ich auch ein wenig übertrieben.

Und nur um ganz sicher zu gehen (Du weißt schon, Pferde, Apotheke und so): Der Server hat wirklich die Version "15.00.0775.038" ? Irgendwas am RBAC verändert? Sieht das bei allen Mailboxen so aus?

Zusätzlich zum Whitespace darf man bei der Größenermittlung zwei Dinge nicht vergessen: - Datenbank-Header und Verwaltungsinformationen werden nicht in den Postfachgrößen eingerechnet. Die Postfächer sind physisch zwischen 10% und 20% größer, als die EMS das anzeigt - die Berechnung im Eingangs-Event geht auf die physische Größe von EDB und STM, EDB und STM beeinhalten Daten aber doppelt in unterschiedlichen Formaten Es ist also vollkommen normal, dass die Summe der Postfachgrößen aus dem EMS und die physische Größe der Dateien deutlich differieren.