NilsK

Moin, aha. Dann wäre natürlich interessant, was das Skript denn genau prüft. Im Übrigen wäre diese Information schon in der Eingangsfrage wichtig gewesen. Wie soll man dir sonst eine Antwort geben? Denkbar ist, dass das Konto bereits gesperrt war, als es deaktiviert wurde. Wenn das Skript jetzt nur die Eigenschaft "gesperrt" prüft, findet es das Konto natürlich. Ist ja auch richtig. Am Ende läuft deine Frage darauf hinaus, in deinem Skript Ausnahmen oder zusätzliche Bedingungen zu definieren. Wie du das am besten machst, kannst du nur anhand des Skripts feststellen ... Gruß, Nils

Moin, naja, kommt drauf an. Dass der Replikationsverkehr höher sei, ist ein Ansatz aus frühen Windows-2000-Zeiten, als man den Global Catalog in Enterprise-Umgebungen noch nicht richtig einschätzen konnte. Aus heutiger Sicht ist es egal, ob eine Gruppe in der Domänenpartition oder im GC gespeichert wird, der Verkehr bleibt gleich. Bleibt die Differenzierung der Gruppentypen und ihrer Eigenschaften, was dann aber eine Frage des eigenen Gesamtkonzepts ist. Gruß, Nils

Moin, wer genau meldet da was genau? Gruß, Nils

Moin, man behalte stets im Auge, dass AGDLP nur eine Empfehlung ist. Man muss es nicht so machen. Wenn man ein anderes, konsistentes Konzept hat, ist das auch OK. Gruß, Nils

Moin, für mich klingt das auch, als sei die HDD der Engpass. Als ich noch HDDs im Notebook hatte, machte es auch weniger Spaß, sobald mehr als eine VM lief. Wenn ich dann noch "im Host" was gemacht habe (z.B. Outlook - ist ja ein Notebook, die VMs fast nur für Lab- und Demozwecke), dann konnte man alles ziemlich vergessen. Seit ich mit SSD arbeite, ist es völlig OK. (Nota bene: für den Lab-/Testgebrauch; für einen Server wäre eine Consumer-SSD nicht OK.) Zu viel RAM kann man mit Hyper-V technisch betrachtet nicht vergeben, dann würde der Hypervisor irgendwann die VMs nicht mehr starten. Es könnte natürlich sein, dass eine VM "innen" nicht genug RAM hat, dann muss das Gast-OS swappen, und das dauert bei einer HDD natürlich auch. Gruß, Nils

Moin, lies dir die Hintergründe noch mal in Ruhe durch. Da sind alle deine Fragen und alle Ungereimtheiten erklärt. Wenn man dann weiß, wie man damit umgeht, ist es in der Praxis auch kein Problem. Nur weil etwas ungewohnt ist, ist es ja noch nicht schlecht. Gruß, Nils

Moin, das Journaling ist etwas völlig anderes. Lass das aus. Bei dem angegebenen Einsatzzweck verstehe ich die Auswahl der Felder nicht. Aber ihr werdet schon wissen, was ihr tut. Gruß, Nils

Moin, am einfachsten geht das mit csvde.exe von einem Rechner aus, der die AD-Verwaltungstools installiert hat. csvde.exe -f C:\Pfad\Ergebnis.txt -u -r "(&(objectClass=user)(objectCategory=person))" -l sn,givenName,telephoneNumber,department,employeeId In welchem Feld bei euch die Personalnummer liegt (Annahme hier: employeeID), müsstest du rausfinden. Nachteil bei csvde: Man hat keine Kontrolle darüber, in welcher Reihenfolge die Felder ausgegeben werden, das kann sich bei jeder Ausführung ändern. Da wäre es dann ggf. relevant, was ihr mit den Daten machen wollt. Gruß, Nils

Moin, solage die Patches das Betriebssystem betreffen und nicht die Firmware der betroffenen CPUs (was schwerlich gelingen dürfte), müssen wohl alle Betriebssysteme gepatcht werden, die möglicherweise eine der betroffenen CPU-Funktionen nutzen. Da auch VMs direkt mit der CPU kommunizieren (sie werden vom Hypervisor ja nur gesteuert, aber er führt nicht die Instruktionen für die VMs aus), müssen ziemlich sicher auch die VMs gepatcht werden. Gruß, Nils

