MDM & GP Tips Blog

This is certainly a topic I have written about in the past, but revisiting how to manually update Group Policy is worthwhile, given the ongoing confusion surrounding the topic. The choice between using `gpupdate` alone or with the `/force` option is a common query.

First, let's recap the automatic Group Policy update mechanisms:

1. Computer-side Group Policy Settings automatically refresh upon the restart of a domain member computer.

2. User-side Group Policy Settings refresh when a user logs onto a domain member computer.

3. By default, Group Policy Settings undergo an automatic refresh every 90 minutes, with a random offset of up to 30 minutes to prevent system overload against the DCs, so they dont fall over and di.=e.

However, there are situations where waiting for an automatic refresh or disrupting a user's session with a logoff or reboot is impractical, especially when immediate action is required. That is when the gupdate command comes into play using either command prompt or PowerShell.

While `gpupdate /force` can be used in any situation, making it a go-to for ensuring all policies are applied, it's not always the most efficient method. Let's explore the nuances between `gpupdate` and `gpupdate /force` to understand when each should be used for optimal Group Policy management.

GPUpdate by Itself

This command efficiently updates Group Policy settings for either a computer or user, applying only the changes made since the last refresh without reapplying unchanged settings of other policies. This command is typically used to apply changes made to a single policy. It is a less intrusive option, often employed for routine Group Policy maintenance. Serving as the go-to command for most needs, it ensures that recent policy adjustments are implemented swiftly and with minimal disruption. It's especially useful for testing or when needing to apply a newly created or revised policy to a specific computer or user session.

GPUpdate /Force
This command forces a refresh of all Group Policy settings, regardless of whether any have changed or not. It re-applies all settings, which can be useful for solving issues related to policy application or when a computer or user receives new policies for the first time. However, because it reapplies all policies, it can be more disruptive, potentially causing logon scripts to run again and requiring a logoff or restart for some policies to reapply effectively. If nothing else, it takes longer to enact and leaves you sitting idle. Use `gpupdate /force` when troubleshooting policy application problems or when you need to ensure that all policies apply again, not just the recently changed ones.

With Windows 10, Group Policy administrators could configure whether Windows Defender receives its updates through standard Windows Update channels or alternative sources such as WSUS (Windows Server Update Services) or manually specified update locations. as shown below. You could set whether Windows Defender should receive updates through standard Windows Update channels, or through alternative means like WSUS (Windows Server Update Services) or manually specified sources.

In Windows 11, Group Policy administrators are now provided with the capability to select specific channels for acquiring virus signatures for both daily and monthly updates. This new feature offers enhanced control over how and from where these crucial security updates are sourced, aligning with the organization's specific requirements and IT infrastructure. The process is quite similar to the process of assigning devices to channels for Windows Update for Business. The new settings reside in the root directory of Microsoft Defender Antivirus as shown here.

First let’s talk about the different types of updates.

1. Daily Security Intelligence Updates are frequent updates that provide the latest definitions for viruses, spyware, and other malware. These are essential for Microsoft Defender to recognize and protect against newly emerging threats once they have been identified.

2. Monthly Engine Updates enhance the capabilities of Microsoft Defender’s threat detection such as scanning functionality and detection algorithms. In addition to improving threat identification and remediation, these updates help optimize the Defender’s performance and resource usage.

3. Monthly Platform Updates introduce new functionality, features, and user interface modifications. They may also address identified bugs or vulnerabilities within the software itself.

Now, let’s talk about the various channels available.

• Beta Channel: Devices assigned to it will be the first to receive new updates. These devices should be used for testing environments. Devices subscribed to the Windows Insider program are assigned to this channel by default.
• Current Channel (Preview): Devices set to this channel will be offered updates earliest during the monthly gradual release cycle. This is recommended for devices in pre-production or validation environments.
• Current Channel (Broad): Devices will be offered updates only after the gradual release cycle completes. Most of the devices in your production environment should be assigned here.
• Current Channel (Staged): Devices assigned here will get updates later during the gradual release cycle but prior to the release to the majority of devices. Microsoft states that no more than 10% of your devices should be assigned to this channel.
• Critical-Time delay: Devices will be offered updates with a 48-hour delay. This is suggested for devices in critical environments only.

