NilsK

Moin, das Objekt $NewRawXML enthält die Daten, die du verändert hast. Also musst du dieses Objekt in eine Datei schreiben. Zumindest ist das die Methode, die zum Rest deines Skripts passt. Gruß, Nils

Moin, ich habe keine Ahnung. Es ist wahrscheinlich, dass der Cluster nichts damit zu tun hat, sondern die Kommunikation mit dem SAN an der Stelle nicht richtig läuft. Da ich vor über zehn Jahren das letzte Mal mit Pass-through-Disks zu tun hatte, kann ich beim Troubleshooting nicht unterstützen. Gruß, Nils

Moin, vermutlich "sorgt" niemand ausdrücklich dafür, sondern da funktioniert halt was nicht. Wie du es jetzt konkret anstellst, kann ich dir mangels Detailkenntnissen der Umgebung nicht sagen. Ich würde jedenfalls den Weg verfolgen, das Storage komplett per VHDX an die VMs anzubinden. Gruß, Nils

Moin, da ist der Fehler. Pass-through macht man nicht. Hat praktisch nie Vorteile, und einen Teil der Nachteile siehst du ja jetzt. Denke schon. Bevor wir über Rechnungen sprechen - Fragen kannst du hier gern stellen. Wenn es in einem Forum nicht mehr gut zu machen ist, werden wir dich drauf hinweisen. Gruß, Nils

Moin, er schrob doch: Gruß, Nils

Moin, hm, ja, wenn man es so liest ... da bin ich wohl nach 22 Jahren Active Directory etwas vorgeprägt. Gruß, Nils

Moin, Da spricht so viel dagegen, dass man gar nicht weiß, wo man anfangen soll. Erstens: ein DC ist niemals ein Host, und ein Host ist niemals ein DC. Zweitens: es gibt keinen Grund, jetzt schon einen DC mit Windows Server 2022 zu betreiben, daher muss man da auch nichts übers Knie brechen. Drittens: es gibt keine gemischte Lizenzierung, du müsstest also alle VMs auf dem Host mit 2022 lizenzieren. Das jetzt erst mal nur die ersten Punkte. Gruß, Nils

Moin, ja, siehst du ... genau das meinten wir mit "nicht einfach irgendwas probieren". Du machst es gerade aktiv schlimmer. Vermutlich war der erste Fehler ein leicht korrigierbares DNS-Problem. Indem du jetzt den alten DC wieder eingeschaltet hast (ein No-go, wenn man dessen Namen schon anderweitig vergeben hat!), hat dessen DNS anscheinend wie erwartet geantwortet. Da der DC aber nicht mehr "er selbst" ist, kannst du dich natürlich dort nicht anmelden. Bei dem neuen wird das möglicherweise jetzt auch nicht mehr gehen. Und wenn du jetzt noch mehr Leichen aus dem Keller holst und aufs Geratewohl irgendwas ausprobierst, wird es mit Sicherheit nur eins: Schlimmer. Gruß, Nils

Moin, ja, was denn nun? Gruß, Nils

Moin, äh - nein. So pauschal wirklich nicht. Ernsthafter Rat: Bevor du jetzt noch mehr kaputt machst, hol dir rechtzeitig jemanden ins Haus, der sich mit der Materie auskennt. Das ist alles kein Hexenwerk, aber wenn man ohne ausreichende Kenntnisse irgendwas macht, kann man schon einiges Unheil anrichten. Das ist das, was Norbert mit "panisch" meinte. Gruß, Nils PS. Um deine Frage ausdrücklich zu beantworten: Nein, man kann einen DC nicht aus der Domäne nehmen und wieder hinzufügen.

Moin, eben. Wie bei jeder Sicherheitstechnik muss man sich auch hier ansehen, wofür die eigentlich taugt. Gerade bei "Verschlüsselung" gehen die Ideen, Anforderungen und Möglichkeiten da oft etwas durcheinander. Das liegt daran, dass das Thema sehr vielschichtig ist. Gruß, Nils

Moin, A hat mit B nichts zu tun. Deshalb: Ja, kann er. Bitlocker ist eine Festplattenverschlüsselung. Damit das Betriebssystem überhaupt starten kann, muss es die Daten lesen können. Ab da läuft das Betriebssystem so wie sonst auch. Gruß, Nils

Moin, ja, das gilt als Best Practice. Das liegt daran, dass man diese Zertifikate mit der Gegenseite, also den Application Providern austauschen muss. Da das eigentlich nie ohne Unterbrechung funktioniert (obwohl das Protokoll das möglich machen würde), möchte man das nicht jedes Jahr machen müssen. Gruß, Nils

