NorbertFe

Wie gesagt, kann man machen, kostet dann aber. Und ob es sinnvoll ist, entscheiden die Anforderungen.

Schlecht und bei deinen Lizenzen wahrscheinlich auch gar nicht möglich. Die Hyper-V sind nur Hyper-V, ansonsten kannst du nur eine VM pro Lizenz drauf betreiben. Aber unabhängig davon hat ein Hyper-V nur ein Hyper-V zu sein und kein DC. Warum das so ist, kannst du hier oft genug im Forum nachlesen. Wozu überhaupt 4 DCs? Hast du irgendwie Angst, dass einer kaputt geht? ;) Also 2DCs als VM, 1 Applikationsserver, 1 WSUS, den man ggf. auch als Fileserver verwenden kann. Ansonsten mußt du eben noch Lizenzen nachkaufen. Ja, aber dann eben nur mit einer VM bei der Basis Lizenz. Bye Norbert

Ist halt immer eine Frage von Kosten/Nutzen. Den Vorteil von Loadbalancer nur für DMZ muß man eben auch erstmal für sich definieren. :) Wenn natürlich alles als "nichts terminiert im LAN" für in Stein gemeißelt gilt, dann gehts nur so.

Na gut, darauf können wir uns einigen.

Naja ein sehr komplexes "fast". ;) Alles andere deiner zielt ja mehr oder weniger auf vorgelagerte Windows Serverfunktionen ab, welche dann _nicht_ auf dem Exchange laufen könnten. Also da sehe ich wie alle anderen hier, genau keinen Vorteil gegenüber eines dedizierten Loadbalancers. Eigentlich müßte man also den Dienstleister fragen, was genau so "schlimm" am Kemp sein soll seiner Meinung nach. Evtl. ist er ja nicht so ganz auf Stand der Technik, wenn er eher das Netzwerk betreut.

Nein, ehrlich gesagt, kann ein Exchange 2016 nichts davon, was ein Loadbalancer kann. ;) Ja man kann Exchange 2016 ohne Loadbalancer dafür mit DNS Round Robin betreiben. Ob das sinnvoller ist, wage ich stark zu bezweifeln. ;) Nö, welchen Vorteil sollte sowas haben, bzw. wieso sollte ich internen Traffic dann erst wieder ins DMZ Segment schieben? Man kann natürlich entsprechende Konstruktionen bauen, aber KISS ist halt anders, und insgesamt dürfte sowas dann auch von den definierten Anforderungen abhängen. Bye Norbert

Dann bräuchte man aber nur die Reihenfolge der Tests ändern. ;) Alles was auf der Blacklist steht wird geblacklistet und der Rest landet im Greylisting. Ich hab dazu nen SQL Server laufen. (nein nicht redundant) und ja, wir reden hier von UTM und Konsorten, also eher nicht von Kundengrößen im O365 Style. Pfft... Ganz ehrlich, erstens halten sich diese Verzögerungen bei meinen Kunden stark in Grenzen (hängt ja oft auch vom Absenderverhalten ab) und zweitens: Email ist kein Realtime Kommunikationsmittel. Ja ich kann meinen Kunden und Nutzern genau das sagen. Hab bei einen Servern gerade mal nachgeschaut. Da sinds um die 6% (fürs erste Halbjahr 2018) die im Greylisting hängenbleiben. Interessanter wäre eher, wieviel von den 6% wären im Zweifel in anderen Filtern hängen geblieben. Die durchschnittliche Verzögerung hier betrug übrigens ca. 20 Minuten. Ich gehe davon aus, dass da einige Ausreißer nach oben für diesen schlechten Wert sorgen, die dann eben erst nach mehreren Stunden den zweiten oder dritten Zustellversuch unternehmen. Gibts ein passenderes? Die ursprüngliche Vermutung des TO war, dass der Mailserver Schuld hat. ;) Bye Norbert

Ich sag ja, die UTM ist viel zu unflexibel diesbezüglich. Und da hat sich seit Jahren auch nichts dran geändert.

Irgendwie versteh ich immer weniger, wieso man bei hp bleibt, wenn’s alle diese bios/treiber nervereien bei anderen Herstellern nicht gibt. ;) sorry für die nicht konstruktive Äußerung meinerseits. :)

Naja gibt schon noch ein paar mehr Möglichkeiten für greylisting . Und greylisting an sich kann pauschal auch nicht zwischen dynamisch oder statischen ips unterscheiden, wäre auch irgendwie sinnlos, da kaum noch jemand überhaupt Nachrichten von dynamischen ips annimmt. Kennst du eine implementation, welche das auf diesem Kriterium abfängt?

Oder digital ;)

Das wäre aber zu einfach. ;) man könnte auch einfach Splitdns Konfigurieren.

Eben, deswegen schrub ich das. ;)

Das ist kein Selfsigned Certificate sondern ein Zertifikat einer eigenen internen CA. das ist ein Unterschied. Für Exchange würde ich sowas aber heutzutage auch nur noch maximal in internen Umgebungen nutzen und auf keinen Fall bei welchen die von extern erreichbar sind.

Naja deine Server wirst du namentlich ja erkennen und kannst auf ein Löschen dieser verzichten. Alle PCs sind eher unkritisch. Ein Statischer Eintrag steht statisch drin. Ein dynamischer hat einen Zeitstempel. ;)

Outlook Anywhere funktioniert _ausschließlich nur_ über Port 443. Da wird kein anderer Port für verwendet. Abgesehen davon, solltest du einfach auf MAPI/HTTP umstellen, das ist etwas weniger "umständlich" als Outlook Anywhere.

Einfach alles löschen und warten was sich wieder einträgt. Wo ist da das Problem?

Genau, leider existiert auch bei admins inzwischen eine gewisse egoistische Ader. Mir doch egal, dass ich ggf. Blacklisten usw. Abfragen muss obwohl es beim greylisting durchaus schon zu Ende sein könnte. :/

Deaktivierst du halt einen sinnvollen antispam Mechanismus. :/

Abgesehen davon ist die sophos mailsecurity eh suboptimal, weils zu wenig Konfigurationsmöglichkeiten gibt.

Naja o365 nutzt ja nicht nur 1-3 verschiedene relays. ;) also schau ins spamfilterlog und prüfe ob’s am greylisting liegt. Alternativ kannst du den Nutzern auch meinen Merksatz rezitieren: E-Mail ist kein Echtzeitkommunikationsmittel! :) bye norvert

Setzt ihr greylisting ein?

Wer sollte das selfsigned denn auch verlängern? Da kannst du dann auch einfach ein neues erstellen. Und ansonsten wäre evtl. der Einsatz eines öffentlichen Zertifikats bzw. einer internen CA empfehlenswert. Da hat man solche Probleme dann nicht (dafür andere :)) Bye Norbert

Geht nicht, weil die DBs auf Org-Ebene hängen und deswegen eben eindeutig sein müssen. ;)

Das geht nicht. Es kann keine zwei identisch benannten dbs geben. ;)