NilsK

Moin, man könnte dir leichter helfen, wenn du mehr Details angäbest. Wir haben keine Ahnung, wie du denn die AD-Gruppe in die lokalen Admins aufnimmst. Wir wissen nicht, was "es funktioniert nicht" genau heißt. Es ist jedenfalls völlig normal, dass geänderte Gruppenmitgliedschaften sich erst auswirken, wenn man sich neu anmeldet. Je nach Mechanismus können auch Neustarts erforderlich sein, wenn es etwa Gruppen angeht, die Computerkonten betreffen. An dieser Stelle hat sich aber zwischen Windows 10 und Windows 11 nichts geändert. Gruß, Nils

Moin, das kann nicht sein. Dann liegt da was anderes im Busch. Wenn du die Adminrecht indirekt vergibst, also per AD-Gruppe, was ist dann bei einem angemeldeten User, der diese Mitgliedschaft hat/haben sollte, im CMD-Fenster die Ausgabe von whoami /groups | find /i "admin" Gruß, Nils

Moin, gibt es den SA-Benefit an dieser Stelle noch, auf den Daniel Melanchthon vor vielen Jahren hingewiesen hat? [Hyper-V Replica: Wie lizenziert man das? | faq-o-matic.net] https://www.faq-o-matic.net/2014/05/12/hyper-v-replica-wie-lizenziert-man-das/ Falls nein, müsste ich den Artikel mal entfernen. Gruß, Nils

Moin, danke für das Feedback. Vermutlich hätte Windows 7 die Meldung des Controllers auf einem physischen Rechner direkt verarbeiten können. In der VM ist der Hypervisor dazwischen, daher kommt das beim Gast-OS nicht an. (Spekulation, kann auch anders sein.) Gruß, Nils

Moin, was du da beschreibst, ist längst nicht alles auf ein USN Rollback zurückzuführen. Da funktioniert offenbar noch mehr nicht. Dann brauchst du dir um USN Rollback auch nicht ganz so viele Sorgen zu machen. Ich würde jetzt zunächst koordiniert versuchen, die vorhandenen Probleme und Fehler einzuordnen und schauen, ob sich die jeweils lösen lassen. Vermutlich sind das zusätzliche Folgen des Ausfalls. Nur wenn das nicht weiterhilft, würde ich prüfen, ob einer der DCs weg muss. Falls ja, einen neuen in die Domäne installieren. Wenn der sich ordentlich repliziert und dann funktioniert, den zu entfernenden DC entfernen. Viel näher kann man das jetzt nicht beschreiben, dazu müsste man es sich vor Ort ansehen, das ist dann nichts für ein Forum. Was das mögliche USN Rollback angeht: Wie gesagt, unwahrscheinlich bei dir. Ob es überhaupt aufgetreten ist, kannst du im Eventlog prüfen: Event-ID 2103 zeigt an, wenn das AD einen USN Rollback erkannt hat. Falls ja, muss das auch erst mal kein Problem sein, das ist es nur, wenn tatsächlich auf beiden DCs Änderungen am selben Objekt erfolgt sind. In dem Fall sollte aber der DC, der in der Meldung als Problem genannt wird, herabgestuft werden. Nicht einfach versuchen, die Replikation wieder einzuschalten. Gruß, Nils

Moin, das ist ja auch beim Hersteller so dokumentiert. Man findet da ne ganze Menge dazu im Web. Gruß, Nils

Moin, ja, das kann ich gut verstehen, und das wäre auch entschieden zu viel für das, was wir hier diskutieren. Ganz so war es auch nicht gemeint, solche Entscheidungen sind immer langfristig. Trotzdem solltet ihr euch das mit den vielen Netzlaufwerken mal grundsätzlich überlegen. Und ihr solltet über euren Berechtigungs-Grundansatz sprechen. Auch das ist nicht simpel, da gibt es kein Patentrezept für alle. Was du berichtest, klingt aber an einigen Stellen so, als könne man da technische Missverständnisse beheben, die sehr verbreitet sind. Gruß, Nils

Moin, Sprache war noch nie logisch. Deshalb eignet sie sich ja auch so gut, um sich voneinander abzugrenzen. Aber wir schweifen ab ... @tgyssling kommst du mit den beiden Hinweisen von Norbert und Martin weiter? Gruß, Nils

Moin, also, ist etwas off-topic, aber man neigt im Deutschen dazu, bei unklarem Genus die weibliche Form anzunehmen. Das ist bei vielen Abkürzungen und Fremdwörtern so, wenn auch längst nicht bei allen. Eine sehr schöne Variante, die ich nur von zwei Leuten kenne: die Switch (bezogen auf Netzwerk-Switches). Und ich kenne Leute, die sich beim Autofahren auf "die Navi" verlassen. Gruß, Nils

Moin, nein, so würde ich das nicht sagen. Für bestimmte Workloads kann das interessant sein. VDI etwa wäre ohne in vielen Situationen kaum machbar. Hat aber mit Dateisystemfehlern ziemlich sicher nix zu tun. Gruß, Nils

Moin, was sagen denn die Win7-VMs selbst dazu? Die werden doch sicher auch was davon mitbekommen. Vielleicht hilft das weiter. Gruß, Nils

