RobertWi

Moin, wie gesagt, dass ist das Problem: Es muss alles manuell gepflegt werden. Den SPF kannst Du auch nehmen. Auch keine 100% Sicherheit, allerdings hat Microsoft hier zumindest den eigenen Antrieb, ihn korrekt zu halten. Aber bei anderen hilft Dir das auch nicht, wenn keine gesetzt ist - t-online.de zum Beispiel.

Wenn ich mit Ontrack PowerControlls "wiederherstelle", kann ich die Sicherung problemlos auch mit Diskshadow und Xcopy in einem Script machen. Aber das führt halt wieder zu der Eingangsfrage: Wie sieht der Wiederherstellungsbedarf aus? Die muss Dirk bzw. der Kunde beantworten.

Moin, ja, dass ist die größte Schwachstelle am Greylisting. Entweder Verzögerungen/Fehler oder ständige Pflege der Whitelists, da sich IP-Adresse ja auch mal ändern. Eventuell bietet Eset automatische Filterupdates für seinen Greylisting Filter an. Die Outlook.com-Adresse stehen hier: https://mail.live.com/mail/ipspace.aspx

Moin, wie immer lautet die wichtigste Frage: Wie schnell und wie viel soll wiederhergestellt werden? Erst, wenn die Wiederherstellungsanforderungen definiert sind, kann man die Backup-Anforderungen festlegen (und fängt neu an, weil der Kunde das nicht bezahlen will). Nicht vergessen: Der Kunde will kein Backup-Konzept - der Kunde will eigentlich ein Wiederherstellungskonzept.

Ich auch. Ich habe auch 300 Anwender mit 20 Exchange Servern erlebt und 450 Mitarbeiter, mit einer IT die fast 80 Leute zählte. Aber über so einen Kunden würden wie hier gar nicht reden. Die wissen, dass IT wichtig ist und eine gewisse Menge Geld kosten wird. Wir reden hier über einen Kunden, der offensichtlich kein Geld ausgeben will oder kann. Daher gilt erstmal der Satz von Norbert: Eventuell definiert der Kunde erstmal seine Anforderungen und das zur Verfügung stehende Budget.

@monstermania: Hast Du Dir mal das Eingangsszenario mal angeschaut? Wir reden über 8 Arbeitsplätze mit einem SBS! Ich persönlich finde da sogar schon eine Sophos UTM oversized (zumal die Erfahrung sagt, dass Mailfilterung eh nicht gut damit geht und viele Probleme macht). Und wenn ein Kunden in eine solchen Umgebung als größte Sorge hat, dass die Firewall ausfällen könnte, läuft im Verständnis irgendwas verkehrt.

OK. Die Aufbewahrungsrichtlinien können nur auf Postfächer zugewiesen werden. Eine "Master" mit Vererbung oder so gibt es dabei nicht. Du könntest den Scripting - CMDLET Extension Agent benutzen, der sich in "New-Mailbox" einklingt und dann die Retentionpolicy entsprechen setzt: http://technet.microsoft.com/de-DE/library/dd297951(v=exchg.141).aspx Hier ein Beispiel: http://theucguy.net/automating-tasks-with-scripting-agent/ Vorteil von dem ist, dass er immer wirkt, egal ob EMS oder EMC benutzt werden.

