NilsK

Moin, fast. Das Umleitungsziel heißt nur "clip". MeinBefehl | clip Gruß, Nils

Moin, bei ADFS hat man sich auch an die Regel gehalten: Mach es unbrauchbar, aber mach es. Gruß, Nils ... wir schweifen ab ...

Moin, es musste schnell gehen, wie so vieles damals. Wenn man mal vergleicht: Mit Windows 2000 kam eine Unmenge an Neuerungen, sowas gab es danach in der Anzahl danach nicht mehr. Qualität hat man sich dann für später aufgespart, bei sehr vielen Komponenten aber nicht mehr umgesetzt. Neben dem GPO-Kram ist die unglaublich verkorkste Steuerung der PKI ein Beispiel. Gruß, Nils

Moin, Was sagen dass Event Log und dcdiag zu denn Thema? Gruß, Nils

Moin, der übliche Weg ist, dass du eine CSV-Datei in eine Objektvariable importierst. Diese kannst du dann mit ForEach auswerten. https://ss64.com/ps/import-csv.html Dein Kommando dürfte die ganze CSV als ein Objekt behandeln, wodurch eben nur ein Durchlauf der Schleife stattfindet, nicht einer pro Zeile. Gruß, Nils

Moin, und wo ist jetzt die "Katastrophe", die du im Titel versprichst? Was genau sind die Probleme der Umgebung? Dass Clients nicht im DNS auftauchen, ist unschön, aber in den meisten Umgebungen ohne problematische Folgen. Wichtig ist vor allem, dass die Server dort auftauchen. Im dritten Bild von unten ist die DNS-Alterung auf dem Server ausdrücklich abgeschaltet. Dann findet sie auch nicht statt, egal, was in der Zone steht. Habe ich richtig verstanden, dass es in der Umgebung nur einen DC gibt? Dann wäre das grob fahrlässig. Installiere mindestens einen zweiten. Gruß, Nils

Moin, von der Logik her ist es ziemlich einfach, warum es nicht funktioniert: Dein Skript macht was völlig anderes, als du willst. Zeile 1 importiert eine CSV-Datei, macht aber nichts damit. Zeile 2 durchsucht das AD nach Konten, bei denen "PasswordNeverExpires" zutrifft. Das Ergebnis wird dann in einer Tabelle ausgegeben, die die Spalten SAM-Name und Objektklasse enthält. Also bekommst du alle AD-User mit festem Kennwort zurück mit der Angabe, dass es sich um User handelt. Mit der CSV-Datei hat das nichts zu tun. Wenn du in der PowerShell noch nicht firm bist, dann arbeite lieber erst mal mit einfacheren Beispielen. Gruß, Nils

Moin, na, das ist mal spannend. Danke für die Rückmeldung. War mir so auch noch nicht bekannt. Gruß, Nils

Moin, also ist der PDC-Emulator korrekt identifziert? Der zugehörige DC funktioniert und antwortet auch? Zu ADSIEdit: Du startest adsiedit.msc. Rechtsklick auf ADSI-Editor, Verbindung herstellen. Auswahl "Bekannten Namenskontext", dort "Standardmäßiger Namenskontext" Im unteren Feld bei der oberen Option einen der beiden DCs auswählen. Rechtsklick auf die Domäne, Eigenschaften. In dem Fenster siehst du dann die diversen Attribute des "Domain Head", dort findest du auch die Felder zu den Kennworteigenschaften. Dann dasselbe noch mal ab dem zweiten Punkt dieser Liste, aber mit dem anderen DC. Sind die Werte identisch oder unterschiedlich? Ich bin gerade nicht mit einer Domäne verbunden und kann es nicht nachstellen, daher nur aus dem Kopf, sollte aber ungefähr so passen. Was findet sich im Eventlog? Was findet sich in dcdiag? Gruß, Nils

