RobertWi

Moin, im Prinzip ist im Vergleich zu Ex 2007 nichts neu. Auch dort brauchtest Du Zertifikate, mit den gleichen Anforderungen bzgl. OA, EAS, OAB. Das ist bei Ex 2013 nicht anders. Das Ex 2013 nun intern OA nimmt, spielt dabei keine Rolle. Denn in einem vernünftigen Design hat man sich schon bei Ex 2007 nicht auf intern/extern konzentriert und es einmal korrekt gemacht. Was man nimmt hängt von den Möglichkeiten und dem Geld ab. Aber externe Zertifikate mit zwei Namen (mehr braucht es nicht) kosten nun wirklich nicht die Welt und machen das Leben deutlich einfacher. Klar kannst Du auch einen SRV-Eintrag setzen, wenn Du keine mobilen Geräte hast, die damit ein Problem haben. Auf jeden Fall nimmt man aber Split DNS.

Und noch ein Link zur Verdeutlichung des Automappings und des AD-Attributes: http://www.msblog.eu/exchange-2010-sp2-automapping-deaktivieren/

Und außerdem darf die UTM gar kein Spam mehr ablehnen, Spam-Filter ist hier also eh überflüssig.

Und ich persönlich würde auch den Wechsel von 2003 beschleunigen. Exchange 2003 ist nicht mehr im Support. Wenn da was passiert, haben die RA Spaß. So ein Verstoß gegen die anwaltliche Schweigepflicht aufgrund veralteter nicht gepflegter Software kann die Zulassung kosten. Und technisch wird da auch keine Rücksicht mehr genommen. Es gibt es also keine Gewähr, dass Outlook 2010 überhaupt noch korrekt mit Ex 2003 zusammenspielt.

Off-Topic: Auch wenn allgemein ein POP-Connector technich bedingt nie sauber funktionieren kann, denke ich, tut man POPCon als Produkt hier unrecht. Das ist für mich definitiv eines der besten am Markt mit gutem deutschen Support. Wenn man, aus irgendeinem nicht vorstellbarem Grund ;), einen POP-Connector braucht, würde ich immer POPCon empfehlen.

Der SBS ist schon ziemlich vermurkst, was den IIS angeht. IMHO hat das schon mindestens 2 Websites. Da würde ich nicht weiter dran rumspielen. Mal abgesehen davon: Wenn man Exchange auf der Kiste hat, muss man ziemlich gut wissen, was man tut. Sonst riskiert man, dass das so wie eingangs endet. Das gilt auch für das Einrichten einer zweite Site. Wäre nicht das erste Mal, dass in den Bindungen, Zertifikaten oder sonst wo was falsch ist und Exchange steht.

Das ist ja ein merkwürdiger und vollkommen widersinniger Spamfilter. Privatkunden -> haben nur ein Postfach -> kein Sammelpostfach Firmenkunden -> bekommen Mails direkt zugestellt -> kein Postfach bei Hetzner=kein Sammelpostfach Ändert aber nichts daran, dass Du nicht mehr ablehnen darfst. Du musst an dieser Stelle alles annehmen und darfst höchsten noch den Betreff taggen. Ablehnen darf technisch und rechtlich halbwegs sauber nur der erste Mailserver. Wenn der die Mail angenommen hat und der Absender das belegen kann, stehst Du im Ernstfall vor Gericht ziemlich b***d da, wenn Du die Mail dann nicht erhalten hast. Sollte Dir Hetzner die Funktion nicht bieten, geht woanders hin. Mailprovider gibt es wie Sand am Meer. Oder mach es richtig und verzichtet auf den Provider ganz.

