NorbertFe

Wenn man weiß, warum das auftritt, kann man durch "zügiges" Arbeiten viele der Meldungen abfangen, aber eben meist nicht alle.

Ja logisch. Interessant war ja auch nicht welche ClientAccessservices du hast, sondern was im oben erwähnten autodiscoverserviceinternalURI steht. Wenn dort überall exchange.domain.de drin steht, dann is ja gut, und dann wird sich der Client irgendwann auch beruhigen. Ist halt immer das Problem bei Neuinstallationen, dass der Server erstmal mit einem falschen Wert installiert wird und man das danach grade ziehen muss.

Im Zweifel sind beide falsch, aber wenn deine Clients Exchange2013 eben akzeptieren, solltest du den erstmal weiternutzen. Ansonsten hilft es, sich mal drüber schlau zu machen, wie Autodiscover funktioniert. :) Du sollst schauen, was unter autodiscoverserviceinternalURI steht. :) Und da steht drin, was die Clients versuchen zu erreichen.

Hast du den Exchange einfach mit Setup weiter enter enter installiert, oder hast du dazu ein How To verwendet?

Na dann hast du doch den Fehler schon gefunden. Zumindest den SCP (set-clientaccessservice) solltest du erstmal auf den bereits existierenden Server setzen. Bye Norbert

Das hilft dir in diesem Falle NUR, wenn die gefakten Absender auch DMARC für ihre Domain konfiguriert haben. Dann würden diese Mails nämlich anhand der DMARC Richtlinie rejected oder in Quarantäne geschoben werden. Ich bevorzuge ersteres. Hatte den selben Fall wie du am Anfang der Woche, und mein Kunde hat DMARC konfiguriert, aber leider setzen viele Empfänger die DMARC Policy offensichtlich aus was auch immer für Gründen nicht um, so dass sie die gefakten Mails dann mit dem Vermerkt "Spamverdacht" oder ähnlichem bis zu deren Empfängern durchgelassen haben. Die stellen dann natürlich meinem Kunden die Frage, warum sie sowas denn bekommen. Und nein, mein Kunde ist NICHT gehackt worden, sondern das waren Mails, die er vor "Wochen" mal an Kunden geschickt hatte. Also ist nicht nachvollziehbar, wo die Daten abgeflossen sind. Kann nämlich auch bei anderen Kommunikationsteilnehmern geschehen sein. Ich empfehle jedem Mailadmin usw. sich mit DMARC, DKIM (und SPF sowieso) zu beschäftigen. Das wird in Zeiten von Phishing immer wichtiger und ist keine Raketentechnik. Im Zweifel fragt man jemanden der sich auskennt. ;) Bye Norbert Der zeigt meiner Erfahrung nach Tagen schon keine Wirkung mehr, und bei Mailkommunikation die mehrfach hin- und hergeht, hat der Nutzer dann das Problem, dass dann mehrfach im Betreff dieser Kram auftaucht. ist wie 1, und sorgt nur für zertorfte Mailbodies, die dann auch keiner mehr sinnvoll lesen kann/will. S/Mime hast du schon angesprochen, man macht sich also das kaputt, was als einziges eindeutig beweisen kann, dass die Mail korrekt vom Absender käme. ;) Nr. 3 ist wichtig, darf aber nicht zu häufig stattfinden, weil das die Nutzer "belästigt", und das wollen die ja nicht. Im Zweifel hilft die Info an alle, dass sie lieber einmal zuviel fragen als einmal zu wenig. Geht natürlich nicht bei jedem Kunden. Bye Norbert

OK, danke. null ist aber kürzer ;)

Nie mit $blank versucht. Akzeptiert das die Exchange Powershell wirklich?

Also entweder hat man es für alle im Zugriff befindlichen konfiguriert oder auf keinem. Denn bei Mischkonfig gibts auf jeden Fall Probleme. Schau doch mal mit dem Healthchecker Skript nach. Wär ja dann mal ne Option das korrekt und sicher zu konfigurieren. Alternativ, installier doch erstmal den neuen Patch von November, bevor hier zuviel Aufwand betrieben wird. Bye Norbert

Aber auch erst, nachdem ihr die Extended Protection aktiviert habt, oder? Und wenn, dann hilft es vermutlich, einfach mal erstmal wieder zu deaktivieren. Für alles andere wären mehr Infos notwendig. Wenn meine Vermutung oben stimmt, dann helfen vermutlich beide Varianten nix. Da muss man schon die Ursache finden in eurem System.

Ja. Wie kam die Zone denn da ursprünglich hin?

Der ist ja auch nicht als AD Integriert konfiguriert. Also musst du schon selbst dafür sorgen, dass da ein Zonentransfer stattfindet. Bye Norbert

Schau halt bei Dell nach, welche CPUs dieser Server unterstützt. https://www.dell.com/support/manuals/de-de/poweredge-r230/r230_om/processor-specifications?guid=guid-e4943b56-488d-4e96-ba66-05b06fee8793&lang=en-us Wenn einer der oben genannten dabei ist, wirds vermutlich problemlos funktionieren.

Ja kann man. Is aber egal, weils standardmässig "deaktiviert" ist. Wenn du es aktivierst, wirst du je nach Kennwortrichtlinie eben ein Kennwort vergeben müssen. Dein obiges Kennwort entspricht nicht der Richtlinie, weswegen deine Konvertierung auch fehlschlägt.

Kannst ja mal testen, ob du damit andere Ergebnisse bekommst: https://www.frankysweb.de/neue-version-des-exchange-zertifikatsassistent-fuer-lets-encrypt/

Und welcher Prozess holt das Lets encrypt Zertifikat bei dir?

Und stehen denn Ereignisse im Log? Ansonsten als Hinweis "/force" benötigt man im Allgemeinen selten bis nie. Wie du siehst, bekommt man stattdessen auf einmal Dinge zu Gesicht, die man ohne gar nicht wahrnehmen würde. ;)

Mit Nachvollziehbar meinte ich eigentlich: Es ist ziemlich unmöglich zu sagen, wann ein User Mitglied eines dynamischen Verteilers war und wann nicht. ;)

Ach hör mir doch mit so neumodischem SchnickSchnack auf. ;)

Dynamische Gruppen sind meiner Erfahrung nach selten eine gute Idee. Klingt anfangs immer toll, aber am Ende ist es meist weniger flexibel als man vorher denkt und vor allem später nicht wirklich nachvollziehbar. :)

Moin, MS hat updates veröffentlicht: https://techcommunity.microsoft.com/t5/exchange-team-blog/released-november-2022-exchange-server-security-updates/ba-p/3669045 bye norbert

Warum müssen die das nur so umständlich machen. :) Bei Kemp per GUI keine 5 Minuten. Bei Citrix per GUI regelmässig "Müll" und per cli ca. 30 Minuten. :/

Aber nicht vom Exchange. ;) Wie hast du es importiert? Per Exchange Powershell? Meist liegts daran, dass man "nicht-Exchange-Mittel" verwendet hat.

Das ist _nicht_ das Standard Zertifikat für Exchange. Das heißt normalerweise/standardmäßig "Microsoft Exchange". ;) Hängt davon ab. Wird dir den TLS angeboten, bzw. kommt eine entsprechende Verbindung zustande? checktls.com kann weiterhelfen.

Das ist auch nicht schlimm. Der nimmt einfach das, was für SMTP enabled wurde _und_ den passenden Namen im CN/SAN hat. Das kann Vorteile bringen, wenn man explizit ein bestimmtes Zertifikat nutzen will/muss. Bspw. wenn DANE im Einsatz ist.