NorbertFe

Die hat man auf Platte, braucht sie aber eigentlich nicht. ;)

Das sind Probleme. ;) wie wärs mit „lösch das, welches nicht konfiguriert ist“?

Steht oben. ;) irgendwas mit dem receive connectors hab ich da noch im Hinterkopf. Aber das merkst du dann schon.

Was gibt denn da nicht zu verstehen? Cu23 ist so alt, da werden die nicht noch für cu22-cu10 was nachliefern. ;)

Sieht du ihn da? ROOOOOT markiert. ;) Man müßte halt lesen :)

Dann hier der neue offizielle Stand ;) https://docs.microsoft.com/en-us/Exchange/plan-and-deploy/supportability-matrix?view=exchserver-2019#microsoft-net-framework Liest du die von dir geposteten Links auch? :) https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2019-2016-and-2013-march-2-2021-kb5000871-9800a6bb-0a21-4ee7-b9da-fa85b3e1d23b Runterscrollen bis: How to get and install the update

Ohne das jetzt zu bewerten, aber die Aussage die ich kenne (und ja die kommt noch aus 2010er Zeiten), ist: Stelle keine Firewall zwischen Exchangeserver und keine zwischen DomainController und Exchange bzw. wenn dann darf kein Traffic geändert oder geblockt werden. Und wenn man das "annimmt", dann ist es ganz einfach. Du kommst mit den Client Ports zum CAS (https, IMAP, IMAPs, POP3, POP3s und SMTP 25, 587) alles andere passiert dann "in einer Blackbox" firewalltechnisch gesehen. Deswegen stehen die Exchangeserver und dazugehörige DCs eigentlich auch getrennt vom Rest. Das betrifft dann deine Replikationsports (DAG, Kerberos usw.). Man kann sich jetzt natürlich hinsetzen und das mitschneiden und hoffen, dass man es hinbekommt, aber das hilft dir halt immer nur bis zum nächsten Problem. Meine Empfehlung wäre also, schotte lieber die Exchangeumgebung vom Rest ab als die Exchangekommunikation zwischen Exchange und beteiligten Systemen zu restriktieren. Das hilft am Ende dann sowieso nicht wirklich weiter. Solltest du es hinbekommen, dann Glückwunsch. :)

Ist der schon übernommen?

Es ist bei MS inzwischen dokumentiert, dass man das machen "kann". Wahrscheinlich hatten sie keinen Bock ständig die Frage zu bekommen, wo man denn CU6, CU 8, CUxx runterladen kann.

Das sieht ms auch so. Allerdings würde ich wetten hatten die vermutlich das selbe Problem, nur früher reagieren können. Netterweise ist der Patch ja vom 14.2. signiert, lag also locker zwei Wochen auf Halde. :/ und bei o365 kannst du ja nicht prüfen. ;)

Na das wird aber eben in vielen Fällen nicht helfen. Wieviele kennst du, die /rpc /mapi /ews per Pre-Auth können und das auch so konfigurieren?

Du hast dann vermutlich "nur" Glück gehabt. Ich sehe hier grad andere Bilder.

Vielleicht falsche Denkweise. Der User hat Zugriff auf den Schlüssel. Ist schließlich seiner. ;) Und bei lokalen Admins hat man immer verloren.

Die patches dürften jetzt auch egal sein, weil die meisten Server schon betroffen sein dürften. :/

Naja außer Windows interessiert dieses flag sowieso kein os. ;) und selbst da gibts Mittel und Wege.

Und warum kann der User ein zertifikat manuell bekommen?

Das ist aber nur in deiner Vorstellung so. ;) ich sehe in deinem Anwendungsbereich eigentlich nur Nachteile, aufgrund der bedienbarkeit.

Was ist denn in der Vorlage dazu definiert?

Wenn ich die Artikel richtig lese, dann ist das nicht notwendig, wenn die patches installiert sind. negative Effekte dürfte das nicht haben.

Wenn du ohne gui klarkommst, kann man sich auch den kostenlosen antun. Empfehlen kann man das wahrscheinlich nicht.

Naja ist ja nicht so, als hätten wir uns hier nicht schon zu Wort gemeldet. :) Das sind so "Problemchen", die man im Forum selten sinnvoll gelöst bekommt.

Ja das siehst du falsch.

Sehe das wie Jan.

Das funktioniert aber auch nur bei korrekter Konfiguration sonst sortiert dir wahrscheinlich fast jeder spamfilter sowas aus.

Also zumindest seit XP Pro auf jeden Fall.