NorbertFe

Er war überflüssig. Denn anonym war vorher schon erlaubt. Also wäre die Frage, warum es nicht funktioniert hat.

Und was ist an der Schemaerweiterung so fürchterlich?

Den default connector sollte man nicht anpassen. Dann lieber einen eigenen bauen. Aber bei deinem Vorgehen ist das wahrscheinlich auch schon egal.

Ja das haben wir dir gesagt. Der interessante Teil ist, ob anonym erlaubt ist und das wäre per default so.

2019 nimmt per default Mails auf Port 25 aus dem Internet (anonym) an. Oder setzt ihr popconnector ein?

Du suchst s/mime und wie das geht findest du per Google bestimmt raus. ;)

Gibt leider jede Menge Shops und Newsletter, die solche Adressen nicht akzeptieren. ;)

"for a while" ist aber sehr freundlich ausgedrückt. Wollte ja auch nur mal was dazu schreiben. ;) Falls du plus addressing jetzt schon nutzen möchtest: https://www.exclaimer.de/address-tagging-for-exchange/

Ich würde behaupten, dass seit Exchange 5.x genau dieses Feature von allen Admins usw. gefordert wurde (war ja sogar schonmal in irgendeiner Beta von 2007 oder 2010 enthalten/angekündigt). Und jetzt so tun, als hätte das vorher nie jemand gebraucht und erst durch die Cloud hätten sie den Bedarf bemerkt. Das ist so "marketing-sprech" ;) Das mit dem Plus-Addressing klingt auch ganz nett, denn das geht on-prem derzeit nur mit 3rd Party (und die hat auch noch ihre Probleme). Dabei ist immer interessant, wie man das spamtechnisch im Griff behalten kann/will.

Ist aber vollkommen unerheblich, weil der Exchangeserver sowieso Windows CALs benötigen wird.

Doch genau das steht ja da.

Und hast im Fall der Fälle Datenverlust. Genau deswegen ist es seitens ms auch weiterhin unsupported.

Und zufrieden? :)

Du machst dir meiner Meinung nach Gedanken über die falschen Probleme. ;) Üblicherweise geht so eine Datei "nicht einfach" so kaputt und selbst wenn, kann man die dann eben aus dem Backup zurückholen. Wenn du nicht weißt welche, weißt du ja auch nicht, was der Lösungsweg ist. Also viele Gedanken um umgelegte Eier in meinen Augen. Im Worst Case fährt man mit /recoverserver sowieso am schnellsten.

Davon gehe ich auch aus. Und auch, dass jemand der heute noch einen SBS virtualisiert weiterbetreiben will/muss, darauf wahrscheinlich keinen Wert legt. ;)

Ich kenn ja deine User nicht, aber die meisten die ich kenne, interessieren sich für Firewall-Erklärungen eher null bis gar nicht. ;)

Liest sich für mich so, oder interpretiere ich das falsch?

Und bei msi musste man Font Dateien auch explizit aktivieren. Einfacher gehts evtl. So: https://www.gruppenrichtlinien.de/artikel/fonts-schriftarten-verteilen/

Den Rdp Port ins Internet zu öffnen ist keine gute Idee. ;) auch nicht per nat. VPN is da die bessere Wahl.

b***d nur, dass der Gast auch 2016/2019 ausführen muss. ;) https://docs.microsoft.com/de-de/virtualization/hyper-v-on-windows/user-guide/nested-virtualization

Wenn Kollegen wissen, was ein unc Pfad ist, brauchen sie ja erst recht keine netzwerkumgebung. ;)

Na da wo man sich im Browser immer die Zertifikate anzeigen lassen kann. Welchen Browser du nutzt, hast du ja nicht verraten.

Dann wunder noch ein bisschen Lebenszeit weg, bevor du manche Dinge akzeptierst. ;)

Genau. Durfte ich mir neulich beim Kunden und seinem beauftragten DSB erst anhören. Backup ist kein Archiv.

Du willst ja nicht glauben, dass es bessere Produkte für solche Spezialfälle gibt. https://www.exclaimer.de/auto-responder/ Über technische Sinnhaftigkeit spreche ich hier explizit nicht, das mußt du selbst abwägen. Bye Norbert