NorbertFe

nimm einen anderen smtp service. Der von MS ist seit Jahren deprecated. https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831568(v=ws.11)?redirectedfrom=MSDN Also schon seit 5 Versionen veraltet. Nach 10 Jahren kann man sich auch mal was neues suchen. Wenn du unbedingt "basteln" willst, dann hier: https://community.spiceworks.com/topic/2359337-no-smtp-available-on-server-2022-what-could-i-use-instead

Läuft. Nach ca. 2h hab ich unsere 5 Server auf aktuellem Stand. Einmal überall deinstallieren und danach wieder installieren. Deinstallation dauert deutlich länger als die Installation. :/

Könnte Dual Scan sein. Deaktiviert man besser, wenn man einen WSUS nutzt. ;) https://www.andysblog.de/windows-update-und-wsus-probleme-durch-dual-scan

Ich, aber erst nach dem Frühstück. Nervt mich, dass ich das jetzt erst deinstallieren muss. https://techcommunity.microsoft.com/t5/exchange-team-blog/re-release-of-august-2023-exchange-server-security-update/ba-p/3900025

Ja genauso leicht wie das Nichtverwenden von hardcoded usernames. ;)

Oder ein zweites Kind. ;) Wobei zeitnah bei MS auch nächster Patchday bedeuten könnte. ;) (Glaube zwar, dass die da rotieren, aber was kann da jetzt so lange dauern? Aber sie haben ja schon zugegeben, dass noch ein Bug im Feature der Settingbackups usw. drin steckt )

Leider nix neues. Auch diverse Formatierungen gehen ja teilweise zwischen den Sprachen verloren, so dass Code auf einmal als Text übersetzt wird usw. usf. Insofern sollte man sich wirklich angewöhnt haben immer _auch_ den englischsprachigen Artikel mal zu überfliegen. Bye Norbert PS: Danke für den Hinweis.

Ach menno noch so eine faq. ;) lösche das Zertifikat und importiere es per Exchange powershell und nicht per mmc (so wie du es jetzt vermutlich getan hast) Du bist dir auch sicher, welche Frage du da mit Ja beantwortest? Da gehts ums Standard smtp Zertifikat. Die beantwortet man nicht automatisch mit ja. ;)

Das ist ja aber auch die entscheidende Frage. Die Mischung ist in meinen Augen nur in wenigen Fällen sinnvoll. Aber das kann man ggf. eben erst in Zusammenarbeit mit dem Kunden entscheiden. ;) Mischung bedeutet wie oben von mehreren erwähnt eben höheren Verwaltungsaufwand hinsichtlich der Lizenzen.

Naja meist hat der Lagerarbeiter dann aber in bestimmten Firmen trotzdem ein Handy mit Postfachanbindung an den exchange. Oder der Busfahrer usw. Usf. Also bleibt meist: nimm das was du weniger hast: wenige User viele Geräte = User cals oder viele User (meist lohnt das nur bei schichtbetrieb) und wenige Geräte = Device cal. Bei letzterem dann aber ggf. Auch für multifunktionsdrucker usw.

Sehe da ms genauso. Userlizenzierung dürfte deutlich einfacher sein. Wenn 100% der Nutzer eine user cal haben, ist die Anzahl der Geräte die sie benutzen egal.

Achso, du meinst die haben keine abuse Abteilung. Hatte ich falsch verstanden.

Warte, ich geb dir noch eine: Was genau ist denn daran kaputt? :p

Ich habs nicht getestet, aber angeblich machen die das: https://letsencrypt.org/docs/revoking/ Und ja EV wird nicht mehr gekennzeichnet (früher "grün"). Stattdessen wir jetzt http als NICHT sicher = rot dargestellt und http/https aus der Leiste per Default auch noch ausgeblendet. ;)

Das Problem wird verschärft durch: 1. in allen modernen Browsern ist die Adressleiste keine Adressleiste sondern eine Seachbar 2. Kunden die lieber erst auf google.de gehen um dann dort dkb.de einzutippen (in die Google Search) Für manche ist da keinerlei Unterschied.

Noch als Hinweis für die, die Exchange Edge Server betreiben (vermutlich nur ich ;)). Dort gibts im Allgemeinen nicht zwingend ein Active Directory und der Nutzer muss deswegen als lokaler Nutzer auf dem Edge angelegt werden. Name 'Network Service' Auch der kann nach dem erfolgreichen Update und der Anpassung in der Registry wieder gelöscht werden. Bye Norbert

Und alles nur weil die Cloud wieder was vorgibt. Ich seh grad: https://support.microsoft.com/de-de/topic/enable-support-for-aes256-cbc-encrypted-content-in-exchange-server-august-2023-su-add63652-ee17-4428-8928-ddc45339f99e

Im IIS ;) https://techcommunity.microsoft.com/t5/exchange-team-blog/released-august-2023-exchange-server-security-updates/ba-p/3892811/page/2#comments Da gibts folgenden Screenshot:

Evtl. wieder die Backend Zertifikatsbindung weg?

Nur wessen? :)

man könnte ja annehmen, dass die Tools für die Erstellung solcher Updates die feste Eingabe von solchen default principals explizit verweigern. Ist ja nicht das erste Mal, dass das zu Problemen geführt hat. Mal davon abgesehen dass in deren Workaround Script die schließende Klammer fehlt. Und andere Rechte gesetzt werden als die, die der Dummy User vom Setup erhält. ;) und man erwarten würde, dass die dann den Dummy User dort wieder entfernen. Boah

Manchmal kann man nur mit dem Kopf schütteln bei solchen Fehlern.

Jetzt gibt es einen workaround für nicht-englischsprachige Systeme. (Wieder mal hardcoded username verwendet, wie es scheint). https://support.microsoft.com/en-us/topic/exchange-server-2019-and-2016-august-2023-security-update-installation-fails-on-non-english-operating-systems-ef38d805-f645-4511-8cc5-cf967e5d5c75

Naja offenbar bei allen nicht englischen Installationen. ;)

Ja, deswegen mein Nachsatz oben. Hab auch noch keine Zeit gefunden das zu testen.