The channel selection process for Monthly Engine and Monthly Platform updates is the same as shown in the screenshot below.

Daily Security Intelligence Updates have fewer channel options as they are much more pertinent.

A cyberattack isn’t a sudden single event, but a storyline compromised of multiple stages. First is the initial compromise, followed by the establishment of a foothold or beachhead that the attackers will base operations from. From there the attackers move laterally across the network to perform reconnaissance. The objectives here are to escalate privilege and identify high-value data to target. The final stage is the actual attack itself.

The initial compromise is usually conducted using a compromised standard user account that was captured using a credential stuffing attack or phishing email. To achieve their mission, attackers must work to escalate their privilege to gain access to all areas of the network. This means targeting a privileged user next such as a domain administrator or senior executive. This process may involve the taking over of multiple accounts in the process.

This is why you should enable auditing that will target privilege escalation activities. One option is to enable “Audit Directory Service Changes” which will alert you when a change is made to an AD object. This could be adding a user account to a privilege group for instance or resetting a password. Any alert will provide information about the old and new properties of the changed objects.

To do so, create a GPO and navigate to Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration as shown below.

You can also enable auditing for “Privilege Use” which will alert you when a security principle is exercising a user right or privilege. You can do so by creating a GPO and going to Computer Configuration > Windows Settings > Local Policies > Audit Policy as shown in the screenshot below.

Microsoft made an announcement back in 2021 that Microsoft Store for Business and Microsoft Store for Education will be retired in the first quarter of 2023. Microsoft wants organizations to transition to Windows Package Manager (WPM) instead. WPM is a command-line tool that utilizes either PowerShell or the Widows Package Manager Client terminal, also referred to as Winget-cli. If you are running Windows 10 version 1809 or greater, it should be installed on your computer through a prior update. You can also install it with the App Installer from the Microsoft Store.

There are two primary components when it comes to WPM. The first is the package, which represents an ap, application or program. The other is the manifest file, which contains metadata used by the Windows Package Manager to install and upgrade software on the Windows operating system. WPM functions similarly to Linux package manager as it doesn’t actually host the packages. What is does is let you create manifests that form a script to download your desired apps from central repositories such as GitHub or the Microsoft Store.

The point of this brief article isn’t to get into the details of WPM but to show how you can manage it with Group Policy. To do this, you will first need the Desktop App Installer Policies” Group Policy Administrative Template files, which you can download from the Microsoft Download Center. You will need to copy these files over to your central store. The create a GPO and go to Computer Configuration > Administrative Templates > Windows Components > Desktop App Installer. You will then see a variety of available settings as shown in the screenshot below.

Let’s look at some of the most important settings here.

1. Enable App Installer: Enable this policy so that users can use WPM. This and many of the WPM policy settings only require you to enable or disable them as shown in the screenshot below.
   
   
    
2. Enable App Installer settings: Enabling this setting will allow users to change settings for WPM
3. Enable App Installer Default Source. Note that the default source for Windows Package Manager is an open-source repository of packages located at https://github.com/microsoft/winget-pkgs. Disabling the policy will make the default source unavailable.
4. Enable App Installer Microsoft Store Source: When enabled, the Microsoft Store becomes available as a source.
5. Enable App Installer Additional Sources: When enabled, additional sources will be available. Note that once additional sources are added here, they cannot be removed. You must specify the source location as shown in the screenshot below.
   
    
6. Enable Windows Package Manager Allowed Sources: This policy is somewhat like the previous one. When enabled, users will be able to choose a source from a list of approved user sources. Here, you must also specify the approved source locations
   
   You can refer to this site for the latest information regarding Windows Package Manager.

