NorbertFe

Sieht man das als nicht Admin überhaupt? Und falls nein, will man jemanden der damit grundsätzlich nix zu tun haben will Admin rechte geben?

Siehste, machs nicht so kompliziert ;) geht einfach out of the box.

Steht das so im eventlog?

Das musst und solltest du da aber nicht auswählen. ;) steht was zum oabgen im eventlog? Ggf. Das diagnostic logging mal hochdrehen.

Warum gibts da überhaupt zwei OABs? Die Dinger heißen 2013 (auch wenn man 2016 oder 2019 installiert), weil die Technologie eine andere war als das vorher in Exchange 2010. ;)

Wie auch immer das läuft. Was kann denn ionos so toll, dass man da seinen mx hin setzt? abgesehen davon werden voicemails (wenn man die denn nutzt) bspw. Direkt von ms aus versendet.

Du kannst ja die freiwillige Basis belassen, nur muss man dann auch ein „konsequenzdatum“ setzen. ;)

Und? Was sagt dir das? Meine Variante wäre besser? ;)

Bleibt ja die Frage, welche Systeme jetzt keine Mails mehr ausliefern können (ohne spf) ;)

Wie gesagt, oben steht ein Weg, der relativ easy geht. Man definiert eine kurze Zeitspanne und informiert gleichzeitig die Nutzer, dass sie jetzt aber spätestens in 10 Tagen ihr Kennwort ändern müssen. Alle die vor Ablauf der 10 Tage ihr Kennwort ändern, haben am 11 Tag dann ein Kennwort, welches solange gilt, wie der Wert den man dann einträgt. Eigentlich ganz einfach, aber manche wollen es halt umständlich. ;) Man kanns nicht allen Recht machen.

Hmm, na wenn du meinst. :)

Und am Exchange melden sich die User nicht an? ;) Du wirst das so nicht gelöst bekommen. Normalerweise setzt man einfach sowas am Feierabend, oder eben für alle gleich. Und zwar, indem man die Policy mal auf 10 Tage setzt und dann bei allen Usern den Haken setzt, übernimmt und dann wieder entfernt. Damit haben ALLE User dann ein nagelneues (altes) Kennwort, welches genau 10 Tage lang gilt. nach den 10 Tagen setzt man den Wert der Laufzeit auf den gewünschten Wert und schon sind alle glücklich. ;) Bye Norbert

Nochmal fürs Protokoll ;) Ohne weitere Fehlermeldungen kannst du zwar stochern wie du willst, wirst aber vermutlich den eigentlichen Grund nicht finden. Gibt's aktuell überhaupt ein Problem, oder interessiert dich nur die obige Meldung?

Ja man erhält dann andere keys.

Natürlich kann man das. https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-client-access-license#rds-cal-version-compatibility

Und wie ist die maximale Anzahl der Empfänger konfiguriert? https://learn.microsoft.com/en-us/exchange/mail-flow/message-size-limits?view=exchserver-2019 mehr oder weniger als das?

Und dann? Was willst du mit dem Ticket erreichen?

Tja ob der notwendig ist, wäre zu klären. Wenn du azure ad sync hättest, wäre das definitiv nicht notwendig, da man dann per Exchange Hybrid centralized mailtransport konfigurieren könntest. Siehe oben, aadc wäre eine Möglichkeit mit Vorteilen, aber auch mit mehr Komplexität.

Unwahrscheinlich und ohne genaue Fehlermeldung kann man nicht mehr sagen. Die Meldung die du oben gepostet hast ist jedenfalls eine von deinem lokalen Exchange und keine smtp Fehlermeldung. Also spricht wenig für den Empfänger. Zumindest mit den vorliegenden Infos.

Nein am Absender liegt das nicht. Mehr kann man mit den paar Infos nicht sagen. Kannst du den Empfänger denn manuell erreichen? Funktionieren andere Empfänger?

Wer sprach vom demote des 1.DCs?

Du hast nen komischen Wald, aber bitte. Jeder wie er mag. Ich wünsch dir jedenfalls noch viel Erfolg.

Dann nimm win2022 als workaround. :p

Siehst, die kommen aufgrund der ganzen Anfragen zu nix mehr.

Die richtigen Begriffe zu verwenden ist nie verkehrt, auch wenn’s bei dir jetzt nicht geholfen hat. viel Erfolg noch norbert