Moin, Wenn es nur einen Standort im AD gibt, braucht man die Subnets nicht einzutragen. Gruß, Nils

Moin, ja, das wäre evtl. mal was für ein Redesign beim TO. Aber erst, wenn ausreichend Vertrauen in die Netzwerkkonfig drumrum besteht. :D Gruß, Nils

Moin, das ist relativ einfach: keins. Windows ist zwar von der Architektur her in der Lage, auch weitere Dateisysteme einzubinden, aber tatsächliche Implementierungen gib es dafür m.W. nicht. Gruß, Nils

Moin, ehrlich gesagt, frage ich mich, was man da missverstehen kann. Es steht doch eindeutig da, dass dieser Einsatz von Storage Replica nur für Recovery-Zwecke gedacht ist. (Und selbst dort muss man sich überlegen, ob man das will - das Feature ist aufwändig einzurichten und fehlerträchtig.) Für den Anwenderzugriff auf verteilte, replizierte Daten gibt es keine einfache Lösung. Es gibt (oder gab?) Enterprise-Software, die mit Replikation und Distributed Locking arbeitet, aber in der Praxis habe ich sowas nie angetroffen. Ändert das Konzept. Ein typischer Lösungsvorschlag ist in #16 genannt worden. Gruß, Nils

Moin, zumindest früher war es nicht mal supported, das Heartbeat-Netz zu teamen. Man sollte stattdessen zwei separate Netze einrichten, weil der Clusterdienst selbst ein Failover darüber macht - genauer gesagt über alle Netze, die ihn mit den anderen Nodes verbinden. Diese Supportstatement gilt zwar nicht mehr, seit das Teaming Teil des Betriebssystems ist, aber es zeigt, dass man an der Stelle kein Team braucht. Viele Kunden wollen wie du maximale Geschwindigkeit für Live Migrations. Da frage ich mich immer, wieviel man denn im Normalbetrieb live migriert. Solange man keine höchstdynamische Umgebung hat, migriert man vielleicht einmal im Monat, vor den Host-Updates. Dafür braucht man aber keine Maximalperformance. Ohnehin hülfe das Team nur, wenn du zwei VMs gleichzeitig migrierst, was man in mittelständischen Umgebungen auch eher selten tut. Ganz abgesehen davon, solltest du aber dem Netzwerkproblem auf die Spur kommen, statt dich auf Nebenschauplätze zu konzentrieren. Das Verhalten des Clusters war nicht OK, und das muss einen Grund haben. Gruß, Nils

Moin, wie sind denn die IP-Segmente der verschiedenen Netze? Sind die voneinander getrennt, oder versucht der Cluster, dasselbe Segment über mehrere Karten zu erreichen? Das wäre spontan das einzige, was mir einfällt, warum der Cluster trotz separierten Heartbeat-Netzes in den Status geht. Oder das Netz ist eben in Wirklichkeit nicht separiert, wodurch der Loop alle Netze in Mitleidenschaft zieht. Gruß, Nils

Moin, DFS-R repliziert Daten ohne Rücksicht auf die Nutzung nach dem simplen Prinzip "Last Writer Wins". Damit eignet es sich nicht für Dateien, auf die an mehreren Speicherorten schreibend zugegriffen wird, denn die jeweils letzte gespeicherte Fassung überschreibt alle anderen. Manche Kunden setzen DFS-R als Vorbereitung zur Datensicherung ein. In solchen Szenarien gibt es immer nur einen Speicherort, auf den Anwender zugreifen. Die Replikate dienen dazu, die Daten an anderer Stelle zu sammeln, um sie dort zu sichern. DFS-R hat durchaus seine Berechtigung, aber eben für weit weniger Szenarien, als oft vermutet wird. DFS-N ist davon völlig unabhängig, es bietet "nur" einen virtuellen Ordnerbaum, dessen tatsächliche Speicherorte auf verschiedenen Systemen liegen können. Man kann DFS-N zwar mit DFS-R kombinieren, aber eigentlich sind sie unabhängig voneinander. Gruß, Nils PS. ja, das ist ziemlich dasselbe, wie ich oben schon schrob.