Those who have updated to Windows 10 Build 19042.964 via Windows 10 KB 10 KB5001391 have noticed the addition of the News and Interest Feed on the Windows taskbar.  The feed is announced on the taskbar by a weather icon by default that represents nearby current sky conditions.  With a click of the mouse you can gain access to nearby weather and traffic conditions, updates on your personal stocks as well as stories on professional or personal interests.   You can customize the stories and publisher sources by clicking on “Manage Interests” at the top as shown in the screenshot below.  A web browser will then open allowing you to tune your fee.  You can also select “More options” on headlines and article in order to share or save them.

Users can also customize how the newsfeed appears on the taskbar.  By default, the weather conditions icon and temperature are shown.  By right clicking on the icon, users can modify this in the context menu as shown below.

Windows admins will understandably want to manage the appearance of this new feature.  This can be done through either Windows Group Policy or Microsoft Endpoint Manager.  In order to access the associated Group Policy you need to obtain the Feeds.admx file.  You can access it by navigating to C:\Windows\PolicyDefinitions on a machine that has the update installed.  Copy the Feeds.admx file and paste it into your group policy central store.  You will also need the Feeds.adml file as well.  Those in the U.S. will find this file in the en-US directory.  The two locations are shown below.

You must then create a computer side policy by going to Computer Configuration > Administrative Templates > Windows Components > News and interests > Enable news and interests on the taskbar.  You can then choose to enable or disable the feature.  Enabling the policy will allow News and interests on the taskbar and give users access to the applicable context menu.  This will give users the ability to turn it off if they wish.  The policy is enabled in the screenshot below.

You can also manage News and interests in Microsoft Endpoint Manager as well by creating a Configuration profile.  Select Windows 10 and later as the platform and choose Settings catalog (preview) as the profile type.  After naming the policy, select “Add settings” to access the Settings Picker as shown below.

Then do a search for “news” and select “News and interest” and enable the setting as shown below.

You can also manage News and interests via the registry.  Go to:

HKEY_LOCAL_MACHINE\SOFTWARE\POLICIES\Policies\Microsoft\Windows\Windws Feeds. 

Then assign a value accordingly:

• 0 – show icon and text
• 1 – show only icon
• 2 – disabled

Of course these registry values can be deployed using Group Policy Preferences as well.  The screenshot below shows the designated registry key.

While the phrase, “between a rock and a hard place” stems from ancient Greek Mythology, it could easily apply to the task of applying Windows feature updates.  A new feature update can integrate new innovation and added value to your users.  On the other hand, that same update may also cause an rebellion amongst your helpdesk team as a ticket monsoon is created from that update going bad.  It’s a pendulum that can swing both ways.

What are Safeguard Holds?

That’s one reason why Microsoft developed Safeguard holds.  Safeguard holds prevent devices with a known compatibility issue from receiving a new feature update.  By doing so, it protects users from a potentially poor desktop experience should the updated feature not be a harmonious match for their particular device.  Microsoft uses quality and compatibility diagnostic data to identify issues of possible incompatibility.  When such a device is identified, it is placed on hold, which serves as a safeguard.  Devices that are placed on hold are prevented from installing the designated Windows 10 feature in order to preserve the user experience for the time being.  Microsoft then uses the captured diagnostic data to release a fix that addresses the compatibility issue and at some point, the hold will be released.  At that point, the update can then be delivered.  Microsoft also uses holds when a customer or partner reports a disruptive issue directly related to an update for which an immediate workaround is not available.  Those enterprises that utilize Microsoft Endpoint Manager can use Update Compliance reporting retrieve data related to current safeguard holds. 

Keep in mind that safeguard holds only apply to Windows devices that use Windows Update for Business.  Safeguard holds do not pertain to feature updates that are deployed through other channels such as Windows Server Update Services (WSUS) or installation media.  Most enterprises should be using Windows Update for Business as it offers administrators the ability to define Windows Update service rings in order to manage update delivery schedules for different user classifications. 

Opting out of Safeguard Holds