Moin, dafür ist es ja da. Die Quelle steht dabei, also prima. Inhaltlich stimme ich dir zu: Einfach halten. Maximal einfach. Sonst wird es nur Probleme bereiten. Man kann sich viele schöne Sachen mit GPOs ausdenken ... sollte man aber nicht. Gruß, Nils

Moin, aber wäre es in so einem Szenario nicht ohnehin besser, die VM herunterzufahren und dann zu exportieren? (Oder einfach zu kopieren ...) Gruß, Nils

Moin, vielleicht hakst du es besser ab. Zu hacken wäre unnötig gewalttätig. (Eine andere Variante, die ich in Betracht zöge, wäre ein Test mit einer frisch aufgesetzten VM.) Gruß, Nils

Moin, zum Beispiel an einem Update des Radius-Systems oder einer Konfigurationsänderung eines Systems in der Kette. Es kann durchaus sein, dass das hier nicht zutrifft, mein Punkt ist einfach, dass die Fehlermeldung anscheinend nicht nur dann auftritt, wenn es wirklich ein Problem mit der Authentifizierung gibt. Darauf weisen die Fundstellen im Web hin. Und was du berichtest, legt den Gedanken ja durchaus nahe. Gruß, Nils

Moin, eine Möglichkeit: Weil eine per Inplace Upgrade übernommene Applikation eben manchmal zickt. Gerade bei einer Applikation wie Access auf einem Terminalserver überrascht mich das jetzt nicht. Und dann kann es noch -zig andere Möglichkeiten geben. Glaskugeln haben wir keine. Gruß, Nils

Moin, prima, danke für die Rückmeldung. Gruß, Nils

Moin, also ein Inplace-Upgrade? Zusammen mit dem lokal installierten SQL Server also schon zwei Dinge, die nicht Best Practice sind. Ich würde den Terminalserver neu machen und den SQL Server separieren. Gruß, Nils

Moin, interessante Story, man versteht aber nur begrenzt, was jetzt im Detail Sache ist. Mit "Upgrade" meinst du genau was? Und was heißt "oder SQL"? Ist auf dem Terminalserver direkt auch ein SQL Server installiert? Gruß, Nils

Moin, übrigens scheint mir die oben zitierte Angabe auch nicht korrekt zu sein. @meinerjunge, hast du eine Quelle dazu? Die Angaben, die ich dazu finde, sind: es darf nicht der komplette SAM Account Name vorkommen ("NilsK") - sofern der kürzer als drei Zeichen ist, gilt die Regel nicht der Display Name wird in seine Teile zerlegt, und keiner der Teile darf vollständig vorkommen ("Nils", "Kaczenski") - auch hier die 3-Zeichen-Regel Das ist ja dann doch was anderes und senkt die Ausschlusswahrscheinlichkeit. Meine Quellen z.B.: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh994562(v=ws.11) https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/password-must-meet-complexity-requirements Gruß, Nils Edit: Zwei Nerds, ein Gedanke.

Moin, da sekundiere ich Norbert. Ich nutze seit ca. 20 Jahren sehr lange Kennwörter und habe damit noch nie ein Problem mit den vordefinierten Kennwortrichtlinien gehabt. Und ja, es geht um eine große Zahl sehr langer Kennwörter. Mein Eindruck ist, dass ihr euch da zu "akademische" Gedanken vor dem Hintergrund traditioneller Ansätze macht. Aber wie gesagt - wenn das bei euch so ist, dann recherchier halt nach einem Drittanbietertool. Gruß, Nils

Moin, "Kette" war missverständlich. Natürlich muss die Zertifikatskette auch gültig sein. Ich meinte aber die Systemkette. Ich habe mehrere Quellen gefunden, wo die Ursache Änderungen an den Systemen waren, z.B. dem Radius. Gruß, Nils

Moin, da kann man sich jetzt mit gewisser Berechtigung fragen, ob eure Vorgabe sinnvoll ist. Wenn ihr tatsächlich von der nicht abrücken könnt, dürfte an kommerzieller Software kein Weg vorbeigehen. Eine Webrecherche nach "Password Filter Active Directory" weist den Weg. Gruß, Nils PS. 10 Zeichen gelten schon lange nicht mehr als "sicher", unabhängig vom geforderten Zeichensatz. PPS. oder deutlicher: eure Vorgabe erzeugt weder hochkomplexe noch lange Kennwörter.

Moin, ich habe keine Lösung, aber eine schnelle Websuche deutet an, dass das Problem evtl. gar nichts mit dem User oder dem Zertifikat zu tun haben muss, sondern woanders in der Kette liegen kann. Gruß, Nils

Moin, für schützenswerte Konten würde ich ein oder mehrere PSOs (Password Settings Objects) einrichten und lange Kennwörter vorschreiben. Dann reicht die normale Komplexität völlig aus. Für Service Accounts lässt man sich dann gute Kennwörter generieren und Benutzern mit Accounts dieser Kategorie empfiehlt man, mit Kennwortsätzen zu arbeiten, die man gut tippen kann. (Eine Suche nach "Correct Horse Battery Staple" illustriert, was ich meine.) Gruß, Nils