NilsK

Moin, Du verwendest anscheinend die Begriffe nicht korrekt. Leider lässt sich nicht verstehen, was deine Frage ist. Gruß, Nils

Moin, Möglicherweise hattest du auch noch nicht bedacht, dass du für einen 2019-Server auch 2019-CALs brauchst. Wenn du jetzt feststellst, dass es auch mit 2012 R2 geht, dann hättest du ja vielleicht eine Menge Geld umsonst ausgegeben. Gruß, Nils PS: in einem RZ installiert man selbstverständlich neu. Dort packt man aber auch nicht mehrere Funktionen auf denselben Server.

Moin, ich würde sowas auch nie per Cloning machen. Neuinstallation ist schnell und risikolos. Die wenigen Parameter, die man in Hyper-V dann noch setzen muss, kann man vorher dokumentieren - mit diesem Skript eine Sache von Minuten. https://gallery.technet.microsoft.com/Get-HyperVInventory-Create-2c368c50 Gruß, Nils

Moin, ob du die CA noch brauchst, kannst du recht einfach feststellen, indem du dir ansiehst, ob sie Zertifikate ausgestellt hat, die noch gültig sind. Wenn ja, schaust du dir die Systeme an, auf denen diese verwendet werden. Solltest du feststellen, dass du noch eine CA brauchst, musst du die alte aber auch nicht migrieren. In den meisten Fällen ist dann der bessere Weg, eine neue PKI ordentlich (!) aufzusetzen und die verwendeten Zertifikate gegen neue von der neuen CA auszutauschen. Oft wird nur migriert, weil man es kann, und dann hat man eine unnötig schlecht eingerichtete PKI. Gruß, Nils

Moin, wenn du gar nicht in der PowerShell unterwegs bist, würde ich das mit adfind.exe auf der Kommandozeile lösen. http://joeware.net/freetools/tools/adfind/index.htm Gruß, Nils

Moin, stell es dir vor wie bei einem Webserver und dessen TLS-Zertifikat ("SSL-Zertifikat") - das ist ziemlich exakt dasselbe. Der Webserver hat ein Zertifikat, mit dem er die Verschlüsselung einleitet. Der Client braucht kein Zertifikat, er muss nur dem Zertifikat des Servers vertrauen. Dafür muss man ihm das Root-Zertifikat seiner PKI zugreifbar machen. Genauso ist das auch beim DC und dem LDAPS-Zertifikat. Die Artikel, die du zitierst, gehen von anderen bzw. speziellen Voraussetzungen aus. Sie gelten nicht allgemein. Im ersten Fall geht es um LDAP-Loadbalancer (die ohnehin im AD nicht supported sind), im zweiten um spezielle Szenarien bei DCs, die mehr als ein Zertifikat haben (was man vermeiden sollte, aber in den meisten Fällen auch kein Problem darstellen würde). Gruß, Nils

Moin, gut, dann dürfte der Principal "Domänencomputer" der richtige sein. Da ich keine Erfahrungen mit diesem Setup habe, würde ich versuchen, ob es ausreicht, dieser Gruppe Schreibrechte auf den Ordner zu geben. Leserechte würde ich nur einer Gruppe geben, die auf die Keys wirklich zugreifen darf. Allerdings würde ich auch noch mal bewerten, ob diese "zweite Option" wirklich sinnvoll ist. Die Ablage im AD erfolgt mit einem anderen Mechanismus, der (vermutlich) besser abgesichert ist als ein Share. (So genau habe ich das noch nicht analysiert, aber in der Tendenz gehe ich davon aus.) Eine zweite Option hat immer einen grundsätzlichen Nachteil: In der Regel ist sie leichter anzugreifen als die primäre Option, mindestens aber eröffnet sie einen zusätzlichen Angriffsweg. Gruß, Nils

Moin, ähem, liebe Kollegen - bitte seid doch einfach mal deutlich. Also: "System" bezeichnet in Berechtigungen immer das lokale System. Bei einem Share wäre das also das Betriebssystem des Dateiservers. Also mit Sicherheit nicht die Instanz, die da zu schreiben versucht - das wäre ja das Betriebssystem des Clients. Diese Berechtigung passt also schon mal nicht. Dann: Man sollte auf Share- und NTFS-Ebene nicht in dieser Form die Berechtigungen unterschiedlich halten. Da NTFS das leistungsfähigere Berechtigungssystem hat, sollten nur dort die Berechtigungen stehen. Das Share wird dann für "Jeder: Vollzugriff" berechtigt. [Datei- und Freigabeberechtigungen in Windows | faq-o-matic.net] https://www.faq-o-matic.net/2015/12/28/datei-und-freigabeberechtigungen-in-windows/ Ob der Mechanismus, den du beschreibst, den Sicherheitsanforderungen genügt, die man zur Ablage von Bitlocker-Schlüsseln haben sollte, kann ich nicht einschätzen. Seltsam klingt für mich, dass du die Keys von "Standalone-Clients" in das Share legen willst. Sind die nicht Mitglieder im AD? Dann wirst du dort kaum eine sinnvolle Berechtigung vergeben können. Gruß, Nils

