NilsK

Moin,

vor 21 Stunden schrieb Wolle68:

die Namesauflösung der Domäne A vom Memberserver mit NSLOOKUP funktioniert

ceterum censeo: das heißt im Zweifel gar nichts. nslookup macht eine Datenbankabfrage, keine Namensauflösung. Das ist was anderes. Wenn das eine funktioniert, kann das andere immer noch fehlschlagen.

Gruß, Nils

Moin,

hui, du probierst gern wild rum oder? 

vor 23 Minuten schrieb Proll012:

Puh keine Ahnung welche Variable ich dann angeben muss, damit der jede eingespielten Datei unter dem eingespielten Namen in ein anderes Verzeichnis speichert.

Wo stehen denn die Verzeichnisse, in die das Skript speichern soll? Falls die noch in keiner Variablen stehen, musst du die eben definieren. Irgendeine Logik wird es ja geben, nach der der Speicherort zu bilden ist.

vor 23 Minuten schrieb Proll012:

$XmlData.Save($files)

Hier versuchst du, die Datei an dem Ort zu speichern, der durch $files angegeben wird. Wenn du jetzt aber mal oben in deinem Skript guckst, was in $files steht - dann siehst du, dass das ein Array ist, das sämtliche Dateiobjekte aus dem Suchpfad enthält. Ist also eher unwahrscheinlich, dass das klappt.

Dein Skript hat keine Variable, die den Dateinamen enthält. Und ganz nebenbei: Es enthält auch keine Schleife, die alle Dateien wirksam durchgehen würde. Die betreffende Schleife (wenn man von den Syntaxfehlern absieht) weist nacheinander den Inhalt jeder Datei derselben Einzelvariable zu, sodass diese vermutlich am Ende nur den Inhalt der letzten Datei im Ordner enthält.

Gruß, Nils

Moin,

vor 2 Minuten schrieb Proll012:

Das war nur ein Beispiel, das wäre $NewRawXML  im oben genannten Skript.

Und darin sollte soweit ich richtig verstehe die überarbeitete Datei drin stehen. 

nein. In $NewRawXML steht der Inhalt der Datei, den du geändert hast. In der Save-Methode brauchst du aber den Dateinamen, unter dem die Datei gespeichert werden soll. Das ist in Olafs Beispiel ja auch gut zu sehen.

Gruß, Nils

Moin,

ja, der fehlt dir ja auch. Er kann aber sehr simpel sein, so in der Art:

$NewRawXML | Out-File 'c:\Pfad\Dateiname.xml'

Statt des festen Pfads dann eben eine passend zusammengebaute Variable.

Gruß, Nils

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,

vor einer Stunde schrieb flyct2k:

Die angehängten Laufwerke kommen direkt von der SAN als Pass-Through-Datenträger

da ist der Fehler. Pass-through macht man nicht. Hat praktisch nie Vorteile, und einen Teil der Nachteile siehst du ja jetzt.

vor einer Stunde schrieb flyct2k:

Ist hier im Forum jemand der sich mit dem HyperV Cluster auskennt.

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:

vor 2 Stunden schrieb Nobbyaushb:

4 Tage Arbeit, dann Urlaub

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,

vor 2 Stunden schrieb derTobsi:

Soweit funktioniert ja alles wieder.

ja, was denn nun?

Gruß, Nils

Moin,

vor 1 Stunde schrieb derTobsi:

Ich kenne das nur wenn so ein Fehler ist, dass man den Client/Server aus der Domäne nehmen muss und wieder neu verbinden.

ä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,

vor 6 Minuten schrieb cj_berlin:

Erwartest Du wirklich, dass man Dich hier in Sachen PKI ausbildet?

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