NorbertFe

Ich hab da http Links drin. Und ja es ist keine gute Idee den Port bis auf die CA aufzumachen. ;) Kann man mittels Reverse Proxy oder eigenem Webserver bspw. in der DMZ aber trotzdem sinnvoll hinbekommen. LDAP Pfade deaktiviere, damit das nicht in den Zertifikaten auftaucht. Ist eher eine Abwägung pro Kunde/Installation.

Das ginge aber auch ohne ad nicht. ;)

Ja sehr wahrscheinlich. ;)

Kannst ja mal berichten.

Offensichtlich nicht, weil der Irrglaube besteht, dass der Zugriff über die Zugriffsrechte des essentials auch für den standardserver gelten. ;)

Ist bei Dell genauso. Da sind das auch alles acocent Geräte mit Dell Logo.

KMS Keys muß man neuerdings immer explizit per Telefon beantragen. Hierzu werden die Lizenznummer und die Authorisierungs-ID benötigt. Telefonnummer: 08005077777

Die zählen zusammen. Bzw. wenn auch Clients aktiviert werden, dann kannst du eine beliebige Mischung von Clients und Servern nutzen, um auf den Aktivierungszähler 25 zu kommen.

Nein muss er nicht. Der 2012R2 kann offiziell zumindest nach Update auch Windows Server 2019 aktivieren. https://docs.microsoft.com/de-de/windows-server/get-started-19/activation-19 Installations of KMS on Windows 8.1 or Windows Server 2012 R2 must be updated in order to support activation of clients running Windows 10 and Windows Server 2016 or Windows Server 2019, or newer client or server operating systems. For more information, see July 2016 update rollup for Windows 8.1 and Windows Server 2012 R2.

Technisch klar, aber dann hast du eben keine sinnvolle testmethode, weil man die ddp nicht filtert.

Ein KVM per https wäre genau die Lösung. ;) Gibts doch genügend Hersteller die sowas anbieten.

Ich glaube wir meinen alle das Gleiche. Es bleibt halt dabei, dass "kein" Organigramm die Vorlage sein sollte, sondern die Anforderungen definieren die OU Struktur. Dabei kann durchaus auch ein Organigramm-ähnliches Konstrukt rauskommen, meist ist das aber weder notwendig noch wirklich hilfreich.

Ihr habt Computer im Organigramm? ;)

Na dann kann er sich ja was aussuchen.

Nimm doch einfach nen KVM mit Netzwerk. ;)

Deswegen packt man sowas ja auch nicht in die Default Domain Policy.

Klar kann er das. Seit Exchange 2013 geht auch mal zur höheren Version ein Zugriff.

Korrekt.

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.