NilsK

Moin, klar, das machen die schon seit Jahren. Die NFS-Lizenz ist auch eine der teuersten, die sie im Angebot haben ... Gruß, Nils

Moin, wie du merkst, ist das per Forum etwas mühsam. Meine Empfehlung: Hol dir jemanden ins Haus. So wild kann es nicht sein, aber man kann sich das vor Ort im Zusammenhang besser ansehen. Gruß, Nils

Moin, mal langsam. Nur weil ein Teil eines Community-Programms nach über 15 Jahren eingestellt wurde, stellt Microsoft ja noch lange nicht die Technik als solche ein. Microsofts Weg in die Cloud dürfte nach all den Jahren wirklich niemanden mehr überraschen. Man muss sich also auch nicht bei jeder Erwähnung drüber aufregen. "On-prem" passiert nur noch vergleichsweise wenig, aber es funktioniert weiter, wird weiter supportet und es wird auch noch dran entwickelt. Dass das möglicherweise weniger ist als man als Kunde oder Experte möchte, war in Wirklichkeit vor 15 Jahren auch schon so, wenn auch vielleicht auf etwas anderem Niveau. Wer Cloud nicht will, muss ja nicht. Auch mit Microsoft-Produkten. Die eine oder andere Technik mag ein Auslaufmodell sein, aber das ist nach so langer Zeit auch nicht verwunderlich - und es geht auch nicht so schnell, dass einem in absehbarer Zeit ein Ast fehlen würde. Gruß, Nils

Moin, Salbei. Du meinst sicher Salbei. Gruß, Nils

Moin, korrekt, das ist meiner Erinnerung nach auch schon seit Windows 2000 so. Relativ unbekannt, aber Tatsache. Die genannten Umgebungen mit nur einem DC haben halt an der falschen Stelle gespart, wenn sie das so gewichten. Wir betonen ja nicht umsonst hier immer wieder, dass man einen zweiten DC schon für ca. 1000 Euro inkl. Lizenz haben kann. Gruß, Nils

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