topic Re: [SOLVED] GPUDATE /FORCE DOESN'T WORK WITH GLOBAL PROTECT in GlobalProtect Discussions

[SOLVED] GPUDATE /FORCE DOESN'T WORK WITH GLOBAL PROTECT

DanielS.Romero — Sun, 10 May 2026 00:08:09 GMT

Hello LiveCommunity Team!

I created this post to share my experience regarding an issue involving GlobalProtect users from Prisma Access who attempt to run gpupdate /force to update GPO policies from the DC server, and who encounter the following error:

CMD ERROR GPUPDATE /FORCE
C:\WINDOWS\system32>gpupdate /force

Updating policy...

User policy cannot be updated successfully due to the following errors:

Group policy cannot be processed because it cannot connect to a domain controller over the network. This condition may be temporary. A success message may be generated once the computer connects to the domain controller and the group policy is processed successfully. Contact your administrator.

- Given this error, I checked the GlobalProtect source IP logs and everything appeared to be allowed.

Then, I tried pinging from an affected endpoint with a custom length and the DF "Don't Fragment" bit active set to 1350 bytes, and the ping was dropped by fragmentation needed. as shown below:

PING TEST WITH 1350 BYTES

Then I try it with 1300 Bytes as the payload and the ping works!

PING TEST WITH 1300 BYTES

So, as a test, I changed the Prisma Access GlobalProtect tunnel MTU to 1300 bytes (default is 1400 bytes) and the gpupdate /force command works!

PRISMA ACCESS GLOBAL PROTECT CONNECTION MTU ADJUSTMENT FROM 1400 TO 1300 BYTES

CMD GPUPDATE /FORCE SUCCESFULLY

C:\Users\pcmolinaa>gpupdate /force
Updating policy...

The computer policy update completed successfully.

Conclusions:

- Some device in the path, most likely the on-premises NGFW, was dropping the LDAP packets because it has a lower MTU and the packets are sent with the DF bit set, disabling IP fragmentation and forcing the drop by some peer.

Thank you for your time, and I hope this information is helpful in your daily cybersecurity work. I would greatly appreciate your support by liking or accepting this as a useful post; it would help me a lot in becoming a CyberElite!

Best Regards,

Daniel Romero
Senior Network/Security Engineer
PANW Partner

Re: [SOLVED] GPUDATE /FORCE DOESN'T WORK WITH GLOBAL PROTECT

JayGolf — Wed, 13 May 2026 23:24:00 GMT

Hi @DanielS.Romero ,

Thanks for sharing! Would love to share more of your insights.

Re: [SOLVED] GPUDATE /FORCE DOESN'T WORK WITH GLOBAL PROTECT

DanielS.Romero — Tue, 28 Jul 2026 19:30:13 GMT

Hello LiveCommunity Team!

For additional information, we have implemented the following changes to improve GPO performance for mobile users:

Prisma Access GlobalProtect GPUPDATE Slowness Troubleshooting Steps:

1- Test GPO functionality with the preferred version of GlobalProtect, such as 6.2.8-263 to avoid buffer and performance issues (Didn't work).
2- Reduce the virtual adapter MTU value from 1400 to 1300 bytes (Didn't work completely).
3- Disable IPv6 on the physical adapter (Didn't work).
4- Test using a mobile hotspot or a different Internet Service Provider (ISP) (Didn't work).
5- Enable "Best Gateway Selection" to use TCP instead of TLS when selecting the best available gateway (Didn't work).
6- Enable manual selection of IPsec and SSL for the GlobalProtect connection (Didn't work).
7- Enable DSRI in the security rules (Didn't work).
8- Change the GlobalProtect mode from "Tunnel and Proxy" to "Tunnel Only" (Didn't work).
9- Create a custom application with TCP port 445 as the destination for SMB traffic, along with an application override rule created within the GlobalProtect scope (Didn't work).
10- Verify QoS rules (Did not work).
11- Disable SMB Multichannel (SMBv3) on the clients/servers sides (Not scalable & recommended).
12- Increase the GPO wait time on the server side (Not recommended).
13- The backend team increased the CPU version on the MU-SPN South America Ecuador Gateway node (Didn't work).
14- Enable App Acceleration on Prisma Access to expedite only the IPv4 TCP traffic (Didn't work).
15- The backend team deploys and upgraded a new gateway node in the Central Colombia region., then we setup the tunnel for the Colombia location and also tested with user connected to the GPGW Colombia location and saw significant improvement with GPO's finishing between 6-8 minutes sucessfully, as belows:

PRISMA ACCESS ARCHITECTURE

PRISMA ACCESS GLOBALPROTECT LOCATIONS

PRISMA ACCESS GW COLOMBIA CENTRAL PING TO GPO SERVER

Conclusions:

- Prisma Access offers worldwide locations for deployment, and a key best practice is to choose locations that are geographically closest to your users or NGFWs to connect with SC-CANs or RN-SPN nodes.

- Deploying a gateway node in a region like Colombia Central directly addresses potential latency and performance issues by reducing the physical distance data needs to travel between the user and the Prisma Access service.

- This successful deployment demonstrates a well-executed troubleshooting step that directly aligns with Prisma Access best practices for optimizing mobile user connectivity and performance.

- SMB is a chattier protocol that performs poorly under elevated latency. The previous route via the MU-SPN South America Ecuador gateway incurred round-trip times of ~174 ms, causing severe GPO processing delays and timeouts.

- Modifying client/firewall configurations (MTU adjustments, DSRI, IPv6 disabling, App-ID overrides, QoS, App Acceleration, and gateway CPU upgrades) did not mitigate the issue because the underlying constraint was physical propagation delay across regions.

Why Colombia Central Solved the Issue?

- BGP Routing & Latency (~174 ms in Ecuador): Traffic targeting Colombia-bound resources via the Ecuador gateway suffered from regional BGP routing paths. In South-America ISPs, cross-border traffic frequently hairpins through international NAPs (such as Miami) rather than taking direct terrestrial routes. This added massive physical propagation delay, raising RTT to ~174 ms.

- SMB/GPO Protocol Sensitivity: Group Policy Object updates rely heavily on SMB/CIFS (TCP 445). SMB is an inherently "chatty" protocol that requires hundreds of sequential round-trips to negotiate sessions and transfer data. At ~174 ms, this back-and-forth communication accumulated into severe application timeouts and failed GPO syncs.

- Direct Local Peering (~41 ms in Central Colombia): Moving to the Central Colombia gateway kept the traffic within national ISP peering networks, bypassing international hops. Dropping the latency to ~41 ms reduced SMB transaction overhead to normal operational levels, allowing GPOs to complete successfully within 6–8 minutes.

Best Regards,

Daniel Romero
Senior Network/Security Engineer
PANW Partner