11
Terminal Server Windows Update durch Benutzer unterbinden
Mahlzeit,
wir sind vor kurzem mit unseren RD-SH von Server 2012 R2 auf 2019 gewechselt. Gestern habe ich auf die harte Tour erfahren das Benutzer tatsächlich Updates starten können. In dem Fall gab es zwar keinen Neustart, aber aus dem Internet wurden die VMware Netzwerktreiber "aktuallisiert", defacto war der Server aus dem Netz. Ich hätte das überhaupt nicht für möglich gehalten aber ich konnte das direkt reproduzieren.
Noch schockierender finde ich tatsächlich die Tatsache, das es da keine wirkliche Lösung für zu gebnen scheint.
- Unter 2012 R2 habe ich keinen Weg gefunden, die Updates als Benutzer auszuführen.
- In meiner Doku habe ich die Blogs und Tutorials durchgesehen, ob mir was dazu entgeangen ist. Hätte man zu so einem Beitrag über das Installieren von RD-SH ja mal erwähnen können - nichts.
- Wir haben GPOs getestet, die aber nur im Computer-Kontext funktionieren, nicht als User GPO:
https://gpsearch.azurewebsites.net/#2790
- Im Internet habe ich diverse ältere Ansätze zu "Frickel"-Lösungen gefunden:
Windows TS Updates nur von Admin starten
https://www.datev-community.de/t5/Technisches-zu-Software/Windows-2016-R ...
Was ist denn hier Best Practice und warum zur Hölle gibt es für sowas keine User GPO von Microsoft zu einem so naheliegenden Problem?
wir sind vor kurzem mit unseren RD-SH von Server 2012 R2 auf 2019 gewechselt. Gestern habe ich auf die harte Tour erfahren das Benutzer tatsächlich Updates starten können. In dem Fall gab es zwar keinen Neustart, aber aus dem Internet wurden die VMware Netzwerktreiber "aktuallisiert", defacto war der Server aus dem Netz. Ich hätte das überhaupt nicht für möglich gehalten aber ich konnte das direkt reproduzieren.
Noch schockierender finde ich tatsächlich die Tatsache, das es da keine wirkliche Lösung für zu gebnen scheint.
- Unter 2012 R2 habe ich keinen Weg gefunden, die Updates als Benutzer auszuführen.
- In meiner Doku habe ich die Blogs und Tutorials durchgesehen, ob mir was dazu entgeangen ist. Hätte man zu so einem Beitrag über das Installieren von RD-SH ja mal erwähnen können - nichts.
- Wir haben GPOs getestet, die aber nur im Computer-Kontext funktionieren, nicht als User GPO:
https://gpsearch.azurewebsites.net/#2790
- Im Internet habe ich diverse ältere Ansätze zu "Frickel"-Lösungen gefunden:
Windows TS Updates nur von Admin starten
https://www.datev-community.de/t5/Technisches-zu-Software/Windows-2016-R ...
Was ist denn hier Best Practice und warum zur Hölle gibt es für sowas keine User GPO von Microsoft zu einem so naheliegenden Problem?
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: 63770750438
Url: https://administrator.de/contentid/63770750438
Ausgedruckt am: 21.11.2024 um 19:11 Uhr
11 Kommentare
Neuester Kommentar
Moin,
Benutzerkonfiguration -> Richtlinien -> Administrative Vorlagen -> Windows-Komponenten -> Windows Update -> Zugriff auf alle Windows Update-Funktionen entfernen
hth
Erik
Benutzerkonfiguration -> Richtlinien -> Administrative Vorlagen -> Windows-Komponenten -> Windows Update -> Zugriff auf alle Windows Update-Funktionen entfernen
hth
Erik
Quote from @ukulele-7:
- Wir haben GPOs getestet, die aber nur im Computer-Kontext funktionieren, nicht als User GPO:
https://gpsearch.azurewebsites.net/#2790
- Wir haben GPOs getestet, die aber nur im Computer-Kontext funktionieren, nicht als User GPO:
https://gpsearch.azurewebsites.net/#2790
Moin,
es gibt doch auch GPOs die die WU Settings für den Benutzer entfernen?
https://learn.microsoft.com/de-de/windows-server/administration/windows- ...
/Thomas
An die beiden vor mir: das hat er doch selbst geschrieben.
Es funktioniert (auf Server 2019 zumindest) NUR als computer-GPO und lässt somit den Admin auch nicht manuell scannen (habe ich geprüft, ist so). Hinzu kommt, dass die GPO natürlich nur die GUI sperrt. Normale Nutzer können mit Kommandozeilentools (z.B. wuinstall.exe) weiterhin nach updates scannen.
Was ich deshalb empfehle:
WSUS einsetzen, Dualscan (WSUS+Internet) verbieten und auf dem WSUS keine Treiberupdates anbieten lassen.
Desweitere kannst Du mir der von dir genannten GPO das manuelle Suchen sperren - wenn wirklich noch Leute scannen per Kommandozeile, muss eben mit Applocker weiter dichtgemacht werden.
Es funktioniert (auf Server 2019 zumindest) NUR als computer-GPO und lässt somit den Admin auch nicht manuell scannen (habe ich geprüft, ist so). Hinzu kommt, dass die GPO natürlich nur die GUI sperrt. Normale Nutzer können mit Kommandozeilentools (z.B. wuinstall.exe) weiterhin nach updates scannen.
Was ich deshalb empfehle:
WSUS einsetzen, Dualscan (WSUS+Internet) verbieten und auf dem WSUS keine Treiberupdates anbieten lassen.
Desweitere kannst Du mir der von dir genannten GPO das manuelle Suchen sperren - wenn wirklich noch Leute scannen per Kommandozeile, muss eben mit Applocker weiter dichtgemacht werden.
1
... ja... auch ich wundere mich seit geraumer Zeit, weshalb Microsoft das den Benutzern ermöglicht.
Aber es ist so, wie es ist und @DerWoWusste geschrieben hat.
Aber es ist so, wie es ist und @DerWoWusste geschrieben hat.
Zitat von @DerWoWusste:
An die beiden vor mir: das hat er doch selbst geschrieben.
Es funktioniert (auf Server 2019 zumindest) NUR als computer-GPO und lässt somit den Admin auch nicht manuell scannen (habe ich geprüft, ist so).
Korrekt. Die GPO unter User funktioniert nicht.An die beiden vor mir: das hat er doch selbst geschrieben.
Es funktioniert (auf Server 2019 zumindest) NUR als computer-GPO und lässt somit den Admin auch nicht manuell scannen (habe ich geprüft, ist so).
Hinzu kommt, dass die GPO natürlich nur die GUI sperrt. Normale Nutzer können mit Kommandozeilentools (z.B. wuinstall.exe) weiterhin nach updates scannen.
Das habe ich nicht getestet, würde mich jetzt aber nicht mehr wundern.Was ich deshalb empfehle:
WSUS einsetzen, Dualscan (WSUS+Internet) verbieten und auf dem WSUS keine Treiberupdates anbieten lassen.
WSUS nutzen wir, Treiber macht der nicht. Dual Scan haben wir bereits erfolgreich aktiviert. Treiber sind ja aber auch nicht meine einzige Sorge, kann der User nicht auch die WSUS Updates anstoßen und daraufhin ggf. neu starten?WSUS einsetzen, Dualscan (WSUS+Internet) verbieten und auf dem WSUS keine Treiberupdates anbieten lassen.
Desweitere kannst Du mir der von dir genannten GPO das manuelle Suchen sperren - wenn wirklich noch Leute scannen per Kommandozeile, muss eben mit Applocker weiter dichtgemacht werden.
Suchen ist egal, downloaden auch. Wichtig ist keine Installation (egal ob Treiber oder Updates) und kein Neustart der vom WSUS genehmigten Updates und keine Online Suche.Dual Scan haben wir bereits erfolgreich aktiviert
DEaktivieren.kann der User nicht auch die WSUS Updates anstoßen
Nein, wenn du die GPO nutzt, kann er das wie gesagt nur über die Kommandozeile. Das macht doch kein Nutzer. Du kannst in der GPO ja auch einstellen, dass keine Meldungen zum anstehenden Neustart angezeigt werden.2
Guten Abend
Als Admin kannst du zum Beispiel via PSWindowsUpdate agieren, das setzt aber vorraus das du eine Elevated Powershell hast. Sollten die Anwenderkonten ja nicht haben
https://www.powershellgallery.com/packages/PSWindowsUpdate/2.2.1.3
Gruß
Zitat von @DerWoWusste:
wenn wirklich noch Leute scannen per Kommandozeile, muss eben mit Applocker weiter dichtgemacht werden.
+1 für den Applocker, falls es jemand mit der Kommandozeile versucht.wenn wirklich noch Leute scannen per Kommandozeile, muss eben mit Applocker weiter dichtgemacht werden.
Als Admin kannst du zum Beispiel via PSWindowsUpdate agieren, das setzt aber vorraus das du eine Elevated Powershell hast. Sollten die Anwenderkonten ja nicht haben
https://www.powershellgallery.com/packages/PSWindowsUpdate/2.2.1.3
Gruß
Hi,
auf Terminalservern den Windows Update Dienst deaktivieren.
Diesen nur aktivieren, wenn ein Admin Updates installieren will.
Bei vielen TS kann man das auch per GPO durchsetzen.
E.
auf Terminalservern den Windows Update Dienst deaktivieren.
Diesen nur aktivieren, wenn ein Admin Updates installieren will.
Bei vielen TS kann man das auch per GPO durchsetzen.
E.
3
auf Terminalservern den Windows Update Dienst deaktivieren.
Diesen nur aktivieren, wenn ein Admin Updates installieren will.
Diesen nur aktivieren, wenn ein Admin Updates installieren will.
+1
Ja meine ich natürlich 
Also Best Practice scheinen zwei Ansätze:
a) Dual Scan DEaktivieren, Manuelle Suche deaktivieren, Meldungen deaktivieren. Bei Bedarf noch mit Applocker die Kommandozeile sperren.
b) Windows Update Dienst deaktivieren und nach Bedarf aktivieren.
(Ich nehme mal an Updates, die keinen Neustart von Windows-Diensten benötigen, führt hier keiner automatisch aus? Ich habs versucht, ist nicht der Hit.)
Ich hätte noch:
c) Compulter-GPO zum Deaktivieren verwenden und bei Bardarf die GPO manuell deaktiveren [EDIT] oder eine Aufgabe anlegen und manuell ausführen, die die Updates durchführt (ist noch ungetestet bei uns).[/EDIT]
Also Best Practice scheinen zwei Ansätze:
a) Dual Scan DEaktivieren, Manuelle Suche deaktivieren, Meldungen deaktivieren. Bei Bedarf noch mit Applocker die Kommandozeile sperren.
b) Windows Update Dienst deaktivieren und nach Bedarf aktivieren.
(Ich nehme mal an Updates, die keinen Neustart von Windows-Diensten benötigen, führt hier keiner automatisch aus? Ich habs versucht, ist nicht der Hit.)
Ich hätte noch:
c) Compulter-GPO zum Deaktivieren verwenden und bei Bardarf die GPO manuell deaktiveren [EDIT] oder eine Aufgabe anlegen und manuell ausführen, die die Updates durchführt (ist noch ungetestet bei uns).[/EDIT]
b) Seit Jahren bekannt: es gibt einen geplanten Task "WaasMedic", der diese Dienstdeaktivierung nach Lust und Laune wieder aufhebt. Deshalb: FakeWSUS. Besser, Aufwand gleich.