Die Basisfunktionen von Extern brauchen bei Exchange keinen Port 80. Port 80 kann man auch gut woanders hinschieben. Bei mir daheim landet 443 auf Exchange und 80 auf einem Linux Apache. Für differenzierte Verteilung gibt es Reverse Proxys, WAP, IIS ARR, usw. WAP funktioniert sogar mit 443/SSL wunderbar. Eine saubere Rollentrennung ist einfach grundlage einer stabilen, guten und pflegeleichten IT-Struktur. Exchange alleine ist ein Produkt, dass auf Änderungen im Umfeld oft sehr sensibel reagiert. Und noch ein paar Punkte: - Exchange nimmt keine Rücksicht auf so etwas - Es kostet Performance, die Exchange für sich beanspruchen will - Alle Reparaturen sind aufwendiger - Es erhöht die Komplexität eines Einzelsystems - Es erhöht den Bedarf an die Verfügbarkeit des Einzelsystem - Die Auswirkungen eines Ausfalls des Einzelsystems sind höher

Eigentlich bin ich davon ausgegangen, dass es darum geht, POPCon abzuschaffen und im Rahmen der richtigen SMTP-Zustellung zu filtern. Wenn ein POP-Connector im Einsatz bleibt, erübrigt sich fast jede Diskussion. Dann sind Spam-Filter prinzipiell falsch bei Exchange und auch den Virenfilter sollte dann gleich der Provider durchführen.

Moin, Exchange 2010 hat keinen Virenschutz. Der Spam-Schutz funktioniert, ist aber eher rudimentär. Als Spam-Schutz kann man ORF von Vamsoft empfehlen. Da kann man ClamAV einbinden und das ganze ist preislich überschaubar. Ich persönlich mag Avira, da ist die Konfig schön übersichtlich und ich kann trotzdem mehrere Server mit der gleichen Konfig bestücken. Aber ansonsten ist das vermutlich Geschmackssache. Ich würde mich auch mal bei dem Hersteller umhören, bei dem Du Client- und Fileserver machst. Oft hat man dann die gleiche Management-Umgebung und kann Regeln vereinheitlichen und muss nicht alles doppelt lernen. Anderseits ist ein wenig Diversifikation gerade beim AV auch nicht schlecht.

Moin, OWA Light ist da eingeschränkt. Ändern kannst Du da nichts. Entweder Du nimmst den Internet Explorer oder ihr wechselt auf Exchange ab 2010. Das OWA dort auch mit Nicht-IE gut läuft, war für mich persönlich das absolute Killerfeature bei 2010.

Moin, das ändern der Standard-Ports für Exchange ist nicht supported und funktioniert teilweise auch gar nicht (z.B. bei Outlook Anywhere und den meisten mobilen Geräten). Außerdem solltest Du tunlichst unterlassen, bei einem Exchange Server am IIS rumzuspielen. Besonders bei einem SBS, der eh schon ziemlich verbastelt ist, damit WSUS und Sharepoint auch funktionieren. Auf keinen Fall solltest Du auf der Kiste aber noch einen weiteren Webserver installieren. Glaub uns: Exchange ist sehr sensibel und nimmt auf so was keine Rücksicht. Du riskierst, sehr viel Spaß im Betrieb und mit jedem Update zu haben (das Dir gnadenlos die Einstellungen wieder zurücksetzt). Ein Exchange ist ein Exchange ist ein Exchange - und nichts anderes. Schon der SBS ist exchangetechnisch "broken by design".

Lustig ist nur, dass Doso und ich für das eigentlich gleiche Problem komplett gegensätzliche Erfahrungen haben. Das haben wir schon bei anderen ähnlichen Fragen bzgl. Automapping/Cache Mode festgestellt. Wegen des OWA-Zugriffs schau mal nach: Get-OwaVirtualDirectory | fl Name,Server,ExplicitLogonEnabled ExplicitLogonEnabled muss auf True stehen, damit das Dreieck erscheint. Du hast ja selbst schon gesehen, dass das Abschalten nicht wirklich viel bringt, da man das andere Postfach immer noch öffnen kann, wenn man die Mail-Adresse an die URL hängt. IMHO ist das einfach nur lästig, aber kein Sicherheitsgewinn.

