NorbertFe

Ja, warum nicht? Und was hat das mit "Forest" zu tun? Bye Norbert

Dann braucht er auch Windows 2019 CALs für alle Leute die auf den Exchange (denn der läuft ja auf Windows 2019) zugreifen. Gelddruckmaschine ;) Das ist auch falsch. Frag die Consultants doch mal, warum der Zugriff auf Exchange 2019/Windows 2019 mit einer 2016er CAL abgedeckt sein sollte. WEnn er 2008er CALs und einen 2008R2 DC hätte wär das ja sonst genauso. ;)

sag ich ja. Und das Zertifikat generiert der WPP auch für einen. 10 Jahre Laufzeit glaub ich.

Jupp, die zu verteilenden Pakete müssen ja signiert werden. TLS für den Zugriff auf den WSUS kann und sollte man natürlich auch konfigurieren. Für interne TLS Verbindungen ist eine eigene CA (welchen Ausmaßes) auch immer schon nicht verkehrt. Für Codesigning finde ich sie im Allgemeinen überzogen. Da ists einfacher sich ein Codesigning Zertifikat zu kaufen. Habs aber nie probiert, ob das mit dem WSUS dann auch funktioniert. Bye Norbert

Ja ein Codesigning Zertifikat. und da das wahrscheinlich eh nur für Domain Member relevant ist, wäre das auch einfacher per Selfsigned Cert zu regeln, welches du in dem Fall per GPO verteilen kannst. Ein von der CA ausgestelltes Zert bringt dir wenige Vorteile in diesem Fall, weil leider keine mir bekannte Timestamping Funktion für Codesigning Zertifikaten vorhanden ist.

https://www.thomas-krenn.com/de/wiki/Windows_Server_2019_Editionsunterschiede#Hardwaremindestanforderungen_f.C3.BCr_Windows_Server_2019 wenn das dort richtig beschrieben steht, dann wird nach CPUs (Max. 2) lizenziert und nicht nach Cores. Also in Physik ist das dann egal wieviele Cores deine zwei CPUs haben. In virtuell wird’s evtl. eng. ;) außerdem kannst du mit essentials nicht virtualisieren.

Weil darüber die antragsprüfung von lets encrypt läuft.

Dann habt ihr es bisher nicht bemerkt oder immer drüber weggesehen. ;) https://www.frankysweb.de/exchange-migration-sonderfall-pst-migration-550-5-1-1/ Hilft evtl. Bye Norbert PS: PST Export/Import ist Mist in fast allen Fällen. ;)

Nein. Das was du suchst nennt sich POPConnector und sowas will man nicht. LAß dir doch die Mails von den anderen Providern einfach weiterleiten. ;)

Viel Spaß. Warum macht man das so? Die Probleme sind alle vorhersehbar (gerade was Termine und Besprechungen angeht). Evtl. kannst du mittels x500 Adresse noch was retten, aber ich habe da so meine Zweifel. Den Hinweise bzw. AppPool kannst du ignorieren, der dürfte null Auswirkungen in deinem Fall haben. Bye Norbert

Wie wurde denn migriert?

https://help.mailstore.com/de/server/Verwendung_von_Lets_Encrypt_Zertifikaten

Ja logisch ist ja eine User Regel. Deswegen schrieb ich ja OWA und nicht ECP.

Das schaltet den Fehler aber auch nicht aus ;) zumindest wenn ich der Description glaube.

Kommt drauf an. Dazu erzähl ich dir demnächst mal was ;)

Hmm... was soll ich jetzt dazu sagen? ;)

Stimmt. Und bei mir gehts auch per OWA 2016

Ich denke es handelt sich um eine client Regel in Outlook, und die konnte man auch noch nie per OWA ansprechen (ausser löschen) ;)

Wir reden also von "Outlook Regeln" und nicht von Transport Rules, oder? Dürfte sich also bei deinem Fall da oben um eine clientseitige Regel handeln, denn Unterordner konnte man afair noch nie Transport Rule ansprechen.

Zeig mal bitte die Regel in 2010.

Ja hast du. Hab ich übersehen.

Dann brauchst du sogar noch RDS CALs. :)

Naja /ecp lässt sich ja einschränken. Geht halt mit Reverse Proxy nur einfacher. ;)

https://blogs.technet.microsoft.com/rmilne/2013/07/29/exchange-and-hyper-v-replica-support/ In short, Exchange does not support the Hyper-V Replica feature. Exchange has a long history of supporting virtualisation from Exchange 2003 onwards. It is fully supported to install Exchange 2007, 2010 or 2013 as a virtual machine on Hyper-V, but using the Hyper-V replica feature is not supported. und ja das gilt auch für 2016 und 2019

Und dahinter dann 1 exchange:p