NilsK

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

Moin, wenn der DC kein Zertifikat von einer CA bekommt, dann gibt es kein LDAPS. Selbstsigniert wäre unsinnig, dem kann ja kein Client ohne Weiteres vertrauen. Die tatsächliche Entscheidung, ob die CA (vorläufig) wegkann, können wir dem TO nicht abnehmen. Wir können nur Hinweise geben, die aufgrund von Forumsinformationen auch nicht umfassend oder vollständig sein können. Es steht dem TO ja frei, sich kompetente Beratung einzukaufen, wenn er konzeptionell begründet vorgehen will. Gruß, Nils

Moin, vermutlich erhält dein Kommando den Wert nicht in einem Format, das die PowerShell als Datum erkennt. Datumsfelder im AD sind so eine Sache für sich. Aber mal richtigrum gefragt: Was willst du denn am Ende erreichen? Gruß, Nils

Moin, und in jedem Fall handelt es sich bei dem genannten Modell um eine Consumer-SSD, der wesentliche Funktionen für den Servereinsatz fehlen. Das kann durchaus zu den bobachteten Phänomenen führen. Insofern würde ich da jetzt nicht weiter forschen. Gruß, Nils

Moin, die Ansicht, die du gepostet hast, sagt hier nichts aus. Schau in der CA-Konsole nach, welche Zertifikate die CA tatsächlich ausgestellt hat. Wie Jan vermute ich auch, dass die CA in Wirklichkeit gar nicht benötigt wird. Dann wäre es am einfachsten, die CA-Dienste zu deaktivieren und die CA nicht zu migrieren. Und, ebenfalls wie Jan sagt, wenn du dann doch eine neue CA brauchst, dann lass dir diese richtig konzipieren und installiere sie auf einem separaten Server (bzw. mehreren). Gruß, Nils

Moin, na, immerhin gut, dass es jetzt läuft. Danke für die ehrliche Rückmeldung! Und noch schöne Feiertage. Gruß, Nils

Moin, gut, da wir systematisch hier nicht weiterkommen, mache ich auch noch einen Schuss ins Blaue, dann ergibt es für mich keinen Sinn mehr: Handelt es sich um Enterprise-SSDs oder um Consumer-Komponenten? Letztere sind für den VM-Betrieb als Server regelmäßig nicht geeignet und könnten solche Phänomene zeigen. Gruß, Nils

Moin, ein letzter Versuch noch: Wenn du schon dabei bist, dann gib doch bitte endlich an, wie die vermuteten Probleme sich bemerkbar machen. Bislang behauptest du, dass es Probleme gebe und wirfst mit irgendwelchen Werten um dich, aber du hast noch nicht gesagt, was denn nun das Fehlverhalten sein soll. Gruß, Nils

Moin, immer, wenn du die Angabe "bevorzugt" in der ipconfig-Ausgabe siehst, solltest du aufmerksam werden. Dann ist praktisch immer etwas damit im Busch - entweder gibt es lokal noch eine Konfig im Konflikt (z.B. von einer früher vorhandenen Karte) oder im LAN. Gruß, Nils PS. Bei der Gelegenheit solltest du auch noch mit einigen mythologischen Verständnissen der Windows-Mechanismen aufräumen, denen du anscheinend anhängst, etwa bei der Replikation, der Firewall, der IPv6-Einbindung ...