Solche Kunden kenne ich sehr gut. Und es ist auch schon vorgekommen, dass ich bei extrem beratungsresistenten Kunden wieder gegangen bin. Das sehe ich auch als ein wenig Selbstschutz, denn wenn der Kunde mich holt und nicht auf mich hören will, sucht er vermutlich nur einen Buhmann, dem er das Versagen nachher in die Schuhe schieben kann. Und über die kalkulatorischen Probleme rege ich mich auch immer auf, schon weil ich gelernter Kaufmann bin. Da wird das Klopapier und der Verbrauch an Wasser pro Mitarbeiter kalkuliert, aber 300 pro Jahr um alle vier Jahre einen neuen Arbeitsplatz (der meistens extrem Effektivitätsschübe bringt) einzuplanen, bringen sogar große Firmen nicht auf die Reihe. Ein wenig kann helfen, wenn Du klar machst, dass HA ähnlich wie IT-Sicherheit nur so gut ist, wie das schwächste Glied in der Kette ist. Es gibt nicht den einen Punkt, den man anfasst und dann ist alles verfügbar oder sicher. Es gibt aber Punkt, bei denen man mehr Benefit rausholt und das Ratio zwischen Kosten und Nutzen besser ist, als bei anderen. Eine doppelte Firewall finde ich zum Beispiel mit einem relativ schlechten Ratio bestückt. Kostet viel Geld, bringt aber relativ wenig ein. Eine doppelte Internetverbindung dagegen bringt für das eingesetzt Geld deutlich mehr zurück.

Moin, über welche Exchange-Version reden wir denn?

Das ist doch wieder mal ein typischer Fall, wie man die Symptome, aber nicht die Ursache bekämpft. Sinnvoll wäre es doch dafür zu sorgen, dass die Internetleitung möglichst nicht ausfällt. Entweder über Redundanz oder über passende Providerverträge. Dann bräuchte man sich kaum Gedanken um das danach zu machen und alle in der Firma würden davon profitieren.

Moin, im Prinzip ist doch schon alles gesagt worden. POP-Connectoren erhöhen die Komplexität und erschweren die Fehlersuche. Das Forum wäre merklich kleiner, wenn es diese Dinger gar nicht gäbe. Das SMTP-Protkoll ist auf dieser Krücke nicht eingestellt, das merkt man auch. Weiter: Der Absender bekommt bei Fehlern keine Nachricht, dass sein Mail nicht angekommen. Bei SMTP bekommt er irgendwann eine Nachricht, dass seine Mail nicht zugestellt wurde und kann sich darum kümmern. Bei POP-Connectoren fällt das weg. Das ist auch rechtlich bedenklich, weil die Mail als zugestellt gilt, wenn sie beim Provider angenommen wurde. Kann der Kunde die aus irgendeinem Grund dann nicht abholen, muss er sich das Versagen anlasten lassen. SMTP ist als unsicheres Protokoll designet worden. Es ist einkalkuliert, dass Mails nicht sofort zugestellt werden können und eine Leitung auch mal für Stunden ausfällt. Warum soll ich mir das bewusst kaputtmachen?

Du kannst auch die Adresse vom Admin auf ein anderes Postfach übernehmen. Es darf halt nur kein AD-User sein, der eine Admin-Funktion hat. Ach ja: Und es kann bis zu zwei Stunden dauern, bis dieser Änderung wirksam ist. Und solltest Du es über eine Gruppe lösen, muss der Benutzer sich eventuell ab- und neu anmelden, wenn Du die Gruppenmitgliedschaft änderst.

Wie? genaue Exchange-Version? Das ist keine DAG, oder? Irgendwelche negativen Auswirkungen, oder nur die Meldung im Eventlog?

Moin, wenn Du jetzt nachschaust, wirst Du feststellen, das Senden Als wieder verschwunden ist. Administrative Konten werden von AD geschützt und manuelle Berechtigungsänderungen an diesen Konten wieder zurückgesetzt (sog. adminSDHolder). Exchange nimmt darauf keine Rücksicht, denn die Entwickler haben hier eine ganz klare Meinung: mit administrativen Konten/Postfächern wird nicht gearbeitet, daher müssen diese Dinge mit ihnen nicht funktionieren.

Wenn man die Nachteile von Greylisting akzeptiert, ist das wirklich immer noch eine der besten Methoden. Blacklisten sind auch immer gut, auch wenn man sich damit in eine Abhängigkeit begibt und notfalls schnelle reagieren muss. Bei mir konnte ich kein erhöhtes Spam-Aufkommen feststellen. Die Rate liegt bei 95+ %.

