15
Es sind keine Energieoptionen verfügbar
Servus
Leider lässt sich bei mir in der Domäne kein Rechner mehr herunterfahren, wenn man unten links im Menü das Power Symbol kommt erscheint nur die Meldung im Titel.
Zudem lässt sich es auch absolut nicht identifizieren woher das kommt, als ich mal meinen Testbenutzer umbenannt habe und eine GPO (Laufwerkszuordnung) gelöscht habe ging das ganze los. Aktuell sind 3 GPOs aktiv die ebenfalls nur stinknormale Laufwerkszuorndungen sind.
Ich weiß nicht wie oft ich jetzt schon meine GPOs kontrolliert habe ob da irgendwas mit Energie oder sonst was eingestellt wurde, aber es ist nicht der fall.
Wenn ich mir per CMD anschaue was da angewendet wird (gpresult /r), sehe ich da auch nichts was das herunterfahren verbietet.
Leider weiß ich nicht weiter und muss hier auf Hilfe hoffen.
Leider lässt sich bei mir in der Domäne kein Rechner mehr herunterfahren, wenn man unten links im Menü das Power Symbol kommt erscheint nur die Meldung im Titel.
Zudem lässt sich es auch absolut nicht identifizieren woher das kommt, als ich mal meinen Testbenutzer umbenannt habe und eine GPO (Laufwerkszuordnung) gelöscht habe ging das ganze los. Aktuell sind 3 GPOs aktiv die ebenfalls nur stinknormale Laufwerkszuorndungen sind.
Ich weiß nicht wie oft ich jetzt schon meine GPOs kontrolliert habe ob da irgendwas mit Energie oder sonst was eingestellt wurde, aber es ist nicht der fall.
Wenn ich mir per CMD anschaue was da angewendet wird (gpresult /r), sehe ich da auch nichts was das herunterfahren verbietet.
Leider weiß ich nicht weiter und muss hier auf Hilfe hoffen.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 52696577535
Url: https://administrator.de/contentid/52696577535
Printed on: May 8, 2024 at 09:05 o'clock
15 Comments
Latest comment
Moin,
welche Einstellungen zeigt dir denn ein rsop auf einem betreffenden Client?
Gruß
Spirit
welche Einstellungen zeigt dir denn ein rsop auf einem betreffenden Client?
Gruß
Spirit
Zitat von @Spirit-of-Eli:
welche Einstellungen zeigt dir denn ein rsop auf einem betreffenden Client?
Hatte ich auch schon durchgeschaut, leider nix gefunden was darauf hindeutet.
Zitat von @commodity:
vielleicht: Domäne Keine Energieoptionen verfügbar
Auf den Thread bin ich schon gestoßen, bei mir war tatsächlich auch die Domänen Benutzer Gruppe nicht eingetragen aber auch danach bestand das problem noch.
Diese Einstellung hast Du gecheckt? Bei den wenigen GPOs geht das ggf. schnell.
Evtl. musst Du die GPO auch einmal aktiv an die Clients durchreichen, um den korrekten Status wieder herzustellen. Dazu würde ich (kein AD-Profi) eine neue GPO machen, die für alle die nachfolgende Einstellung auf "deaktiviert" setzt.
Benutzerkonfiguration\Administrative Vorlagen\Startmenu und Taskleiste:
Wenn es dann wieder gehen sollte kann die GPO IMO auch wieder entfernt werden. Wenn es dann wieder nicht geht, steuert eine andere GPO die Einstellung auch.
Viele Grüße, commodity
Evtl. musst Du die GPO auch einmal aktiv an die Clients durchreichen, um den korrekten Status wieder herzustellen. Dazu würde ich (kein AD-Profi) eine neue GPO machen, die für alle die nachfolgende Einstellung auf "deaktiviert" setzt.
Benutzerkonfiguration\Administrative Vorlagen\Startmenu und Taskleiste:
Wenn es dann wieder gehen sollte kann die GPO IMO auch wieder entfernt werden. Wenn es dann wieder nicht geht, steuert eine andere GPO die Einstellung auch.
Viele Grüße, commodity
Zitat von @commodity:
Diese Einstellung hast Du gecheckt? Bei den wenigen GPOs geht das ggf. schnell.
Evtl. musst Du die GPO auch einmal aktiv an die Clients durchreichen, um den korrekten Status wieder herzustellen. Dazu würde ich (kein AD-Profi) eine neue GPO machen, die für alle die nachfolgende Einstellung auf "deaktiviert" setzt.
Benutzerkonfiguration\Administrative Vorlagen\Startmenu und Taskleiste:
Wenn es dann wieder gehen sollte kann die GPO IMO auch wieder entfernt werden. Wenn es dann wieder nicht geht, steuert eine andere GPO die Einstellung auch.
Viele Grüße, commodity
Diese Einstellung hast Du gecheckt? Bei den wenigen GPOs geht das ggf. schnell.
Evtl. musst Du die GPO auch einmal aktiv an die Clients durchreichen, um den korrekten Status wieder herzustellen. Dazu würde ich (kein AD-Profi) eine neue GPO machen, die für alle die nachfolgende Einstellung auf "deaktiviert" setzt.
Benutzerkonfiguration\Administrative Vorlagen\Startmenu und Taskleiste:
Wenn es dann wieder gehen sollte kann die GPO IMO auch wieder entfernt werden. Wenn es dann wieder nicht geht, steuert eine andere GPO die Einstellung auch.
Viele Grüße, commodity
Grad alle GPOs auf die von dir gezeigte einstellung kontrolliert, steht überall auf "nicht konfiguriert"
die GPO mit der funktion auf "deaktiviert" habe ich gerade erstellt und auch auf einem rechner angewandt (gpresult zeigt es), hat aber nichts gebracht problem besteht weiterhin.
Na zeig doch einfach mal was bei rsop raus kommt...
Wie mache ich das am besten? sonst müsste ich ja von jeder Seite im Richtlinenergebnissatz nen Screenshot machen...
Hast Du vorsorglich auch mal die lokalen GPOs kontrolliert?
Viele Grüße, commodity
Viele Grüße, commodity
Hast du die GPO, die es deaktiviert, auch ganz unten hingesetzt z.B. in die letzte Organizationseinheit, in der dein Testgerät existiert? Nicht, dass sie durch einen untergeordneten Eintrag überschrieben wird.
Mach ruhig eine neue OU dafür mit dem Namen Test, du kannst ja das Gerät danach wieder in die Original OU eins höher schieben und die Test OU löschen. Bei der neuen Test OU kannst du dir sicher sein, dass da keine GPO untergeordnet ist, die überschreiben kann.
Mach ruhig eine neue OU dafür mit dem Namen Test, du kannst ja das Gerät danach wieder in die Original OU eins höher schieben und die Test OU löschen. Bei der neuen Test OU kannst du dir sicher sein, dass da keine GPO untergeordnet ist, die überschreiben kann.
Zitat von @commodity:
Hast Du vorsorglich auch mal die lokalen GPOs kontrolliert?
Viele Grüße, commodity
Hast Du vorsorglich auch mal die lokalen GPOs kontrolliert?
Viele Grüße, commodity
Habe da komischerweise keine berechtigung drauf, trotz Admin. Muss mal schauen woran das liegt.
Zitat von @NordicMike:
Hast du die GPO, die es deaktiviert, auch ganz unten hingesetzt z.B. in die letzte Organizationseinheit, in der dein Testgerät existiert? Nicht, dass sie durch einen untergeordneten Eintrag überschrieben wird.
Mach ruhig eine neue OU dafür mit dem Namen Test, du kannst ja das Gerät danach wieder in die Original OU eins höher schieben und die Test OU löschen. Bei der neuen Test OU kannst du dir sicher sein, dass da keine GPO untergeordnet ist, die überschreiben kann.
Hast du die GPO, die es deaktiviert, auch ganz unten hingesetzt z.B. in die letzte Organizationseinheit, in der dein Testgerät existiert? Nicht, dass sie durch einen untergeordneten Eintrag überschrieben wird.
Mach ruhig eine neue OU dafür mit dem Namen Test, du kannst ja das Gerät danach wieder in die Original OU eins höher schieben und die Test OU löschen. Bei der neuen Test OU kannst du dir sicher sein, dass da keine GPO untergeordnet ist, die überschreiben kann.
Hatte ich eben getestet, den Rechner in ne komplett neue OU gesetzt und die GPO die genau das verbieten deaktviert dorthin verknüpft. Hat leider nichts gebracht.
Hallo nochmal
Auch nach dem neuinstallieren des domaincontrollers, ohne erstellen von irgendwelchen GPOs funktioniert es nicht.
Direkt nachdem ich mit dem Testrechner der Domain beigetreten bin und mich mit einem AD Konto angemeldet habe, waren die Energieoptionen direkt wieder weg.
Auch nach dem neuinstallieren des domaincontrollers, ohne erstellen von irgendwelchen GPOs funktioniert es nicht.
Direkt nachdem ich mit dem Testrechner der Domain beigetreten bin und mich mit einem AD Konto angemeldet habe, waren die Energieoptionen direkt wieder weg.
Ich hatte es schon befürchtet. Dann ist es vielleicht ein Fall des seltenen GPO-Tattooing.
Da wirst Du evtl. die Registries der betroffenen Clients untersuchen und ggf. "reparieren" müssen.
Das Thema ist allerdings auch hier umstritten...
sHier gibt's auch noch einen kleinen Überblick.
Vorher würde ich aber das Thema lokale GPO nochmal aufgreifen.
Viele Grüße, commodity
Da wirst Du evtl. die Registries der betroffenen Clients untersuchen und ggf. "reparieren" müssen.
Das Thema ist allerdings auch hier umstritten...
sHier gibt's auch noch einen kleinen Überblick.
Vorher würde ich aber das Thema lokale GPO nochmal aufgreifen.
Viele Grüße, commodity
Zitat von @commodity:
Ich hatte es schon befürchtet. Dann ist es vielleicht ein Fall des seltenen GPO-Tattooing.
Da wirst Du evtl. die Registries der betroffenen Clients untersuchen und ggf. "reparieren" müssen.
Das Thema ist allerdings auch hier umstritten...
sHier gibt's auch noch einen kleinen Überblick.
Vorher würde ich aber das Thema lokale GPO nochmal aufgreifen.
Viele Grüße, commodity
Ich hatte es schon befürchtet. Dann ist es vielleicht ein Fall des seltenen GPO-Tattooing.
Da wirst Du evtl. die Registries der betroffenen Clients untersuchen und ggf. "reparieren" müssen.
Das Thema ist allerdings auch hier umstritten...
sHier gibt's auch noch einen kleinen Überblick.
Vorher würde ich aber das Thema lokale GPO nochmal aufgreifen.
Viele Grüße, commodity
Scheint tatsächlich ne lokale GPO gewesen zu sein, an der GPO die das Herunterfahren steuert waren keine Domäne-Benutzer eingetragen. Jetzt funktioniert es
Vielen dank für eure antworten.
Falls mir da vielleicht jemand helfen kann: Wieso konnte ich mit meinem Admin Account (im AD mitglied von der Administratoren gruppe) nicht auf die Lokale sicherheitsrichtlinie zugreifen? Dies klappte erst als ich das AD Konto manuell mit dem localadmin als admin eingtragen habe (dort ist auch die Gruppe Domäneadmins eingetragen)
Na also.
Nicht so prima, dass Du den Beitrag dann bei Dir als gelöst anschreibst...
How can I mark a post as solved?
Viele Grüße, commodity
Nicht so prima, dass Du den Beitrag dann bei Dir als gelöst anschreibst...
How can I mark a post as solved?
Viele Grüße, commodity
Zitat von @Caleber:
Scheint tatsächlich ne lokale GPO gewesen zu sein, an der GPO die das Herunterfahren steuert waren keine Domäne-Benutzer eingetragen. Jetzt funktioniert es
Vielen dank für eure antworten.
Falls mir da vielleicht jemand helfen kann: Wieso konnte ich mit meinem Admin Account (im AD mitglied von der Administratoren gruppe) nicht auf die Lokale sicherheitsrichtlinie zugreifen? Dies klappte erst als ich das AD Konto manuell mit dem localadmin als admin eingtragen habe (dort ist auch die Gruppe Domäneadmins eingetragen)
Zitat von @commodity:
Ich hatte es schon befürchtet. Dann ist es vielleicht ein Fall des seltenen GPO-Tattooing.
Da wirst Du evtl. die Registries der betroffenen Clients untersuchen und ggf. "reparieren" müssen.
Das Thema ist allerdings auch hier umstritten...
sHier gibt's auch noch einen kleinen Überblick.
Vorher würde ich aber das Thema lokale GPO nochmal aufgreifen.
Viele Grüße, commodity
Ich hatte es schon befürchtet. Dann ist es vielleicht ein Fall des seltenen GPO-Tattooing.
Da wirst Du evtl. die Registries der betroffenen Clients untersuchen und ggf. "reparieren" müssen.
Das Thema ist allerdings auch hier umstritten...
sHier gibt's auch noch einen kleinen Überblick.
Vorher würde ich aber das Thema lokale GPO nochmal aufgreifen.
Viele Grüße, commodity
Scheint tatsächlich ne lokale GPO gewesen zu sein, an der GPO die das Herunterfahren steuert waren keine Domäne-Benutzer eingetragen. Jetzt funktioniert es
Vielen dank für eure antworten.
Falls mir da vielleicht jemand helfen kann: Wieso konnte ich mit meinem Admin Account (im AD mitglied von der Administratoren gruppe) nicht auf die Lokale sicherheitsrichtlinie zugreifen? Dies klappte erst als ich das AD Konto manuell mit dem localadmin als admin eingtragen habe (dort ist auch die Gruppe Domäneadmins eingetragen)
Hätte dir ja direkt per RSOP auffallen können. Dort ist ja sofort ersichtlich woher die GPO kommt.
