gpupdate vs. gpupdate /force - Mythos #1 und #2
gpupdate vs. gpupdate /force
gpudate /force ist im normalen Administrativen Kontext totaler Blödsinn, unnötig, sinnlos und bringt absolut nichts.
Warum? Ein gpupdate muss schon alles machen, was ihr möchtet. Ein /force forciert nichts, das nicht sowieso schon funktioniert. Oder anders ausgedrückt, ein /force hilft nichts, wenn es infrastrukturell nicht geht. Forcieren erzwingt nichts. Forcieren macht nichts besser. Es klingt nur wie "zwingen". Zudem wird wird es bei Microsoft falsch mit "Erzwungen" übersetzt und der eigene Sprachgebrauch benutzt es gerne ähnlich, anstelle eines steigerns oder verstärkens.
Forcieren ignoriert die Version der Richtlinie und wendet Einstellungen erneut an, das ist alles, was /force macht. Werte die schon da sind oder da sein sollten, aber vielleicht nicht mehr so sind werden erneut geschrieben. That´s it.
Wer es noch nie gemacht hat: gpupdate /?
/Force Wendet alle Richtlinieneinstellungen erneut an. Standardmäßig werden nur geänderte Richtlinien angewendet.
Was bedeutet das für die Prasis?
- Ihr ändert eine Richtlinie, egal welche, egal welche inhaltliche Komponente. gpupdate muss die Einstellungen übernehmen, da sich die Richtlinien Version erhöht hat. Jeder Schreibvorgang, praktisch jedes "klick OK" in der Richtlinie, erhöht die Version um "+1". Benutzer- und Computerkonfiguration werden getrennt gezählt. Das ist der Trigger und der Auslöser für den Aktualisierungsprozess der Gruppenrichtlinien Infrastruktur. Das Objekt führt eine Historie Liste inkl. der Versionen seiner übernommenen Richtlinien, die bei jedem gpupdate Prozess (Anmeldung, Rechner Start, update im Hintergrund) abgeglichen wird.
- /force übernimmt alle Einstellungen OBWOHL (!) sich nichts geändert hat erneut. /force ist der längere Prozess und noch wichtiger: /force meldet, wenn der Rechner neugestartet werden soll oder der Benutzer sich abmelden muss, damit die Einstellungen übernommen werden können. Das ist nur eine Information, mehr nicht. Das Ergebnis bei gpupdate ohne force ist 100% identisch, nur das gpupdate als Silent Befehl ausgelegt wurde, da er permanent läuft. Der User soll nicht alle 90 Minuten informiert werden, das er sich abmelden soll damit die Richtlinie übernommen werden kann. Das /force hingegen informiert über die Tatsache.
Warum benutzen dann alle gpupdate /force und glauben an die Heilswirkung?
Einfache Antwort: Es hat sich so etabliert und das "force" ist eine Verlockung, der man nur schwer entsagen kann. Es kommt aus der Zeit, wo es viele Strukturprobleme gab, der Administrator etwas falsch gemacht hat und dachte, wenn es nicht geht, dann nehme ich die große Kelle und prügel es erzwungen aka force auf den Client. Meistens hätte der Administrator nur die Replikation abwarten müssen oder neustarten sollen, dann wäre es von alleine gegangen.
Wann benötige ich ein /force?
Es kann im Troubleshooting verwendet werden. Der Administrator am System entfernt per Hand Richtlinien, um Fehler zu diagnostizieren. Das gpupdate würde die gelöschten Eintrage nicht wieder integrieren, da sich an der AD GPO Infrastruktur nichts geändert hat, sondern nur lokal am Client. Erst das /force bringt diese zurück.
Wer Benutzer hat, die lokale Adminrechte haben, hat das Problem, das diese das System manipulieren können, ohne das die Werte durch die GPO korrigiert werden. Der Übernahmeprozess vertraut darauf, das ein Benutzer mit Benutzerrechten das System nicht verändern kann. Die Lösung für dieses Problem ist nicht "gpupdate /force" im Anmeldeskript, sondern Entzug der administrativen Rechte für Personen, die das System mutwillig manipulieren.
Ein weiterer Grund ist: Das Objekt wurde im AD verschoben. gpupdate behält die GPList der letzten Übernahme, schaut aber nicht erneut nach dem DistinghuishedName des Obekts. Dieser bleibt erhalten. Das gpupdate /force ermittelt den DN erneut und bekommt damit Notiz von dem wechsel. Alternativ ist Neustart des Computer oder Abmelden/Anmelden des Benutzers die Lösung. Genaugenommen ist das immer die Lösung, wenn man eine sichere Funktion gewährleisten möchte.
... es sei denn ihr Fast Boot aktiviert und GPO Caching, dann braucht es gerne mal länger, aber das ist jetzt eine andere Geschichte.
... oder ihr verteilt Registry Werte an eine Software oder einen Dienst, der erst neugestartet werden muss, damit die neuen Werte funktionieren. Dann hat die GPO ihren Job im Hintergrund erledigt, sie funktioniert, aber die zu steuernde Software kriegt es nicht mit, da sie keinen "Refresh" erhält.
Understanding Group Policy Behavior When a Computer or User is Moved in Active Directory | SDM Software
Aufgrund von logischen Prozessen und der sogenannten Verlässlichkeit der Kette werden Richtlinien jedoch häufiger erneut angewendet als gedacht. Sobald sich zB eine einzige Richtlinien in der GPOList des Objekts ändert müssen alle darin enthaltenen Client Side Extensions alle Richtlinien verarbeiten, in denen sie vorkommen, damit das Endergebnis stimmt.
Beispiel und Mythos 2: Richtlinien werden nur bei Änderung verarbeitet (Nein!)
1. GPO "Bildschirmschoner 10 Minuten mit Kennwortschutz", erstellt 25.02.2021, Version = 3
die Richtlinie gilt für alle Benutzer
2. GPO "Bildschirmschoner aus", erstellt 25.02.2021, Version = 1
die Richtlinie gilt für Monitoring/Präsentationsdisplays/Produktionsmaschinen etc
Ergebnis: an den betreffenden Systemen wird der Bildschirmschoner deaktiviert, was dem gewünschten Resultat entspricht.
Am 25.05.2021 lässt der Chef die 10 Minuten auf 20 ändern. Die Version der Richtlinie erhöht sich auf "4". Damit der Ergebnis stimmt müssen beide Richtlinien angewendet werden. Das ist tatsächlich der Fall -> Verlässlichkeit der Kette.
Ihr könnt praktisch mit der Änderung einer kleinen Einstellungn einen großen Übernahmeprozess triggern, das ihr fast so etwas wie ein /force auslöst.
Fazit:
gpupdate /force macht nichts kaputt, es dauert nur länger und ist in 99% der Fälle unnötig.