NorbertFe

Irgendwie werde ich nicht mehr verstehen, warum man sowas will, wenn eigentlich inzwischen jeder mal die Fehler und Komplikationen gesehen haben dürfte. Man könnte den- oder Diejenige ja auch einfach einladen. Dann braucht’s auch keine kalenderberechtigungen.

Das Gerücht hält sich hartnäckig. Das ist die Empfehlung keine Anforderung.

Das Ergebnis solch eines support case ist aber kein anderes als bei 2019 oder 2016. ne Menge verbrauchte Zeit mit wenig greifbaren/messbaren Werte . ;)

Nö, beides im Extended Support bis 2023.

alles klar. Beim nächsten Mal einfach Fehlermeldung auch mal in google eingeben ;)

Nur wenn er auch als DC hochgestuft wurde. ;)

https://practical365.com/exchange-server/exchange-2013-the-internal-transport-certificate-cannot-be-removed/

Die Frage war, "Sicher, dass die Synchronisation auch funktioniert?". :)

Sicher? Erscheint mir irgendwie unlogisch, dass ein Domainjoin kein Konto erzeugt.

ja kannst du. Evtl. Fehler kannst du dann ja hier posten.

Wieviele DCs habt ihr denn?

Machs nochmal weg und binde es direkt über die Powershell mittels import-exchangecertificate ein oder über die EMC/EAC.

Na dann entweder eine löschen oder ändern ;)

Unabhängig von deinem Problem, würde ich darauf verzichten, die Antispam-Agents auf einem Mailboxserver zu verwenden. Da sind einfach inzwischen zuviele Probleme bekannt, als dass man das verwenden wollte. :)

Deine Fehlermeldung sagt aber was anderes. Aber sei's drum. Wie wurde das neue Zertifikat importiert? Über die MMC oder in der EMC/EMS? Bye Norbert

https://www.frankysweb.de/exchange-2016-backend-zertifikat-neu-erstellen/ Ist bei 2013 mehr oder weniger identisch.

Ich versteh es auch nicht komplett, aber evtl. Hilft ja sowas: https://directaccess.richardhicks.com/2018/11/27/always-on-vpn-and-windows-server-2019-nps-bug/ da gibts im rechnet Forum auch noch einen längeren thread, der am Ende den selben workaround bietet. Da der Fehler bei 2019 von Anfang an besteht, würde ich bei w10 nicht unbedingt auf Besserung hoffen. bye norbert

Dann werden die wohl Recht haben. ;) Schonmal geschaut, welche Adresse das sein könnte? Evtl. hilft so ein Skript (Beispiele) https://goodworkaround.com/2014/02/05/powershell-script-to-find-duplicate-proxyaddresses/ https://gallery.technet.microsoft.com/scriptcenter/Find-Duplicate-Values-in-6b012059#content

unerbetene eingehende Meldungen wird vermutlich eh nicht mehr funktionieren. Das war afair für den Windows Nachrichtendienst gedacht. https://de.wikipedia.org/wiki/Nachrichtendienst_(Windows) das geht aber auch seit Windows 7 schon nicht mehr. ;)

Und was ist jetzt das dubiose? Dass die Firewall konfiguriert ist?

für die angegebenen Nutzerzahlen sollte das problemlos ausreichen, wenn der dc nur dc ist.

Gib’s doch mal in Google ein ;)

Aber es klingt so l33t

Vermutlich, da ich nicht davon ausgehe, dass du das hier umgesetzt hast.

Ja aber nur global afair. Ich vermute die Erwartung ist, dass nur von in der eigenen gal enthaltenen Usern die tips einsehbar sind. ich wüsste aber spontan auch nichts dazu.