NorbertFe

Wenn ich das nur glauben könnte. ;)

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

Zitat

SMTP and the associated management tools are deprecated. Though the functionality is still available in Windows Server 2012, ...

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. :/

vor 1 Minute schrieb passt:

Jetzt hat der Server aber das Update wieder heruntergeladen und stellt es zur Installation bereit.

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

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