We deploy our Windows Firewall settings (among other security settings) as local policies to our machines. They are not part of a domain. There is a weekly restart configured for each machine, combined with a chkdisk.

The problem is, that on some machines the firewall settings when the service starts are NOT loaded from the Group Policy - the local settings and rules are used (which we do not desire). This only happens occasionally and the problem is not reproducible reliably. When I check the configured Group Policies on the machine where the local settings were used instead, everything is set correctly.

How does the Windows Firewall service determines if it should load the rules and settings from the Group Policy or from the local settings? Are there known bugs or race conditions regarding the Group Policy service and the Windows Firewall service or has anybody else encountered a similar problem? Is it possible that the chkdisk interferes with the policies?

The workaround would be that we set the local settings to be a copy of the policy settings, but I would like to understand what the cause of this problem is.

The event log entry looks like this (these settings are taken from the local settings, not the ones defined in the Group Policy - although they are defined!)

The following policy was active when the Windows Firewall started.

Group Policy Applied:   No
Profile Used:   Public
Operational mode:   On
Allow Remote Administration:    Disabled
Allow Unicast Responses to Multicast/Broadcast Traffic: Enabled
Security Logging:
Log Dropped Packets:    Disabled
Log Successful Connections: Disabled
  • You may try gpupdate /force, that should enforce GP. – week Nov 18 '13 at 17:29
  • @week The group policies are not changed since installation. The machine is in no domain, the GP are applied as local policies. At which point should I try to gpupdate /force? The loading of the rules and settings happens on system boot by the Firewall Service, so I am not sure if this is a solution. – Mario Pistrich Nov 18 '13 at 17:33
  • I didn't post it as a solution but possible workaround? Run it in a script, after boot. You may try to adjust update intervals, look here – week Nov 18 '13 at 17:44

I've encountered this problem also. In our case, it doesn't use local rules, it blocks everything. Don't know if it's stuck using the persistent rules, or if it is defaulting to local rules and local rules are void by a different policy setting. Anyway it's broken and I didn't find any answers asking in the Microsoft community. Wouldn't it be nice if Windows logs actually contained useful information.

So I use this workaround: run gpupdate /force at startup using Task Scheduler. I run it as SYSTEM though don't know if that's required.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.