12
Registry Schlüssel suchen und neu erstellen
Hallo Forenmitglieder
Habe eine ziemlich knifflige Herausforderung. Ich habe Windows 10 Arbeitsstationen, welche nicht an einer AD angebunden sind. Somit kann ich nicht mit den AD GPOs arbeiten. Die lokalen GPOs haben gewisse Einträge nicht.
Das Problem ist wie folgt.
Ich habe Benutzer, welche sich über RDP an ihre Maschine im Geschäft anmelden. Bei Windows 10 ist beim Startmenu das Herunterfahren der Maschine in einer RDP Session möglich. Genau das möchte ich verhindern. Mit der registry Option NoClose könnte ich das Menu unsichtbar machen (da gibt es eine lokale Richtlinie), aber diese gilt generell für die Maschine. Das würde bedeuten, dass wenn der Benutzer sich lokal ander Arbeitsstation anmeldet, auch kein Herunterfahren knopf vorhanden ist. Das Herunterfahren Knopf soll aber nur in der RDP Session ausgeführt werden.
Ich habe nun folgendes herausgefunden.
Wenn sich der Benutzer an einer RDP Session anmeldet, wird ein neuer Schlüssel erstellt. Wie z.B
KEY_CURRENT_USER\Volatile Environment\17
SESSIONNAME REG_SZ Console
CLIENTNAME REG_SZ
Das Problem ist jedoch, dass die Zahl, in diesem Beispiel 17, jedes Mal neu erstellt wird.
Meine Idee wäre gesesen eine Batch zu schreiben, welche in der Registry den REG_SZ Schlüssel CLIENTNAME sucht. Wenn dieser vorhanden ist, dass ist eine Remotesession am laufen. Dann soll der NoClose Registry Schlüssel geschrieben werden und mit gpupdate /force alles sofort aktualisiert werden. Beim ausloggen von der RDP Session, soll der entsprechende Schlüssel
KEY_CURRENT_USER\Volatile Environment\17 <--- die Randomzahl gelöscht werden. Somit wird auch der Unterwert CLIENTNAME gelöscht. Meldet sich der Benutzer lokal an, wird nochmals überprüft, ob der REG_SZ CLIENTNAME vorhanden ist. Wenn nein, soll nichts unternommen werden.
Meldet sich der Benutzer neu an die RDP Session an, wird ein neuer REG_SG Schlüssel generiert z.B. KEY_CURRENT_USER\Volatile Environment\6 mit den entsprechenden CLIENTNAME REG_SZ
Das macht es schwierig diesen Schlüssel abzufangen.
Dazu kommt noch, dass die Output Dateien HKEY_CURRENT_USER enthalten. Möchte ich aber mit reg delete arbeiten müsste HKEY_CURRENT_USER in HKCU abgeändert werden. Das wird für meine Kenntnisse sehr komplex
Ich habe mal mit ein paar Batch Dateien versucht etwas zu basteln, beisse aber in die Tischplatte. Ich kriege es nicht hin.
Meine Batch Dateien lesen im Augenblick nur die Registry aus. Hier ein Beispiel
VolEnvQuery.cmd
@echo off
echo "Liest das Volatile Enfironment aus"
rem reg query "HKCU\Volatile Environment" /s > "%~dp0regquery.txt"
reg query "HKCU\Volatile Environment" /s /v "CLIENTNAME">"%~dp0regquery.txt"
SetVolEnvOut.cmd
echo off
rem PowerShell.exe -WindowStyle Hidden "unterdrückt die Powershell Konsole
PowerShell.exe Set-ExecutionPolicy Unrestricted
PowerShell.exe "%~dp0VolEnv.ps1"
PowerShell.exe Set-ExecutionPolicy Restricted
$OrgWSLoc = Get-Location
Get-Content -Path "$OrgWSLoc\regquery.txt" | select -last 4 | select -first 1 | Out-File "$OrgWSLoc\output.txt"
Könnte mir jemand eine Lösung anbieten, welche ich verwenden könnte? Ich weiss sonst nicht, wie ich das Problem lösen könnte
Danke im Voraus für Eure Hilfe.
Habe eine ziemlich knifflige Herausforderung. Ich habe Windows 10 Arbeitsstationen, welche nicht an einer AD angebunden sind. Somit kann ich nicht mit den AD GPOs arbeiten. Die lokalen GPOs haben gewisse Einträge nicht.
Das Problem ist wie folgt.
Ich habe Benutzer, welche sich über RDP an ihre Maschine im Geschäft anmelden. Bei Windows 10 ist beim Startmenu das Herunterfahren der Maschine in einer RDP Session möglich. Genau das möchte ich verhindern. Mit der registry Option NoClose könnte ich das Menu unsichtbar machen (da gibt es eine lokale Richtlinie), aber diese gilt generell für die Maschine. Das würde bedeuten, dass wenn der Benutzer sich lokal ander Arbeitsstation anmeldet, auch kein Herunterfahren knopf vorhanden ist. Das Herunterfahren Knopf soll aber nur in der RDP Session ausgeführt werden.
Ich habe nun folgendes herausgefunden.
Wenn sich der Benutzer an einer RDP Session anmeldet, wird ein neuer Schlüssel erstellt. Wie z.B
KEY_CURRENT_USER\Volatile Environment\17
SESSIONNAME REG_SZ Console
CLIENTNAME REG_SZ
Das Problem ist jedoch, dass die Zahl, in diesem Beispiel 17, jedes Mal neu erstellt wird.
Meine Idee wäre gesesen eine Batch zu schreiben, welche in der Registry den REG_SZ Schlüssel CLIENTNAME sucht. Wenn dieser vorhanden ist, dass ist eine Remotesession am laufen. Dann soll der NoClose Registry Schlüssel geschrieben werden und mit gpupdate /force alles sofort aktualisiert werden. Beim ausloggen von der RDP Session, soll der entsprechende Schlüssel
KEY_CURRENT_USER\Volatile Environment\17 <--- die Randomzahl gelöscht werden. Somit wird auch der Unterwert CLIENTNAME gelöscht. Meldet sich der Benutzer lokal an, wird nochmals überprüft, ob der REG_SZ CLIENTNAME vorhanden ist. Wenn nein, soll nichts unternommen werden.
Meldet sich der Benutzer neu an die RDP Session an, wird ein neuer REG_SG Schlüssel generiert z.B. KEY_CURRENT_USER\Volatile Environment\6 mit den entsprechenden CLIENTNAME REG_SZ
Das macht es schwierig diesen Schlüssel abzufangen.
Dazu kommt noch, dass die Output Dateien HKEY_CURRENT_USER enthalten. Möchte ich aber mit reg delete arbeiten müsste HKEY_CURRENT_USER in HKCU abgeändert werden. Das wird für meine Kenntnisse sehr komplex
Ich habe mal mit ein paar Batch Dateien versucht etwas zu basteln, beisse aber in die Tischplatte. Ich kriege es nicht hin.
Meine Batch Dateien lesen im Augenblick nur die Registry aus. Hier ein Beispiel
VolEnvQuery.cmd
@echo off
echo "Liest das Volatile Enfironment aus"
rem reg query "HKCU\Volatile Environment" /s > "%~dp0regquery.txt"
reg query "HKCU\Volatile Environment" /s /v "CLIENTNAME">"%~dp0regquery.txt"
SetVolEnvOut.cmd
echo off
rem PowerShell.exe -WindowStyle Hidden "unterdrückt die Powershell Konsole
PowerShell.exe Set-ExecutionPolicy Unrestricted
PowerShell.exe "%~dp0VolEnv.ps1"
PowerShell.exe Set-ExecutionPolicy Restricted
$OrgWSLoc = Get-Location
Get-Content -Path "$OrgWSLoc\regquery.txt" | select -last 4 | select -first 1 | Out-File "$OrgWSLoc\output.txt"
Könnte mir jemand eine Lösung anbieten, welche ich verwenden könnte? Ich weiss sonst nicht, wie ich das Problem lösen könnte
Danke im Voraus für Eure Hilfe.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 381525
Url: https://administrator.de/forum/registry-schluessel-suchen-und-neu-erstellen-381525.html
Ausgedruckt am: 07.04.2025 um 20:04 Uhr
12 Kommentare
Neuester Kommentar
Boardsuche
Herunterfahren RDP Windows 10 verhindern
Herunterfahren RDP Windows 10 verhindern
Hallo Kraemer
Diesen Artikel hatte ich auch schon gefunden, funktioniert aber nicht und zwar aus folgenden Gründen.
HKEY_CURRENT_USER\ Software\ Microsoft\ Windows\ CurrentVersion\ Policies\ Explorer hat der Benutzer keiner Rechte etwas zu schreiben. Keine Ahnung wieso.
Also musste ich den Wert NoClose auf HKEY_LOCAL_MACHINE\ Software\ Microsoft\ Windows\ CurrentVersion\ Policies\ Explorer anwenden
zudem gelten diese Schlüssel für die RDP sowie lokale Anmeldungen.
Meldet sich der Benutzer von seinem PC zu hause über RDP auf die entfernte Arbeitsstation "A", dann ist das Herunterfahren ausgeblendet. Nun meldet sich Angwender direkt an dieser Arbeitsstation "A" an, fehlt ihm dann das Herunterfahren auch, da dieser Registry Schlüssel für den Benutzer oder Workstation ist und keine Unterscheidung gemacht wird, ob sich der Benutzer an der Arbeitsstation "A" lokal, oder über RDP anmeldet.
Diesen Artikel hatte ich auch schon gefunden, funktioniert aber nicht und zwar aus folgenden Gründen.
HKEY_CURRENT_USER\ Software\ Microsoft\ Windows\ CurrentVersion\ Policies\ Explorer hat der Benutzer keiner Rechte etwas zu schreiben. Keine Ahnung wieso.
Also musste ich den Wert NoClose auf HKEY_LOCAL_MACHINE\ Software\ Microsoft\ Windows\ CurrentVersion\ Policies\ Explorer anwenden
zudem gelten diese Schlüssel für die RDP sowie lokale Anmeldungen.
Meldet sich der Benutzer von seinem PC zu hause über RDP auf die entfernte Arbeitsstation "A", dann ist das Herunterfahren ausgeblendet. Nun meldet sich Angwender direkt an dieser Arbeitsstation "A" an, fehlt ihm dann das Herunterfahren auch, da dieser Registry Schlüssel für den Benutzer oder Workstation ist und keine Unterscheidung gemacht wird, ob sich der Benutzer an der Arbeitsstation "A" lokal, oder über RDP anmeldet.
Wer lässt seine User schon als Admin per RDP arbeiten?? Koppschüttel ... Denn nur die hier haben dass Recht eine Kiste runter zu fahren:
Also raus aus den Gruppen und sie bekommen den Eintrag auch nicht zu gesicht. Btw. als Admin haben die auch andere Möglichkeiten die Kiste auszuschalten.
Grüße Uwe
Also raus aus den Gruppen und sie bekommen den Eintrag auch nicht zu gesicht. Btw. als Admin haben die auch andere Möglichkeiten die Kiste auszuschalten.
Grüße Uwe
Hallo Uwe
Wenn du diesen Eintrag entfernst, kannst du, wenn du dich lokal an der Arbeitsstation anmeldest, diese auch nicht mehr herunterfahren, da der Knopf ebenfalls fehlt.
Ich fasse nochmals zusammen:
Arbeitsstation A ist die Arbeitsstation, welche im Geschäft läuft (diese ist nicht an einer AD angebunden)
Benutzer meldet sich von zu Hause aus über RDP an Arbeitsstation A an. Herunterfahren ist deaktiviert.
Nun kommt der Benutzer ins Geschäft und arbeitet an Arbeitsstation A und möchte diese aus irgend einem Grund herunterfahren. Geht nicht, da er keine Berechtigung hat
Wenn du diesen Eintrag entfernst, kannst du, wenn du dich lokal an der Arbeitsstation anmeldest, diese auch nicht mehr herunterfahren, da der Knopf ebenfalls fehlt.
Ich fasse nochmals zusammen:
Arbeitsstation A ist die Arbeitsstation, welche im Geschäft läuft (diese ist nicht an einer AD angebunden)
Benutzer meldet sich von zu Hause aus über RDP an Arbeitsstation A an. Herunterfahren ist deaktiviert.
Nun kommt der Benutzer ins Geschäft und arbeitet an Arbeitsstation A und möchte diese aus irgend einem Grund herunterfahren. Geht nicht, da er keine Berechtigung hat
Zitat von @Ralus67:
Hallo Uwe
Wenn du diesen Eintrag entfernst, kannst du, wenn du dich lokal an der Arbeitsstation anmeldest, diese auch nicht mehr herunterfahren, da der Knopf ebenfalls fehlt.
Ich fasse nochmals zusammen:
Arbeitsstation A ist die Arbeitsstation, welche im Geschäft läuft (diese ist nicht an einer AD angebunden)
Benutzer meldet sich von zu Hause aus über RDP an Arbeitsstation A an. Herunterfahren ist deaktiviert.
Nun kommt der Benutzer ins Geschäft und arbeitet an Arbeitsstation A und möchte diese aus irgend einem Grund herunterfahren. Geht nicht, da er keine Berechtigung hat
Runterfahren können sie die Kiste auch auf andere Weise trotzdem auch wenn der Eintrag dort nicht vorhanden ist! Ist also Blödsinn.Hallo Uwe
Wenn du diesen Eintrag entfernst, kannst du, wenn du dich lokal an der Arbeitsstation anmeldest, diese auch nicht mehr herunterfahren, da der Knopf ebenfalls fehlt.
Ich fasse nochmals zusammen:
Arbeitsstation A ist die Arbeitsstation, welche im Geschäft läuft (diese ist nicht an einer AD angebunden)
Benutzer meldet sich von zu Hause aus über RDP an Arbeitsstation A an. Herunterfahren ist deaktiviert.
Nun kommt der Benutzer ins Geschäft und arbeitet an Arbeitsstation A und möchte diese aus irgend einem Grund herunterfahren. Geht nicht, da er keine Berechtigung hat
Meinst du mit Shutdown /f /t 0
Nicht alle Anwender kennen diesen Befehl und ich denke, dass sollte den Benutzern auch nicht unter die Nase gestrichen werden....
Oder wie hast du das gedacht? Welche Möglichkeit siehst du?
Nicht alle Anwender kennen diesen Befehl und ich denke, dass sollte den Benutzern auch nicht unter die Nase gestrichen werden....
Oder wie hast du das gedacht? Welche Möglichkeit siehst du?
Min jung, ein User der Mitglied der lokalen Administratoren ist kann alles verändern und machen auch deine Beschränkungen wieder rückgängig, deswegen bringt deine Bastelei hier rein gar nichts, Administratoren dürfen nun mal einfach alles an der Kiste. Also die User in eine als aller erstes in eine andere Gruppe packen. Möglichkeiten zum Runterfahren lassen sich auf andere Weise geben, bspw. über einen Task den der User anwirft.
Meine Benutzer sind nicht Mitglieder der lokalen Administratoren Gruppe
Dann sind sie aber in einer Gruppe oder über eine verschachtelte Mitgliedschaft Mitglied einer Gruppe die die Kiste herunterfahren darf und das ist der Fehler.
Man kann es nicht oft genug vorbeten
https://social.technet.microsoft.com/Forums/sharepoint/en-US/0f1bb07c-54 ...
Man kann es nicht oft genug vorbeten
https://social.technet.microsoft.com/Forums/sharepoint/en-US/0f1bb07c-54 ...
Hallo Colinardo
Nein, das ist nicht die Lösung. Bei Windows 10 ist das Verhalten speziell.
Die Lösungen welche du mir geschickt hast, sind alles Lösungen mit Active Directory Domäne. Meine Windows 10 Arbeitsstationen sind in einer Workgroup. Das gibt es im 2018 immer noch.....
Probiere es mal selber aus. Erstelle dir eine virtuelle Window 10 Maschine und führe eine RDP Session zu dieser Maschine aus. Du wirst als "normalen" Benutzer das Herunterfahren haben. Wenn du die lokalen Policies gemäss Anleitung anwendest, wird zwar über RDP das Herunterfahren deaktiviert sein, aber auch bei einer lokalen Anmeldung auf die Arbeitsstation, das heisst über eine Konsolenanmeldung. Dort wird das Herunterfahren dann auch fehlen.
Nein, das ist nicht die Lösung. Bei Windows 10 ist das Verhalten speziell.
Die Lösungen welche du mir geschickt hast, sind alles Lösungen mit Active Directory Domäne. Meine Windows 10 Arbeitsstationen sind in einer Workgroup. Das gibt es im 2018 immer noch.....
Probiere es mal selber aus. Erstelle dir eine virtuelle Window 10 Maschine und führe eine RDP Session zu dieser Maschine aus. Du wirst als "normalen" Benutzer das Herunterfahren haben. Wenn du die lokalen Policies gemäss Anleitung anwendest, wird zwar über RDP das Herunterfahren deaktiviert sein, aber auch bei einer lokalen Anmeldung auf die Arbeitsstation, das heisst über eine Konsolenanmeldung. Dort wird das Herunterfahren dann auch fehlen.
Nein, auch in Workgroups kein Problem.
Das ist eine Systemweite Einstellung, die kann sich nicht über die Nutzerrechte in den lokalen Policies hinwegsetzen.
Probiere es mal selber aus. Erstelle dir eine virtuelle Window 10 Maschine und führe eine RDP Session zu dieser Maschine aus. Du wirst als "normalen" Benutzer das Herunterfahren haben.
Weiß ich, das versuche ich dir ja gerade klar zu machen. Nehme den Benutzern generell erst mal das Recht herunterzufahren, das geht auch lokal ohne Domäne, dann gibst du ihnen die Möglichkeit per Task der mit entsprechenden Rechten ausgestattet ist und Verknüpfung auf dem Desktop oder Startmenü um die Kiste runter zu fahren, fertig. Anders herum wirst du nie verhindern das sie egal mit welchem Mittel cmd/powershell/sysinternals/etc. die Kiste auszuschalten!Das ist eine Systemweite Einstellung, die kann sich nicht über die Nutzerrechte in den lokalen Policies hinwegsetzen.
Hallo Colinardo.
Ja, das mit der Shutdown Verknüpfung auf dem Desktop hatte ich mir auch schon überlegt. Ich wollte jedoch das so belassen, dass die Benutzer über den üblichen Windows Knopf die Maschine herunterfahren können.
Naja... suchen wir da nicht weiter.....
Ja, das mit der Shutdown Verknüpfung auf dem Desktop hatte ich mir auch schon überlegt. Ich wollte jedoch das so belassen, dass die Benutzer über den üblichen Windows Knopf die Maschine herunterfahren können.
Naja... suchen wir da nicht weiter.....
