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.

@MurdocX Das sind eigentlich Camper-Module (WoMo-Dach) - weder das Garagentor noch der Gartenzaun eignen sich für "normale" Module, die sind viel zu breit. Oder zu lang. Oder zu schwer... https://1drv.ms/i/c/dfb9cfbc79e75468/ESHS8Y3iDBtFhko6wx2-pUQByHuiCoSFIN8DoJxvi9yJqg?e=Tu1NLL https://1drv.ms/i/c/dfb9cfbc79e75468/ETD0jj_3NxZNg7pqEy02fn0BBLcuwCkw-5McTvkDlZ0DYg?e=nm4i0o https://1drv.ms/i/c/dfb9cfbc79e75468/EWI5Wh_88ApChAlbpcV4O2kBBu81x8zoQHd4VrHXcO335g?e=rDexQS https://1drv.ms/i/c/dfb9cfbc79e75468/Ee8TURYNyt5AsRKqDam1_o8B8YyjHl74idXux99LQcPlZw?e=nkbaZf https://1drv.ms/i/c/dfb9cfbc79e75468/EUX-dp1vrHVOoolaI-fhZ4UB5DUpIt8tO-1I2HXRne-gog?e=GCUFMD Ich hoff mal daß die Links funktionieren. Gekauft bei Aliexpress - in Deutschland gibt's so was schlicht nicht. Oder nur zu homöopathischen Preisen...

Mehr Rendite als bei nem BKW kriegst grad nirgends. Stuttgart fördert die auch noch mit 200,- -> effektive Kosten unter 200,-... "Nobrainer" ist glaub das Buzzword dafür Und die Panels sind bei Aliexpress halt echt billig.

Ne, aber das brauch ich auch nicht. Entweder es produziert oder halt nicht - mit den paar Watt brauch ich hier nix xteuern, das versinkt im Grundverbrauch.

HMS-800W-2T - gibt's gelegentlich für unter 100,-. Keinen Bock auf Experimente mit Aliexpress, wo die 2-MPPT-Dinger auch nicht weniger kosten, aber dubiose Backends dahinter stecken. So sieht das am Garagentor jetzt aus. Kabel alle von den MC4-Steckern befreit, durch ein 6mm-Loch nach innen in nen Kabelkanal auf Höhe der Lücke zwischen den Panels gesteckt. Oben und unten jeweils in Reihe, die zwei dann parallel. WAF hat jedenfalls funktioniert

Jepp. Garage und Zaun. 15 Meter auseinander. An die Garage kommen 800w, an den Zaun 700. Die Panels sind 100w 900x530mm 18v/6A flex (Montagesituation ist schwierig - Standardpanels passen nirgends, und Verschattung ist auch ein Thema.)

Bräuchte man jetzt jemand mit Source Code Zugriff und -Verständnis, der prüfen kann, ob der RPC-Listener auch noch "Code dahinter" hat, der auf was reagiert... Oder ob die Firewall nur noch den Listener registriert, der aber auf nix antwortet.

Wenn er mit dem Test-TcpPorts den RPC-Port sieht, muss er wohl offen sein - ich hoffe ja, das war "remote" und nicht lokal

Hier trübe und feuchtwarm... Heute Balkonsolar 1,6 kWp bestellt (DYI mit 2 gedrosselten MWR, bei senkrechter Montage kommt nicht besonders viel raus).

Das ist dann seltsam... Kann ich jetzt spontan leider nicht erklären Die Portnummer ist wurscht, das ist RPC-Highport, die sind "random" ab 49152 aufwärts. Evtl. findest Du in nem Wireshark-Trace was, den Du auf dem Client mitschneidest, wo Du die MMC aufrufst. Mein Skript gibt leider "out of the box" die RPC Interface GUIDs nicht aus, hat sie intern aber. Vielleicht haben sie die GUID in 24H2 geändert, ich weiß es nicht.

# for hex 0x6d9 / decimal 1753 : EPT_S_NOT_REGISTERED winerror.h # There are no more endpoints available from the endpoint # mapper. Da gibt's keinen RPC-Listener... Kannst ja mal lokal und remote schauen, ob Du was findest: https://github.com/daabm/PowerShell/blob/master/Scripts/Test-TcpPorts.ps1 .\test-tcpports.ps1 -computer <IP-Adresse> -Ports 135 -IncludeEPM Da sollte ein RPC Highport auftauchen, der was mit Firewall im Namen hat. Kann Dir leider kein Beispiel dafür anbieten, hier läuft nix mehr "vor 24H2".