Gpupdate /force failing

I get the below when I try to perform a “gpupdate /force” on my computer when connected to ZPA. I believe I have the app segment and policy configured correctly. I’m not seeing any blocked traffic to my domain controllers. I can’t figure out why this is failing.

C:>gpupdate /force
Updating policy…

Computer policy could not be updated successfully. The following errors were encountered:

The processing of Group Policy failed because of lack of network connectivity to a domain controller. This may be a transient condition. A success message would be generated once the machine gets connected to the domain controller and Group Policy has successfully processed. If you do not see a success message for several hours, then contact your administrator.
User Policy could not be updated successfully. The following errors were encountered:

The processing of Group Policy failed because of lack of network connectivity to a domain controller. This may be a transient condition. A success message would be generated once the machine gets connected to the domain controller and Group Policy has successfully processed. If you do not see a success message for several hours, then contact your administrator.

To diagnose the failure, review the event log or run GPRESULT /H GPReport.html from the command line to access information about Group Policy results.

Now I’m getting this. my domain is already set in the DNS search domain list.

C:\WINDOWS\system32>gpupdate /force
Updating policy…

Computer policy could not be updated successfully. The following errors were encountered:

The processing of Group Policy failed. Windows could not resolve the computer name. This could be caused by one of more of the following:
a) Name Resolution failure on the current domain controller.
b) Active Directory Replication Latency (an account created on another domain controller has not replicated to the current domain controller).
User Policy could not be updated successfully. The following errors were encountered:

The processing of Group Policy failed. Windows could not resolve the user name. This could be caused by one of more of the following:
a) Name Resolution failure on the current domain controller.
b) Active Directory Replication Latency (an account created on another domain controller has not replicated to the current domain controller).

To diagnose the failure, review the event log or run GPRESULT /H GPReport.html from the command line to access information about Group Policy results.

1 Like

So I got it working when all TCP and UDP ports are open to the domain controllers. Which is weird because I never saw any dropped traffic to the domain controllers. There are definitely additional ports being hit now that never showed up in logs. I’m pretty confused.

My client has the same issue.
I checked the log in ZPA portal, and there was no log of domain controller.
Which means, I guess the traffic to domain controller was not reachable to ZPA-ZEN.

I assume that the end user’s device just cannot do name resolution because of its configuration.
I mean I do not know if this is caused by Zscaler service.

I also would like to know fix this and cause of issue.

What ports do you have open?

If you’d defined Active Directory with specific ports, then you wouldn’t see drops in the Diagnostics Logs. You’d need to check in the ZAPP logs, or in a PCAP, to see why something was getting dropped. Opening all ports would resolve the issue, but ideally you’d want to segment down to just the necessary ports.
Ensure the connectors are in your AD Sites subnets. You need DNS SRV records to pass, and LDAP & CLDAP to function (TCP/389 & UDP/389) to enumerate the domain. The client will make an RPC call (TCP/135) to retrieve a high port for the connection for GPO - by default this in is the range 49000-65535. You can restrict this by following these directions from Microsoft https://support.microsoft.com/en-us/help/154596/how-to-configure-rpc-dynamic-port-allocation-to-work-with-firewalls . Otherwise you’ll need to include 49000-65535 in the port ranges for your Active Directory.

2 Likes

Thanks for the information. That’s helpful. I’m still confused about logging. Why do I see block logs for any other applications that are not defined in policy? For example, I’m seeing block logs for an intranet site I forgot to define in policy. Why would this be any different for AD/GPO traffic? I never saw the 49000-65535 traffic in logs until I allowed all ports.

If it’s not a port defined in the application segment, then it would get dropped at the ZAPP client. If the port is defined in the application segment, but blocked by policy (or dropped because of firewall/ACL) then you’d see this in the Diagnostics portal - because the traffic was intercepted by the ZAPP client and forwarded to a connector.

For example :-

Application Segment 1 - *.domain.com TCP/1-65535
Application Segment 2 - dc.domain.com TCP/88, TCP/135, TCP/389, UDP/389

The DNS SRV lookup _ldap._tcp.domain.com will hit application segment #1, and return dc.domain.com:389 as the response
Access to a server server.domain.com:8080 would hit application segment #1, and be allowed. However is server.domain.com is not listening on port 8080, you would see an error in the diagnostics log.
When user connects to TCP/389 or UDP/389 to dc.domain.com they will authenticate and need to retrieve their GPO policy. They will connect to TCP/135 (Portmapper) to request an available port.
User will connect to dc.domain.com on “high port” (say 49001). Since the port is not allowed for the application segment it will get dropped at the client. In the ZSATunnel log files (C:\programdata\zscaler) you would see the log entry

Exception in ZpnServerHandler init for tag id: 0 (Error: Application exception: ZPN: Port not allowed: : 49001)

I recorded a short video which might help (although I didn’t do the log piece). Maybe this helps? https://youtu.be/0AUl-mtdqXU

4 Likes