daabm

Hier 25, die sich wie 38 angefühlt haben - deutlich zu feucht das ganze 🙈

Nö hilft nicht, weil das Ende fehlt... Womit hören die Zeilen auf? Also was ist der komplette Inhalt einer Zeile? Und nein, das ist NICHT standardkonform.

Ne, da war nur das ILT für Gruppenmitgliedschaften im Editor "broken". Ich würd ja das GPMC/GPEdit Debug Logging mal anschmeißen - der TO findet bestimmt raus, wie das geht Und wenns nix hilft: DC wegwerfen und neu machen... Was WinHTTP damit zu tun haben könnte, erschließt sich mir nicht.

Was haben GPOs und Loginskripte mit einem vermurksten Verfügbarkeitskonzept für einen Fileservice zu tun? Wenn Du nur erzählen willst, was Du für Probleme hast und wie Du sie löst, bist Du hier mittelfristig falsch.

Nein, das war damals schon falsch. Es gibt einen Grund, daß Windows-Fileservices im RZ-Betrieb quasi bedeutungslos sind. Besorg Dir 2 Syno/QNap/Netapp/whatever und schieb das Zeug auf Storage, der für sowas gedacht ist.

Wenn DFSR funktionieren würde, sind da genau so viele Änderungen wie auf Server a. Das Konzept hinkt... Aber das steht ja oben schon oft genug. Und wenn Du nicht so verliebt in "deine" Lösung wärst, könnten wir hier sogar über Alternativen reden

Zum Reinschnuppern vom Autor selbst: https://learn.microsoft.com/en-us/sysinternals/resources/webcasts#case-of-the-unexplained

Vermutlich nicht, aber das vergoldete Waschbecken in der Garage... 😂

Ist der Trend nicht Virtualisierung? Warum muss das Linux-System auf dem Blech laufen? Oder warum das Windows-System? Geht in beiden Varianten auch virtuell und macht vieles einfacher.

@cj_berlin hat recht wie fast immer msDS-UserPasswordExpiryTimeComputed : 9223372036854775807 Name : Administrator PS Y:\> net user administrator /dom Benutzername Administrator Konto aktiv Ja Konto abgelaufen Nie Letztes Setzen des Kennworts 26.10.2013 18:07:23 Kennwort l„uft ab Nie @NilsK Computed Property...

Was @cj_berlin sagt, meinte ich auch. Das ist doch kein Fehler, das ist vermutlich (wieder Kaffeesatz, ich hab keinen Sourcecode-Zugriff) ein Teil des DFS-Clients, daß er Referrals eben so enumeriert wie er es halt tut. Du kannst jederzeit Server B aus der DFSR-Gruppe werfen, den Share woanders neu aufsetzen, die Dateien pre-stagen (Google hilft - "robocopy /sec") und ihn dann wieder reinnehmen.

GPResult /h report.html ist unser Freund Da steht ganz viel dazu drin.

"Kaffeesatz", weil das ja kein Problem verursacht, sondern nur Neugier ist: Der DFS-Client enumeriert alle Referrals (egal ob aktiv oder nicht) und macht - aus unbekannten Gründen - einen Tree Connect auf die Shares. Könnte man im NW-Trace sehen. Die drei Sub-Befehle von dfsutil cache könnten auch noch ein wenig helfen.

Gern geschehen Wenn man mal weiß, nach was man suchen muß, ist die Lösung oft ganz einfach 👍

"StrictNameChecking" und "LoopbackCheck" als Stichworte - von DNS-Aliasen stand da nichts bisher...

Falsche Sehhilfe...

Ich würd ja einfach den Code von CreateUser in die ISE kopieren, die Variablen passend füllen und das mal ausführen. Spoiler-Alert: -Path ist nicht der DN des Users, sondern der DN der OU, in der er erstellt werden soll.

Kerberos oder NTLM? Und gibt es Firewalls, die Zugriffe zwischen Client, Server und allen beteiligten DCs blockieren könnten? Du könntest übrigens auch mal auf dem Server ins Eventlog schauen (System/Security/NTLM/xyz). Da würde dann vermutlich mehr stehen. Und Du kannst natürlich auch noch einen NW-Trace machen - was lokal aber schwierig ist, weil das nicht über den NW-Stack läuft (wo der Trace abgefangen wird), sondern nur über den MUP. Du siehst schon - per Forum eher schwer zu lösen, aber sicher was eher triviales

Durch ein Loch, das ich oben in der Mitte reinbohre...

Die rF im Keller spielt fröhlich Pingpong. Vorgestern noch 50%, heute wieder 70%... Ich füll den irgendwann einfach mit Fließbeton auf, dann ist Ruhe

"Irgendwann sperre ich die bösen Jungs wieder aus, die sich durch die ganzen Sicherheitslücken meiner veralteten Infrastruktur eingeschlichen haben"... SCNR

Process Monitor ist gut.

Ich hab bestimmt schon viele gpsvc.log gesehen - aber noch nie ein so nichtssagendes... Da stimmt irgendwas nicht, sicher daß das von den Timestamps her zu Deinem gpupdate /target:user passt? Ansonsten lösch das einfach mal, boote neu und kontaktiere mich mit dem vollständigen Log (nach Benutzeranmeldung) per PN. Macht mich schon neugierig, was da schiefgeht

("Es steht im Internet, also muss es _NICHT_ wahr sein" )

Stimmt leider nicht. Wenn der aktuelle User keine RSoP-Daten hat, fällt GPResult auf die Nase. Auch bei /scope:Computer. Das geht dann nur mit GPMC (interaktiv oder mit dem COM-API). "gpupdate /force" ist auch in dem Fall immer noch flüssiger als Wasser. Und nach der Ursache forscht man im GPO-Eventlog oder im gpsvc-Debuglog. Nicht per "try and error" durch wahlfreie Aktionen in AD.