Moin, also ... für mich passen die Frage und die Antwort nicht zusammen. Das Abo ist einem User (also einer natürlichen Person) zugewiesen. Diese wird über ihren O365-Account identifiziert. Nur diese Person darf Office auf mehreren eigenen Rechnern nutzen und muss sich dabei mit dem zugewiesenen Account anmelden. Das Abo ist also auf mehreren Geräten, aber nur von einer Person zu nutzen. Franz' Antwort hat mit der Nutzung eines Service-Accounts nichts zu tun, sondern beschreibt nur einen Trick, um Geld zu sparen. Der Hinweis des "MS-Vertriebs" (was immer das hier heißen soll) scheint mir in der Tat jenseits der Lizenzbestimmungen zu liegen - wenn ich ihn richtig verstehe, dass hier die Zuweisung zu einer konkreten Person umgangen werden soll. (Und dann noch mit einer Anmerkung à la "wo kein Kläger, da kein Richter".) Gruß, Nils

Moin, also steht in der DDP etwas anderes als bei der Ausgabe von net accounts /domain? Noch zwei weitere Tests: was sagt netdom /query fsmo im CMD-Fenster? Wenn du adsiedit.msc öffnest und dir die Eigenschaften des Domänenobjekts ansiehst, was steht dort bei den Feldern, die die Kennworteigenschaften angeben? Kommen andere Werte zurück, wenn du adsiedit mit einem anderen DC verbindest? Es ist tatsächlich zu erwarten, dass sich im Eventlog was findet, denn es scheint wohl ein Problem zu geben. Was steht dort? Prüfe dabei alle Protokolle, die in Frage kommen, also auch die passenden unter "Anwendungs- und Dienstprotokolle". Weiterhin kann "dediag /E > c:\Pfad\dcdiag.txt" Aufschluss geben. Gibt es weitere Auffälligkeiten oder Probleme, die damit zusammenhängen könnten? In dem Fall würde ich nicht mehr zögern, sondern einen Call bei Microsoft eröffnen. Gruß, Nils

Moin, gut. Und was genau steht in der DDP bei den Kennwortrichtlinien drin? Dann zweiter Schritt: Was sagt ein RSoP? Gruß, Nils

Moin, dann ist etwas nicht so, wie du vermutet hast. Meist sind es keine Replikationsprobleme, sondern Fehler beim Einstellen. Fangen wir mal vorne an: Was für GPOs sind denn auf Domänenebene definiert? Es interessiert nur "ganz oben", weil Kennwortrichtlinien nur dort wirksam werden. In welchen davon sind welche Einstellungen für die Kennwörter vorgenommen? Gruß, Nils

Moin, was sagt denn net accounts /domain in einem CMD-Fenster dazu? Gruß, Nils

Moin, das sind eben die Beschränkungen des CMD-Interpreters. Solange du Basics wie copy usw. benutzt, bist du auf deren Spezifikationen festgelegt. Aus gutem Grund ist Abwärtskompatibilität bei Microsoft sehr wichtig, das ist eine wesentliche Ursache für deren kommerziellen Erfolg. Daher haben Uralt-Techniken eben oft auch uralte Beschränkungen. Manche Modernisierungen sind dann nachträglich drangestrickt, so etwa die Unterstützung langer Dateinamen und zusätzlicher Zeichen. Und genau in dem Bereich spielt sich das Phänomen ab, das du beobachtet hast. Da kann man sich natürlich auf den Standpunkt stellen, dass Windows "fette Bugs" habe und dass man für "so eine einfache Sache" nur die Basis-Tools verwenden will - aber dann kriegt man eben auch nur das, was die Basis-Tools halt können. Gruß, Nils

Moin, eine solche Umgebung würde ich nie ohne zentrales Management aufbauen oder betreiben. Ob man dafür ein "herkömmliches" AD verwendet, ein Azure AD oder was auch immer, hängt dann vom Konzept ab. Das ist aber zu groß für ein Forum. Falls deine Frage auch dahin ging, ob man in der derzeitigen Umgebung eine zentrale Analyse der vorhandenen Rechner machen kann: Geht sicher irgendwie, wird aber großer Aufwand. Gruß, Nils

