10
Powershell und Store unter Windows 10 Enterprise sperren Phänomen entdeckt
Guten Morgen zusammen,
ich bin bei einem Test die Power Shell und Windows Store unter Windows 10 Enterprise mit einer GPO zu sperren, auf ein Phänomen gestoßen, welches ich mir nicht erklären kann.
Ich habe eine GPO angelegt und folgende Einstellungen vorgenommen:
Computerkonfiguration-Administrative Vorlagen-Windows Komponenten-Store=Store Anwendungen deaktivieren auf Aktivieren gesetzt und für die Power Shell
Windows Einstellungen-Sicherheitseinstellungen-Anwendungssteuerrichtlinien eine Regel erstellt, das nur der Test User die Power Shell nicht nutzen darf. Im Zuge dessen auch unter Systemdienste, den Anwendungsidentitätsdienst aktiviert.
So weit so gut. Nun komme ich zum erkannten Phänomen.
Wenn ich nun die Testsysteme hochfahre und mich mit dem Test User anmelde, ist es mir nicht mehr möglich, mit der Windows Taste das Startmenü zu öffnen, mit der Maus das Startmenü, bzw. unten rechts das Info Center zu öffnen. Weiterhin erhalte ich, wenn ich unten links auf das Windows Symbol, mit der rechten Maustaste das Menü aufrufe und versuche eine Verknüpfung aufzurufen entweder, die Meldung das die App durch den Systemadministrator gesperrt wurde, bzw. es passiert nichts.
Noch kurioser, wenn ich mich danach als Domänenadmin anmelde, passiert das gleiche, genauso wenn ich den lokalen Admin nutze.
Das Deaktivieren der GPO, bzw. das entfernen der Testrechner aus der OU bringt auch nichts.
Derzeitige Lösung meiner Seite. Die Rechner neu installieren.
Hat einer von euch evtl. dieses Phänomen ebenfalls schon mal gehabt, bzw. eine Lösung für das Problem und zum Anderen gibt es eine alternative Lösung um mein Vorhaben umzusetzen?
Gruß
Mav
ich bin bei einem Test die Power Shell und Windows Store unter Windows 10 Enterprise mit einer GPO zu sperren, auf ein Phänomen gestoßen, welches ich mir nicht erklären kann.
Ich habe eine GPO angelegt und folgende Einstellungen vorgenommen:
Computerkonfiguration-Administrative Vorlagen-Windows Komponenten-Store=Store Anwendungen deaktivieren auf Aktivieren gesetzt und für die Power Shell
Windows Einstellungen-Sicherheitseinstellungen-Anwendungssteuerrichtlinien eine Regel erstellt, das nur der Test User die Power Shell nicht nutzen darf. Im Zuge dessen auch unter Systemdienste, den Anwendungsidentitätsdienst aktiviert.
So weit so gut. Nun komme ich zum erkannten Phänomen.
Wenn ich nun die Testsysteme hochfahre und mich mit dem Test User anmelde, ist es mir nicht mehr möglich, mit der Windows Taste das Startmenü zu öffnen, mit der Maus das Startmenü, bzw. unten rechts das Info Center zu öffnen. Weiterhin erhalte ich, wenn ich unten links auf das Windows Symbol, mit der rechten Maustaste das Menü aufrufe und versuche eine Verknüpfung aufzurufen entweder, die Meldung das die App durch den Systemadministrator gesperrt wurde, bzw. es passiert nichts.
Noch kurioser, wenn ich mich danach als Domänenadmin anmelde, passiert das gleiche, genauso wenn ich den lokalen Admin nutze.
Das Deaktivieren der GPO, bzw. das entfernen der Testrechner aus der OU bringt auch nichts.
Derzeitige Lösung meiner Seite. Die Rechner neu installieren.
Hat einer von euch evtl. dieses Phänomen ebenfalls schon mal gehabt, bzw. eine Lösung für das Problem und zum Anderen gibt es eine alternative Lösung um mein Vorhaben umzusetzen?
Gruß
Mav
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: 449356
Url: https://administrator.de/contentid/449356
Printed on: April 19, 2024 at 21:04 o'clock
10 Comments
Latest comment
Guten Morgen @maverik6,
ich hatte das gleiche Problem auch schon bei manchen Clients.
Allerdings glaube ich nicht, dass es etwas mit der GPO zu tun hat. (Kann mich aber auch täuschen)
Ich habe den Store auch per GPO deaktiviert.
Mit PowerShell habe ich keine Settings vorgenommen.
Bei mir hat es früher geholfen das Benutzerprofil zu löschen (auch wenn das meist nicht so toll ist).
In der aktuellen Version 1809, die wir nutzen, habe ich dieses Problem nicht mehr.
Woher dieses Phänomen kommt, kann ich dir aber nicht beantworten.
Gruß joehuaba
ich hatte das gleiche Problem auch schon bei manchen Clients.
Allerdings glaube ich nicht, dass es etwas mit der GPO zu tun hat. (Kann mich aber auch täuschen)
Ich habe den Store auch per GPO deaktiviert.
Mit PowerShell habe ich keine Settings vorgenommen.
Bei mir hat es früher geholfen das Benutzerprofil zu löschen (auch wenn das meist nicht so toll ist).
In der aktuellen Version 1809, die wir nutzen, habe ich dieses Problem nicht mehr.
Woher dieses Phänomen kommt, kann ich dir aber nicht beantworten.
Gruß joehuaba
Guten Morgen Mav,
in deiner konkreten Konstellation kann ich dir leider keinen Hinweis geben.
Lediglich tritt bei uns ähnliches Phänomen auf, sobald ich auf einem PC per TeamViewer aufgeschaltet bin.
D.h. ich schalte mich auf einen PC auf und auf meinem lokalen PC funktionieren, solange die Verbindung offen ist,
die Windowstaste nicht mehr, oder das @-Zeichen kann nicht aktiviert werden.
Ist natürlich raten in's Blaue, da ich nicht weiß, ob ihr überhaupt den TeamViewer im Einsatz habt.
Ansonsten weiterhin viel Erfolg bei der Suche nach deiner Problemlösung!
Gruß
geenation
in deiner konkreten Konstellation kann ich dir leider keinen Hinweis geben.
Lediglich tritt bei uns ähnliches Phänomen auf, sobald ich auf einem PC per TeamViewer aufgeschaltet bin.
D.h. ich schalte mich auf einen PC auf und auf meinem lokalen PC funktionieren, solange die Verbindung offen ist,
die Windowstaste nicht mehr, oder das @-Zeichen kann nicht aktiviert werden.
Ist natürlich raten in's Blaue, da ich nicht weiß, ob ihr überhaupt den TeamViewer im Einsatz habt.
Ansonsten weiterhin viel Erfolg bei der Suche nach deiner Problemlösung!
Gruß
geenation
Ebenfalls Guten Morgen,
auch wir setzen die Version 1809 ein, allerdings haben wir das Problem leider aktuell. Gott sei Dank sind wir noch in der Testphase. Auch das Löschen der Profile hat nichts gebracht, hatte ich allerdings auch vergessen zu erwähnen. Weiterhin möchte ich noch erwähnen, das die Windows 10 Enterprise vorher noch mit DISM angepasst wurde und eine relevanten Apps aus dem Image entfernt wurden.
Gruß
Mav
auch wir setzen die Version 1809 ein, allerdings haben wir das Problem leider aktuell. Gott sei Dank sind wir noch in der Testphase. Auch das Löschen der Profile hat nichts gebracht, hatte ich allerdings auch vergessen zu erwähnen. Weiterhin möchte ich noch erwähnen, das die Windows 10 Enterprise vorher noch mit DISM angepasst wurde und eine relevanten Apps aus dem Image entfernt wurden.
Gruß
Mav
Moin.
Du sperrst ja nicht den Store, sondern die Store-Anwendungen. Den Store sperrst Du mit der Policy direkt daneben.
Du sperrst ja nicht den Store, sondern die Store-Anwendungen. Den Store sperrst Du mit der Policy direkt daneben.
Guten Morgen
Ein ähnliches Phänomen hatte ich mit dem AppLocker.
Vielleicht läßt sich "meine" Lösung irgendwie anpassen?
https://social.technet.microsoft.com/Forums/Windows/de-DE/ce28aba7-63c9- ...
Ein ähnliches Phänomen hatte ich mit dem AppLocker.
Vielleicht läßt sich "meine" Lösung irgendwie anpassen?
https://social.technet.microsoft.com/Forums/Windows/de-DE/ce28aba7-63c9- ...
Hallo,
in meinen Auge beschreibst du das Problem doch schon selbst mit der Lösung, falls ich dich richtig verstanden habe.
Betrachten wir nun einmal was bei deiner Anmeldung passiert. Die GPO setzt die COMPUTERKONFIGURATION auf den von dir festgesetzten Wert. Das hast du ihr ja so gesagt.
Als nächstes meldest du dich mit dem lokalen doer Domänen Administrator an. Dafür hast du deiner Aussage nichts konfiguriert. Also wird auch an der Einstellung nichts verändert. Du gehst jetzt irrtümlich davon aus, dass du den Store hast, hast du aber nicht da die Computerkonfiguration ihn ja deaktiviert hat. Wenn du den Rechner nun aus der GPO oder der OU entfernst ändert es sich logischerweise auch nicht. Hast du ja auch nirgends gesagt.
Mach dir bewußt, was die GPO an der Stelle macht. Sie setzt einen von dir festgelegten Eintrag auf einen festgelegten Wert. Wenn du den Rechner aus der GPO löscht wird bei neuen Anmeldungen die GPO nicht mehr ausgeführt. Es wird aber nicht die bereits durchgeführte GPO rückgängig gemacht.
Lösung für dein Problem:
1. Setze die GPO nicht auf die Computerkonfiguration sondern auf den User. Habe grade keinen DC zur Hand und weiß daher nicht ob das mit dem Store geht.
2. Erstele eine GO für die Administratoren, die das erlaubt was du beim Test User verboten hast.
Wie gesagt: Kernproblem ist es in meinen Augen, dass du die Computerkonfiguration als ziel setzt, aber nur beim Test-User ein Verbot ahst, beim Admin aber keine Erlaubnis.
Gpo bedeutet:
deaktivieren: aus schalten
aktivieren: an schalten
nicht konfiguriert: so lassen wie es ist, aus bleibt aus, an bleuibt an.
Du knipst es nur aus, aber nie wieder an :D
Auch wenn ich mich in dem Post etwas wiederhole, hoffe ich dass du verstanden hast worauf ich hinaus wollte.
in meinen Auge beschreibst du das Problem doch schon selbst mit der Lösung, falls ich dich richtig verstanden habe.
Ich habe eine GPO angelegt und folgende Einstellungen vorgenommen:
Computerkonfiguration-Administrative Vorlagen-Windows Komponenten-Store=Store Anwendungen deaktivieren auf Aktivieren gesetzt und für die Power Shell Windows Einstellungen-Sicherheitseinstellungen-Anwendungssteuerrichtlinien eine Regel erstellt, das nur der Test User die Power Shell nicht nutzen darf. Im Zuge dessen auch unter Systemdienste, den Anwendungsidentitätsdienst aktiviert.
Computerkonfiguration-Administrative Vorlagen-Windows Komponenten-Store=Store Anwendungen deaktivieren auf Aktivieren gesetzt und für die Power Shell Windows Einstellungen-Sicherheitseinstellungen-Anwendungssteuerrichtlinien eine Regel erstellt, das nur der Test User die Power Shell nicht nutzen darf. Im Zuge dessen auch unter Systemdienste, den Anwendungsidentitätsdienst aktiviert.
Betrachten wir nun einmal was bei deiner Anmeldung passiert. Die GPO setzt die COMPUTERKONFIGURATION auf den von dir festgesetzten Wert. Das hast du ihr ja so gesagt.
Als nächstes meldest du dich mit dem lokalen doer Domänen Administrator an. Dafür hast du deiner Aussage nichts konfiguriert. Also wird auch an der Einstellung nichts verändert. Du gehst jetzt irrtümlich davon aus, dass du den Store hast, hast du aber nicht da die Computerkonfiguration ihn ja deaktiviert hat. Wenn du den Rechner nun aus der GPO oder der OU entfernst ändert es sich logischerweise auch nicht. Hast du ja auch nirgends gesagt.
Mach dir bewußt, was die GPO an der Stelle macht. Sie setzt einen von dir festgelegten Eintrag auf einen festgelegten Wert. Wenn du den Rechner aus der GPO löscht wird bei neuen Anmeldungen die GPO nicht mehr ausgeführt. Es wird aber nicht die bereits durchgeführte GPO rückgängig gemacht.
Lösung für dein Problem:
1. Setze die GPO nicht auf die Computerkonfiguration sondern auf den User. Habe grade keinen DC zur Hand und weiß daher nicht ob das mit dem Store geht.
2. Erstele eine GO für die Administratoren, die das erlaubt was du beim Test User verboten hast.
Wie gesagt: Kernproblem ist es in meinen Augen, dass du die Computerkonfiguration als ziel setzt, aber nur beim Test-User ein Verbot ahst, beim Admin aber keine Erlaubnis.
Gpo bedeutet:
deaktivieren: aus schalten
aktivieren: an schalten
nicht konfiguriert: so lassen wie es ist, aus bleibt aus, an bleuibt an.
Du knipst es nur aus, aber nie wieder an :D
Auch wenn ich mich in dem Post etwas wiederhole, hoffe ich dass du verstanden hast worauf ich hinaus wollte.
nicht konfiguriert: so lassen wie es ist, aus bleibt aus, an bleuibt an.
Nein, ganz falsch. Das gilt nur für tattooing GPOs (und die stellen nur ca. 2% der gesamten GPOs dar). Lies mal nach, was das ist: https://sdmsoftware.com/gpoguy/whitepapers/understanding-policy-tattooin ...
ganz falsch ist es nicht, aber auch nicht ganz richtig. Da stimme ich dir nach der Lektüre deines Links zu.
Die Frage ist dann allerdings: Der in der Ausgangsfrage gesetzte Wert in der GPO wird in welchen Registry Key geschrieben?
Sollte es einer der 4 sein, die in deinem Link stehen, so müsste der Wert wieder entfernt werden, wenn die GPO nicht mehr zutrifft. Wenn die GPO allerdings einen Registry-Wert außerhalb der 4 ändert, dann würde wiederrum meine Aussage "aus bleibt aus, an bleibt an" zutreffen.
Nach meiner Recherche sollte es unter HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsStore abgelegt werdeb, aber wie gesagt: grade keinen DC zum Testen zur Hand. Wenn das Stimmt, dann sollte laut deinem Artikel meine Vermutung/Lösung wirklich nicht zutreffen.
Ich würde mich nur nicht blind darauf verlassen, sondern lieber den Wert auf den Wert setzen, den ich haben möchte. Ich habe schon einige Probleme gelöst, die dadurch verursacht wurden, dass der Schalter per GPO nur in eine Richtung definiert wurde. Und das auch bei Registry-Einträgen, die in dem genannten Bereich lagen.
Die Frage ist dann allerdings: Der in der Ausgangsfrage gesetzte Wert in der GPO wird in welchen Registry Key geschrieben?
Sollte es einer der 4 sein, die in deinem Link stehen, so müsste der Wert wieder entfernt werden, wenn die GPO nicht mehr zutrifft. Wenn die GPO allerdings einen Registry-Wert außerhalb der 4 ändert, dann würde wiederrum meine Aussage "aus bleibt aus, an bleibt an" zutreffen.
Nach meiner Recherche sollte es unter HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsStore abgelegt werdeb, aber wie gesagt: grade keinen DC zum Testen zur Hand. Wenn das Stimmt, dann sollte laut deinem Artikel meine Vermutung/Lösung wirklich nicht zutreffen.
Ich würde mich nur nicht blind darauf verlassen, sondern lieber den Wert auf den Wert setzen, den ich haben möchte. Ich habe schon einige Probleme gelöst, die dadurch verursacht wurden, dass der Schalter per GPO nur in eine Richtung definiert wurde. Und das auch bei Registry-Einträgen, die in dem genannten Bereich lagen.
ganz falsch ist es nicht, aber auch nicht ganz richtig
Es ist in ca. 2% der Fälle richtig. Und das sind die ganz alten, schon bei NT4 vorhandenen Policies. KEINE der modernen.
Ich habe den Artikel schon verstanden, dass es seit NT4 der Fall sein sollte. Dennoch bleibt folgende Tatsache:
Wir hatten bei einigen Kunden die Option "Updates die keinen Neustat erfordern sofort installieren" aktiviert. Standardmäßig ist diese ja deaktiviert. Als wir die GPO entfernt haben, blieb die Option aktiviert. Erst als wir den Wert händisch bzw. mit der GPO wieder deaktiviert haben, war das verhalten der betroffenen Server wieder wie gewünscht. Es ist natürlich nicht auszuschließen, dass es sich dabei um einen Fehler handelt.
Aber wir entfernen uns etwas vom Thema.
Unabhängig davon was das System automatisch machen sollte oder nicht würde ich in den nächsten Schritten erstmal mit gpresult prüfen was an Einstellungen und Richtlinien wirklich übernommen wurde und dann den entsprechenden Registry Key händisch prüfen. Soweit ich das gestern gelesen habe wird der entsprechende Key für den Store nur gesetzt, wenn die GPO aktiviert wird. Wenn keine entsprechende GPO aktiv ist, sollte es den Key nicht geben.
Wir hatten bei einigen Kunden die Option "Updates die keinen Neustat erfordern sofort installieren" aktiviert. Standardmäßig ist diese ja deaktiviert. Als wir die GPO entfernt haben, blieb die Option aktiviert. Erst als wir den Wert händisch bzw. mit der GPO wieder deaktiviert haben, war das verhalten der betroffenen Server wieder wie gewünscht. Es ist natürlich nicht auszuschließen, dass es sich dabei um einen Fehler handelt.
Aber wir entfernen uns etwas vom Thema.
Unabhängig davon was das System automatisch machen sollte oder nicht würde ich in den nächsten Schritten erstmal mit gpresult prüfen was an Einstellungen und Richtlinien wirklich übernommen wurde und dann den entsprechenden Registry Key händisch prüfen. Soweit ich das gestern gelesen habe wird der entsprechende Key für den Store nur gesetzt, wenn die GPO aktiviert wird. Wenn keine entsprechende GPO aktiv ist, sollte es den Key nicht geben.