Sagt so zumindest das Technet. Habe ich aber selbst noch nie mit ÖO ausprobiert.

Moin, wenn Du DeliverToMailboxAndForward auf TRUE gesetzt hast, gibt es da keine andere Möglichkeit. ich würde erstmal CU6 installieren. Eventuell ist das ein Bug, der schon behoben ist.

Ein korrekt funktionierendes Exchange-Backup sorgt dafür, dass die Log-Dateien nach dem Backup gelöscht werden.

Aber dann müsste das Problem bei allen Clients auftreten, nicht nur bei einem. Und auch hier: Bei korrekter Konfiguration geht nichts nach draußen und damit kann auch nicht von Strato dazuwischen gefunkt werden. Ist das ein interner Client oder eine mit Outlook Anywhere?

Interessanter wäre es zu klären, warum Outlook eine Verbindung zu Strato aufbauen will. Das wäre bei einem korrekt konfiguriertem Server und einem korrektem Outlook eigentlich gar nicht der Fall.

Moin, kommt das nur bei einem? Hat der eventuell noch ein zweites Postfach per POP oder IMAP eingebunden?

Moin, kannst Du nicht. TLS 1.0 ist hardcoded bei SMTP. Es wird wohl an einer Änderung gearbeitet, zuerst allerdings für Ex 2013. Wann die fertig ist und ob es dann einen Rückport auf Ex 2010 gibt, kann aber niemand sagen.

Moin, ich vermute mal sehr stark, dass im Ex 2003 auf dem virtuellen SMTP-Server ein Smarthost eingestellt ist. Der gehört da nicht hin und muss stattdessen bei 2003 im SMTP-Connector eingestellt werden. im vSMTP gilt er für die gesamte Organisation und wird auch von Ex 2010 beachtet.

Moin, Du musst natürlich auch noch die URLs für Active Sync, OWA, ECP und vorallem Outlook Anywhere korrekt setzen. Und nicht nur die internal URLs, sondern auch die external. DNS muss natürlich auch dazu passen.

Moin, grundsätzlich kann man schon Ex 2013 nehmen, wenn man sich an die wichtigen Grundlagen hält: Nichts auf einem Exchange, was damit nichts zu tun hat. Keine manuelle Konfig an IIS oder Windows Komponenten, möglichst viele Einstellungen im Standard lassen. Jedes CU sauber planen (Schema-Updates und unbedingt alle Dritt-Anbieter-Programme vorher testen!) Allerdings ist die Produktqualität immer noch sehr verbesserungswürdig. Es gab kein CU, dass wirklich fehlerfrei war. Und damit meine ich kapitale Fehler, die langjährige Funktionen lahmlegen. Mal gehen Dritt-Anbieter-Tools nicht, mal Hybrid-Modus. Mal starten Dienste nicht (weil Microsoft das CU intern nie getestet hatte), usw. Beispiel von CU6, das gleich zwei dicke Bugs hat: http://www.expta.com/2014/08/dont-deploy-exchange-2013-cu6-if-youre.html Niemand bei Microsoft hat offensichtlich Co-Existenz mit Ex 2007 und Hybrid Modus komplett getestet. Die Fehler sind keine Fehler bei außergewöhnlichen Konfigurationen. Das ist Alltagsgeschäft. Das ist das, war mir Sorgen macht. Wären es ungewöhnliche Sache, ok. Aber Standard-Funktionen, die plötzlich nicht mehr laufen, machen extrem viel Arbeit im Feld. Anekdote zum Korrekturscript für den Hybrid-Modus: Das läuft nur, wenn Exchange nach "c:\program files\......" usw installiert ist, da irgendein Entwickler auf die Idee kam, den Pfad fest einzubauen. So hat man vielleicht vor 20 Jahren programmiert, aber doch im Jahr 2014 nicht mehr.