8
Per GPO Logoff als default bei Server
Hallo Zusammen
Ich möchte auf unseren Servern es so einstellen, dass wenn sich die Admins Anmelden, dass als Standard nicht Herunterfahren im Startmenü kommt, sondern das "Abmelden" im Start Menü kommt.
Ich habe die GPO erstellt unter: Benutzerkonfiguration - Richtlinien - Administrative Vorlagen - Startmenü und Taskleiste - Ein-/Aus-Schalter im Startmenü ändern
angepasst. Nun ist dies eine Benutzerkonfiguration , ich möchte aber diese Einstellung nur auf der OU anwenden wo die Server drin stehen. Die Admins sollen diese GPO nur auf dem Server erhalten nicht aber, wenn Sie sich an einem PC Anmelden.
Wie kann ich dies bewerkstelligen?
Besten dank schon im Voraus für eure Hilfe.
LG
Stingray79CH
Ich möchte auf unseren Servern es so einstellen, dass wenn sich die Admins Anmelden, dass als Standard nicht Herunterfahren im Startmenü kommt, sondern das "Abmelden" im Start Menü kommt.
Ich habe die GPO erstellt unter: Benutzerkonfiguration - Richtlinien - Administrative Vorlagen - Startmenü und Taskleiste - Ein-/Aus-Schalter im Startmenü ändern
angepasst. Nun ist dies eine Benutzerkonfiguration , ich möchte aber diese Einstellung nur auf der OU anwenden wo die Server drin stehen. Die Admins sollen diese GPO nur auf dem Server erhalten nicht aber, wenn Sie sich an einem PC Anmelden.
Wie kann ich dies bewerkstelligen?
Besten dank schon im Voraus für eure Hilfe.
LG
Stingray79CH
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: 228662
Url: https://administrator.de/forum/per-gpo-logoff-als-default-bei-server-228662.html
Ausgedruckt am: 12.04.2025 um 17:04 Uhr
8 Kommentare
Neuester Kommentar
Hallo stingray79ch,
dafür gibt es den Loopbackverarbeitungsmodus - Loopback Processing Mode der Richtlinien.
Grüße Uwe
dafür gibt es den Loopbackverarbeitungsmodus - Loopback Processing Mode der Richtlinien.
Computerkonfiguration > Administrative Vorlagen > System > Gruppenrichtlinien > Loopbackverarbeitungsmodus für Benutzergruppenrichtlinie
Sicher bin ich mir nicht aber...
mach doch eine OU nur für die Server und eine in der die PCs drinne sind.
und dann machste die Gruppenrichtlinie auf die Server-OU. Dann haste das Problem doch nicht oder?
mach doch eine OU nur für die Server und eine in der die PCs drinne sind.
und dann machste die Gruppenrichtlinie auf die Server-OU. Dann haste das Problem doch nicht oder?
Hi.
Weiterer Weg: erstelle am Server eine MLGPO, die nur an die Admins gerichtet ist.
Weiterer Weg: erstelle am Server eine MLGPO, die nur an die Admins gerichtet ist.
Also MLGPO in Domänenumgebung würde ich nicht wählen.
Wie colinardo schon schreibt: Loopback-Modus.
Du musst für die Server(!) eine GPO schreiben, die für diese den Loopback-Modus aktiviert:
- entweder "ersetzen", dann gelten für den Benutzer bei Anmeldung an diese Server nur GPOs, die er über den Pfad des Computer-Objekts erbt.
- oder "zusammenführen", dann gelten bei Anmeldung an diese Server alle GPO, welche der Benutzer über den Pfad seines eigenen Objekts erbt als auch jene, welche er über den Pfad des Computer-Objekts erbt
Also wenn Du für die Server den Loopback-Modus aktiviert hast (gpupdate nicht vergessen, oder booten), dann kannst Du an der OU mit den Servern(!) GPO mit Benutzereinstellungen hängen, die für die Admins(!) gelten sollen.
Pass aber bitte auf, wenn Du den Loopback-Modus das erste Mal benutzt. Teste das erstmal mit nur einem Computer. Egal ob Server oder Workstation. Besonders dann, wenn die Admins servergespeicherte Profile haben. Man kann sich da viel versauen.
E.
Wie colinardo schon schreibt: Loopback-Modus.
Du musst für die Server(!) eine GPO schreiben, die für diese den Loopback-Modus aktiviert:
- entweder "ersetzen", dann gelten für den Benutzer bei Anmeldung an diese Server nur GPOs, die er über den Pfad des Computer-Objekts erbt.
- oder "zusammenführen", dann gelten bei Anmeldung an diese Server alle GPO, welche der Benutzer über den Pfad seines eigenen Objekts erbt als auch jene, welche er über den Pfad des Computer-Objekts erbt
Also wenn Du für die Server den Loopback-Modus aktiviert hast (gpupdate nicht vergessen, oder booten), dann kannst Du an der OU mit den Servern(!) GPO mit Benutzereinstellungen hängen, die für die Admins(!) gelten sollen.
Pass aber bitte auf, wenn Du den Loopback-Modus das erste Mal benutzt. Teste das erstmal mit nur einem Computer. Egal ob Server oder Workstation. Besonders dann, wenn die Admins servergespeicherte Profile haben. Man kann sich da viel versauen.
E.
emeriks, moin.
Gib mal kurz an, welche Nachteil Du siehst. Überlege bitte, dass Loopback für alle GPOs auf dem TS zieht - evtl. keineswegs wünschenswert. Deshalb mein Vorschlag.
Gib mal kurz an, welche Nachteil Du siehst. Überlege bitte, dass Loopback für alle GPOs auf dem TS zieht - evtl. keineswegs wünschenswert. Deshalb mein Vorschlag.
Mahlzeit!
MLGPO sind nur "aufgebohrte" Local Policies. Der einzige Vorteil, den ich gegenüber den einfachen Local Policies sehe, ist die Tatsache, dass es nicht nur eine für alle Benutzer des Computers gibt sondern je eine für Admins und Nicht-Admins.
Und soweit ich weiß, kann man da nicht alles einstellen, was man mit Domänen-GPO einstellen kann.
Ich weiß nun nicht, von wieviel Servern wir hier überhaupt reden, aber wenn ich bei uns auf jedem einzelnen Server solche Policies, welche nur auf diesen Servern gelten sollen, pflegen müsste, dann könnte ich einpacken. Warum sollte ich das auf jedem Server einzeln machen, wenn ich es doch zentral erledigen kann?
Aber Dein Hinweis für "alle GPO's" ist richtig.
@stingray79ch
Wenn Du das mit dem Loopback machst, und sicher gehen willst, dass Benutzer bei Anmeldung an diesen Servern nur GPO bekommen, die explizit für Anmeldung an diesen Servern gedacht sind, dann musst Du sicherstellen, dass keine unerwünschten GPO's "von oben" geerbt werden. Höchstwahrscheinlich musst Du dann an der OU mit den Servern die GPO-Vererbung ausschalten.
E.
MLGPO sind nur "aufgebohrte" Local Policies. Der einzige Vorteil, den ich gegenüber den einfachen Local Policies sehe, ist die Tatsache, dass es nicht nur eine für alle Benutzer des Computers gibt sondern je eine für Admins und Nicht-Admins.
Und soweit ich weiß, kann man da nicht alles einstellen, was man mit Domänen-GPO einstellen kann.
Ich weiß nun nicht, von wieviel Servern wir hier überhaupt reden, aber wenn ich bei uns auf jedem einzelnen Server solche Policies, welche nur auf diesen Servern gelten sollen, pflegen müsste, dann könnte ich einpacken. Warum sollte ich das auf jedem Server einzeln machen, wenn ich es doch zentral erledigen kann?
Aber Dein Hinweis für "alle GPO's" ist richtig.
@stingray79ch
Wenn Du das mit dem Loopback machst, und sicher gehen willst, dass Benutzer bei Anmeldung an diesen Servern nur GPO bekommen, die explizit für Anmeldung an diesen Servern gedacht sind, dann musst Du sicherstellen, dass keine unerwünschten GPO's "von oben" geerbt werden. Höchstwahrscheinlich musst Du dann an der OU mit den Servern die GPO-Vererbung ausschalten.
E.
Wenn ich davon ausgehe, dass man die Richtlinien, die man für Benutzer der Domäne einstellt, auch am TS gelten lassen will, dann ist es doch undenkbar, Loopback zu verwenden, denn dann müsste man diese gewünschten, aber nun blockierten Richtlinien ja ALLE am Server nachbauen, DAS macht nun wirklich weit mehr Arbeit.
MLGPO ist angebracht hier, ohne jeden Zweifel.
Nebenbei: Sollte man wirklich in die Verlegenheit kommen, dass auf mehreren (Hunderten?) Servern per MLGPO regeln zu müssen, kann man das auch deployen: http://www.verboon.info/tag/gpopack-wsf/
MLGPO ist angebracht hier, ohne jeden Zweifel.
Und soweit ich weiß, kann man da nicht alles einstellen, was man mit Domänen-GPO einstellen kann
Fast alles. Eben wie bei gpedit.msc üblich. Keine Softwareverteilungspolicy, keine Druckerverteilung und ein paar andere Dinge, die hier definitive keine Rolle spielen.sondern je eine für Admins und Nicht-Admins
Es geht darüber hinaus, man kann einzelne Nutzer und auch Gruppen als Empfänger einsetzen.Nebenbei: Sollte man wirklich in die Verlegenheit kommen, dass auf mehreren (Hunderten?) Servern per MLGPO regeln zu müssen, kann man das auch deployen: http://www.verboon.info/tag/gpopack-wsf/
Letzten Endes wohl Geschmackssache und Frage des Konzepts.
Im konkreten Fall geht es wohl nicht speziell um TS, vermute ich.
Aber auch wenn TS:
Wir trennen bei uns strikt zwischen GPO für PC und solchen für TS.
Eine GPO, die dann doch mal für beide Umgebungen gelten sollte, liegt dann in der Hoheit der TS-Admins und wird eben zweimal (oder mehrmals) verlinkt. Dieselbe GPO. Wo ist da das Problem?
Und das funktioniert tatsächlich auch bei hunderten von TS ohne großen Aufwand. Wir haben ein paar hundert davon, in mehreren Gruppen für verschiedene Kunden. Es gibt GPO für alle TS (die Benutzer von denen) und welche nur für bestimmte TS. Und die Benutzer haben GPO nur für Anmeldung am Computer. Und dann noch die GPO's für Admins. Die Server werden dann entsprechend hirachisch in OUs gelegt und die GPO's verlinkt. Geht prima.
Bei uns wird jeder Admin gelyncht, der ohne Not lokale Sonderlocken strickt.
E.
Edit:
Fairerweise sei gesagt: Local Policies haben den Vorteil, dass die Verarbeitung schneller ist, als bei Domänen GPO. Wenn es bei der Anmeldung auf Sekunden ankommt, dann könnte das - punktuell - ein Ansatz sein.
Im konkreten Fall geht es wohl nicht speziell um TS, vermute ich.
Aber auch wenn TS:
Wir trennen bei uns strikt zwischen GPO für PC und solchen für TS.
Eine GPO, die dann doch mal für beide Umgebungen gelten sollte, liegt dann in der Hoheit der TS-Admins und wird eben zweimal (oder mehrmals) verlinkt. Dieselbe GPO. Wo ist da das Problem?
Und das funktioniert tatsächlich auch bei hunderten von TS ohne großen Aufwand. Wir haben ein paar hundert davon, in mehreren Gruppen für verschiedene Kunden. Es gibt GPO für alle TS (die Benutzer von denen) und welche nur für bestimmte TS. Und die Benutzer haben GPO nur für Anmeldung am Computer. Und dann noch die GPO's für Admins. Die Server werden dann entsprechend hirachisch in OUs gelegt und die GPO's verlinkt. Geht prima.
Bei uns wird jeder Admin gelyncht, der ohne Not lokale Sonderlocken strickt.
E.
Edit:
Fairerweise sei gesagt: Local Policies haben den Vorteil, dass die Verarbeitung schneller ist, als bei Domänen GPO. Wenn es bei der Anmeldung auf Sekunden ankommt, dann könnte das - punktuell - ein Ansatz sein.