Safeguard holds are a good thing.  However, there are instances when you might not want them.  For instance, internal IT may want to validate the newest feature on a test device (for those who have it, it is best to validate feature updates using the Windows Insider Program for Business Release Preview Channel).  Allowing the update to go through will allow you to experience the compatibility issue firsthand as well as assess other implications concerning the update.  For those who want to bypass holds for special circumstances, Microsoft released a Disable safeguards for Feature Updates Group Policy late last year.  The policy is applicable to any Windows Update for Business device running Windows 10, version 1809 or later with the October 2020 security update installed.

Deploying the Policy

There are several ways to deliver the Disable Safeguards policy to your devices.  For domain-joined devices, Group Policy is easy.  Create a GPO and go to Computer Configuration > Administrative Templates >Windows Components > Windows Update > Windows Update for Business and enable “Disable safeguards for Feature Updates” as shown in the screenshot below.

Administrators can also use an MDM such as Microsoft Endpoint Manager to manage your devices, you can create a custom profile to deploy the policy.  While the involved settings do not appear in the management interface, you can create a custom device configuration profile using OMA-URI settings.  Using Microsoft Endpoint Manager go to Devices and create a custom profile for the Windows 10 platform.  Provide a name for the OMA-URI setting and optional description if desired.  Then add the following settings as shown in the screenshot below.

• OMA-URI: ./Vendor/MSFT/Policy/Config/Update/DisableWUfBSafeguards
• Data type: Select Integer
• Value: 1

Another way is to modify the registry.  You can do this manually or deploy the modification using Group Policy Preferences.  Start by going to the following key:

Go to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

Right click on WindowsUpdate and select New > Dword (32-bit) Value

Name it DisableWUfBSafeguards

Set its value to “1” and reboot.

The finished result is shown below.

For those enterprises that utilize both domain-joined and non-domain joined machines, there are third party solutions such as PolicyPak that you can use to deploy the Disable Safeguards policy to any internet connected Windows 10 device.  In this case, the PolicyPak editors are built inside the Group Policy Management Editor so creating the policy is simple and straightforward.  Once created, you can deploy it using standard Group Policy, your chosen MDM solution or PolicyPak Cloud.  The screenshot below shows the creation process that utilizes the ADMX templates. 

To be clear, you shouldn’t disable Safeguard Holds to rush out feature updates to standard users, but this policy does provide administrators with greater the flexibility they need at times. 

Few things in this world are black and white and that includes software you download. 

There is a lot of "gray-ish" stuff residing on computers today.  A good example is software that comes bundled with the computer or was installed by another software application of a different vendor. 

Most of the time these applications aren’t something you want in the first place.  Other examples include advertising software or evasion software that actively tries to dodge the detection of your cybersecurity tools.   While these software files may not pose a direct threat to your computer in the same way that malware, Trojans and other types of malicious software do, these unwanted applications can impede the performance of your endpoints.  These unwanted software servings are referred to as Potentially Unwanted Applications (PUA).  A PUA is an application that has a poor reputation.  These applications can serve as a time consuming distraction of cleaning up these files.  Over time, these applications can increase the risk to your network. 

Windows 10 Defends Against PUAs

Windows 10 (Professional and Enterprise editions) can detect and block possibly harmful third party and unwanted applications using Windows Defender and does so without requiring Defender ATP or Enterprise licenses.  When activated, the PUA security feature looks for certain file structures and conditions that include the following:

• The file is being scanned from the browser
• The file is in a folder with "downloads" in the path
• The file is in a folder with "temp" in the path
• The file is on the user's desktop
• The file does not meet one of these conditions and is not under %programfiles%, %appdata% or %windows%

Should these conditions be met, the file in question is then quarantined and not allowed to be installed until approved. 

Using PowerShell to Enable PUA

You can use PowerShell to enable PUA within Windows Defender. 

The command options are as follows:

Set-MpPreference -PUAProtection Enabled

Set-MpPreference -PUAProtection AudiMode

The PS command will add and modify the DWORD value in the protected registry key as is shown below.

HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Windows Defender\MpEngine\MpEnablePus.

And assigns one of the following values.

