NorbertFe

Sehr wahrscheinlich gar keine. Denn wenn das Auswirkungen in deiner Umgebung produziert, heißt es, dass da noch ziemlich alte Systeme beteiligt sind. Und die würdest du ja sicherlich kennen, oder? ;)

Ok es gibt eine Umgebung 😉

Tjo, ich weiß schon was du meinst, aber leider sind die Securitygötter immer die, auf die man am wenigsten hören möchte. Ich persönlich hab auch kein Problem damit, die 120 Tage weiterhin beizubehalten und nur die Länge zu erhöhen :)

Natürlich nicht. ;) Und ich bezweifle auch, dass es schon praxisrelevante Anzahlen von Umgebungen ohne NTLM gibt. ;)

Wir sind aktuell bei 14 Zeichen Länge und 10 History sowie 120 Tage maximales Kennwortalter und aktivierte Komplexität. Wir überlegen gerade, ob wir von den 120 Tagen hochgehen auf 365 und dafür 16 Zeichen erzwingen.

Den Default auf die schwächste Richtlinie (also bspw. 12 Zeichen x History usw.) wie bisher konfigurieren. Für alle die davon abweichende (schärfere) Richtlinien benötigen gibt es PSOs.

Dann ist der User offenbar mal aus dem Sync gefallen (oder genommen worden). Sonst wär er ja lokal auch gelöscht. Heißt irgendwo hat jemand das lokale ad Objekt so modifiziert, dass es nicht mehr synchronisiert wird und damit ist es im azure als gelöscht markiert. Jetzt musst du nur noch rausfinden, wie eure Sync rules sind und warum der User da nicht mehr matcht. Danach dann synchen und ggf. wieder die passende Lizenz zuweisen.

Es geht konkret um modern auch für active Sync. ;)

Das sollte man aber mal ändern ;) und sauber konfigurieren. Aber wie siehts jetzt mit tls 1.2 aus?

Und was steht im ehlo String? Und das was da steht, steht das auch im Zertifikat?

Nichts hält länger als das Provisorium. Ein Jahr nach Ankündigung des Produkts soll’s immer noch dauern? ;)

Ach ich lass mich da überraschen. Und wenn man sieht, was für Ausnahmen wieder für die ecc Zertifikate gelten, so is das dann vermutlich auch wieder mit dem anderen Thema. Auf dem Papier erfüllt in der Praxis eher so: najaaaa

Eigentlich nur, wenn dort explizit ein bestimmtes tls Zertifikat gebunden ist. Schau mal nach.

Naja bis cu2 würd ich da mal nix erwarten. 😑

Für die SA Inhaber der Exchange Admins sollte es keine zu großen Veränderungen geben. https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-server-roadmap-update/bc-p/4136089/highlight/true#M39043

Na dann get-exchangecertificate :p achne das ging ja nicht in diesem Fall 😂

Fürs nächste mal einfach certlm.msc ;) viel schneller.

Weil die bösen Angriffe ja alle nur von außen kommen. ;) Aber am Ende eh egal, so wie viele schon jetzt ihre Exchange Server nicht gepatcht haben, wird das auch niemanden stören.

Danke für die Rückmeldung.

Tjo, hat alles Vor- und Nachteile. ;) so wie es jetzt bei dir ist, kannst du technisch das ad jederzeit wegwerfen. Wenn du es aber weiterhin benötigst hast du mehr Arbeit und vor allem doppelte User.

Ja, sonst können es ja nur maximal 2 gleichzeitig. Und das sind rds cals. Die Windows cals brauchst du ja sowieso.

Wenn du aadc einsetzt ist das lokale ad das führende System und Einstellungen die Exchange betreffen können dann nur noch im ad konfiguriert werden. Also bspw: Emailadressen, sichtbar im Adressbuch im exo wird eine Änderung dann nicht mehr möglich sein. Das war bis vor kurzem auch der Grund, warum man zwingend einen lokalen Exchange benötigte (ja ich weiß, es ging auch immer schon ohne).

Alternativ eben mal für den einen User eine andere Lizenz erwerben. Oder sind die Daten nicht so wichtig? 😂ich weiß, das hilft dir nicht weiter.

Ja und? Exportieren wird ja auch nicht grad nur 2 Minuten gedauert haben. Danach hättest du also das Postfach (Archiv) einfach mal aufräumen können. So dass 50gb rauskommen (oder wo ist das Limit für das onboarding?).

Wär’s nicht einfacher das Archiv einfach zu verkleinern anstatt zu deaktivieren?