NorbertFe

Oder nen dkim transportagent. ;) ach da fällt mir sicher noch mehr ein.

Vermutlich auch nur halb, so dass man damit dann wieder nicht ecc requests erstellen kann usw. usf.

Ich hoffe mal, dass sie die zur Verfügung stehenden Funktionen und Rollen nicht kastrieren. Schön, was die alles soweit in die Zukunft bis Exchange SE CU1 schon geplant haben, aber sind nicht in der Lage das vor "early part of Q3 of 2025" zu veröffentlichen, obwohl es codeidentisch sein wird. Das is einfach nur bekloppt™

LOL die hängen sich an solchen Sachen wie ECC Zertifikate und TLS 1.3 auf. Was schert denn da schon architektonische Sicherheit? ;)

Hallo, MS hat gerade mal ein Update der Roadmap veröffentlicht: https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-server-roadmap-update/ba-p/4132742 Na das war ja klar. Am Ende hätten sie es auch einfach weiter Exchange 2019 nennen können und nur den Lizenzschlüssel geändert. ;) Warum man bei Erscheinen von CU15 nicht direkt dann auch die SE ausliefert ist mir unklar. We will release one final Cumulative Update (CU) for Exchange Server 2019—the 2024 H2 CU aka CU15—later this year. To allow for rapid adoption and deployment, the RTM release of Exchange Server SE will be code equivalent to (e.g., the same exact code as) Exchange Server 2019 CU15, except for the following changes: The License agreement, an RTF file shown only in the GUI version of Setup, will be updated. The name will change from Microsoft Exchange Server 2019 to Microsoft Exchange Server Subscription Edition. The build and version number will be updated. Bye Norbert

Es gibt nur einen DC?

Wäre ja jetzt die Frage, wie dein aktueller Stand ist? Ist er vom April 2024 oder älter? Technisch sollten die CUs, wie der Name schon sagt cumulative sein. Aber das PACEnforcement wurde ja mehrfach verschoben. Insofern wäre jetzt die nächste Frage, was der Pentest denn prüft und ob das überhaupt korrekt ist.

Und über Roaming Profiles wollen wir lieber generell nix mehr sagen. Es geht immer alles so lange, bis es auf einmal "bis vor kurzem" nicht mehr klappt. ;) Roaming Profiles sind einfach seit spätestens Windows 10 kaputt. Der eine merkt es früher, der andere später.

Wenn man schreibt und gleichzeitig was anderes liest ;)

Der Kunde. Wer denn sonst?

Naja, sowas hab ich dann tatsächlich auch schon gesehen: Ach wir haben ja 3 Internetanschlüsse, da können wir einen kündigen/umziehen. ;) Ups das war ja der, über den die ganzen statischen IPs irgendwelche Dienste angeboten haben :)

Wie, bei euch wird die Internetleitung mal umgestellt und dem Admin erzählt man davon nix? Das hilft natürlich ;) Danke für deine Rückmeldung.

Korrekt. Ich würde sowieso immer SAN Zertifikate vorziehen, gegenüber einem Wildcard Zertifikat (auch für die zukünftige Verwendung). Für die Umstellung gehts ja sowieso nicht. ;) Zertifikat mit 4 Namen kostet vermutlich irgendwas um 100€ wenns später nur noch 2 sein sollten, dann wirds vermutlich noch mal etwas billiger. Alternativ schau dich um, ob Lets encrypt bei dir funktionieren würde.

Ja das kann man umsetzen. Am sinnvollsten ist es, für die Umstellungsphase ein Zertifikat mit neuem _und_ altem Namen zu nutzen. Dann gibts keine Fehlermeldungen. Mobile Devices musst du einmalig von Hand ändern, bzw. wenn du den Namen dann irgendwann aus dem DNS löschst werden die schon zu dir kommen. ;)

Was genau pingst du da an? Hier wäre jetzt ein Beispiel ganz praktisch, aber das mit der doppelten Domäne, deutet darauf hin, dass du nicht punktiert abfragst. https://www.faq-o-matic.net/2014/02/12/wenn-und-warum-nslookup-unerwartete-ergebnisse-zeigt/ Für mehr Antworten bräuchte man jetzt mehr Infos. ;) Bspw. mal ein ipconfig /all | clip vom Exchange. Die Fehlermeldung ist eher unabhängig vom Namensauflösungsthema. Bei Zeitverzögerung und Mailversand/-empfang fällt mir als erstes immer SMTP Backpressure ein, aber auch das sollte man im Eventlog finden können. Bye Norbert

Aktuell vom thread hier. Vom Rest fange ich lieber nicht an.

So viele sinnvolle Vorschläge und umgesetzt wird der, von dem alle mehr oder weniger abraten.

Und das am heutigen Tage? 😂 das glaubst du doch selbst nicht.

Würde auch definitiv davon abraten. Verursacht nur nen Haufen ndr und im Zweifel blockt dich strato weil du nen Haufen spam einlieferst und backscatter verursachst.

Najaaaaaa: https://duo.com/docs/rdp-notes Version 4.2.0 - September 23, 2021 da darf man auch schon mal updaten, oder?

Wie soll denn der Client Udp mit dem Server sprechen, wenn der gar nicht auf dem Protokoll/Port antwortet? Auf dem Server bewirkt der Befehl nur, dass seine rdp Client Verbindungen kein Udp nutzen. So wie die Clients eben auch. Also ist er auf dem Server ziemlich sinnlos.

Warum willst du das denn clientseitig deaktivieren? Mach’s doch einfach am Server aus.

Im hcu wär auch nicht soviel besser ;)

Ok 😆

👍 naja wenn „neue maildomain = sofort = bereits in Nutzung“, dann kannst du so schnell gar nicht migrieren, dass du den workaround nicht zumindest einführen müsstest.