Brought to you by PolicyPak Software
Jun 2018

The case of the insane flickering of GPupdate!


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: 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:
  2. Here’s a chat about Group Policy updates making Dynamics flicker:
  3. Here’s a patch which fixed Outlook To-Do bar flashing with GPupdate:


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…


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!


The case of the insane flickering of GPupdate 01


Log Name:       System

Source:         Microsoft-Windows-GroupPolicy

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

Event ID:      1502

Task Category: None

Level:         Information


User:          SYSTEM



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="">


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







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


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

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



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



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

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

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

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

    <Data Name="DCName">\\</Data>

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




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.”


The case of the insane flickering of GPupdate 02


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.



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: 


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.



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. 😊

May 2017

Prevent Wannacry using Group Policy

In the effort of “not repeating excellent work of others” … here are two articles to help you turn off SMB 1 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:

May 2016

How to Block Windows Store in Windows 10 Pro with Group Policy (even though the GP setting

You might have read the news that it’s no longer possible to use the built-in Group Policy SETTING to prevent access to the Windows Store starting in Windows 10 / 1511 with some updates. I don’t make the news, I just report it.

The official article at Microsoft is “Can’t disable Windows Store in Windows 10 Pro through Group Policy:“. Except, good news.. turns out there IS a way to prevent Windows Store from running with Windows 10 Pro Video.


For more killer tips, be sure to sign up at for the  newsletter list to stay informed.

For Group Policy training, (live and online) sign up at

And to extend Group Policy to manage applications and browsers, check out

UPDATE: Found another technique which works with “Software Restriction Policies”, which is a little less intense than using, say, AppLocker to do it. Personally, I prefer the method in MY video, but this alternate method using SRP should work a-ok for most people as well. Link to another blog / video.

Apr 2016

Fix GPPrefs Scheduled Tasks and also Updating AD

A student in a recent class showed me this article, which demonstrates how to make Scheduled Tasks (correctly) run as SYSTEM. I didn’t know this was a bug, but I’m glad I know there’s a fix !

The same guy also has a nifty script to perform a full replication of all DCs in the domain. Handy if you’re getting inconsistent results with GP. Here’s a pointer to that nice script:

Good job, MadDog 2050.. whomever you are !

Jun 2014

Preventing Windows Store Apps from popping up all across your network.

I was asked how to minimize the impact of users’ purchasing and downloading their own applications from the Windows 8 Store.

Turns out, it’s one easy policy setting.

This setting is “weird” inasmuch as it appears on both user AND computer side, making it quite flexible. You’ll find this setting at…

User Configuration | Administrative Templates | Windows Components | Store


Computer Configuration | Administrative Templates | Windows Components | Store

Here’s the picture.

Hope this helps you out, and see in Atlanta Aug 18-21 !

Nov 2013

How I worked with Bob to improve Group Policy logon times by 15-30 seconds.

Let me jump to the end of the story: I didn’t really do anything here.

Bob did all the hard work.  I did POINT Bob in the right direction though and get him thinking about the problem.

Bob came to me with the following query: “We played with deploying printers via GP and ultimately decided not to.  However, despite removing the deployed printers from GP, every machine still goes through the “Applying Group Policy Printers policy” step even though there are no printers deployed that way and I can’t figure out how to get rid of it…  On some machines, it’s just a few seconds delay, but on others, it’s upwards of 30 seconds and I’d really like to get rid of it.  Any ideas?”

I THOUGHT Bob was talking about Group Policy Preferences Printers. But he wasn’t. He was talking about “Deployed Printers.”

This is totally different, and honestly, one of the parts of GP which isn’t my favorite.

Bob found the golden ticket all on his own. Here’s what Bob replied:

“I figured it out from this article:

The relevant info was:

While you ‘re in adsiedit, highlight the GPO node itself, “properties”, look for the attribute “gPCUserExtensionNames”. This is an array of an array of GUIDs.

Copy the entry to notepad, identify a block in square brackets (“[]”) that starts with the GUID {8A28E2C5-8D06-49A4-A08C-632DAA493E17} and remove the whole square brackets block. Then, look simply for the GUID {180F39F3-CF17-4C68-8410-94B71452A22D} (shouldn’be present, but better be careful) and remove just the GUID.

This cleans up the AD part of your GPO and afterwards, deployed printers will not be processed anymore during user gpo refresh.”

Logins are now 15-30 seconds faster.

Thanx for the help! 😀

So the moral of the story is.. if you’ve ever tried “Deployed Printers” and then.. well, stopped… then this could be something that helps you out if logon times have increased.

Oct 2013

How to make the Ultimate ADMX Central Store

Guest post from Chris Jaramillo (a regular friend!) with a little help from Jeremy Moskowitz, Group Policy MVP.

Well, another OS release from Microsoft, and you “workin’ it” Group Policy Admins know what that means: Time to update the central store with the latest definitions.

GPO Definitions: Latest and Greatest

GPO’s definitions start out life on each operating system type. The newest (as of this writing is 2012 R2 and Windows 8.1.)

You would EXPECT them to ship with the same Group Policy definitions, right?

Think again.

Well, I (Chris) did a quick WinDiff of the PolicyDefinitions folders on fresh 2012R2 and Win8.1 builds:

Default on clean install of both Windows 8.1 and 2012R2 systems

  • 167 common ADMX files (and their corresponding AMDL)

ADMX files which are only on a clean install of 8.1:

  • deviceredirection
  • enhancedstorage (Available on 2012R2 via a Feature)
  • sdiagschd
  • search (Available on 2012R2 via a Feature)
  • shapecollector (Available on 2012R2 via a Feature)
  • winstoreui (Available on 2012R2 via a Feature)

ADMX files which are only on a clean install of 2012 R2:

  • grouppolicy-server
  • grouppolicypreferences
  • mmcsnapins2
  • napxpqec
  • pswdsync
  • servermanager (Available on Win8.1 via RSAT)
  • snis
  • terminalserver-server
  • windowsserver

ADMX files which you can get only on 2012 R2 Only, when you install a Role:

  • fileservervssagent

ADMX files which you can get on either 2012 R2 and Win 8.1, when you install a Feature

  • searchocr

So in short, you get the issue as last time. That is, you have to grab some of them from the workstation OS and others from the Server OS. And/or you need to turn on specific features or Roles to get these ADMX files to actually appear at all !

If you had to manually do this, this would make Central Store management almost unbearable.

It would require installing all Roles/Features on each of a Vista, Windows 7, Windows 8, Windows 8.1, 2008R1, 2008R2, 2012R1, and 2012R2 nodes, each with the latest Service Pack.

Then starting with Vista, copy the PolicyDefinitions folder, overwriting with 20018R1, then Windows 7, 2008R2, Windows 8, 2012R1, Windows 8.1, and finally 2012R2. Even then, I have seen instances where MS has removed certain older policy settings from certain newer versions of the same ADMX !

Jeremy’s 2¢

So, here’s my (Jeremy’s) 2¢: Chris is right, but there’s some good news. You DON’T have to go through ALL those gyrations to get the “latest pack” of ADMX files.

Traditionally, Microsoft makes available a download of all the latest ADMX files all in one shot.

The basic rule of thumb would be to simply always just overwrite what’s already in the Central Store *WITH* what Microsoft provides.

So if you had any “extras”.. that’s cool, they just stay there and you can use them. But you’re always overwriting the old ADMX files with the LATEST ADMX files.

As of this MOMENT, Microsoft doesn’t yet have the “latest” ADMX files from Win 8.1 and 2012R2 yet available. I’m pretty sure they’re coming soon. When they do, I’ll post about it.

If it were me, I’d just limp along a little while longer until MS produces them as a full download.

So, that’s the story: Standby for when it drops from MS.

Chris Final 2¢

Special notes: In the 2008R2 version of AppCompat.ADMX, “Prevent access to 16-bit applications” was a user AND computer option. In the 2012R2 version of the same ADMX, the user option is gone. I’m pretty sure I’ve seen IE settings disappear in a newer ADMX as well.) Add on the fact that certain applications (such as IE) have their ADMX/adml files updated when the application is released (sometimes out of band from the OS release), or that certain hotfixes (such as the 2012R1 WSUS patch that I forwarded you a week or two ago) will update ADMX/adml files, and it’s enough to make your head spin.

