1
GPO um Usern zu verbieten Updates zu installieren
Hallo liebe Freunde gepflegter Probleme...
wir haben hier einige Terminalserver und in einer verknüpften GPO zu der OU in der die WTS liegen ist die Einstellung gesetzte worden das User keine Updates installieren können.
Das Thema wurde auch l hier besprochen.
Die Einstellung "Verhindern, dass Benutzer Windows Installer zum Installieren von Updates und Upgrades verwenden" bewirkt auf den WTS das Software die Updates im Hintergrund durchführt und dabei den Windows Installer nutzt scheitert und danch wenn überhaupt nur mit Fehlern läuft.
Das wurde von einem IT Dienstleister gesetzt und ist sicher auch eine Methode um Einsätze beim Kunden zu forcieren.
Frage: Wie verhindere ich das User Updates durchführen und die Programme aber dennoch ihre Updates machen können?
Im anderen Thread heißt es :
Hier liegt dein eigentliches Problem. Der wirksamste schutz um eine installation zu verhinden ist das entziehen von Schreibrechten in Teilen des Dateisystem und der Registry (Programme , Windows Ordner sowie Lokal_Machine).
Normale User haben diese Rechte nicht, Admins (auch lokale) schon.
Mir ist auch unklar warum Anwender die Netzwerkeinstellungen verwalten solten (naja Auf Notebooks vieleicht).
Mir ist aber nicht klar in welchen Verzeichnisen ich denen die Schreibrechte entziehen soll OHNE ein heilloses Durcheinander zu bewirken.
Gruß Tom
wir haben hier einige Terminalserver und in einer verknüpften GPO zu der OU in der die WTS liegen ist die Einstellung gesetzte worden das User keine Updates installieren können.
Das Thema wurde auch l hier besprochen.
Die Einstellung "Verhindern, dass Benutzer Windows Installer zum Installieren von Updates und Upgrades verwenden" bewirkt auf den WTS das Software die Updates im Hintergrund durchführt und dabei den Windows Installer nutzt scheitert und danch wenn überhaupt nur mit Fehlern läuft.
Das wurde von einem IT Dienstleister gesetzt und ist sicher auch eine Methode um Einsätze beim Kunden zu forcieren.
Frage: Wie verhindere ich das User Updates durchführen und die Programme aber dennoch ihre Updates machen können?
Im anderen Thread heißt es :
Hier liegt dein eigentliches Problem. Der wirksamste schutz um eine installation zu verhinden ist das entziehen von Schreibrechten in Teilen des Dateisystem und der Registry (Programme , Windows Ordner sowie Lokal_Machine).
Normale User haben diese Rechte nicht, Admins (auch lokale) schon.
Mir ist auch unklar warum Anwender die Netzwerkeinstellungen verwalten solten (naja Auf Notebooks vieleicht).
Mir ist aber nicht klar in welchen Verzeichnisen ich denen die Schreibrechte entziehen soll OHNE ein heilloses Durcheinander zu bewirken.
Gruß Tom
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 391515
Url: https://administrator.de/contentid/391515
Ausgedruckt am: 15.11.2024 um 23:11 Uhr
1 Kommentar
Hi,
für einen TS wäre es doch sicher praktikabel, ihn per GPO einer WSUS-Gruppe zuzuordnen (z.B. "TS-Gruppe") und die Update-Installation auf "manuell" zu setzen. Dann für diese Gruppe im WSUS erst dann Updates genehmigen, wenn man diese installieren will. Also i.A. unmittelbar vor dem Wartungsfenster. Damit diese Updates aber schon vorher vom WSUS von MS heruntergeladen werden, kann man eine Dummy-Gruppe im WSUS erstellen, welche keinem Computer zugeordnet wird und für welche man dann dieses Updates genehmigt. Gleichzeitig verhindern, dass der TS allgemein auf die Updates-Sites von MS im Web zugreifen kann (Firewall, Webproxy).
Jetzt bietet der WSUS Client auf dem TS erst dann Updates an, wenn am WSUS-Server neue Updates für diese "TS-Gruppe" explizit genehmigt wurden. Also wenn der Admin im Wartungsfenster aktiv wird.
E.
für einen TS wäre es doch sicher praktikabel, ihn per GPO einer WSUS-Gruppe zuzuordnen (z.B. "TS-Gruppe") und die Update-Installation auf "manuell" zu setzen. Dann für diese Gruppe im WSUS erst dann Updates genehmigen, wenn man diese installieren will. Also i.A. unmittelbar vor dem Wartungsfenster. Damit diese Updates aber schon vorher vom WSUS von MS heruntergeladen werden, kann man eine Dummy-Gruppe im WSUS erstellen, welche keinem Computer zugeordnet wird und für welche man dann dieses Updates genehmigt. Gleichzeitig verhindern, dass der TS allgemein auf die Updates-Sites von MS im Web zugreifen kann (Firewall, Webproxy).
Jetzt bietet der WSUS Client auf dem TS erst dann Updates an, wenn am WSUS-Server neue Updates für diese "TS-Gruppe" explizit genehmigt wurden. Also wenn der Admin im Wartungsfenster aktiv wird.
E.