Danke für die Infos. Den Cisco Link habe ich an die Netzwerker weitergegeben. Das ich die ACL nicht gefunden habe, liegt vermutlich daran, dass ich nicht auf die Idee gekommen bin nach "ACL" zu suchen. :) Das ist vielleicht nicht so komfortabel, kann aber genau die einfache Lösung sein, die gebraucht wird, da es hier ja nicht um differenzierte Regeln, sondern einen Totalblock geht.

Moin, mal eine Frage aus einem Bereich, mit dem ich mich nur am Rande auskennen und wo ich wohl auch den richtigen Suchbegriff nicht gefunden haben. Mehrere virtuelle Maschinen teilen sich einen vSwitch auf drei Hyper-V-Clusterknoten. Aus netzwerktechnischen Gründen laufen alle im gleichen vLAN und der gleichen IP-Range. Außerdem fällt die Windows Firewall als verbindliche Sicherheitslösung aus, da die Leute aus betrieblichen Gründen lokale Admins sein müssen. Bietet Hyper-V eine Möglichkeit, auf Ebene des vSwitches eine Firewall zu implementieren? Es soll verhindert werden, dass VM1 mit VM2 kommunizieren kann, egal, was in der Maschine passiert.

Moin, Reply To ist normalerweise alleine kein Spam-relevantes Feld. Du musst also erstmal genau klären, warum Du auf einer Blacklist gelandet bist.

Das schwierige ist ja: Das hängt auch vom Gegenüber ab. Ist ein "AW: Vielen dank für Ihre Mail" nun eine automatische Antwort weil der Gegenüber selbst in Urlaub ist oder ein erwarteter Reply (und beim Amerikaner steht da "Re: Vielen Dank...."). Also kann man Header auswerten, Betreff, eventuell auch den Body, Msgids und Thread-Ids mitloggen und muss trotzdem immer hoffen, dass beim Gegenüber kein Admin sitzt, der wichtige Header-Zeilen filtert. Nicht umsonst machen sich Ticketsystem die Mühe, ihre Ticket-ID an so vielen Stellen wie möglich unterzubringen, in der Hoffnung, dass der Gegenüber wenigstens eine der Stellen drin lässt und sie damit ihre Mail wiedererkennen. Aber das wirklich gemeine ist ja, dass wenn ich eine Prüfung vergesse und dadurch eine Schleife entsteht, habe ich im schlimmsten Fall binnen weniger Minuten tausende von Mails, vollgelaufene Postfächer, überlastete Server und einen zurecht verärgerten Kunden. Das System hat Null Fehlertoleranz mit fatalen Auswirkungen. Wäre mir als Programmierer oder Admin zu heikel. Dann kommt eher das in Frage, was Dukel schrieb: Ein echtes Ticketsystem, wo genau für solche Probleme viel mehr Erfahrung drin steckt.

Moin, ja, machen kann man viel. Wobei man bei einer eigenen Lösung mit automatischen Antworten die Loop-Detection nicht unterschätzen darf. Die muss man dann IMHO selbst bauen.

Moin, wenn Du die Outlook Regel anlegst, sagt Dir Outlook, ob das eine nur Client-Regel ist. Ich vermute auch, dass das eine Client-Regel ist. Und bei einer Transport-Regel muss ich mich vermutlich korrigieren, das kann die gar nicht, hatte ich falsch in Erinnerung.

Moin, beide Fehlermeldungen verschwinden von alleine, wenn Du Ex 2003 los bist. Du bräuchtest auch für die Deinstallation über die Systemsteuerung die CD im Laufwerk, das Programm erwartet sie. Du kannst daher auch gleich die Deinstallation mit der CD durchführen, kommt auf das gleiche hinaus.

Moin, das Risiko bei automatischen Antworten ist, dass man sich Mailschleifen baut. Exchange versucht das zwar zu erkennen, das braucht aber Mitarbeit vom Server gegenüber. Du könntest eine Transport-Regel bauen (mit den Exchange Werkzeugen) oder eine Outlook-Regel (mit Outlook, das geht mit Exchange Werkzeugen bei 2007 noch nicht).

