Liebes Forum,

auf einem MBPro 16" mit M1 Pro (macOS 12.5) läuft unter Parallels (17.1.4) ein Windows 11 Business (10.0.22621). Alle Updates sind installiert. Das Windows hängt in einer Domäne.

Nun erzeugt im Win11 der "Diensthost: Gruppenrichtlinie" eine CPU-Auslastung von ca. 25 % (Wert schwankt zwischen 18 % und 40 % im Leerlauf) was zu einem erheblichen Energieverbrauch führt. Das Aktivieren der Energiesparoptionen sowie des "Reisemodus" per Parallels lindern das Problem nicht.

Während das MBP mit M1 immerhin nicht heiß wird, hat das MBP Bj. 2019 (Intel) eines Kollegen den selben Fehler, wobei dort die Lüfter permanent rennen und der Akku schneller geleert wird als er befüllt werden kann (dort außerdem CPU-Auslastung ohne Reisemodus und Energiesparoptionen bei 100 %).

Ist jemandem das Problem und, viel wichtiger, eine Lösung bekannt?

Vielen Dank für die Unterstützung!

Stehen im Eventlog Fehler mit der Quelle Gruppenrichtlinienverarbeitung?
Eventuell mal gpupdate ausführen und im Eventlog zu der Uhrzeit nachschauen.

Bitte mal die Lösung aus folgendem Thread probieren:

@ caMpi:
Im der Ereignisanzeige taucht die Gruppenrichtlinie nicht unter "Fehler", sondern nur unter "Warnungen" auf. gpupdate habe ich noch nicht probiert.

@rmayergfx:
Auf dem Intel-MBP meines Kollegen hat das sofort geholfen. Er ist überglücklich. Auf meinem M1 Pro allerdings hat es gar nichts bewirkt.

@ caMpi:
Nach Ausführen der gpupdate.exe steht seit einer knappen halben Stunde: "Die Richtlinie wird aktualisiert..."
Ich nehme an, dass das nicht das erwartete Verhalten ist. Allerdings habe ich keinerlei Erfahrungen damit.

Korrekt. Da wird eine Richtlinie anscheinend nicht zu Ende ausgeführt. Im Eventlog müsste ein entsprechender Eintrag zu finden sein.
Ansonsten lässt sich das besser von einem Admin über die Gruppenrichtlinienverwaltung troubleshooten.
Da nur „Die Richtlinie wird aktualisiert“ da steht, hängt es vermutlich direkt an einer Computerrichtlinie, da diese vor den Benutzerrichtlinien verarbeitet werden.

Einfach mal gpresult auf dem lokalen Rechern ausführen

Wenn es beim Kollegen (hat er auch WIN11) funktioniert solltet ihr mal prüfen ob ihr beiden den selben Patchlevel habt, d.h. sind alle Updates für WIN11 installiert?

Weitere Infos:

Bitte auch unbedingt prüfen ob der Defender aktuellste Signaturen hat. Es kam leider schon oft genug vor, das Gruppentichtlinien nicht installiert werden konnten, da der Defender quer geschossen hat.

@rmayergfx:
gpresult bleibt auf dem M1 ohne Ergebnis. Zwar gibt es keine Fehlermeldung - allerdings auch keine Ausgabe. Auf dem Intel-MBP läuft es durch. Mein Kenntnisstand genügt allerdings nicht, um aus den erzeugten Daten etwas Sinnvolles herauszulesen.

Beide Rechner sind absolut auf demselben Stand. Auch der Defender ist aktuell.

Danke Dir für die weiterführenden Links. Sie bringen mich allerdings nicht voran. Der letzte Link verweist auf einen Thread den mein Kollege 2019 erstellt hat als er sein Intel-MBP erhielt. Damals half es ihm nicht weiter. Allerdings verschwanden die Probleme mit der Zeit (Windows-Updates ?) und sind erst seit kurzem wieder akut.

