NorbertFe

Es gibt auf deutsch zwei gleichlautende Richtlinien dazu.

 
Das blöde ist, dass nur eine davon die richtige ist aber beide gleich heißen. Auf englisch wird das deutlicher:
 

Die sind also aktuell nicht gesynct? Falls ja, dann wirst du einen Support Case eröffnen müssen.

Üblichweise Domainvalidiert, denn mal vom Preis abgesehen, kennst du irgendeinen User der den Unterschied sehen würde? ;) Wenn man also nicht aus irgendeinem Grund genötigt wird Org-Validierte Zertifikate nutzen zu müssen -> Domain Validiert.

Einfachster Test in solchen Fällen: Kannst du eine SMTP Session zum Smarthost mit bspw. Telnet erstellen. Falls ja, kann man weiterschauen.

Läuft auf jeden Fall auf aktuell gepatchten Exchange 2016 und 2019. im Zweifel schau mal, es gibt auf der GitHub Seite auch einen manuellen Installationsweg. Aber ich wüsste nicht, dass ich den in letzter Zeit mal gebraucht hätte.
 

klar, gibt auch kostenpflichtige Lösungen. ;)

Was vollkommen normal ist, weil United Domains sicher nicht die IP Adresse gehört, sondern deinem Internet Service Provider (Telekom, Vodafone oder sonst wem). Also musst du Reverse Einträge üblicherweise auch dort ändern. (Ausnahme du hast eine Reverse Zone Delegation erhalten).

In deinem Sendconnector, was steht da im Feld HELO String? Taucht dieser Name auch in deinem TLS Zertifikat für SMTP auf?
 

 
Da sollte nicht nichts drin stehen, wenn dein Host nicht zufälligerweise intern wie extern identisch heißen sollte (was sehr unwahrscheinlich ist).

Wirst du wohl auf den korrekten Header abstellen müssen und nicht nur auf den Empfänger.

Ist denn im Tenant die Verwendung von SendasAlias überhaupt aktiviert? ;)
Get-OrganizationConfig | ft Name, SendFromAliasEnabled  
Ich seh grad, es geht auch per GUI ;)
 

Na dann konvertiere sie doch mal in eine Usermailbox. Den Button sollte die das Admincenter ja anzeigen.
Finde ich nicht verwunderlich, sondern würde das erwarten.

Am Ende ist es wichtig, dass bei allen die Zeit nachvollziehbar gleich ist. Das geht in deinem Szenario am einfachsten, wenn dein PDC Emulator die Zeit von einem externen System zieht. Ob das die Firewall (wenn sie es anbietet) ist oder eine RTC oder einfach ntp.org ist am Ende mehr oder weniger egal. Alle anderen Server, Clients, ESX usw. holen sich dann die Zeit von ALLEN DCs (egal ob 1 oder 2.) ich trage bei Systemen die mit DNS klarkommen dort normalerweise den AD Domain Namen ein, denn dann werden die DCs per round robin aufgelöst. Bei Systemen die keine DNS Auflösung nach intern können oder dürfen musst du halt die notwendigen IP Adressen eintragen und bei Ersatz deiner DCs dran denken.
 
Bye
Norbert

Fragen wir doch mal anders:
 
wo genau siehst du denn zu erwartende Probleme?
 
Mal davon abgesehen, dass ich persönlich Quarantäne nicht einsetzen würde.
 
bye
norbert

https://www.powershellgallery.com/packages/Set-UpnWithMailAddress/3.0/Content/Set-UpnWithMailAddress.ps1
 

Man könnte natürlich auch einfach mal in certlm.msc nachschauen.
https://learn.microsoft.com/de-de/exchange/plan-and-deploy/post-installation-tasks/security-best-practices/exchange-serialization-payload-sign?view=exchserver-2019#november-2023-su
 
 

Für extern eingehende Mails werden die Mails auf dem jeweils letzten mta vor diesem ausgefallenen Server. Wenn’s ausgehende Mails sind, dann bleiben die halt im Client.

Ähnliches Verhalten hab ich schon mit anderen Lösungen und der Deaktivierung von LLMNR gesehen. Liegt dann meist am VPN Gateway, die keine vernünftige Namensauflösung durchbekommen, sondern irgendwelche Workarounds (wie LLMNR) nutzen, damit es irgendwie funktioniert. Ich habs mit Cisco durch.  ;)

Nö, da bei s/mime kein (afaik) timestamping stattfindet wird jede Öffnung der Mail gegen das verwendete Zertifikat durchgeführt. Und das ist dann irgendwann abgelaufen. Das sollte dir die Fehlermeldung in Outlook auch anzeigen. Also nicht Signatur ungültig weil was verändert wurde, sondern wegen Zertifikat abgelaufen.

Dann hat mal jemand vergessen das Zertifikat zu erneuern bzw. zu warten bis es auf allen Exchange Servern angekommen ist.
https://blog.icewolf.ch/archive/2018/03/20/exchange-2016-renew-microsoft-exchange-server-auth-certificate/
 
Hilft dir weiter
 
Bye
Norbert

Man müsste halt lesen was da steht. ;)

Ja, es ist auch empfohlen. Das bedeutet aber nicht, dass wenn keine Probleme auftauchen man Probleme suchen müsste. Wenn du also keine Probleme hast, dann hast du keine Probleme und kannst zur Tagesordnung übergehen.

Das blöde ist, dass Exchange eigentlich immer Umleitung macht, auch wenn sie es Forwarding nennen.

Welchen DNS Server hat der Client?
Achso das Netz klingt stark nach FritzBox. Falls die IPv6 aktiv hat, dann drauf achten, dass du keine Router Advertisments macht. Entweder korrekt konfigurieren, oder komplett ipv6 an der Fritzbox abschalten.

Üblicherweise sind die leer (mit Exchange 2010 kann man sie setzen), weil das autodiscover virtual directory logischerweise keinen Verweis auf den zugriffspunkt braucht, denn dann ist man ja bereits da.
 
das was du brauchst um den Fehler zu beheben ist also nicht set-Clientaccesservice, sondern das e2k10 powershell module. ;)
 
https://support.microsoft.com/en-au/topic/autodiscover-event-id-1-after-installing-exchange-server-2019-cu3-or-exchange-server-2016-cu14-93850e62-4cf4-8a76-5fd4-c8ce6f032015
 
am Ende kannst du den Fehler aber auch einfach ignorieren. ;)
 
bye
norbert

So pauschal? Nö, eher unwahrscheinlich, dass es am Update liegt. Was sagt denn das Eventlog? Oder auch das SMTP Logging?

https://learn.microsoft.com/en-us/exchange/troubleshoot/administration/publicfoldermailboxes-dynamic-distribution-groups
 
Get-DynamicDistributionGroup -IncludeSystemObjects PublicFolderMailboxes* | Remove-DynamicDistributionGroup