Moin, entschuldige, aber deine Frage ist etwas durcheinander formuliert. Wonach fragst du jetzt genau? Gruß, Nils

Moin, das wenige, was man auf dem Bild erkennen kann, passt zu der Aussage, dass die Taskleiste nur eine Zeile hoch ist. Darüber ist es auf dem Bild schwarz, während die Taskleiste dunkelgrau ist. Für mich klingt das nach einem Treiberproblem. Insbesondere angesichts der im Eingangspost genannten Workarounds. Gruß, Nils

Moin, weil Franky schon ein Guter ist, aber es ja noch viele andere Gute gibt. Gruß, Nils

Moin, dass ein gelöschter User als SID in einem Berechtigungseintrag auftaucht, ist durchaus normal. Das Löschen eines Users bezieht sich immer nur auf das AD-Objekt, nicht auf nachgeordnete Systeme. Das eigentliche Problem, das du beschreibst, hat mit der Tatsache der Löschung sehr wahrscheinlich nichts zu tun. Hier scheinen Einträge in den ACLs nicht ganz korrekt zu sein. Das sieht man leider immer mal wieder. Es liegt wahrscheinlich daran, dass die ganze Vererbungs-Mechanik sozusagen nachträglich an NTFS angeflanscht wurde und je nach Situation nicht ganz korrekt funktioniert. Dazu kommt noch, dass der Explorer für sowas nicht eben das beste Werkzeug ist. Du könntest mal schauen, ob du dem Problem mit SetACL oder SetACL Studio abhelfen kannst. https://helgeklein.com/setacl/ https://helgeklein.com/setacl-studio/ Gruß, Nils

Moin, was immer "die Firewall" da macht, ich würde sie in den Kreis der Verdächtigen aufnehmen. Warum trägst du nicht die DNS-Server des Providers direkt als Forwarder in deine Windows-VMs ein? Dein Screenshot zeigt nur, dass "die Firewall" einen DNS-Client hat. Dass dort ein DNS-Server laufe, ist dem Bild nicht zu entnehmen. Gruß, Nils

Moin, ich nehme an, dass dein Setup schon korrekt ist. Deine Formulierung ist nicht völlig eindeutig, aber es sollte passen: Interner DNS-Server hat den externen DNS-Server als Forwarder eingetragen. Die Clients nutzen den internen DNS-Server. (Dabei sind die DNS-Server selbst auch DNS-Clients und müssen in ihrer IP-Konfiguration sich selbst bzw. sich gegenseitig fragen.) Fungiert die Firewall tatsächlich selbst als DNS-Server? Dann kann man deren IP-Adresse als Forwarder nehmen. Man spart sich aber einen Hop, wenn man als Forwarder gleich die Server des Providers einträgt. Die Fehler, die du im Eventlog siehst, können verschiedene Ursachen haben. Die genannten IP-Adressen scheinen zu einem Cloud-Service zu gehören. In vergleichbaren Situationen scheint sich eine Fehlkonfiguration der DNS-Forwarder als Ursache herausgestellt zu haben: http://eventid.net/display-eventid-5504-source-DNS-eventno-642-phase-1.htm Gruß, Nils

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

Moin, das Risiko ist gering, aber durchaus vorhanden. An dieser Stelle kann es durchaus sinnvoll sein, dir professionelle Unterstützung zu holen. Das wird kein riesiger Umfang sein. Gruß, Nils

Moin, ja, das verstehe ich schon. Solche durchaus legitimen Fragen führen aber leider oftmals zu Braindump-Empfehlungen, die wir hier nicht wollen. Es gibt durchaus auch seriöse Anbieter von Testprüfungen, die genau das von dir genannte Ziel verfolgen. Früher hat Microsoft auch mal welche empfohlen und sogar Trial-Versionen auf CD in den damaligen MS-Press-Büchern mitgeliefert. Die waren brauchbar, aber eben auch absichtlich keine 100-Prozent-Nachbildung der echten Prüfungen. Eine Webrecherche sollte dich da weiterbringen. Gruß, Nils