• Disabled: 0 (Does not block PUAs)
• Enabled: 1 (Blocks PUAs)
• Audit Mode: 2 (PUA events are reported in Windows Event Viewer.  PUAs will not be blocked however)

Of course, you can make the changes directly in the registry itself.

The end result is as follows:

Enabling PUA with Group Policy

For domain-joined machines, you can enable PUA protection through Group Policy.  Simply create a GPO and go to Computer Configuration > Administrative Templates > Windows Defender Antivirus and enable “Configure protection for potentially unwanted applications.”

Then choose which your desired option:

You can also use Configuration Manager to deploy the setting as well.

05:07

Enabling PUA with Microsoft Endpoint Manager (Intune)

You can configure the Defender/PUA Protection CSP for your Intune enrolled devices.  You can either create a configuration profile or use the preferred method of enabling and configuring a security baseline.  To create a configuration profile choose Windows 10 as the platform and Device restrictions as the profile type. 

To deploy PUA using a security baseline, go to Endpoint Security > Security Baselines > Microsoft Defender ATP baseline > Profile configure the “Defender potentially unwanted app action” setting as is shown below.

Enable PUA in Chromium-based Microsoft Edge

The new Edge browser (version 80 and greater) contains its own PUA protection ability.  Go to your browser settings and select Privacy and services.  Then enable the “Block potentially unwarned apps” as is shown in the screenshot below.

You can also deploy this Edge setting using Group Policy as well.  Simply create a GPO and go to Computer Configuration > Administrative Templates > Microsoft Edge > SmartScreen settings and enable “Configure Microsoft Defender SmartScreen to block potentially unwanted apps.”

To enable the same setting using Microsoft Endpoint Manager, create a configuration profile and choose Windows 10 as the platform and Administrative Templates as the profile type.  Then go to Microsoft Edge > SmartScreen Settings and enable “Configure Microsoft Defender SmartScreen to block potentially unwanted apps."

You should enable these PUA tools as a part of your multilayer security strategy.  Hardening your desktop devices and reducing their attack surface exposure is critically important.  Another way to stop PUA (or, really any unwanted file download) is application control via PolicyPak Least Privilege Manager.  You can check it out here.

I've never met this author, but I like the author's breakdown of the problem.

In summary... I get this question all the time.. "Jeremy... If I disable the UN-used half of the GPO, will it speed up GP processing?"

For 800 years, I've said "Don't bother." You only GAIN headaches because now the other half of the GPO might not process if you end up using it.

Now, a great article with excellent workmanship to prove the point: Don't bother.

https://blogs.technet.microsoft.com/askpfeplat/2018/10/22/does-disabling-user-computer-gpo-settings-make-processing-quicker/

Enjoy the read.

This isn’t my story: This is me sharing THEIR story. In this story, I (Jeremy) am only the narrator. ?

While at a conference, I met two new friends (who already knew one of my friends). A bunch of awesome Danish gents who said to me.. “Hey Mr. Group Policy Guru.. maybe you know… we have a problem when Group Policy updates, some of our applications flicker! And our users are going crazy !”

The guys were: Roland Jørgensen (twitter: @mindlessdk) and Jonas Weinreich (twitter: @weinedk) (both at the conference), and Claus Wordenskjold (twitter: @CWordenskjold) (my original friend, who was NOT at the conference.)

Now I had heard of this issue from time to time. But to set the stage, in fact, a little flicker during foreground and GPudpate is perfectly normal.

In fact, there’s an older web article: https://msdn.microsoft.com/en-us/library/ms812018.aspx which tells the tale..

Consider notifying users that their policy is updated periodically so that they recognize the signs of a policy update. When Group Policy is updated, the Windows desktop is refreshed; it flickers briefly and closes open menus. Also, restrictions imposed by Group Policies, such as those that limit the programs a user can run, might interfere with tasks in progress.

So, if this is expected behavior, why are my Danish pals seeing a more “profound” flicker.. enough to make users call the help desk and start to get pretty annoyed?

You can find others’ with flicker issues if you Goog, I mean.. Bing for it.

