NorbertFe

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. ;)

vor 1 Stunde schrieb teletubbieland:

Jetzt, wo das Kind in den Brunnen gefallen ist, kann man ruhig das Seil hinterher werfen

Oder ein zweites Kind. ;)

vor 17 Stunden schrieb Nobbyaushb:

Scott Schnoll hat ein neues SU auf Anfrage angekündigt, das zeitnah kommen soll 

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)

vor 3 Minuten schrieb PeterchenFrost:

Meine Änderung tätigen wollen, dann kam auch die abfrage die Ich mit J beantwortet habe.

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. ;)

vor 13 Minuten schrieb franzjosef:

Da wird nur gefragt wieviele User und wieviele Computer (nicht Geräte)

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.

vor 44 Minuten schrieb zahni:

Wie geschrieben: Ich hatte mal vor längerer Zeit (ok, es war 2018) eine eindeutig "unerwünschte" Webseite dort gemeldet.

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

vor 2 Minuten schrieb NilsK:

PS. wie, Trigger Warning ...?

Warte, ich geb dir noch eine:

Was genau ist denn daran kaputt? :p

vor 3 Minuten schrieb zahni:

Ich hatte mal probiert, dort ein Zertifikat zurückziehen zu lassen. Machen die nicht.

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.

Microsoft hat ein neues SU für Exchange 2016/2019 veröffentlicht.

https://techcommunity.microsoft.com/t5/exchange-team-blog/released-august-2023-exchange-server-security-updates/ba-p/3892811

Habs auch erst gelesen, deswegen kann ich noch nichts zur "Verträglichkeit" sagen.

Bye

Norbert

vor 25 Minuten schrieb ASenna:

Danke. Die Nachfrage nach den Leerstellen hat sich damit erledigt. Thumbprint und Seriennummer haben bei mir keine Leerstellen. Ich hatte vermutet, dass es dort keine Leerstellen geben darf.

Dann hast du Windows Server 2019 oder 2022 ;)

vor 25 Minuten schrieb ASenna:

Das Zertifikat und der private Schlüssel für die Entschlüsselung wurden nicht gefunden.

Da ist dein Problem. Du brauchst den privaten Schlüssel. Und wenn das Zertifikat mit einem neuen CSR erstellt wurde, ist die Frage, wo befindet sich der private key für das neue Zertifikat. ;)

Wenn keine Leerzeichen da sind, dann brauchst du auch nichts löschen. Da du hier nix kaputt machen kannst, sollst du den obigen Befehl ausführen und dort entweder die Seriennummer des NEUEN Zertifikat (oder den Thumbprint) dort einfügst. Dabei wird dann der private key wieder dem Zertifikat zugeordnet.

Bye

Norbert