Moin, heißt was? Wie viele Clients, wie viele User? Wie viele Server sind AD-Mitglieder? Sind Dateiserver mit Berechtigungen dabei? Andere Systeme mit Windows-basierten Berechtigungen? SharePoint? SQL Server? Ein internes Mailsystem, das die Daten (Adressen, Gruppen) aus dem AD nutzt? Drucker, Scanner mit LDAP-Abfragen? Web-Gateways mit LDAP-/AD-Abfragen? All das sind Beispiele für Systeme, die bei einer Migration (oder einer Umbenennung per rendom.exe für die, die auch bei 220 auf der Autobahn noch beschleunigen) zu berücksichtigen - und sehr wahrscheinlich zu bearbeiten - sind. Das mag eine Idee des Aufwands und des Risikos vermitteln. Und möglicherweise die Argumentation gegenüber der Marketing-Abteilung erleichtern. Auch die genannten Workarounds sähe ich kritisch. Das mag vordergründig das Problem "lösen", aber wehe, man ändert irgendwo mal irgendwas - in ein paar Wochen kann sich niemand erinnern, was da hingebastelt wurde. Gruß, Nils

Moin, ja, man hat sowas früher oft mit SUBST "gelöst". Ist aber auch eher halbgar. Gruß, Nils

Moin, oha. Ich wage energisch zu bezweifeln, dass du auf dem Weg irgendein sinnvolles Ziel erreichst. Ich verstehe den Ansatz, aber das wird nix. Schon deshalb nicht, weil du heutzutage nicht davon ausgehen kannst, dass zu jedem "langen" Namen tatsächlich ein 8.3-Name vorhanden ist. Schau dich einfach mal mit "dir /X" in einem CMD-Fenster in verschiedenen Ordnern um. Wenn wirklich eine Software beteiligt ist, die mit langen Pfaden nicht umgehen kann, dann ist der einzige sinnvolle Weg, die Pfade tatsächlich zu kürzen, d.h. die Daten in eine einfachere Struktur zu verschieben. EDIT: Weil ich jetzt doch noch ein wenig rumgesucht habe, hier eine interessante Fundstelle dazu. Aber: du bist gewarnt. Für produktionsreif halte ich das nicht. Bei mir gibt es mehrere Volumes ohne Kurznamen. https://devblogs.microsoft.com/scripting/use-powershell-to-display-short-file-and-folder-names/ Gruß, Nils

Moin, könntest du bitte noch mal erläutern, was du dir unter einer vorstellst? Gruß, Nils

Moin, meine letzten Kunden, die gegen meinen Rat angefangen haben, ihr AD "umzubenennen" (= in ein neues AD zu migrieren), wollten mir nicht glauben, dass das zu einem empfindlich fünfstelligen Projekt wird. Das haben sie dann erst getan, als sie mittendrin mal die Rechnungen addiert haben. Aber bitte, muss jeder selbst wissen. "rendom.exe" willst du nicht benutzen. Sofern Exchange im Einsatz ist, kannst du es auch nicht. Nur damit du nicht sagst, es habe dich keiner gewarnt. Gruß, Nils

Moin, die schlichte Antwort noch mal deutlicher: Weil das AD dann nicht mehr geht. [Was muss ich beim DNS für Active Directory beachten? (Reloaded) | faq-o-matic.net] https://www.faq-o-matic.net/2007/01/09/was-muss-ich-beim-dns-fuer-active-directory-beachten-reloaded/ Gruß, Nils

Moin, wer baut denn sowas? Die übliche Weiterleitung geht andersrum, also von "kein Hostname" zu "www". Am einfachsten (möglicherweise auch die einzige Möglichkeit): Ihr sprecht mit eurem Marketing, dass sie diese hinderliche Konfiguration entfernen und den Webserver mit www-Hostnamen zum Standard erklären. Dazu böte es sich an, wie oben erwähnt die Umleitung umzukehren. Und weil du vermutlich als nächstes danach fragst: Das AD umzubenennen, erfordert eine vollständige Migration in einen neuen AD-Forest. Kann man machen, ist aber sehr aufwändig. Und dann nimmt man (um auch das schon erwähnt zu haben) einen abstrakten AD-Namen, der nichts mit dem Firmennamen und der Domain zu tun hat. Gruß, Nils

Moin, das (der vertrauenswürdige Speicherort) scheint mir durchaus ein Element zu sein, das den Makroschutz fragwürdig macht. Wie immer bei Pfadregeln. Gruß, Nils