So, even with populating the latest versions of all of the possible ADMX files, that may not populate the admin templates with all available settings for all client/server/apps (which was kind of the point of a Central Store). However, doing so probably the closest thing to an all-encompassing Central Store that is possible.

Chris extra notes: My recommendation is to keep a copy of the PolicyDefinitions folder from each OS version (including Service Packs) handy, just in case you temporarily need a previous version of the ADMX.

Oct 2013

Can you speed up login times when using GPPrefs Printers deployment? (And does it matter?)

The Question: To pre-install or NOT to Pre-Install

On linked in, someone asked the following question: If you pre-install “big / universal drivers” on your target machine, will you will save login time when GPPreferences is used to deploy shared printers?

The idea is that the driver is “already there” and GPPrefs would just “do nothing.”

So.. SOMEONE had to figure it out. It might as well be me. 🙂

Tests and Methodology

Results: Here’s the result of my testing using the HP PCL 6 64-bit universal  printer driver. It’s a 17MB download. Then installing it on the server and doing a roundup of HP*.* I find 48MB of HP files within c:\windows\system32\spool\drivers\x64\3 after sharing a universal printer.

(Note: It doesn’t actually matter if the raw byte count is TRUE count or not, as the times I get on MY machine are RELATIVE to what you’ll see.)