Moin, ich möchte hier aber noch anmerken, dass man in aller Regel für ADFS kein Zertifikat von einer internen PKI einsetzt. Der Witz ist ja, dass man Federation auch von außen machen kann (muss man nicht, aber die meisten Unternehmen wollen das sofort oder später). Dafür sollte man ein TLS-Zertifikat von einer "echten", also kommerziellen PKI nutzen. Die Zertifikate hingegen, die ADFS ohnehin selbstsigniert ausstellt, sollten auch in diesem Modus bleiben, also auch nicht von einer eigenen PKI ausgestellt werden. Gruß, Nils

Moin, und wenn du für die IT so eine Aufgabe lösen sollst, lässt sich da nix machen? Meiner Erfahrung nach kann man mit Leuten reden. Am Ende hängt es aber auch nicht an adfind.exe, das macht es nur viel einfacher, als wenn man alles in PS selbst bauen muss. Du kannst den Aufbau in mehreren Schritten ja auch mit der PowerShell machen. Ich finde es halt, wenn es nur einmalig sein soll, in aller Regel viel einfacher, für sowas keine verschachtelten Programmschleifen bauen zu müssen, bei denen man schnell Fehler einbaut und die viel Aufwand beim Testen machen. Daher zerlege ich sowas lieber, auch wenn es nicht so elegant ist. Gruß, Nils

Moin, also, ich würde die Aufgabe so lösen: Schritt 1: Ausgeben aller gewünschten Gruppen in eine CSV-Datei Dazu nähme ich adfind.exe von joeware.net. Da kann man mit LDAP-Filtern arbeiten. Hier braucht man im Wesentlichen den Namen und den distinguishedName pro Gruppe. Eine Gruppe pro Zeile. Schritt 2: Bearbeiten der Gruppenliste mit Excel Excel fungiert im Folgenden als Skriptgenerator. Hier würde ich mir mit den Stringfunktionen für jede Gruppe ein adfind-Kommando bauen, das mir die Mitglieder der betreffenden Gruppe ausgibt. Das geht so: [Excel: Admins unbekannter Liebling | faq-o-matic.net] https://www.faq-o-matic.net/2008/01/19/excel-admins-unbekannter-liebling/ Hier unterscheidet sich dann die Logik: Falls es Verschachtelung gibt, User also indirekte Gruppenmitglieder sein können, dann früge ich das attribut "tokenGroups" ab und suchte also nach solchen Usern, denen die Gruppenmitgliedschaft zugeordnet wird. adfind.exe kann das. Ist Verschachtelung kein Thema, dann ist es einfacher: Zu jeder Gruppe nur den Inhalt des Attibuts "member" ausgeben. Ausgabe wieder in eine CSV-Datei. Schritt 3: Bearbeiten der Mitgliederliste Nun kann man die Mitgliederliste auch noch in Excel öffnen, um die Dubletten (Mehrfachmitgliedschaften) loszuwerden. Dafür hat Excel eine Funktion, die das direkt macht. Gruß, Nils

Moin, um wie viele Gruppen geht es denn? Und gibt es da auch Verschachtelungen, wie ich oben beschrieben habe? Ist sichergestellt, dass jeder User nur in maximal einer dieser Gruppen ist? (Sonst müsstest du bei deiner Frage ja auch noch die Mehrfachmitgliedschaften ausfiltern.) Bei solchen einmaligen Auswertungen mache ich es mir normalerweise einfach, aber was "einfach" ist, hängt natürlich von der Gesamtmenge ab. Gruß, Nils

Moin, nein, das erwartet er nicht, Er weiß nur nicht, wie man GPOs konfiguriert und hat irgendwo geklickt, wo ihm der Zusammenhang fehlt. Auch dies: Kein Vorwurf, sondern eine Beschreibung. Aber, @Fries, wie du ja merkst - auf die Weise bringt das in einem Forum nichts. Um das selbst zu lösen, müsstest du sehr viele Grundlagen aufbauen. Kann man machen, ob es sinnvoll in deinem Jobprofil ist, wissen wir nicht. Wenn du ein Problem vermutest, das du offenbar nicht selbst lösen kannst (was OK ist), dann hol dir jemanden dazu. Aber nicht ein Forum, das ist hier nicht das richtige Werkzeug. Gruß, Nils

