RobertWi

Du kennst die internen Diskussionen und weißt, was die anderen MVPs dazusagen. ;) Immerhin hat das mittlerweile wenigstens Einzug ins Technet gehalten.

Moin, Spamfilterung "macht" immer nur Sinn, auf dem ersten Geräte, dass die Mails empfängt. Alle anderen Geräte danach können Spammails technisch nicht mehr ablehnen und sinnvoll behandeln.

Moin, hier hast Du was (viel :)) zum Lesen: http://technet.microsoft.com/en-us/library/bb124392(v=exchg.141).aspx http://www.msexchange.org/articles-tutorials/exchange-server-2010/security-message-hygiene/exchange-2010-domain-security-part1.html

DAG mit Windows Standard? Ich würde Exchange 2010 noch nicht auf Windows 2012 einsetzen, zumal der reine Betrieb mit 2012 DC noch nicht supported ist. Mindestens ein 2008 R2 DC ist also auch erforderlich.

Das ist das, was wir mit dem Grundlagenwissen meinen: Wenn Du einmal eine Wiederherstellung eines DC mit installiertem Exchange hinter Dir hast, weißt Du, warum Microsoft dringend rät, keinen Exchange auf dem DC zu installieren. Was zum Beispiel bei Dir interessant sein könnte: Du brauchst eh Windows Enterprise. Damit kannst Du aber auch vier virtuelle Maschine bauen. Also Windows Enterprise auf die Kisten, DC und Exchange innen virtuell. Braucht eventuell mehr Hardware (und ist bei reinen VM-DC eigentlich noch nicht supported, macht aber weniger Probleme als das Kombi-Gerät), gibt aber eine saubere Rollen-Trennung. Wie gesagt: Das muss man aber vor Ort klären, das übersteigt ein Forum.

Es gibt keine "DC Backup". DC sind ein Multi-Master-Konzept, aber ok, ich verstehe, was Du meinst. Aber ich kann Norbert nur zustimmen. Dir fehlt Grundlagenwissen, dass für den Betrieb absolut notwendig ist. Sonst fährst Du später gegen die Wand und weißt nicht mal, warum. Du solltest Dir mal einen Fachmann ins Haus holen, der Deine Umgebung analysiert und mit Dir zusammen dann ein gutes Konzept baut.

Moin, also nur aus Backup-Gründen wären mir zwei Windows Enterprise Lizenzen zu teuer, aber theoretisch ist das Konzept von Exchange am Ende (da gehört aber ein wenig mehr dazu, also nur zwei Kisten mit DAG) auf eine backuplose Infrastruktur ausgelegt. Den letzten Satz verstehe ich nicht, Exchange ist doch schon auf dem DC?

Fehlermeldungen beim Booten kann man i.d.R. ignorieren. Exchange ist massiv abhängig von anderen Diensten und wenn die noch nicht online sind, gibt es erst mal Fehler. Das spielt sich nach wenigen Minuten aber von alleine ein. Nur, wenn der Fehler nach einer Zeit nicht verschwinden (5 bis 10 Minuten, je nach Anzahl der Server und Aufbau des Netzwerkes), muss man sich drum kümmern. Wenn ich hier meine vier Exchange-Server boote, habe ich problemlos 30 bis 40 "Fehler" pro Gerät. Keine davon kommt zweimal und ist daher unkritisch.

Rein technisch funktioniert die DAG übrigens auf einem DC, ob sie supported ist, weiß ich aber nicht. Allerdings ist eine nachträgliche "Trennung" von DC und Exchange nicht möglich. Du brauchst dann einen neuen Exchange, musst alles verschieben und den alten deinstallieren.

Formell: ja. Allerdings gibt es keine Verschrift, wie ein anderes System das auswertet. Sehr restriktiv ist z.B. gmail.

Kannst Du von Win 8 Gerät OWA aufrufen?

Einfache Antwort: Nein. Vollzugriff ist Vollzugriff.

Allerdings schreibst Du auch "intern". Und dann geht meine Shell-Lösung sowieso nicht, weil das die externen Connectoren sind. Transport Agent programmieren, würde mir noch einfallen.

Zumindest nicht für Windows/Exchange. Aber andere Produkte (Virenscanner, Backup, Archiv) sehen manchmal nur die Mailboxen und kümmern sich nicht um die Verwendung.

Per PowerShell und Taskplaner den Sendconnector deaktivieren, ist die einfachste Variante. Dann bleiben die Mails in der Warteschlange stehen.

Local ist grundsätzlich immer verkehrt, und wenn man zukünftig möglichst wenig Probleme haben will, sollte man davon weg gehen. Leider gibt es keine offizielle TLD für internen Betrieb. .test ist für was anderes reserviert und .intern ist "frei". Ich persönlich empfehle daher i.d.R. so was wie "ad.dom.de" - also eine Sub-Domäne unter der bestehenden.

Bitte auf Cross-Postings hinweisen, danke -> http://www.msxforum.de/modules/newbb/viewtopic.php?post_id=82260

Moin, gar nicht, weil es nicht funktioniert. Du musst entweder die Authentifizierung abschalten, oder kannst nicht von Extern empfangen. Warum Du der einzige bist, liegt vermutlich daran, dass Verteilerlisten eher selten eingesetzt werden. Für Zusammenarbeit gibt es bessere Möglichkeiten, so dass Verteiler eher nur als "Newsletter" verwendet werden.

Moin, Du kannst den DC nicht entfernen, wenn Exchange drauf ist. Also wäre es am einfachsten, Du installierst den gesamten Server neu und nimmt die Maschine dann in die SBS-Domäne auf.

Moin, ergänzend: Der Fehler kommt bei "StopDagServerMaintenance"? Dann bist Du entweder kein lokaler Admin oder der Cluster ist nicht im Wartungsmodus. Der genaue Fehler wird leider nicht angezeigt.

Moin, mein Befehl (Post #8): get-receiveconnector | fl Name,RemoteIPRanges Dein Befehl: get-receiveconnector | ft Name,*IP* ist offensichtlich nicht identisch. Und um die IP-Adressen geht es eigentlich. Wenn Du zuviel kürzt, können wir nichts mehr erkennen.

Nimm doch bitte mal meinen Befehl, habe ich extra wegen der Ausgabe angepasst.

Korrekt. Im Badmail-Ordner landeten früher mal Unzustellbarkeitsnachrichten, die selbst nicht zustellbar waren. Siehe auch: Im http://www.msxfaq.net/admin/badmail.htm Eigentlich sollten seit Ex 2003 SP 1 dort gar keine Mails mehr drin liegen. http://blogs.technet.com/b/evand/archive/2004/06/18/159573.aspx Es gibt wohl nur ein paar wenige Ausnahmen, die passen aber nicht zum Problem: http://social.technet.microsoft.com/forums/en-US/exchangesvrgeneral/thread/565c6759-4058-41ad-98fc-aeee6cd71ae6 Ist da zufällig ein POP-Connector im Einsatz?

Moin, sorry, schreib doch dazu, dass Du nur sehr wenig PowerShell-Erfahrung hast und meinen Fehler dadurch nicht bemerkt hast. Nimm (an zwei Stellen angepasst): get-receiveconnector | fl Name,RemoteIPRanges

Moin, vom Schema-Update sollten die Leute nichts mitbekommen, das macht nur ein wenig Replikationsverkehr, der im normalen Verkehr meist zu vernachlässigen ist. Nur sollte dabei was schiefgehen, dann würden die Recovery-Maßnahmen eventuell die Leute betreffen.