I turned on the setting which enables me to SEE *WHEN* and *HOW LONG* each GP CSE takes to process. I also put a stopwatch next to it, then COUNTED HOW LONG these words appeared (

Here are the test cases / results.

Again, WARNING: I am on a ludicrously fast testlab / laptop. The point is NOT for me to report exact seconds or even total time to log on.  The point is the FINAL RATIO of how long each test case takes VERSUS another test case.

The FINAL RATIO should be the same for just about anyone based upon these numbers.

Scenario 1: No GPPrefs Printers linked anywhere.

Result: ZERO seconds / “Applying Group Policy Printers policy” never appear.

Scenario 2: Universal Printer Driver shared on server in \\DC\HPPRINT1. GPPreferences item is linked to West Sales Users OU. Mr. WestSalesUser 1 logs on.

Result: 29 seconds for the CLIENT to show “Applying Group Policy Printers policy”… then MOVE ON.

Scenario 3: Same as scenario 2. BUT.. Mr. WestSalesUser1 has already logged on and downloaded the driver. NOW Mr. WestSalesUser2 logs on.

Result: 3 seconds for the CLIENT to show “Applying Group Policy Printers policy”… then MOVE ON.

*INTERESTING RIGHT?!* – More insights and thoughts below. Let’s continue onward.

Scenario 4: Universal Print Driver is pre-installed on target machine. GPPreferences item is linked to West Sales Users OU. Mr. WestSalesUser 1 logs on.

Result: 6 seconds for the client to show “Applying Group Policy Printers policy”… then MOVE ON.

Scenario 5: Same as 4. Mr. WestSalesUser1 has already logged on and used the driver. NOW Mr. WestSalesUser2 logs on.

Result: 3 seconds for the client to show “Applying Group Policy Printers policy”… then MOVE ON.

So.. how do we interpret these results?

Answer: Pre-installing the “big / universal” printer driver BEFORE using GPPreferences yields an 80% time improvement for the first user and a 90% time improvement for user #2.

However, if the FIRST user “suffers” and downloads the print driver via GPPreferences / the network, the improvement for user #2 is the same for over the network AND local installs of the driver.

Counter-intuitive thinking (so stick with me)

You might think my final advice would be “Yes, of course pre-stage universal drivers.. you get an 80%- 90% improvement in first-user login time!”

But that is NOT what I would suggest.

My belief is and has always been “The First Login Time For Any User Doesn’t Matter.”

Even if it takes, say, 3 times longer than the NEXT login (for the same user, or for the second user on the same machine)… my feeling has always been… “SO WHAT?”

Before you throw things at me, think about it: The first login time is “forgettable”. Its not an every day occurrence.

Sure.. If there’s some delay that can be eliminated at EVERY login (from login 2 onward) you should do it. (Crappy login scripts which copy big files EVERY time, or things that CRAWL the file system, etc etc.) OF COURSE — dump that crap — and make EVERY login time faster.

But that’s not what we’re talking about HERE.

HERE, in the case of “Do we” or “Don’t we” pre-install big universal print drivers, we DONT gain speed at EVERY login.

So, my final thought is: Generally *DONT* pre-install big univeral print drivers. You don’t get benefit at EVERY login.

Is there an exception?

Sure. Here goes: If you use non-persistent VDI where EVERY login feels like the FIRST login, then I could likely get behind pre-baking in items like this which make EVEN THE FIRST LOGIN go faster.

Again: That’s only because every login ACTS like its the FIRST login.

There are possibly other time-critical logins (Nurse’s stations, Stock Floor Trader) where maybe, again, would I agree that baking them in feels like the right thing to do to save X number of seconds (because you don’t know who has NEVER logged into that machine before.)

There’s my wrapup on this topic. I hope it helps you out. Please make your insightful (but kind) comments below. Thanks !