NilsK

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

Moin, so ist der Plan. Da die Aufzeichnungen i.d.R. noch nachbearbeitet werden, kann das ein paar Tage dauern. Gruß, Nils

Moin, dann wäre es vielleicht mal an der Zeit, über eine Verdrängungsarchivierung nachzudenken. Früher nannte man sowas auch HSM. Gruß, Nils

Moin, da "Ransomware" (man hört, dass es da mehr als ein Produkt gibt und man dort auch über v1.0 hinaus ist) schon seit langem auch in der Lage ist, Schattenkopien zu zerstören und Online-Backup-Lokationen zu erkennen und ebenfalls zu verschlüsseln, wird sie natürlich auch so etwas Simples wie ein eingebundenes OneDrive, Dropbox et al. mit verschlüsseln. Man braucht ein Backup, das im Normalbetrieb nicht erreichbar ist und das mehr als eine Version vorhält. Ist ja nun nix Neues. Gruß, Nils

Moin, die Frage ist prinzipiell berechtigt, aber es könnte sich ja auch um einen Agenten handeln. Gruß, Nils

Moin, wenn es eine Neuinstallation ist, also noch nie funktioniert hat, dann gibt es leider auch keinen Support durch Microsoft. Nur als Anmerkung. Gruß, Nils

Moin, Ich weiß von einem Buch über Hyper-V, in dem gerade die Themen Backup und - vor allem - Recovery sowie das Netzwerk-Design sehr ausführlich erklärt werden. Das ist zwar für die Version 2016 und neu nur noch als E-Book zu haben, aber trotzdem noch aktuell. Just saying. Gruß, Nils

Moin, SMB wäre ja kein Block Storage. Ist der Gigabit-Link wenigstens exklusiv für iSCSI? Gruß, Nils

Moin, also zweistufig. Backup to File, File to Tape. Wäre ja meist ohnehin das, was man will. Gruß, Nils

Moin, gemeint ist vor allem eine funktionale Trennung von Adminkonten. Ein Client-Adminkonto darf nicht genutzt werden, um auf einem Server zu administrieren. Und ein Serveradmin soll nicht das AD manipulieren. Umgekehrt soll sich ein AD-Admin gar nicht auf einem Client anmelden können usw. Vor allem Letzteres ist relevant: Keine Admins höherer Sicherheitsbereiche auf Rechnern niedrigerer Stufen - heißt: keine Anmeldung für deren Konten. Ein Weg dazu kann LAPS sein, wobei ich es insgesamt nicht so sehe, dass das der einzige Weg dazu wäre (zumal LAPS so toll nun auch wieder nicht ist). Schau mal nach "Administrative Tiering" und "ESAE". Gruß, Nils