All about Group Policies: Group Policy GPUpdate Commands

Group Policy is a feature of Windows that facilitates a wide variety of advanced settings that network administrators can use to control the working environment of users and computer accounts in Active Directory. In this article, I will discuss “All about Group Policies: Group Policy GPUpdate Commands: GPUpdate, GPUpdate/force, LogOff, Boot, Wait, and Sync”. These steps are similar to How to install Windows Server 2019 on Virtualbox, how to install and configure Ubuntu Linux on VirtualBox, and How to install Windows Server 2022 on VirtualBox.

When a Group Policy is created using either the Group Policy Management Editor or the Local Group Policy Editor, these policies aren’t immediately applied to the user and computer objects Active Directory or your local computer. You may wan to lean about the differences between “Local Security Policy vs Local Group Policy“.

By default, these updates are applied every 90 minutes, plus a random offset between 0 and 30 minutes. To us, this is like forever, and we want these policies to be applied immediately. Here, the GPUpdate command can be used to achieve this. But when a Domain Controller is targeted by a policy, the default refresh time is five (5) minutes.

In this article, I will be focusing on and clearing the misconception between gpupdate vs gpupdate /force. Here is a brief explanation of the difference between the two.

You may want to see the following articles as well. Why use RSAT? How to Install RSAT on Windows 10, Remote Server Administration Tools: To install RSAT on Windows Server, and what is Group Policy Object and how can it be launched in Windows.

Gpupdate

Here the gpupdate reads the Group Policy store and versions of the GPOs and applies GPOs only if something has changed. In other words, it applies any policies that are new or changed user and computer policy settings are applied.

That is, once the refresh interval expires, the Group Policy Client service queries the Domain Controller (DC) for any new or updated policies. If it detects changes, it downloads and applies the updated policies on the client computer.

Gpupdate /force

Here all group policies are downloaded and applied. In other words, it reapplies every policy, both new and old. As you may know, normally when Windows performs a periodic background refresh or foreground refresh during reboot or re-logon. It checks to see if anything has changed within the GPO infrastructure.

If nothing has changed, none of the Client Side Extensions (CSEs) that process policy settings will actually do anything. This is a performance optimization. Using the /force switch tells the GP engine to ignore that nothing has changed. And then forces the CSEs to act as if something has changed and re-process all applied policy settings.

Simply running gpupdate is sufficient most of the time. Running gpupdate /force against several targets (devices) can have tremendous effects. These devices will end up re-evaluating the GPO applied to them.

In this way, if there are settings configured wrongly by some other administrators, these settings will be applied. Here is the syntax of how the tool is used.

Gpupdate [/Target:{Computer | User}] [/Force] [/Wait:<value>] [/Logoff] [/Boot] [/Sync]

Please see How to prevent the saving of RDP Credentials in Windows 10, and how to fix your device cannot use a Trusted Platform Module: Allow BitLocker without a compatible TPM. How to Enable BitLocker without Compatible TPM, and how to correctly disable MBAM-encrypted devices.

Update Group Policy Via Command Prompt

For other switches as displayed in the image above, here are some descriptions.

gpupdate /force

GPO Update Switches

/LogOff: Here, certain GPOS, such as Folder Redirection, can’t apply in the background. If a logoff is required, this switch will initiate it.

/Boot: If a policy, such as software installation, needs to be applied, the boot command will reboot the machine.

Therefore, “Boot” is the same as “/logoff”, except that it applies to per-computer Clint side extensions (CSEs) that need to do some foreground work (e.g. per-computer software installation as discussed at the beginning of this sentence), and then reboots the computer if you say yes to the prompt.

Again, this prompt only happens if there are per-computer CSEs that apply to the machine, that actually needs a foreground processing cycle.

/Sync: Actually does not perform a group policy refresh. All it does, if specified alone, is set some flags for both per-computer and per-user processing that forces the next foreground refresh (i.e. reboot or re-logon) to be performed synchronously. Useful for changing the foreground (startup/logon) processing to sync.

