NorbertFe

Ne du klickst auf Vererbung aktivieren. ;) und wenn du nicht weißt, warum der in der Gruppe ist, wär das definitiv rauszufinden.

Korrekt.

Für Standard retention policies braucht man keine Enterprise cals.

Logisch, wenn man das gebraucht kauft.

Schade. :)

Muss ich erstmal suchen. Ist schon ne Weile her. edit: so gefunden. Man muss eine Mail schicken: yes, the documentation says no more than 6, but try it. If it will not allow you, you can contact MSFT Volume Licensing to ask for additional activations to be configured, or, to ask for an additional KMShost product key. Your MSFT agreement administrator (in your company) must approve this request (or be the requester) - MSFT VL support will validate with your agreement admin. If needed you can contact MSFT via email: kmsadd-at-microsoft-dot-com is schon ne Weile her, dass ich das machen musste, aber wird vermutlich immer noch so sein.

Erzähl mehr.

War wohl "kritisch" ;)

Fix scheint bereitzustehen, wenn ich das richtig interpretiere https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0796

Doch wollte man. ;) Und Kanalbündelung erst :p

KMS Keys haben eine begrenzte Anzahl an Aktivierungen (afair 3 oder 5) und danach darf man sich bei MS melden und weiteren Bedarf anmelden. Und wenn das Ding bei "gebrauchter Software" gekauft wurde, weißt du ja, was das ggf. bedeutet. :)

Vielleicht wurde der key zu oft aktiviert, oder stammt aus einem abgelaufenen Vertrag.

Naja technisch gesehen reicht es ja, wenn einer von zu Hause durch seine Fritzbox auf so ein Ding namens UNC Pfad klickt und schon haste einen Client, der ggf. von innen weiterbearbeitet werden kann. Zumindest interpretiere ich das so.

Manchmal sind eben andere Dinge notwendig, als die von Microsoft bereitgestellten. Ja, das soll tatsächlich in der realen Welt vorkommen. ;)

Weil ich in die Cloud wechsle und den lokalen MX behalte (zumindest bei obigem erwähnten Produkt handelt es sich afaik nicht um einen cloudservice, sondern einen on premise MTA), und das ist zwar möglich und von MS auch so beschrieben, aber logischerweise mit dem Hinweis "empfohlen" ist es, direkt bei MS den MX zu haben. https://docs.microsoft.com/de-de/exchange/transport-routing Dass es cloudlösungen gibt, is mir auch klar. Evtl. einen Blick wert: https://www.hornetsecurity.com/de/services/365-total-protection/

naja wenn man sich nen eigenen spamfilter hinbaut, geht vieles. Hat man halt irgendwie nur ne schräge Konfiguration. ;) dafür aber mehr Möglichkeiten.

Ja natürlich kann man sich selber Löcher ins Boot bohren. WEnn man dann noch weiß, warum ists ok.

Der brauch also keine Kennwortrichtlinie? ;) Kannst du ja auch. Gilt dann halt nicht so wie du denkst. Wie wärs denn hiermit? https://www.gruppenrichtlinien.de/artikel/fine-grained-password-policies-fgpp-password-settings-objects-pso/ oder https://www.gruppenrichtlinien.de/artikel/kennwortrichtlinien/ Bye Norbert

Und den kann man nicht anrufen und fragen?

Nein, die cals gelten für alle Server.

Naja das sind bisher aber noch absolute Basics, also kein Grund zu „heulen“. ;)

NUR (nicht eher) für SMTP Server Traffic, wenn wir schon dabei sind.

Kommt auf die Anforderungen hinsichtlich Sicherheit an. Grundsätzlich wär ein Reverse Proxy nicht verkehrt, aber auch allein ist der Exchange jetzt nicht zwingenderweise das größte Risiko, wenn man ihn korrekt konfiguriert. Da das ding ja vor allem von intern erreichbar ist, ist ein Exchange von der Positionierung ähnlich wie ein DC. Den stellst ja auch nicht in die DMZ, bloß weil da ggf. LDAP benötigt wird. Also Option 1. Option 2 kann sinnvoll sein, aber das kann man hier sicher nicht ohne weiteres klären. Option 3 ginge zwar, aber dürfte für vieles ziemlich unpraktisch sein. Option 4.. Schonmal versucht? ;) BE und FE war Exchange 2003!

weniger kompliziert. man installiert die DHCP Rolle und überlegt ob einem die alten Leases wichtig sind oder nicht. je nach Komplexität der vorhandenen DHCP Konfiguration kann man das dann entweder alles ex- und importieren oder man klickt es ggf. schnell von Hand auf dem neuen zusammen.

Dass er es hinterher nicht mehr ist. Wenn er also nicht von vornherein bereit war, das System zu kompromitieren, hat er jetzt weniger Chancen. Abgesehen davon gibts genau dafür ja entsprechende Deploymentrichtlinien und Berechtigungen, dass eben nicht jeder "Honk" einen PC in die Domäne aufnehmen darf. Muss man halt vorher konfigurieren.