@caMpi:
Die Computerrichtlinien werden sicherlich auf dem Server ausgeführt? Da werde ich mit der lokal aufgerufenen Gruppenrichtlinienverwaltung nichts ausrichten können, oder? Womöglich ist der Server nicht auf den Zugriff mit Macs und Parallels eingestellt. Der Betrieb eines ARM-Macs macht die Sache nicht besser.

Sofern der User keine Adminrechte hat, was ich 2022 schwer hoffe, werden auch hier nur die Userrichtlinien angezeigt.
Dennoch läuft dabei der komplette Prozess, weswegen hier wohl auch gar nichts angezeigt wird.
Die Richtlinien kommen vom Server, werden aber vom Client ausgeführt.
Die lokale Richtlinienverwaltung hilft da nicht weiter.
Gibt es noch mehr Rechner mit Windows 11 in der Domäne? Gibt es auch mehr ARM-Systeme in der Domäne?
Wie gesagt: im Eventlog unter Windows-Protokolle > Anwendung müssten entsprechende Fehler und Warnungen stehen.

caMpi: Das waren auch meine ersten Gedanken. Selbst bei identischem Build reden wir hier von einem ARM Windows. Es kann durchaus Gruppenrichtlinien geben die nur unter x86-64 Windows sauber laufen und für ARM schlicht nie getestet wurden.

Nicht zu vergessen das Disaster mit den Gruppenrichtlinien die zum Anfang noch nicht einmal in der Lage waren sauber zwischen Windows 10 und Windows 11 zu unterscheiden. Wer aktuell Windows 11 im Produktiven Umfeld einsetzt hat aus meiner Sicht einfach zu viel Zeit. Windows 11 hat noch so viele offene Baustellen. Ich möchte mit einem System arbeiten und nicht den ganzen Tag Fehler bereinigen.

@Emil
Bitte mal im Eventlog nachsehen.

Welche Parameter hast Du verwendet?

gpresult /h <Dateiname.html> muss etwas ausgegeben

gpresult /scope computer /h <Dateiname.html> gibt die Computerrichtlinien aus. Das muss in einem Adminkontext ausgeführt werden.

Wenn da nix passiert, dann muss entweder die kompletten Richtlinienbearbeitung im Eimer sein, oder die GPOs sind schrott. Oder das Computerkonto ist in der falschen OU. Aber selbst dann müsste gpresult liefern

Evtl. mal ein Domain-Rejoin versuchen. Ggf. vorher das Computerkonto im AD löschen.

Oder es liegt daran, dass Windows 11 on ARM immer noch eine Developer Preview ist.

Windows 11 ARM Bug ?

gpresult liefert auf dem M1 keinerlei Ergebnis, egal welche Parameter (auf dem Intel-MBP funktioniert es).
eventlog zeigt keine offensichtlichen Fehler.

Adminrechte sind auf dem M1 und dem Intel-MBP, denn es sind die Laptops der Admins... Es sind die einzigen Macs in der Domäne bzw. es ist der einzige ARM in der Domäne.

Auch unter Windows 10 traten auf dem Intel-MBP die beschriebenen Probleme auf. Win11 läuft hier, weil davon ausgegangen wurde, dass es unter der Haube mit Win10 identisch ist.

Zwischenfazit: Mein Horizont bzgl. Gruppenrichtlinien etc. ist - offensichtlich - äußerst begrenzt. Ich hatte die Hoffnung, dass eine gut dokumentierte Anleitung existiert, so dass ich das ungewöhnliche Verhalten zügig Abschalten kann.
Da Win11 (oder auch Win10) nur selten (z.B. für die Einrichtung spezieller Hardware) benötigt wird, und die Macs in dem Fall sowieso am Netzteil hängen, kann ich mit diesem Problem leben. Die Hoffnung bleibt, dass zukünftige Updates Windows und ARM besser zusammenbringen.

Du könntest das/die betroffenen Notebooks in eine extra OU stecken und eine Richtlinie nach der anderen zuweisen. Zwischendrin immer gpupdate, dann siehst du ja, woran es hängt.