Group Policy intermittently not applying

Joshua Thompson 201 Reputation points
2021-03-15T21:27:56.13+00:00

We have Win10 workstations (v1909) that are intermittently not applying their group policies properly after a nightly restart. It seems to be centered only around the firewall policy.

After the restart we are noticing that the DOMAIN firewall profile is ON when we have specific group policies that turn that off.

When we see a workstation in this condition we run a "gpupdate /force" and the domain firewall profile gets disabled (per the policy).

Nothing stands out in the Event viewer of the workstations that show why the firewall policy is not being applied properly.

The workstations restart at midnight and we are still seeing the issue at 0530 in the AM so there has been plenty of time for the group policy to refresh.

I am not sure if this is a coincidence or not but we are not seeing this happen on workstations that have Win10 20H2 installed.

Any suggestions?

Windows
Windows
A family of Microsoft operating systems that run across personal computers, tablets, laptops, phones, internet of things devices, self-contained mixed reality headsets, large collaboration screens, and other devices.
4,735 questions
0 comments No comments
{count} votes

4 answers

Sort by: Most helpful
  1. Daisy Zhou 18,701 Reputation points Microsoft Vendor
    2021-03-16T05:54:32.177+00:00

    Hello @Joshua Thompson ,

    Thank you for posting here.

    1.How many Win10 workstations (v1909) are there have such issue?
    2.Do you mean the issue reoccurs after restarting the machine? If you do not restart the machine, there is no such issue, right?
    3.Are all the Win10 workstations v1909 in the same OU have such issue?
    4.How many DCs do you have in your AD environment?

    You can try to check if AD replication is working fine by running the commands on PDC server.

    repadmin /showrepl >c:\repsum1.txt

    repadmin /replsum >c:\repsum2.txt

    repadmin /showrepl * /csv >c:\repsum.csv

    And you can try to check if SYSVOL replication is working fine by creating one file/folder under C:\Windows\SYSVOL\domain\Policies on any one DC, then check if the new file/folder can be replicated to each other after ten minutes later automatically.

    For example:
    If you have 2 DCs (DC1 and DC1), create file1 under C:\Windows\SYSVOL\domain\Policies on DC1, check if file1 can be replicated to C:\Windows\SYSVOL\domain\Policies on DC2 after ten minutes later automatically.
    And you can create file2 under C:\Windows\SYSVOL\domain\Policies on DC2, check if file2 can be replicated to C:\Windows\SYSVOL\domain\Policies on DC1 after ten minutes later automatically.

    78060-sy1.png

    If AD replication and SYSVOL replication between all DCs works fine.

    Maybe the issue is related to network, after the machine restart, does the machine connected to domain network immediately?
    Or if you do not run gpupdate /force, does the domain firewall profile gets disabled (per the policy) after 90-120 minutes later automatically?

    Hope the information above is helpful.

    Should you have any question or concern, please feel free to let us know.

    Best Regards,
    Daisy Zhou

    1 person found this answer helpful.

  2. Matthias Furrer 11 Reputation points
    2022-11-09T10:08:19.607+00:00

    FYI I found the issue.

    The problem is the following setting which is part of the recommended configurations in the CIS benchmark for Windows Server.

    18.8.21.2 (L1) Ensure 'Configure registry policy processing: Do not apply during periodic background processing' is set to 'Enabled: FALSE' (Automated)

    HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy{35378EAC-683F-11D2-A89A-00C04FBBCFA2}:NoBackgroundPolicy

    Registry processing takes too long and the MpsSvc starts with the settings in the PersistentStore.
    You can deploy the PeristentStore settings via the following registry key:
    SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile EnableFirewall REG_DWORD: 0x0 (0)

    17:41:36.9470338 svchost.exe 2000 2596 RegDeleteValue HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall\DomainProfile\EnableFirewall SUCCESS
    17:41:44.6079838 svchost.exe 2100 3508 RegQueryValue HKLM\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\EnableFirewall SUCCESS Type: REG_DWORD, Length: 4, Data: 1
    38724 [3] 0834.0DB4::10/18/22-17:41:44.6986418 [windows] dllmain_cpp1227 FwGPLockInternal() - FwGPLockInternal: EnterCriticalPolicySectionExStub returned 0000000000000000
    38725 [3] 0834.0DB4::10/18/22-17:41:44.6986465 [lh] fw_prof_mgr_c2023 FwProfileMgrUpdateCachedPolicy() - Acquiring the GP Lock Failed... GP will not be pushed, until next GP notification (soon to come)
    38726 [3] 0834.0DB4::10/18/22-17:41:44.6986473 [lh] fw_prof_mgr_c2027 FwProfileMgrUpdateCachedPolicy() - updateGroupStore=0

    1 person found this answer helpful.

  3. Daisy Zhou 18,701 Reputation points Microsoft Vendor
    2021-03-17T05:53:27.617+00:00

    Hello @Joshua Thompson ,

    Thank you for your update.

    Would you please check if you restart one machine manually to see if the same issue reoccurs(DOMAIN firewall profile is ON)?

    If so, we can try to capture the Process Monitor during you reproduce the issue. Then you can try to analyze the Process Monitor log and find any process or app change the DOMAIN firewall profile.

    Or you can check if there is any audit policy to audit DOMAIN firewall profile changes. If so, try to configure the audit policy, then if the issue reoccurs, check the corresponding log.

    Hope the information above is helpful.

    Thank you for your understanding and support.

    Tip: Please kindly remind that since private information and security information may be involved, the forum does not analyze any logs.

    Best Regards,
    Daisy Zhou


  4. Joshua Thompson 156 Reputation points
    2022-09-22T13:42:46.827+00:00

    Unfortunately I was never able to narrow the problem fix.

    I 'believe' this went away when we rolled out 20H2 to all of our workstations.

    0 comments No comments