1. For instance, here’s a resolution with GPupdate flicker + Cortana: https://answers.microsoft.com/en-us/msoffice/forum/msoffice_outlook-mso_win10/the-calendar-in-outlook-2016-is-blinkingflickering/07c3ca0f-4b38-4ad9-857e-f7d486d6e9b1
2. Here’s a chat about Group Policy updates making Dynamics flicker: https://community.spiceworks.com/topic/1539867-group-policy-refresh-causing-dynamics-gp-forms-to-flicker-on-windows-10
3. Here’s a patch which fixed Outlook To-Do bar flashing with GPupdate: https://www.policypak.com/knowledge-base/general-on-prem-troubleshooting/how-can-i-fix-outlook-to-do-bar-flashing-when-gp-or-policypak-does-a-background-refresh.html

So, yes, I (Jeremy) had heard of it.

I told them I would poke around, and they would too, and we’d meet up. But they found an answer.. and that’s this story.

Problem Statement

So after a little investigation, the team made a problem statement:

1. When the computer ran a gpupdate, some applications would flicker.
   •  Outlook 2016 started flickering, and switching back and forth, going to not responding and blank pages and return to normal.
   • Navision 2009 R2 client flickered and the formular which the user was working in would be reset.
2. We experienced the issue on both virtual and physical computers, and in a variety of different OS from Windows 8.1 to Windows 10 1607, 1703 and 1709.
3. The issue occurs every time a new setting is set a GPO. Thereby it happened every time a policy with a Group Policy Preferences item was run. All of our drive and printer mapping is set in GPO.

To get started to pare it down, they did what I always recommend…

GO NAKED.

By which I mean.. have a computer that is “born fresh”, has all the latest patches, and few applications as possible… JUST FOR TESTING.

This aspect is critical, because you can eliminate SO MUCH from your testing by paring it down and stripping the computer / OS to as basic as you can get.

Then.. BUILD UP you machine.. and find WHEN the problem STARTS.

And.. with this technique, they were able to start with a “pretty naked” machine, as soon as Group Policy applied, and Group Policy Preferences were re-applying, the “mega flicker” issue occurred.

Next step: Event Logs

My Danish friends got different reports and different applications flickering. But for them, it was Outlook that was driving them crazy, and flickering all the time.

So… with Group Policy, the best place to START troubleshooting would be.. the event log ! On the first computer they checked, they saw GPOs being refreshed every minute.

Then, some time later, it started to refresh every 5 seconds!

Crazy!

Log Name:       System

Source:         Microsoft-Windows-GroupPolicy

Date:          16-05-2018 16:25:39

Event ID:      1502

Task Category: None

Level:         Information

Keywords:     

User:          SYSTEM

Computer:      L-TEST-T480S.internal.org

Description:

The Group Policy settings for the computer were processed successfully. New settings from 8 Group Policy objects were detected and applied.

Event Xml:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">

  <System>

    <Provider Name="Microsoft-Windows-GroupPolicy" Guid="{AEA1B4FA-97D1-45F2-A64C-4D69FFFD92C9}" />

    <EventID>1502</EventID>

    <Version>0</Version>

    <Level>4</Level>

    <Task>0</Task>

    <Opcode>1</Opcode>

    <Keywords>0x8000000000000000</Keywords>

    <TimeCreated SystemTime="2018-05-21T01:17:12.416286700Z" />

    <EventRecordID>14030</EventRecordID>

    <Correlation ActivityID="{14E5F0E1-F113-47CD-B4F2-D7A2A362F1F4}" />

    <Execution ProcessID="6120" ThreadID="12080" />

    <Channel>System</Channel>

    <Computer>L-TEST-T480S.internal.org</Computer>

    <Security UserID="S-1-5-18" />

  </System>

  <EventData>

    <Data Name="SupportInfo1">1</Data>

    <Data Name="SupportInfo2">4201</Data>

    <Data Name="ProcessingMode">0</Data>

    <Data Name="ProcessingTimeInMilliseconds">9953</Data>

    <Data Name="DCName">\\ADSERVER.internal.org</Data>

    <Data Name="NumberOfGroupPolicyObjects">15</Data>

  </EventData>