Exchange 2010 steht auf der ersten Seite. Die Option in OWA, die Norbert meint, ist das kleine, unscheinbare Dreieck neben Deinem Benutzernamen rechts oben. Da klickt man drauf und kann man ein andere Postfach öffnen. Ich persönlich kenne solche Probleme übrigens nur, wenn das zusätzliche Postfach groß und per Automapping eingebunden ist und damit keine eigene OST hat. Das Problem kommt bei uns immer gelöst werden, in dem man Automapping deaktiviert und das zusätzliche PF per Hand einbinden. Ob das mit Cache oder ohne passiert war egal, wichtig war nur: Ohne Automapping.

Meine Erfahrung: Wer den Unterschied kennt und differenzieren kann, der weißt auch, dass man bei like mit "*" sucht. Sehr viele adaptieren aber nur Beispiele, die sie im Internet finden. Und wenn dort ein -like "*Manager*" steht, können die daraus problemlos ein -like "*+Eva*" machen. Steht dort aber -match "Manager" schlägt der Versuch fehl, das in -match "+Eva" umzuwandeln. -like hat eben nur zwei Zeichen (wobei ich ? noch nie wirklich verwendet habe), die ich kennen muss. Bei -match sind das gut 20, auch noch in verschiedenen Möglichkeiten. Mit der richtigen Übung ist das kein Problem, aber ich habe in Workshops oft Leute, die Anfänge sind und keine Scripting Erfahrung haben. Dann wären RegEx garantiert zu hoch.

Was soll eine "ungefähre" Suche sein? -match ist eine RegEx Suche -like ist eine Platzhaltersuche Steht übrigens auch so in deinem zweiten Link. Allerdings steht da auch, dass "*" bei -match eine Wildcard sei. Das ist falsch. "*" ist bei -like eine Wildcard, bei -match ist das aber ein Quantifier, der für 0 oder mehr Treffer steht ({0,}). Der macht in vielen Fällen das gleiche, aber eben nicht immer. PS C:\> $person = "Guy Thomas 1949" PS C:\> $person -like "Th*" False PS C:\> $person -like "Gu*" True PS C:\> $person -like "Gu*1949" True PS C:\> $person -match "Gu*" True PS C:\> $person -match "Gu*1949" False Man beachte den Unterschied zwischen -like "Gu*1949" (= True) und -match "Gu*1949" (= false). Das liegt daran, dass Suchen mit RegEx (-match) im Normalfall "greedy" (=gierig) sind. Die finden ALLES, was nach dem Metacharacter kommt. Bei -like ist er dagegen ungierig, findet also nur bis zum ersten anderen Treffer. Das hier wäre identisch: PS C:\> $person -like "Gu*1949" True PS C:\> $person -match "(Gu)*?1949" True Und richtig lustig wird es, wenn man nach den Zeichen suchen will, die in einem RegEx eine besondere Bedeutung haben: PS C:\> $test2 = "Adam+Eva" PS C:\> $test2 -like "+Eva" False PS C:\> $test2 -like "*+Eva" True PS C:\> $test2 -match "*+Eva" "*+Eva" wird analysiert - Quantifizierer {x,y} nach nichts. In Zeile:1 Zeichen:1 + $test2 -match "*+Eva" + ~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : OperationStopped: ( [], ArgumentException + FullyQualifiedErrorId : System.ArgumentException PS C:\> $test2 -match ".*+Eva" ".*+Eva" wird analysiert - Geschachtelter Quantifizierer +. In Zeile:1 Zeichen:1 + $test2 -match ".*+Eva" + ~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : OperationStopped: (:) [], ArgumentException + FullyQualifiedErrorId : System.ArgumentException PS C:\> $test2 -match ".+Eva" True Wer jetzt nichts mehr versteht merkt sich einfach das, was ich oben schriebe: Wenn ich nicht weiß, wie-match genau funktioniert, ist -match vermutlich falsch.

Danke. Ich habe das als Feedback übermittelt, dass lieber -like als -match in Beispielen benutzt werden sollte.