Here is exactly what happens.
1. Starting the Service
When you type the command, it wakes up a specific background task called the Group Policy Client.
- If you just run gpupdate, the server only asks for settings that have changed.
- If you run gpupdate /force, the server ignores its history and re-downloads every single setting.
2. Finding a Domain Controller
The server needs to find a "source" for its settings. It checks your network’s DNS to find a Domain Controller. Once it finds one, it proves who it is (authenticates) using its computer account.
3. Figuring Out Which Policies Apply
The server asks the Domain Controller for a list of all Group Policy Objects (GPOs). It checks several things to see which ones it should actually use:
- Location: Is the GPO linked to the server’s specific folder (OU) or domain?
- Permissions: Does the server have permission to read and use that GPO?
- Filters: Are there rules saying "only apply this to Windows Server 2022" or similar?
4. Checking for Version Changes
Every GPO has a version number. The server compares the version number on the Domain Controller to the one it already has saved.
- If the number on the DC is higher, the server knows there is an update.
- If the numbers match, the server usually skips that GPO (unless you used /force).
5. Downloading the Files
Once the server knows which GPOs are new, it connects to a shared folder on the Domain Controller called SYSVOL. It downloads the actual files, which contain the registry settings, scripts, or wallpaper paths.
The SYSVOL folder is physically located on every Domain Controller at C:\Windows\SYSVOL\sysvol, but member servers access it over the network using the path \\DomainName\SYSVOL. To get there, the member server uses its Computer Account to authenticate via Kerberos, proving it is a trusted part of the domain without needing a user to log in manually. It connects using the SMB (Server Message Block) protocol over Port 445, which is the standard way Windows shares files. Because SYSVOL uses DFS (Distributed File System), the server doesn't have to point to one specific Domain Controller; it simply asks the domain for the files, and Windows automatically connects it to the closest available DC to download the necessary Group Policy templates.
6. Applying the Settings
The main Group Policy engine doesn't actually change your settings. Instead, it hands the files over to "specialists" called Client-Side Extensions.
- One specialist handles Registry changes.
- Another handles Security rules (like who can log in).
- Another handles Preferences (like mapping a network drive).
Think of the Group Policy engine as a project manager. It finds the instructions, but it doesn't do the physical labor. Instead, it hires "specialists" called Client-Side Extensions (CSEs) to do the actual work on the server.
Each specialist has one specific job they are trained for:
- The Registry Specialist: This is the most common one. Its only job is to open the Windows Registry and change the settings you’ve picked, like disabling the Control Panel or setting a wallpaper.
- The Security Specialist: This worker handles the "lock and key" settings. It decides which users are allowed to log in to the server and what they are allowed to do once they get in.
- The Preferences Specialist: This one handles the "extras" that make a user's life easier, such as automatically connecting to a printer or making sure a specific folder appears on the desktop.
When the Group Policy engine finishes downloading the instruction files from the network, it calls these specialists one by one. It hands each of them the part of the file they understand. The specialists then go into the server's system, make the changes, and report back when they are done. This is why some settings (like security) might take a few seconds longer to apply than others.
7. Finishing and Logging
After the specialists finish their work, the server saves the new version numbers so it knows it is up to date. It then records a "Success" message in the Windows Event Viewer so you can check it later.
If you want to see exactly which policies worked and which ones failed, run gpresult /r. This gives you a simple list of every policy applied during the update.
Required ports:
Port 53 (TCP/UDP): DNS – Used to find the Domain Controller.
Port 88 (TCP/UDP): Kerberos – Used to authenticate the computer account.
Port 135 (TCP): RPC Endpoint Mapper – Used to start the connection process.
Port 389 (TCP/UDP): LDAP – Used to search for the list of GPOs in Active Directory.
Port 445 (TCP): SMB – Used to download the policy files from the SYSVOL folder.
Ports 49152–65535 (TCP): RPC Dynamic Ports – Used to transfer the policy data.
.png)