daabm

"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.

Weitere Möglichkeiten: In dem VBS die Eingabe in Umgebungsvariablen zu speichern. Oder in dem VBS eine CMD zu erstellen, die nur SET aufruft, und die dann in der ursprünglichen CMD nach dem VBS aufrufen. Und dann gibt es auch noch ganz trivial "set /p"

Wenn Du gpresult in System32 ausführst, mußt Du das als Admin tun. Und wenn Du scope:computer haben willst, auch. Hast Du auch mal ins Application Eventlog geschaut? Und ins System Eventlog? Und wenn Du da nix findest, aktiviere gpsvc Debug Logging: https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/a-treatise-on-group-policy-troubleshooting-8211-now-with-gpsvc/ba-p/400304

Heute neuen Luftentfeuchter installiert und in Betrieb genommen. Aufgrund der aktuellen Wetterlage hat der Keller aber eh nicht mehr 80% rF, sondern nur noch ~60%. Und die taupunktdifferenzgesteuerte aktive Belüftung meldet ein dTP von 3° - damit kann man arbeiten Das Elend war ja nur, daß es über Wochen draußen extrem warm und dazu noch sehr feucht war, das krieg ich nicht raus.

Spoiler: "robocopy /mon" macht genau was der TO will. Bräuchte halt pro Ziel einen Task, in dem der läuft. Und soweit ich weiß, nutzt Robocopy dabei kein Polling, sondern einen File System Watcher - also mit "nahe null" Systemlast.

Hat nichts mit dem 08/2024 zu tun, bedeutet lediglich, daß es für den aktuell angemeldeten Benutzer keinen RSoP gibt. Warum? Remote schwer zu sagen... Ich würde das mal per GPMC verifizieren. Und im GPO-Eventlog findet man dazu meistens auch sinnvolle Hinweise (Tip: Erst löschen, dann nacheinander "gpupdate /target:computer" und "gpupdate /target:user" ausführen, dann hat man das einigermaßen nachvollziehbar. Ein einfacher "gpupdate" macht gleichzeitig Computer und User, dann wird das Log etwas b***d zu lesen )

Schwierig, wenn kein Platz mehr frei ist Ich würde auch den Tausch erwägen, aber wenn das finanziell nicht darstellbar ist sollte der Plan mit sagerun funktionieren.

Im Gewölbekeller "noch" 22°, aber das ist echt hart. Der Keller wird feuchter und feuchter, und ich kann nichts dagegen tun, weil die Außenluft so unglaublich warm ist. Wenn die auf 22° abkühlt, fängt es fast schon an zu tauen... Taupunkt im Keller aktuell 19° und auch draußen, dort allerdings bei 29° Lufttemperatur. Da wird's im Keller nicht trockener, wenn ich die Außenluft mit ihren 55% rF in den Keller puste, wo es eh schon 80% rF hat 😒

Und warum sollte da "alter DC" nicht stehen, wenn der läuft und arbeitet? Woher soll der Client wissen, daß Du das nicht willst? BTW: AD kennt keine "alten" und "neuen" DCs, das kennt nur "DC" oder "nicht DC".

Wir haben im Herbst wieder ne Planstelle frei 😂 Wollen das nicht alle? Außer denen, die noch nicht wissen, wie der DCLocator über Forests funktioniert https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/how-domain-controllers-are-located-across-trusts/ba-p/256180 https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/how-dcs-are-located-across-forest-trusts-part-two/ba-p/257293

Ersetze "sich selbst" durch "was ich als Admin möchte", dann bin ich damit einverstanden AD-integriertes DNS ist zwar einfach, aber muss nicht sein - AD ist bezüglich DNS ziemlich agnostisch.

Auf einem DC möchtest Du das NICHT machen...

Privat. Da steht nur wenig, was mit meinem Beruf zu tun hat Vor allem nicht "heute noch" - ein Commodore 4040 ist irgendwie nicht mehr en vogue 😂