Moin, das habe ich mir gedacht, darum die Frage. Aller Erfahrung nach ist Hyper-V Replica dafür nicht das richtige Mittel. So, wie du es beschreibst, suchst du einen Failover-Cluster und keine Replikation. Hyper-V Replica ist kein Mechanismus für Ausfallsicherheit, sondern für Wiederanlauf in ganz bestimmten Situationen. Das ist ein relevanter Unterschied. Replica ist asynchron und nimmt Datenverluste in Kauf, und es ist "teuer" mit Blick auf den Datenverkehr, den es verursacht. Aus diesem Grund ist es für viele Applikationen ungeeignet und für einen Teil davon auch nicht supported. Hyper-V Replica ist auch nicht der "Cluster des kleinen Mannes" oder sowas. Es ist gedacht, um für wenige (!) Systeme einen Wiederanlauf - vom Grundgedanken: einen manuellen Wiederanlauf - an einem anderen Standort zu ermöglichen, wenn dieser Wiederanlauf wichtiger ist als die Konsistenz der Daten. Gruß, Nils

Moin, gut, aber dann wiederhole ich die relevante Frage: Was willst du mit der Replikation erreichen? VM-Replikation ist kein "One size fits all", sondern nur für sehr spezielle Szenarien gedacht und geeignet. Gruß, Nils

Moin, ja, soweit passen die Erkenntnisse schon. Abhängig von der Umgebung kann es allerdings sein, dass der logische Ansatz trotzdem nicht passt: mit dem Verfahren über "memberOf" findet man nur direkte Mitglieder der Gruppen, keine indirekten (wenn also ein User nur in einer "GruppeX" ist und diese Gruppe ist per Verschachtelung Mitglied einer gesuchten Gruppe "GroupY", dann taucht die gesuchte Gruppe "GroupY" unter "memberOf" nicht auf) in großen AD-Umgebungen kann dieses Vorgehen viel Last erzeugen, weil vom DC zu Client alle Daten übertragen werden müssen und erst der Client das Filtern übernimmt Ist das eine Ausbildungs-Aufgabe? Oder geht es nur darum, das Ergebnis zu erhalten? Gruß, Nils

Moin, wobei dann die Frage in den Blick kommt: Was möchtest du denn erreichen? Gruß, Nils

Moin, nein, finde ich nicht. Ich wollte ein bisschen provozieren. Das mit den Netzwerkkarten hätte man sich IRL (also in einer professionellen Umgebung) vorher angesehen. Oder dein Labortest hätte eben als solcher zur Vorbereitung gedient. (Ja, die Tools sind Mist. Das ist aber bekannt und es gibt Workarounds.) Für die VM-Übertragung hätte man geschaut, welche VMs wirklich konvertiert werden sollen. Jede Konversion ist ein Risiko, das würde man etwa bei einem DC gar nicht erst eingehen. Auf der neuen Plattform einen neuen DC einrichten und in einer halben Stunde ist das durch, ohne jedes Risiko. Bei den wenigen VMs, die man dann wirklich noch konvertiert, kann man einiges an Vorbereitungen treffen. Welche das sind, hast du jetzt zum Teil auf hartem Weg rausgefunden. Es gibt in der Tat im Web wenig dazu, aber es gibt was. Auch in "diesem Buch" haben die Autoren genau auf diesen Aspekt einige Arbeit und Sorgfalt verwendet. Konversionstools gibt es deshalb so wenig (egal in welche Richtung), weil der Nutzen, für den Kunden bereit sind zu zahlen, relativ gering ist, andererseits die Fallgruben im Detail sehr tief. Sprich: Es ist sehr teuer, sowas "in ordentlich" zu bauen und die Kundengruppe ist klein. Deshalb macht das keiner. Gruß (und nix für ungut ), Nils

Moin, nun ... dass Hyper-V im Detail anders ist als VMware, hat dich doch aber nicht ernsthaft überrascht, oder? Das ist schon ein witziger Bericht, aber im Effekt hast du per Trial and Error ja dann doch so ziemlich alles falsch gemacht, was geht. Gruß, Nils PS. natürlich braucht Hyper-V auf den VM-Netzwerkkarten keine IPs, wenn der Host nicht demselben Netz angehören soll.

Moin, Dann hat "er" bestimmt auch die Zeile dazu geschrieben, oder? Welche ist das? Woher soll dein Skript denn wissen, welche Datei es importieren soll? Das Beispiel nutzt jedenfalls nicht das angegebene Trennzeichen. Gruß, Nils