Strict Enforcement Mode sort of breaks Windows Update


I think we’ve found kind of a catch 22 with Windows Update (and other cloud based services) and ZCC Strict Enforcement mode; wondering if anyone else has encountered this and found a way around it.

Effectively what happens: Machine is set to go to Microsoft for Windows Updates, it sees an update (an OS build update in this case), a user is logged on and registered with ZScaler so the WU process pulls down the bits, applies them, then prompts for/has a policy set reboot.

At this point the machine reboots and sits at the logon screen (patches happen after hours), here’s where the problem comes in, the WU process needs to reach back out to Microsoft, it can’t because of Strict Enforcement, and the WU process fails.

We’ve seen similar behavior with other cloud based agents, if no one is logged in and registered with ZScaler the machine is effectively offline.

It seems like there must be a way to handle this, but support is saying there isn’t. If it were a single, static URL I could put it in the VPN bypass list, but Windows Update is a whole long, ever changing list of URLs and the VPN bypass list doesn’t support wildcard URLs.

I really don’t want to turn strict enforcement off because that severely weakens ZIA as a whole, there needs to be/must be some sort of happy medium where I can define a finite list of URLs (including wildcards) that a machine should ALWAYS be able to get to, regardless of the client user state.

Any ideas?


I thought strict enforcement is only a concern when the user is logged off of ZCC.

It is, but in the case of Windows Updates that happen very late at night the system is routinely rebooted, left logged off, and the WU process expects to be able to access the internet.

So: Reboot > No One Logs in > WU tries to go out to Microsoft (in the background) > Can’t (because no one is logged in) > WU fails

Hello Tony,
“If it were a single, static URL I could put it in the VPN bypass list, but Windows Update is a whole long, ever changing list of URLs and the VPN bypass list doesn’t support wildcard URLs.”

We are currently working on bypassing applications using the process name. So you will be able to bypass any applications by whitelisting that process.

1 Like

Any chance that’s available in the pre-release versions? If not, any ETA?

We do not have a pre-release versions. We are targeting (this might change) Jan 2023. We might have a Beta version by the end of this year.

Short of that, is there really no other way to do this other than reinstalling the ZCC with Strict Enforcement off temporarily?

This seems more a problem of pre-windows login than strict-enforcement. Strict enforcement is to prevent from logging out of ZCC or exiting from ZCC by limiting internet access unless a user is logged in. I don’t see a workaround with only ZIA enabled, but you could enable a machine tunnel that allows these updates while the user is not yet logged in, which is also known as Pre-Windows Login.

Unfortunately, this requires Zscaler Private Access (ZPA) to function and is not available today with just a ZIA subscription.

Hi Tony,

Agree with Mark, something else is going on here.
Can you share a little more about your ZCC config like:

  1. Are you using a Policy Token to assign a Default App Profile as part of ZCC install script ?
  2. If so, what Forwarding profile - System Proxy configured as?


We are using a policy token to assign a default app profile as part of the ZCC install script.

Here is the Forwarding Profile configuration associated with it:

We did initially work with pro-services to deploy ZIA.

Edit: One note, the reason why we’re using the ZCC tunnel on the trusted network is sort of an odd story. We DO have an IPSec tunnel established from our trusted network to the ZIA edge, but we have an odd instability. We worked extensively with support and engineering during implementation, but were never able to pinpoint an exact root cause. Every 4-8 hours the tunnel stops passing traffic; it doesn’t drop but bidirectional traffic completely ‘freezes’. As a workaround I put together a script the gets the HTTP response code of an external site and if it’s anything other that a HTTP 200 that indicates the tunnel is ‘frozen’ and it drops the IPSec tunnel on our edge, which forces it to reestablish and it works for another 4-8 hours.

Our end is a Cisco ASA. We ended up allowing the clients to directly egress to the ZIA edge because that isolates them from the tunnel weirdness; even with the script, depending on when the ‘freeze’ happens and the point in the scheduled task cycle, it can be up to 5 minutes where the machines using the IPSec tunnel for egress are effectively cut off.

Thanks very much,

Hi Tony,

I can only imagine that Professional Services had a reason for configuring this.
System proxy can get ‘interesting’ especially for and other related services.