Moin, liegt die Datei an einem Speicherort, der zuvor als "vertrauenswürdig" deklariert wurde? Dann prüft Office erst gar nicht ... Quelle: https://support.office.com/de-de/article/ändern-der-makrosicherheitseinstellungen-in-excel-a97c09d2-c082-46b8-b19f-e8621e8fe373 Kann ich hier auch nachstellen. Schalte ich auf "deaktivieren", kann ich xlsm-Dateien von einem Ordner öffnen (und Excel führt die Makros aus), den ich früher als vertrauenswürdig deklariert habe. Kopiere ich dieselbe Datei in einen lokalen Pfad, den ich für sowas noch nie genutzt habe, führt Excel die Makros nicht aus. Ohnehin muss man sagen, dass die heise-Meldung (wie so oft) von falschen Annahmen ausgeht, was den Umgang in Unternehmen angeht. Da wird i.d.R. viel mit Makros gearbeitet, aber selten signiert oder sowas. Daher schalten nur wenige Unternehmen Makros wirklich aus. Gruß, Nils

Moin, dann solltest du die Probleme beheben und keine neuen schaffen. Es ist ausgesprochen unwahrscheinlich, dass zwischen dem Herunterfahren und dem Domänennamen ein Zusammenhang besteht. Dass AD-Domäne und Azure-Domäne unterschiedlich heißen, ist nicht nur oft so, sondern dürfte eher der Normalfall sein. Die allermeisten Administratoren haben weiland ihre Domänen mit nicht-offiziellen Domänennamen aufgesetzt. Das hat sicher Nachteile, aber es verursacht keine unlösbaren Probleme. Das mit dem Name-Suffix sehe ich wirklich nicht als Problem an. Das lässt sich prozessual leicht in den Griff bekommen. Und, wie gesagt, dein DC-Problem wird an einer anderen Stelle liegen. Das würdest du durch einen Rename nicht nur nicht beheben, sondern du würdest ein erhebliches Risiko erzeugen, dass dein AD dann erst recht nicht mehr läuft. Wenn du unbedingt umbenennen willst, dann nicht per rendom, sondern per Migration. Insbesondere, wenn die Umgebung ohnehin noch nicht vereinheitlicht ist - dann dürfte der Aufwand noch überschaubar sein. Aber dann nimm nicht den Firmennamen als AD-Namen, sonst stehst du in wenigen Jahren mit erstaunlich hoher Sicherheit erneut vor demselben Problem. Gruß, Nils ... der solche Diskussionen sehr oft mit Kunden führt, dabei fast immer verliert und hinterher viel Dienstleistung verkaufen kann ...

Moin, niemals eine Domäne aus kosmetischen Gründen umbenennen. Man unterschätzt immer die Kosten, die das verursacht. Gruß, Nils

Moin, es wird dich nicht überraschen, du wirst es nicht hören wollen und du wirst ganz bestimmt richtig gute Gründe haben, warum du es doch machst, aber: Man übergibt keine Kennwörter über ein Skript. Gruß, Nils

Moin, Abgesehen davon, ist Frankys Behauptung das Tier-Modell sei eine einfache Maßnahme, nicht zutreffend. Es ist komplex. Gruß, Nils

Moin, naja, das lässt sich ja feststellen. [LDAP Signing auf Domänencontrollern erzwingen | faq-o-matic.net] https://www.faq-o-matic.net/2018/07/16/ldap-signing-auf-domnencontrollern-erzwingen/ Gruß, Nils

Moin, wenn du ZDF gucken willst, gehst du ja auch nicht aufs Dach und stellst den Sat-Empfänger um. Du nimmst die TV-Fernbedienung. Auf einem DC will man keine Anmeldesessions offen haben, das erzeugt unnötiges Risiko. Schön, dass es jetzt klappt. Also kein DLL-Problem, sondern nur ein Missverständnis wegen der MMC. Gruß, Nils

Moin, das ist beides so nicht richtig. Windows-Server-VMs werden immer über den Host lizenziert und niemals über die VM. Die VMs können also gar keine Lizenzen "haben". Das ist keine verbale Haarspalterei, sondern hat handfeste Folgen: so kann man auf dem Host keine Lizenzen mischen (bei unterschiedlichen Versionen), und sobald ein zweiter Host ins Spiel kommt, wird das in jedem Fall ein Thema. Je nachdem, welche Lizenzen tatsächlich vorliegen, könnte es bei Betrieb mit einem Host aber sogar günstiger werden - das müsste man sich ansehen. Jedenfalls sollte @Bruchstein dieses Thema noch mal prüfen. Gruß, Nils

Moin, für die AD-Administration sollte man sich weder lokal noch per RDP auf einem DC anmelden. Dort sollten nur dann Anmeldesessions laufen, wenn der betreffende DC konfiguriert oder gewartet wird. Das ist selten der Fall, wenn überhaupt. Dies hier hast du schon probiert? https://www.petenetlive.com/KB/Article/0001448 Gruß, Nils