/Target:{Computer | User} : this one lets you refresh either computer or user policy selectively. For example, if you made a change to a per-user GPO setting, it’s much quicker to issue the command gpupdate /Target:user than to simply type gpupdate, which refreshes both per-computer and per-user settings.

/Wait:{value}: This enables you to handle the situation where GP processing hangs for a long period of time. The default is to wait for 10 minutes for the command to complete. If it takes longer than that, then GPupdate simply gives up and returns. If you set this value to -1, then gpupdate will continue indefinitely.

Run GPupdate Via PowerShell

You can also use PowerShell cmdlets to target remote devices to apply GPUpdate. Example 1 below.

Invoke-GPUpdate -Computer COMPUTERNAME –Force

Example 2. Please see How to disable Cortana via the registry or GPO.

$Computers  = Get-AdComputer -SearchBase "OU=testuser, DC=TechDirectArchive,DC=local" -Filter *
Foreach ($Computer in $Computers) {invoke-gpupdate -Computer $Computers.Name} 

Via Group Policy Management Console

Lastly, Microsoft also has a feature built into Group Policy Management Console that enables you to run GPUpdate against an OU.

• On the desired “OU”
• Right-click and select Group Policy Update and that is all.

Group Policy Templates

A Group Policy Object (GPO) serves as the primary component of Group Policy, with the Group Policy Template (GPT) being equally important. The GPT works alongside the GPO to enforce policies effectively.

Active Directory stores GPOs in SYSVOL, a file share on domain controllers that distributes policy-related files. GPTs contain registry settings, security configurations, applications, scripts, installers, shortcuts, XML files, graphic files, and other resources depending on the settings defined in the associated GPO.

Manging Group Policy with the Group Policy Management Console (GPMC)

Group Policy can be also be managed through the Group Policy Management Console (GPMC), which is installed on all domain controllers and included in the Remote Server Administration Tools (RSAT).

The GPMC connects directly to the domain controller holding the Primary Domain Controller Emulator (PDCe) role to apply and modify Group Policy settings.

How Group Policy Replication Works

Group Policy replication ensures that Group Policy Objects (GPOs) and Group Policy Templates (GPTs) remain consistent across all domain controllers (DCs) in an Active Directory (AD) environment. Since both GPOs and GPTs are part of AD, they follow the standard Active Directory replication process.

Workflow of Group Policy Replication

This replication process ensures that Group Policy settings remain consistent across the domain. Thereby reducing the risk of policy mismatches and configuration drift. Below are the steps involved in GPO replication.

1: Initiating a Group Policy Change: When an administrator creates or modifies a GPO using the Group Policy Management Console (GPMC), the request is directed to the Primary Domain Controller Emulator (PDCe).

2: Updating Active Directory and SYSVOL: The GPMC updates the GPO in the Active Directory database. Simultaneously, the corresponding GPT is created or modified within the SYSVOL folder.

3: Active Directory Replication: Once the changes are made, Active Directory replication propagates the GPO across all domain controllers based on the AD replication schedule.

• If the PDCe and the local DC are in the same site, replication typically completes within five minutes. However, for different AD sites, replication takes longer, depending on site link schedules and inter-site replication intervals.

4: SYSVOL Replication via DFS-R: Unlike AD database replication, SYSVOL replication follows a separate mechanism called Distributed File System Replication (DFS-R).

• DFS-R synchronizes the GPT files in SYSVOL across all DCs using the same replication schedule as AD.
• Since both AD replication and DFS-R follow the same schedule, GPO and GPT updates generally arrive at the local DC around the same time.

FAQs

If you have found these tips useful on “All about Group Policies: Group Policy GPUpdate Commands: GPUpdate, GPUpdate/force, LogOff, Boot, Wait, and Sync”. kindly comment below and let me know via the comment session.