</Event>

The Discovery… It wasn’t Group Policy at all.

So the team started to kill process after process looking for a solution.

And this is where Claus Wordenskjold found the process that made the problem stop.

When killing ccmexec (SCCM) process, the issue stopped.

The team proved that it was ccmexec causing the issue, which can be seen in the picture below. You should see four parts.. numbered 1 -4 with four little stories:

1. SCCM runs without GPO's applied
   • Gpupdate runs every 10th second
2. SCCM service is disabled and no GPO’s are applied
   • Gpupdate runs as per standard configuration
3. SCCM service is disabled and all GPO’s are applied
   • Gpupdate runs as per standard configuration
4. SCCM service is enabled and all GPO’s are applied
   • Gpupdate runs every 10th second

The key thing to look for in each of these stories is the number of 1502 events which expresses the attempt to perform computer-side Group Policy updates.  When SCCM was disabled, the 1502 events were normal and not “out of control.”

Event log KEY:

• Event 1500: The Group Policy settings for the computer were processed successfully. There were no changes detected since the last successful processing of Group Policy.
• Event 1501: The Group Policy settings for the user were processed successfully. There were no changes detected since the last successful processing of Group Policy.
• Event 1502: The Group Policy settings for the computer were processed successfully. New settings from X Group Policy objects were detected and applied.

So, in summary: the real issue was not gpupdate or the Group Policy engine. Gpupdate is working exactly as expected.

Solution

So, if killing SCCM processes made Group Policy “happier”, the Danish team needed to dig deeper.

Now, SCCM has a massive amount of logs, so this took a while.

After searching and searching, they discovered a lot of activity in wuahandler.log.

The errors discovered were identical as what is described here:

http://eskonr.com/2014/02/configmgr-onsearchcomplete-failed-to-end-search-job-error-0x80244022-wuahandler-log/ 

And….

As described in the article, the application pool "WsusPool" in the IIS server on our SCCM distribution point (DP) was stopped. Once it was started it, all of the computers did not refresh every 10th second anymore.

All refreshes returned to normal GPO update behavior.

Conclusion 

The programs are still flickering when GPO’s are refreshed, but this is expected and has has always happened.

The problem became obvious and noticeable to end users because GPO refresh happened every 10th second.

People started to notice.

It got weird.

So, why does the failure of an SCCM service make Group Policy “flip out?”

We’re not sure why.

The theory is that the when the SCCM agent cannot see its DP it will try to find a new one. For instance, if a computer moves from one branch office to another, then it might not be able to reach its former DP.

And, the information on where to find the DP is supplied in a GPO targeted the computer.

Thus we think the SCCM agent will trigger it’s own GPupdate, attempting to update only the computer policy. However, we do not have prove of that theory. But that’s what we think is going on.

If you have anything to share, on this interesting case, then just email me (Jeremy) and I’ll compile the best responses and tack them onto the end of the article.

Hope this helps you out.. and happy Group Policy + SCCM co-existence. ?

In the effort of “not repeating excellent work of others” … here are two articles to help you turn off SMB 1 via Group Policy:

• https://blogs.technet.microsoft.com/staysafe/2017/05/17/disable-smb-v1-in-managed-environments-with-ad-group-policy/ 
• http://www.grouppolicy.biz/2017/03/how-to-disable-smb-1-on-windows-7-via-group-policy/ 

It doesn’t take much, and you should do it.. yesterday.

You should also start thinking about how to block attacks that users themselves (or even slightly tired IT people) can click upon and wreck their networks.

I humbly suggest you check out PolicyPak Least Privilege Manager and our SecureRun feature. Here are two videos showing you you could have prevented the attack in the firstplace:

• https://www.policypak.com/video/stop-cryptolocker-and-other-unknown-zero-day-attacks-with-policypak-secureruntm.html 
• https://www.policypak.com/video/policypak-elevate-scripts-and-java-jar-files.html