NorbertFe

Also kein Schutz. Das was im Exchange vorhanden ist, kannst du heutzutage als nicht ausreichend ansehen. WEnn du jetzt noch sagst, was es war... ;) Ich tippe mal auf ne Watchguard oder Fortigate mit SMTP Pfuschereien. ;)

Grundsätzlich richtig. Logging noch aktivieren, damit man auch was sehen kann. Was genau ist dein Problem? Was heißt es kommen keine Mails an? Von wo gesendet? TTL ausreichend kurz bzw. lang gewartet? Jans Frage nach dem Spamfilter wäre noch interessant ;)

1. Den Default Frontend Connector faßt man gar nicht an. 2. Man trägt dort keine IP ADressen ein, die der Exchange gar nicht hat. ;) 3. Man legt einen eigenen Receive FE Connector an (SMTP Inbound o.ä.) und konfiguriert auf dem dann anonymen Zugriff und TLS und den passenden HELO Namen (dein externer MX Name). Bye Norbert PS: Ein MX zeigt auf einen A-Record und nicht auf IPs.

Naja der Aufwand steht doch sowieso innerhalb des nächsten Jahres bevor, oder?

Das steht im zweiten Post also der zweiten Antwort, die du hier bekommen hast.

Oder man deaktiviert mal im autodiscover „Last Known good” per gpo.

Wer auf solche Ideen kommt, wartet ja nur auf zusätzliche Probleme imho. betrifft das denn alle User? Gehen neue Profile? Laufen alle notwendigen Dienste? Auf welchem Stand ist der Exchange denn jetzt? Ich würd ja erstmal wieder einen Stand herstellen mit SE und aktuellstem Patch. Danach kann man dann weitersehen.

Also quasi nix. ;) wenns cloud sein soll, dann wär ich da bei Jan. Auch ansonsten hat er recht mit Vamsoft, wobei ich da aber erwähnen würde, dass das entweder vorgelagert auf einem Edge laufen sollte oder man nur einen internen Exchange habe sollte und man muss wollen, dass der dann aus dem i-net heraus erreichbar ist. Mag ja auch nicht jeder. Aber ansonsten wär das von mir ganz klar eine Empfehlung.

Naja die mailsecurity läuft AFAIK lokal und nur die Dateianalyse läuft über Sophos central. Mir persönlich ist die mailsecurity von Sophos zu unflexibel und außerdem hab ich den Eindruck, dass da sowieso seit Jahren nicht mehr aktiv dran entwickelt wird und man das nur notgedrungen anbietet aber eigentlich seine cloud mailsecurity verkaufen will (die ich aber auch nicht nutzen wollen würde). Insofern, was spricht dagegen, wenn ihr es einfach testet? Was nutzt ihr denn derzeit als spamfilter und über welche Größenordnung an Mails reden wir hier eigentlich?

Ja Genitiv weiblich Singular ;) Die AD, der AD , der AD Wir schweifen ab ;)

Bestimmt von die nds denn ursprünglich war bei ms ja mal immer von ads die Rede. ;) fürchterbar

Was gibts da nicht zu verstehen? Der zeigt dir ja die lokalen Richtlinien an, die du definieren kannst: er zeigt dir nicht die per gpo definierten Richtlinien an.

Ich verstehe dich nicht. Natürlich ist es aus Sicht von Exchange online das Ziel möglichst ohne on-prem Exchange auszukommen. Das ging ja bisher auch schon, nur eben jetzt kann man die Attribute direkt in der Cloud setzen anstatt im führenden lokalen ad.

Was genau meinst du?

Stimmt, das w hab ich überlesen. Naja dann eben ohne 😉

Deswegen heißt das ja auch Männerspielzeug. Einfach weils geht ;) Falls du mal gucken magst: https://www.opendtu.solar/

Und das Männerspielzeug OpenDTU funktioniert auch schon? ;)

Beste Voraussetzungen also. 😆 welche wr nimmst du?

Und wieso zwei WR? Verschiedene Wände?

Vermutlich wärst du selbst drauf gekommen. ;)

So langsam gehts mir trotzdem auf die Nerven: Ja, man muss dann nur noch den Sync auf Cloud-Sync umstellen, damit man all die neuen Features nutzen kann. Ich bezweifle, dass es wirklich technische Gründe gibt, das nicht auch in Entra Connect zu implementieren, abgesehen davon, dass man Entra Connect insgesamt eigentlich gar nicht mehr haben möchte.

Mag sein, nur ist der Exchange nicht der Grund für das Zertifikat auf dem dc.

Exchange funktioniert problemlos ohne Zertifikate auf den dcs.

Und hyper-v Hosts mit laps sind auch ein Stolperstein, wenn mal die komplette Umgebung down sein sollte. Und ja alles schon erlebt. Utilman.exe hilft zwar, dauert aber alles in solche Situationen. ;) seitdem sind die hyper-v Hosts bei den Kunden meist ohne laps konfiguriert und haben einfach komplexe lange Kennwörter, die man ja nie eingeben muss, solange die Dinger im ad hängen.

Dann nimm halt esx ;) alternativ bau halt nicht nur zwei luns sondern mehrere. Dann hast du zwar das gleiche Problem, kannst aber notfalls einen Teil der Maschinen einfach umhängen. Auf Kosten der Flexibilität im Storage natürlich. Es bedient sich imho bescheiden. auch wenn ich das Bedürfnis verstehe, den Cluster nicht ins produktive AD zu hängen, wäre das für mich immer noch kein wirklicher Grund es nicht trotzdem zu tun. Erst recht nicht, wenn der workload einzig und allein die Umgebung des AD und seinen Mitgliedern beinhaltet. Wenn dein ad kaputt is sind die hyper-v Hosts das geringste Problem und wenn die hyper-v Hosts die Ursache für die Übernahme waren, dann gabs sowieso ein Problem an anderer Stelle. Anders sieht es aus, wenn da noch weitere unabhängige Systeme drauf laufen.