NorbertFe

Wer redet von _einem_ LB. Ich geh halt von HA aus. ;) Schon klar. :)

Nee das klappt nachweislich nicht. ;)

Ja.

Läuft der Anmeldedienst auf den betroffenen Geräten?

die virtuelle IP, die im Zweifel zwischen den redundanten Loadbalancern wechselt. ;)

Naja.... Da macht NLB sicher jede Menge Probleme, aber mit Kemp und ähnliche hält sich das stark in Grenzen und ist auch relativ genau dokumentiert. Insofern würde ich das einfach als "Gelaber" abhaken. ;)

Nee aber der Admin. Und der Nutzer muss sich das Zertifikat besorgen. Denn das gehört ja ihm und nicht dem Admin. ;)

Stimmt, dafür hast du das Zertifikatshandling :p

Einfach in die Domäne der VMs aufnehmen. Wo genau siehst du das Problem? Und wieso noch zwei Bleche? Wenn schon soviel Blech für 3 User geplant wird, dann plan halt noch ein drittes Blech dazu, dann kannst du mit nur einem virtuellen DC auskommen. Abgesehen davon wäre ja auch technisch zu klären, ob VM Replikation für die verwendeten Systeme und Dienste überhaupt "unterstützt" wird. Funktionieren und Support sind dann doch unterschiedliche Schuhe.

Wahrscheinlich gar nicht. :) Denn dafür müßtest du dann Windows Server 2016 mit SA besitzen afaik und selbst dann ist die 1803 eben kein "vollwertiger" WIndows Server 2016.

Das ist vollkommen egal, wofür er DC ist, ein Hyper-V ist kein DC. ;) So schwer ist das doch nicht zu verstehen.

Das lokale Administratorkonto wird nicht deaktiviert. Und selbst wenn, könnte man es ja einfach wieder aktivieren.

Du liegst falsch.

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.