Moin, Jan liegt richtig. Den Host zu sichern, ist unsinnig. Im Ernstfall hättest du sowieso andere Hardware und müsstest den Host neu installieren. Also alle wichtigen Konfigurationen dokumentieren, in größeren Umgebungen evtl. PowerShell-Skripte zur Einrichtung entwickeln. VMs sichern, fertig. (Kurz gesagt.) Wenn man weiß, was man tut, hat man einen Host in einer halben Stunde installiert und eingerichtet. Mit einem Restore ist man nicht schneller, muss dafür aber viel nacharbeiten. Gruß, Nils

Moin, deinem letzten Satz stimme ich vollständig zu, den Mutmaßungen darüber nicht. Du solltest im Produktionssystem prüfen, ob wirklich alles OK ist. Nach einem Recovery sollte jedenfalls kein DFSRMig erforderlich sein. Abgesehen von Verzögerungen beim ersten Start muss das AD auch bei einem einzeln zurückgesicherten DC natürlich starten, ebenso wie nach dem Ausfall von DCs, wenn nur noch einer arbeitet. Also: Eventlogs aller DCs prüfen, dcdiag, Replikation usw. Netzwerkkonfigurationen aller DCs prüfen. Durchaus auch einzelne DCs neu starten (nicht mehrere gleichzeitig, es geht ja ums Testen) und sehen, was passiert und ob sich ggf. beim Startvorgang Fehler oder Meldungen auftun. Gruß, Nils

Moin, generell ja. Gruß, Nils

Moin, https://www.heise.de/newsticker/meldung/Analyse-Endlich-offenes-WLAN-3861616.html Viel mehr können wir dazu nicht sagen, für Details wäre eine Rechtsberatung erforderlich. Gruß, Nils

Moin, nein, das würde nicht passieren. Zu beobachten wäre eine deutliche Verzögerung, aber natürlich hört das AD nicht auf zu funktionieren, wenn ein Replikationspartner nicht gefunden wird. Dann könnte man die ganze Ausfallsicherheit ja vergessen. Da wird also noch was anderes im Busch sein. Gruß, Nils

Moin, eine Consumer-SSD ist trotzdem für den Servereinsatz nicht geeignet. Es ist sehr wahrscheinlich, dass die Performanceprobleme bleiben. Damit ist hier alles gesagt, ich bin raus. Gruß, Nils

Moin, du hast völlig Recht. Man ignoriere diese Anmerkung. Gruß, Nils

Moin, rhetorische Frage, gell? Das ist natürlich keine Frage des Intervalls, sondern des Prinzips. Einen Zwang zum Kennwortwechsel sollte es nur dann geben, wenn es den Verdacht gibt, dass das Kennwort nicht mehr sicher ist. Ein turnusmäßiger Wechsel erhöht die Sicherheit eines Kennworts nicht, wenn es nicht "geknackt" wurde und nicht leicht zu knacken ist. Die Sicherheit eines schwachen Kennworts erhöht man durch einen turnusmäßigen Wechsel auch nicht. Bei schwachen Kennwörtern tritt hingegen beobachtbar ein Effekt ein, der dauerhaft für schwache Kennwörter sorgt: Die User suchen nach einfachen Auswegen und hängen meist eine Ziffer an, die sie schlicht hochzählen. Wobei das alles ja nicht neu ist. https://helgeklein.com/blog/2009/06/how-forcing-password-changes-actually-weakens-security/ https://www.faq-o-matic.net/2017/09/20/nist-kennwortrichtlinien-runterschrauben/ Gruß, Nils

Moin, ergänzend könnte man jetzt noch darüber philosophieren, dass ein erzwungener regelmäßiger Kennwortwechsel die Sicherheit effektiv senkt und nicht erhöht ... aber zum Kernthema des Threads ist wohl alles Nötige gesagt worden. Gruß, Nils