MDM & GP Tips Blog

Nov 2018
12

(Jeremy's been right for years)... Don't bother disabling unused GP "half".

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.

Oct 2018
09

Windows 1809 Group Policy Blue Screen After Upgrading (that you don't have to panic about)

Hi Team..!

As some of you know, Windows 1809 rollout was paused for upgrade problem (https://support.microsoft.com/en-us/help/4464619/windows-10-update-history).

But I got a copy before it got yanked. When I did some tests.. in upgrading from Windows 1803 to 1809 on  some machines ,

I found this interesting "Blue Screen" which.. you should NOT FREAK OUT ABOUT.

GPSVC service failed UUID Blue Screen

The good news is that this only occurs ONE time per machine, on the first attempted login. Then.. never again.

Maybe again the next time Windows is upgraded... maybe maybe you'll see it again.. but ... maybe not.

 Anyway: If you get people reporting this.. you can cheerfully just say "Got it" and then.. don't worry about it.

It's the one blue screen.. NOT to freak out about.

My friend Thorbjorn Sjovold from SpecopSoftware explains also how this can occur:

https://specopssoft.com/blog/things-work-group-policy-processing/ 

Another great read !

 

Also, and totally unrelated.. I'm doing a live webinar with my friends at NetWrix.. 

What: Group Policy Changes - What You Don’t Know Can Hurt You"
When: October 25 at 1.00 PM EST.
Who: You. Me. Them.
Where: https://www.netwrix.com/webinars.html?webinar_id=516&utm_source=webinars&utm_medium=jeremy-moskowitz&utm_campaign=gpanswers-link-upcoming-group-policy-changes
Anything else? : Not that I can think of.

Great? So what are you waiting for? Sign up and see you there.

See ya soon.

-Jeremy Moskowitz
 

Jul 2018
19

Edge in Windows 17718 just got more policies and new ADMX templates just shipped.

Team:

Microsoft just pre-announced a bunch of interesting new policies for a future version of Windows. 

https://docs.microsoft.com/en-us/microsoft-edge/deploy/new-policies 

And, the latest ADMX items, which fix a small problem I mentioned several weeks back... is now available:

https://www.microsoft.com/en-us/download/details.aspx?id=56880

Go forth and go policy my friends !

 

Jun 2018
11

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: 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!

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

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

 

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.

 

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

Jun 2018
08

Two "Off the beaten path", but FREE utilities from Microsoft

In my GP training classes, I go into DEEP DIVE DETAILS on how to set up and manage LAPS.. which is a local admin password rotation system. If you've taken the class, here's a great ADD-ON to tell you about overall LAPS health. Nice !

https://blogs.technet.microsoft.com/askpfeplat/2018/06/04/how-healthy-is-your-laps-environment/ 

And, unrelated, I also found this little nugget.. a more bad-a$$ password filter for Active Directory

And now.. the plugs. :)
Come to my next GP & MDM training class

Seattle (Tacoma) .. Aug 7 ,8 and 9 (three days).. 
$2250.. includes Awesomesauce.
www.gpanswers.com/live-class 
See you there, mates.

May 2018
09

1803 ADMX files .. Errors that come with a Byte?

Some people, like my friend Brian I. (that’s “Brian I.”, not “Brian and I”)… discovered that upon UPDATING you existing Central Store with latest 1803 ADMX/ ADMLs.. You could get bitten.

The problem appears that the (current 1803) ADMX files are missing .. well.. and ADMX. That is, for every ADMX there should be a corresponding ADML file for each language.

And one ADMX file.. didn’t make it into the 1803 ADMX download: SearchOCR.admx.

So what’s happening is, that:

1. Some old (totally fine) ADMX version is there in your central store.
2. You leave that in place; and update/ overwrite the SearchOCR.ADML.
3. Now.. the OLD SearchOCR.ADML kind of “loses its mind” because he’s paired up with (essentially) the wrong SearchOCR.ADMX.

And.. Bingo. You’ve got an error message every time you open the GP editor.

Screenshot: https://i.imgur.com/EksFBMH.png

There are a few ways to solve this.. (now, note I could not reproduce the problem, but I think I’ve got a strong handle on what would solve it.)

1. JUST WAIT. I dont know DIRECTLY.. but I bet this gets fixed in some minor Admx update from Microsoft.

2. Delete the SearchOCR.ADMX and SearchOCR.ADML in the central store (for now.). This is a little tricky because you cannot know if you’re using these policies or not. But even if you *ARE*, the data in any GPOs which use(d) this ADMX are still valid. Just the definitions are now “gone” if you try this. Then when Microsoft repairs this problem, you can put these files (just these) back in.

3. Hand-edit the SearchOCR.ADMX file you *HAVE* to make SearchOCR.ADMX **NOT** lose its mind and properly marry up withthe SearchOCR.ADML.

Nice step by step details are found here… (so I dont need to go over it.)

https://social.technet.microsoft.com/Forums/windowsserver/en-US/cb97affb-9724-457b-a113-32cbd3d53331/searchocradmx-error-after-installing-win101803-admx-templates?forum=winserverGP

That’s it. Hope this gets you BACK on the road if you’re bitten by the 1803ADMX item.

Quick update, my friend Alan Burchill from GroupPolicy.Biz has this nice breakdown of the problem too. Click here for more.

(Another update): Official MS article about this published: https://support.microsoft.com/en-us/help/4292332/error-when-you-open-gpedit-msc-in-windows

Feb 2018
15

Three GP News items: hresult-0x80071128 fix, 2016 Baselines, and Windows 10 extends support

What is it: (Updated and Fixed: The Group Policy cannot be written bug.)
Time to re-read: 180 seconds.
www.gpanswers.com/blogs/view-blog/hresult-0x80071128-on-server-2012r2-dcs-when-editing-gpos/

 

What is it: Security Baseline for Office 2016 & Office 365 Proplus
Time to read: 200 seconds
https://blogs.technet.microsoft.com/secguide/2018/01/29/security-baseline-for-office-2016-and-office-365-proplus-apps-draft/

 

Windows as a Service Changes .. AGAIN.
Insanely fast summary: Got one of the four ORIGINAL Windows 10 editions? Windows 1511, 1607, 1703, and 1709), an extra six months of support is being added. Future builds.. will only get the 18 months as previously stated. From Microsoft:
https://blogs.technet.microsoft.com/windowsitpro/2018/02/01/changes-to-office-and-windows-servicing-and-support/

Jan 2018
26

HRESULT: 0x80071128 on Server 2012R2 and 2016 DCs when editing GPOs

Team:

Wanted to alert you to a known issue with the January patches.

This is MY INTERPRETATION of the problem and advice, and is coming from ME and NOT from Microsoft.
And, I have not PERSONALLY seen this problem, but wanted to get it to you quickly.

Please use your own brain when reading the rest of this email and don’t knee jerk and do anything that would get you in the doghouse.

When the JAN patch is on your Server 2012 R2 servers there are reports of editing some GPOs using GPMC or AGPM 4.0 may fail with error “The data present in the reparse point buffer is invalid. (Exception from HRESULT: 0x80071128)” after installing this update on a domain controller.

This is now a known issue at…
https://support.microsoft.com/en-us/help/4056898/windows-81-update-kb4056898

Update: Feb 14, 2018… And the current resolution is… The FEB 2018 patch !

https://support.microsoft.com/en-us/help/4074594  (2008R2)

https://support.microsoft.com/en-us/help/4074590  (2016)

 

-or.. OLD ADVICE… not needed now that there is the FEB patch…-
Remove the JAN patch from your Server 2012 R2 and Server 2016 DCs. The one that should be removed is

  • The problem has been identified. Should only affect Windows Server 2012 R2 and Windows Server 2016.
  • The KBs affected are:
    • WS2012R2: KB4056895 (1B – January 8th monthly rollup) and KB4056898  (1B – January 3rd security-only monthly rollup) and Server 2016 KB4057142.

I hope this helps you out.

UPDATE: Jan 29th.. I have a theorized and UNTESTED workaround for this problem I bet if you use the GPMC and point to a Server 2008 R2 DC, and make your changes THERE, then NATURALLY wait for replication to occur… I bet you’ll work around this problem. Just a hunch. 🙂

And… Since you likely got to the end of this.. Now’s a good time for you to PENCIL IN my next Group Policy TRAINING CLASS.

April 16, 17 and 18… in Northern VA / DC Area. You CANNOT sign up for this class yet.
I will announce OPEN dates on Monday I think.

Thanks team.. and .. Always use your brain !! 🙂

PS: Thanks to Susan Bradley MVP  and “PolicyPak Customer Ted A.” with the Assist on this one !

 

Jeremy Moskowitz
GPanswers.com (Group Policy Community)
PolicyPak.com (PolicyPak Software)

Dec 2017
13

It's NOT a Group Policy Bug... !! <Grumble>

<Rant mode on>

So I go a little BSC (That’s Bat-Spit Crazy) when I read
“Group Policy Bug takes over the earth”.

As you might expect, my hackles go up…
(And, if you’re not a dog, where, exactly **ARE** your hackles? Just sayin’)

Anyway.. This latest up-hackles occurred when I read
the beginning of, and now the end of items like this.

(These are all reporting the same thing, and basically the same way..)

winaero.com/blog/bug-group-policy-updates-windows-10/
windowsreport.com/group-policy-bug-windows-10-fix/
mspoweruser.com/group-policy-bug-blocks-windows-update-user-delays-installation-updates/

(Note: The HTTP and HTTPs are removed so there are no links.. on purpose.)

They’re all saying that this is a “Group Policy Bug.”
(which is now fixed by the way… see below)

Annnnd.. No it’s not a Group Policy bug. It just isn’t.

A Group Policy bug would be something like:

1. You run GPupdate and it explodes. (This doesn’t happen.).
2. You have conflicting values and the final value is not present (This doesn’t happen.).
3. You click in the GP / MMC editor and it explodes (This can happen due to some underlying MMC code, etc.)
4. Data saved in the MMC and written to SYSVOL doesn’t make it there in one piece. (This is super insanely rare, but can happen when YOUR GPMC/management machine is over a slow link to a DC.)
5. You get data to the endpoint, but the CSE (internal to Microsoft or 3rd part CSE) does the “wrong thing” (this can happen from time to time.)

But NONE of that type of thing happened here.

So.. What occurred in this latest “Not really a Group Policy” bug ?

Nothing. Nothing at all that has to do with Group Policy anyway.

What DID happen is that:

1. Admins used the GP MMC editor to make a value change. The MMC worked as expected.
2. Data was saved in SYSVOL perfectly.
3. The Admin Templates CSE / REG.POL CSE performed perflecty and delivered the value as expected.
***THE END** … in terms of Group Policy doing its job.

What happened next?

The Windows Update engine on Windows 10 had a bug in it which read the value.. (anything except zero).. as “Never update ever again, like ever, please.”

Then Microsoft made a patch to fix the Windows Update engine to honor the zero and make it work as expected which is “Update when I tell you, as per the setting in policy.”

So *WHY* is this maligned and deemed as a Group Policy bug?

It’s not. It simply isn’t a GP bug.

Here’s what this would look like if this wasn’t Group Policy:

You: I’m going to use FedEx to deliver a nice sweater to my friend Steve directly from Amazon.
Steve: I got the sweater from FedEx. And I took it out of the box, but it doesn’t fit *AND* is in shreds, actually.
You: That’s crazy.. I’m really sorry to hear it.
Steve: DAMN YOU, FEDEX for delivering the sweater!! And screw you Amazon for putting it in a box!
You: Wait.. isn’t it the maker of the sweater you should be mad at?
Steve: That makes no sense ! I want to be mad at FedEx and Amazon !!!

This kind of maligning to GP is is what gives Group Policy a BAD NAME, and something I’m (clearly) passionate about eradicating.

So, go ahead.. find these bloggers and people in the press and tell them straight.

GP worked perfectly… The “Package” from Amazon was put in the box correctly. FedEx delivered the box. But when it got there, the sweater was in tatters.

NOT GROUP POLICY’S FAULT.

The bug was in the Windows update engine. And (if I have my story right,
fixed with KB4051963 and should be in the December 2017 Windows 10 update.)

Sooooo… to recap:

– This wasn’t a Group Policy bug.
– It was a Windows Update engine bug. And that’s what was fixed.

The end.

</Rant mode off>

And, back to friendly happy Jeremy land.

If you made it this far… BIG announcement coming on Friday.

See you then !

-JM