daabm

Für's nächste Mal: Ein vollständiges Event wäre in solchen Fällen immer hilfreich, da gibt's relativ viele Felder mit Status- und Errorcodes.

Mach nen Batch-Wrapper, der vorher per cmdkey /delete den Server aus den Anmeldeinformationen entfernt. Dann kommt immer die Abfrage mit Kennwort und Benutzer. Sonst kommt immer nur die Abfrage mit Kennwort. Ich gehe mal davon aus, daß Du von einer shared Workstation redest, wo ein technischer User angemeldet ist und dann die RDP-Verbindung mit dem tatsächlichen User erfolgen soll. Da wäre auch noch möglich (siehe oben) einen Wrapper drum rum zu bauen, der User-ID und Kennwort abfragt und per cmdkey /add in die Anmeldeninformationen schreibt. Und danach halt wieder entfernt. Am Ende wird es auf einen Trick rauslaufen, der mit Get-Credential und cmdkey.exe Dinge zaubert

Wenn Du noch selbst einkaufen gehst und nicht alles liefern lässt, kannst Du Weihnachten nicht übersehen - geht schon los in den großen Supermärkten... Ist nur unsere fortgeschrittene Expertise in Prokrastination, die das zum Problem werden lässt

Das hat schon fast was von Cross-Selling

Bissele offtopic möglicherweise - aber bei Parametern, die komplett offensichtlich sind, lasse ich gern den Parameternamen weg. Das erhöht die Lesbarkeit oft deutlich

Danke Was auch immer Du genau gemacht hast - lass mich bloß mit KI in Ruhe. Intelligent ist daran gar nichts...

Da fehlen die Anführungszeichen...

Gesagt, getan: https://github.com/daabm/PowerShell/tree/master/Scripts https://github.com/daabm/PowerShell/blob/master/Scripts/Invoke-SysvolD4Restore.ps1 Error handling ist verbesserungswürdig - aber wenn es nicht funktioniert, gibt es strukturelle Probleme in der Infrastruktur, die so variabel sind dass ein Skript sie nicht sinnvoll diagnostizieren kann.

Wir blocken outbound im public profile. War etwas Herzrasen beim Rollout (6-stellige Anzahl Clients - wehe die finden keine Domäne mehr...), funktioniert aber einwandfrei. Und braucht auch keine große Pflege. Im domain profile ist outbound offen - das würden wir nicht verwaltet kriegen, zu viele Sonderlocken... Nachtrag: "Bei uns im Netzwerk" ist etwas kurz gegriffen - was ist mit Laptops unterwegs oder zuhause?

Doch, kannst Du. Lösch einfach mal c:\windows\system32\grouppolicy (oder schau vorher, was drin ist und benenn dann einfach um). Die registry.pol ist in notepad etwas b***d zu lesen, weil die Signatur ASCII ist, der Rest aber Unicode. Man versteht es aber trotzdem ein wenig

Feststellung - Skript lungert schon ewig fertig rum und wurde auch schon erfolgreich in Multi-Domain/Multi-Forest Umgebungen erprobt, funktioniert wie die Eins Ich bin so einer, wenn ich Codesamples im Netz zusammensuche, dann gebe ich das Ergebnis gern zurück.

Erinnert mich dran, daß ich mein Fixup-Skript für Sysvol-DFSR mal auf Github schmeißen sollte

Der PW-Reset ändert ja auch nichts an Problemen in der technischen Infrastruktur Was DNS mit der Uhrzeit zu tun hat, kann ich grad nicht nachvollziehen. Was liefert denn in cmd.exe ein klist purge & klist get host/%computername% auf dem problematischen Client in dem Moment? Und man kann auch das Kerberos-Logging ein wenig hochdrehen - https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-kerberos-event-logging (würde ich in dem Fall erst mal nur auf ein paar Clients machen) #0 ist das TGT, #1 ist das TGS für den Client. Aktuelle Anmelde-ID ist 0:0x1818c1 Ein Ticket f?r host/<Clientname> wurde erfolgreich abgerufen. Zwischengespeicherte Tickets: (2) #0> Client: <Username> @ <Domain-FQDN> Server: krbtgt/<Domain-FQDN> @ <Domain-FQDN> KerbTicket (Verschl?sselungstyp): AES-256-CTS-HMAC-SHA1-96 Ticketkennzeichen 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize Startzeit: 9/2/2025 17:41:24 (lokal) Endzeit: 9/3/2025 3:41:24 (lokal) Erneuerungszeit: 9/9/2025 17:36:30 (lokal) Sitzungsschl?sseltyp: AES-256-CTS-HMAC-SHA1-96 Cachekennzeichen: 0x1 -> PRIMARY KDC aufgerufen: <DC-FQDN> #1> Client: <Username> @ <Domain-FQDN> Server: host/<Clientname> @ <Domain-FQDN> KerbTicket (Verschl?sselungstyp): AES-256-CTS-HMAC-SHA1-96 Ticketkennzeichen 0x40a10000 -> forwardable renewable pre_authent name_canonicalize Startzeit: 9/2/2025 17:41:24 (lokal) Endzeit: 9/3/2025 3:41:24 (lokal) Erneuerungszeit: 9/9/2025 17:36:30 (lokal) Sitzungsschl?sseltyp: AES-256-CTS-HMAC-SHA1-96 Cachekennzeichen: 0 KDC aufgerufen: <DC-FQDN>

Ich werfe dann noch mmc.exe mit dem gpedit Snapin in den Raum, das macht das mit den lokalen Richtlinien noch mal etwas komplizierter Sollte man schlicht abschalten - https://gpsearch.azurewebsites.net/#318 Dann weiß man immer, wo man zuerst suchen muss.

Nachtrag: Geht nicht mit den HMS-800W-2T Wechselrichtern. Problem ist das "W" - die haben WLAN und die DTU ist integriert bzw. gibt es nicht mehr.