16
Windows Server 2016 und SettingsPageVisibility
Hi,
laut Microsoft soll der Eintrag "SettingsPageVisibility" unter Win2016 erst dann wirken, wenn man den Patch KB4457127 installiert hat.
(Hierbei geht es um das Ausblenden von Einstellungskatorien unter den "Einstellungen" von Win2016.)
https://docs.microsoft.com/en-us/windows/client-management/manage-settin ...
https://support.microsoft.com/de-de/help/4457127/windows-10-update-kb445 ...
Die aktuellen ADMX-Dateien haben wir bereits. D.h. wir bekommen diese Einstellung auch unter "Benutzerkonfiguration" einer GPO angeboten und können sie konfigurieren. Nur auf unseren Win2016 Terminalservern wirkt das nicht.
Auf diesen ist der o.g. Patch nicht installiert. Unser WSUS hat diesen noch nicht mal in seiner Liste. Auch nicht als "abgelehnt". Also habe ich diesen manuell heruntergeladen.
Wenn wir aber nun versuchen, diesen unter Win2016 zu installieren, dann meldet er, dass dieser nicht für dieses OS geeignet sei.
Im o.g. Artikel steht:
Wenn man dem Link zwei Absätze tiefer hinter Microsoft Update-Katalog folgt, dann landet man jedoch auf der Seite für den Download des KB4457127.
In der Ersetzungsliste des KB4132216 steht auch nicht drin, dass es den KB4457127 ersetzen würde. Das wäre ja auch komisch. KB4132216 ist "2018-05" und KB4457127 ist "2018-09".
Hat da jemand den Überblick?
Was muss nun auf Win2016 installiert sein, damit SettingsPageVisibility wirkt?
E.
laut Microsoft soll der Eintrag "SettingsPageVisibility" unter Win2016 erst dann wirken, wenn man den Patch KB4457127 installiert hat.
(Hierbei geht es um das Ausblenden von Einstellungskatorien unter den "Einstellungen" von Win2016.)
https://docs.microsoft.com/en-us/windows/client-management/manage-settin ...
https://support.microsoft.com/de-de/help/4457127/windows-10-update-kb445 ...
Die aktuellen ADMX-Dateien haben wir bereits. D.h. wir bekommen diese Einstellung auch unter "Benutzerkonfiguration" einer GPO angeboten und können sie konfigurieren. Nur auf unseren Win2016 Terminalservern wirkt das nicht.
Auf diesen ist der o.g. Patch nicht installiert. Unser WSUS hat diesen noch nicht mal in seiner Liste. Auch nicht als "abgelehnt". Also habe ich diesen manuell heruntergeladen.
Wenn wir aber nun versuchen, diesen unter Win2016 zu installieren, dann meldet er, dass dieser nicht für dieses OS geeignet sei.
Im o.g. Artikel steht:
Wenn Sie Windows Update verwenden, wird Ihnen das neueste SSU (KB4132216) automatisch angeboten. Das eigenständige Paket für das neueste SSU finden Sie im Microsoft Update-Katalog.
KB4132216 ist auch schon installiert.Wenn man dem Link zwei Absätze tiefer hinter Microsoft Update-Katalog folgt, dann landet man jedoch auf der Seite für den Download des KB4457127.
In der Ersetzungsliste des KB4132216 steht auch nicht drin, dass es den KB4457127 ersetzen würde. Das wäre ja auch komisch. KB4132216 ist "2018-05" und KB4457127 ist "2018-09".
Hat da jemand den Überblick?
Was muss nun auf Win2016 installiert sein, damit SettingsPageVisibility wirkt?
E.
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: 424829
Url: https://administrator.de/forum/windows-server-2016-und-settingspagevisibility-424829.html
Ausgedruckt am: 12.04.2025 um 12:04 Uhr
16 Kommentare
Neuester Kommentar
Hi.
Wenn Du das letzte CU drauf hast, ist es wohl installiert, da halt kumulativ.
Kann es sein, dass schlicht die Loopbackverarbeitung aktiviert ist am TS?
Wenn Du das letzte CU drauf hast, ist es wohl installiert, da halt kumulativ.
Kann es sein, dass schlicht die Loopbackverarbeitung aktiviert ist am TS?
Ja, definitiv. Das sind TS.
Die betreffende GPO ist aber auch im Pfad des TS verlinkt. Die GPO wird angewendet.
Die betreffende GPO ist aber auch im Pfad des TS verlinkt. Die GPO wird angewendet.
Ist LBP aktiv, dann ist natürlich noch die Frage, wie es eingestellt ist merge/replace
Zitat von @DerWoWusste:
Ist LBP aktiv, dann ist natürlich noch die Frage, wie es eingestellt ist merge/replace
replaceIst LBP aktiv, dann ist natürlich noch die Frage, wie es eingestellt ist merge/replace
Wie gesagt, die betreffende GPO wird angewendet bei Anmeldung unter TS. Das habe ich explizit geprüft.
Dann verstehst Du (meiner Ansicht nach) LBP falsch. Es filtert ka keine GPOs, jedoch die Settings im Userbereich der GPO.
Ganz sicher nicht. 
Loopback beeinflusst nur, welcher Pfad zum Ermitteln der überhaupt in Frage kommenden GPO's gilt.
Ohne Loopback: nur über die OU mit dem Benutzer-Konto
Loopback "merge": über die OU mit dem Benutzer-Konto + über OU mit Computerkonto, wobei die vom "über Computerkonto" u.U. Vorrang haben.
Loopback "replace": nur über die OU mit dem Computer-Konto
Lassen wir das bitte bei dieser Frage außen vor. Die GPO wird angewendet.
Es filtert ka keine GPOs, jedoch die Settings im Userbereich der GPO.
Loopback ändert nichts an der Art und Weise wie GPO oder GPP in den GPO gefiltert werden.Loopback beeinflusst nur, welcher Pfad zum Ermitteln der überhaupt in Frage kommenden GPO's gilt.
Ohne Loopback: nur über die OU mit dem Benutzer-Konto
Loopback "merge": über die OU mit dem Benutzer-Konto + über OU mit Computerkonto, wobei die vom "über Computerkonto" u.U. Vorrang haben.
Loopback "replace": nur über die OU mit dem Computer-Konto
Lassen wir das bitte bei dieser Frage außen vor. Die GPO wird angewendet.
Kann ich nachstellen. Nur nicht heute, sondern morgen.
Im Schnelltest nur mal lokal im gpedit.msc am TS 2016 1607 angewendet und es geht wie erwartet.
showonly:about
gesetzt.
showonly:about
gesetzt.
Zitat von @DerWoWusste:
Im Schnelltest nur mal lokal im gpedit.msc am TS 2016 1607 angewendet und es geht wie erwartet.
showonly:about
Danke!Im Schnelltest nur mal lokal im gpedit.msc am TS 2016 1607 angewendet und es geht wie erwartet.
showonly:about
Irgendwas machen wir hier also falsch ...
Es würde dich weniger als eine Minute kosten, das LBP abzuschalten, gpupdate am Server auszuführen und dann erneut zu testen.
Zitat von @DerWoWusste:
Es würde dich weniger als eine Minute kosten, das LBP abzuschalten, gpupdate am Server auszuführen und dann erneut zu testen.
Nein, mehr. Es würde dich weniger als eine Minute kosten, das LBP abzuschalten, gpupdate am Server auszuführen und dann erneut zu testen.
DWW, diese Einstellung landet auf dem Server in der Registry. Definitiv! Die GPO wird angewendet. Loopback hin oder her.
Komisch. Bei uns wird sie mit LBP aktiv+replace-mode eben gerade nicht angewendet und das ist auch genau das, was ich erwarten würde.
Ich möchte jetzt sicherstellen, dass wir nicht aneinander vorbei reden.
Bei uns wird sie mit LBP aktiv+replace-mode eben gerade nicht angewendet
"sie" ist die ganze GPO oder nur diese eine Einstellung?
Ich habe eine Test-GPO diesmal auf Domänenebene erstellt mit nur dieser einen Einstellung auf dem TS ist keine deratige GPO lokal gesetzt.
Sie wird auf meinem PC angewendet.
Sie wird auf dem TS erst dann angewendet, wenn ich LBP+replace abschalte.
Sie wird auf meinem PC angewendet.
Sie wird auf dem TS erst dann angewendet, wenn ich LBP+replace abschalte.
Ich habe eine Test-GPO diesmal auf Domänenebene erstellt mit nur dieser einen Einstellung auf dem TS ist keine deratige GPO lokal gesetzt.
In der Benutzerkonfiguration?Sie wird auf meinem PC angewendet.
Wo kein Loopback aktiviert ist?Sie wird auf dem TS erst dann angewendet, wenn ich LBP+replace abschalte.
Was nicht logisch ist, es sein denn, da ist zwischendurch die Vererbung blockiert. Wenn- TS und User in der selben Domäne sind und
- diese GPO an der Domäne verlinkt ist und
- im OU-Pfad des TS keine Vererbung blockiert ist
Ja, in der Benutzerkonfig.
Nein, auf meinem Client (Win10) ist kein LBP aktiv.
Ich finde es logisch, aber ich habe ein anderes Verständis davon, wie LBP arbeitet, wie mir scheint. Ob das nun richtig ist, will ich damit nicht sagen.
Nein, auf meinem Client (Win10) ist kein LBP aktiv.
Ich finde es logisch, aber ich habe ein anderes Verständis davon, wie LBP arbeitet, wie mir scheint. Ob das nun richtig ist, will ich damit nicht sagen.
