NorbertFe

Warum müssen die das nur so umständlich machen. :) Bei Kemp per GUI keine 5 Minuten. Bei Citrix per GUI regelmässig "Müll" und per cli ca. 30 Minuten. :/

Aber nicht vom Exchange. ;) Wie hast du es importiert? Per Exchange Powershell? Meist liegts daran, dass man "nicht-Exchange-Mittel" verwendet hat.

Das ist _nicht_ das Standard Zertifikat für Exchange. Das heißt normalerweise/standardmäßig "Microsoft Exchange". ;) Hängt davon ab. Wird dir den TLS angeboten, bzw. kommt eine entsprechende Verbindung zustande? checktls.com kann weiterhelfen.

Das ist auch nicht schlimm. Der nimmt einfach das, was für SMTP enabled wurde _und_ den passenden Namen im CN/SAN hat. Das kann Vorteile bringen, wenn man explizit ein bestimmtes Zertifikat nutzen will/muss. Bspw. wenn DANE im Einsatz ist.

Dann gib mal Bescheid, wenn du es eruiert hast, damit der Thread hier nicht erodiert. ;)

Doch. Und die genauere Erklärung siehe unten. Deine Filter überschneiden sich. Sinnvoller wäre vermutlich auf ein Attribut zu filtern, welches einen Techniker eindeutig identifiziert und das nicht ein Teil des DN ist. ;)

Wie Nils schon schrub, ist das nicht möglich im AD.

Was deutlich angenehmer ist/war. ;)

Wobei das Argument der Interoperabilität ja jeder bringen kann, um sich nicht zu verändern. ;) An der Stelle würde ich von SAP eben auch erwarten, dass sie zwar drauf hinweisen, aber die Empfehlung sollte ja trotzdem lauten die höchstmögliche Sicherheit umzusetzen. Was dann eben bedeutet, dass die interoperablen Systeme sich mitändern müssen. :)

Sehe ich auch so. Von TLS 1.2 steht ja nix drin.

Wenn die Lizenz aber durch Lizenzgründe mit win10 teurer wird, sind die Kostengründe ja eher für Server. ;)

Dann solltest du ihnen sagen, sie sollen bei extensiv bleiben, wegen Gründen siehe Nils' Antwort. :)

Na dann ist ja nicht so schlimm. Echtes Problem wäre, wenn er es exzessiv oder intensiv nutzen würde. ;)

Stimmt Wolfpack war zumindest deutlich instabiler und genauso schlecht dokumentiert. ;)

Und das muss unbedingt ein Windows 10 sein? Tuts nicht ein Windows Server 2016/2019? Wär lizenztechnisch definitiv einfacher.

Mit dem KMS vom 2022 DC bspw. also zumindest wenn die alle in einem entsprechenden Netzwerk hängen. Und einen Berater der mir sowas wie oben erzählt, würd ich komisch anschauen und fragen, wo das steht. :) Bye Norbert

Alles andere was ich kenne, würde nicht billiger. ;)

Wär bei O365 direkt sowas hier möglich: https://learn.microsoft.com/de-de/microsoft-365/compliance/ome?view=o365-worldwide

standardmäßig auf jeden Fall übers I-net. Kann man per Policy abdrehen, damit nicht ständig Anfragen an der Firewall ankommen. Da könnte man dann aber sehen, wo die Kisten hinwollen. Lt. obigem Link muss das dann ja http://ctldl.windowsupdate.com sein.

Die Empfehlung lt. Security Guide ist sowieso den Store komplett zu leeren und nur die reinzunehmen, von denen man weiß, dass man sie benötigt. ;) Alternativ schau mal, ob das auch noch für 2016 aufwärts gilt. Ich habs nicht getestet: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn265983(v=ws.11)

Du könntest dir natürlich auch die notwendigen Zertifikate selbst verteilen. :) Dann hast du komplette Kontrolle.

Häh? Sbs?

Die kms Schlüssel ändern nix an irgendwelchen Versionen. Die aktivieren alle Versionen für die sie vorgesehen sind. Also kms win10 aktiviert Client os ab Vista Aufwärts (egal ob, pro, Business, Enterprise) und kms Server 2019 aktiviert alles was Client und Server ab Vista aufwärts ist. Und welche Dinge sind das? Ja.

Full Access vergibt man sinnvollerweise weder auf Share noch auf ntfs Ebene für Nutzer. ;) auch wenn das hier alles eher nach „Ausprobieren“ klingt.

Nimm ihm die Rechte auf ntfs doch mal weg. Dann siehst du was er in der Freigabe machen kann. Nämlich nix. zu deinem Problem. Welche Rechte gibts denn auf ntfs Ebene?