MDM & GP Tips Blog

If you haven’t yet utilized the updated GPMC’s new "Comments" feature, it’s pretty neat. The idea is that you can specify a comment over a GPO about, say, who created it,  who supports it, and what it’s supposed to be doing.

But something came up in my last class that I was teaching and I thought was neat and I wanted to share with you.

Someone wanted to know how they could create a comment ONE TIME, then "recycle" that comment to other GPOs.

So, imagine I had a comment in a GPO which says: "Mean Man Moskowitz made me make this GPO." An then imagine that comment could be applicable to multiple GPOs.

But, how do you repro the comment over and over again?

Turns out: it’s short and sweet. And no scripting or programming required.

The comment is inside the GPT (SYSVOL) portion of the GPO in a file called "GPO.CMT."

Just copy that file to the ANOTHER GPO’s GPT (that’s the portion that lives in SYSVOL) and.. whamo !

You’ve copied the comment.

I don’t know if this is "officially sanctioned" or not, but it seemed to work pretty well when I tested it out! So, use at your own risk, I guess.

I know lots of people who used them, then decided to dump ’em.. only to begin recently using them again.

What gives?

Let’s go back.. way back.. to a time you may not remember. That’s right: a time when your organization DIDN’T have AD. That’s right.

Before Caring about AD.

Or, BC AD.

So, when your world was BC AD, you couldn’t use AD-based GPOs to do all the dirty work for you. That’s because you didn’t have AD. (I do realize that many people grew up only starting with Windows 2000 and newer. And for that, be happy my friends.)

Anyhoo.. that’s when LGPOs were handy. LGPOs, or Local Group Policy Objects were great, because you got the power of Group Policy, but kind of in 1 on 1 sort of way. LGPOs mean that you walk up to a machine and type "gpedit.msc" and edit the Local Group Policy.

When you do — EVERYONE on that machine is affected. Sounds great! Let’s "Prevent access to the Control Panel" for everyone and give everyone the same "Active Desktop Wallpaper." Whee.
Great. Until you realize that when YOU want to log on, you’re stuck without Control Panel and can’t change the desktop background to that Porsche 911 Carerra you always wanted.

So, Vista and Windows 7 have a new trick up its sleeve called MLGPOs, or Multiple Local GPOs. I cover MLGPOs in huge detail in the updated Green book . But, here’s the summary. There are now THREE levels of Local GPOs for that matter.

Level 1: Affects everyone
Level 2A: Affects the person if they’re a Joe User
Level 2B: Affects the person if they’re a local Admin
Level 3: Affects a specific person based on username

So, you see there are three levels. But, there are four lines listed above, because a person can only be a USER *OR* an Admin. Not both.

Therefore, MLGPOs affect "Everyone First" then get more specific as they apply DOWN toward the most specific — the specific person based on username.

Now, if people stopped using LGPOs, do MLGPOs matter? Yep.

Here’s a scenario: imagine you wanted to implement a baseline of setting on your machine. Then, once you make contact and join a domain, you want the AD-based GPOs to override the local settings.

Neat! So now if you machine gets "lost in transit" between your "build shop in the basement" and it’s final destination in Kenya, you’ve at least got some baseline setting built-in. And, provided you set up the AD-based GPOs perfectly, you’ll be able to "revert" the LGPO settings on the machine.

But wait. I have an even better idea. There’s a new policy setting — just for Vista and later. And it’s called "Turn Off Local Group Policy Objects Processing." My suggestion would be to take a GPO and link it to a place in AD where you computers join after the machine makes it to Kenya.

So, the machine makes it to Kenya, safe and sound, but full of Local GPO settings that would usually affect everyone on the machine.

But, now that you’ve set up that special policy setting in the domain, you get a little magic.

The machine joins the domain, and LGPOs are immediately neutralized the moment the machine is joined.

Neat, right ?

Last week, I finished giving a Group Policy Master class. In the middle of the class one of the guys asked me "Jeremy, now that we’ve been using GP a little while, and are really embracing GPOs, things are a little bit slower sometimes when new users log on."

And my response might shock you.

I said "Awesome !"

He was a little taken back. And I know why. He thought he had a problem. But he doesn’t. He just missed a key point about how GP works.

Let’s imagine that you wanted to do something a little crazy. And, I know you wouldn’t really want to do what I’m about to describe; it’s just something for us to hang our hats on, okay? So, imagine you wanted to (yikes) re-ACL your entire hard drive. Yep. That’s the directive. Ouch. Again, it’s just theoretical, so go with me here.

So, in simple terms you have a handful of options:

• Use a startup-script which manually does the deed
• Manually run a script which does the deed on each machine
  or
• Use GP to deliver the same set of instructions via the NTFS security node

They all do the same thing, right? Right. And the action they’re taking (the actual
"thing" they’re doing) is kind of slow and painful ,right?

So is the GP engine the cause of this "slowdown?" No. It’s the "action" you’re doing. The theoretical re-ACL’ing of the hard drive.

So I was kind of excited when he said that sometimes things are slower because that means he’s actually DOING something with GP. So, I like to say that GP is a "Blame the message, not the messenger" technology.

A little later in the GP 2.0 Catch-up class I showed him how to bust apart Windows 7’s new logging mechanism and see — precisely — how long a "GP Cycle" takes. That way he can be really really sure how long GP was taking to process each step if he wanted to. Heck, it might not even be that anything he’s DOING with GP is even causing the slowdown!

In other words — Group Policy might not be likely to blame AT ALL for any slowdown. By showing him how to "bust apart" the logs, he could see that GP wasn’t taking long at all ! The culprit was, well, something else.

But in any case, the next time you think "Hey, the computer is running a little slowly" take a step back. It means it’s working. (But also consider getting smarter in GP troubleshooting it too, to be 100% sure GP isn’t the culprit !)

This tip is a "blast from the past"… I talked about this some time ago, and bringing it back, as it appears to be a hot topic right now.

Let’s start with Replication Problems.

Remember that a GPO is make up of two halves: the GPC and GPT.

And they get replicated to all DCs. What if one of your DCs isn’t getting the message about the updated GPO? And then, some of your client machines are trying to ask that DC for the latest GPO information.

Right, they get either no information or the wrong information.

So what can you do?

First, try GPOtool. It’s a download from the Microsoft 2003 Resource Kit. It can help you troubleshoot to see if the GPC and GPT are on all of your DCs.

But, here’s another tip: try creating a new user and then using Active Directory Users and Computers to "Change Domain Controllers" and verify that new account "makes it" to all your DCs. That will verify the path of the GPC.

Similarly, try creating a new text file (like a readme file or something) and dropping it into SYSVOL. Then, check out the SYSVOL on all DCs and make sure that readme file "makes it." This will verify the path of the GPT.

If the GPC and GPT are successfully replicating to all DCs (and you’ve verified that replication itself is working A-OK) there are lots of other things to check, which we’ll examine in other tips !

My pal and fellow MVP Jeff Hicks noticed something. He noticed that the Group Policy Powershell cmdlets had a Backup-GPO and Restore-GPO (seen here…)

But there was no way to really get into the "Manage Backups" stuff that you can only get to within the GUI.

So he created it. You can see Jeff’s interesting blog post about using PowerShell to get to this part of the world here: http://jdhitsolutions.com/blog/2011/05/get-gpo-backup/

Also, I wanted to say THANKS to the folks who showed up for my "Secret Group Policy Meetup" at TechEd.

We got to the bottom of some sticky issues for those who attended and had a really fun overall "rap" session.

We even had several guest stars: Aaron Margosis, Microsoft Technical Services and fellow TechEd speaker, Thorbjorn Svolvold, Group Policy big-brain from Specops software and Zach Alexander from the Group Policy team at Microsoft. Thanks everyone for attending !

Photo Credit: Takayuki Shodai also in attendance, but not shown, since he’s taking the picture. Thanks Takayuki !

I ran GPupdate today on one of my Windows 7 machines and got this. . .

It's kind of a mouthful, but here's the short, sweet story here.

Group Policy relies on the Kerberos protocol. Kerberos relies on the clock. If the clock between your client and your server is skewed by more than the allowable value (normally 5 minutes) then you won't process GPOs correctly !

So, this warning, is saying: My clock is weird versus the domain controllers.

No problem. Usually, a reboot fixes this kind of thing. Or it gets fixed on it's own when the time sync service does its thing.

But, one of the key troubleshooting steps for GPOs is to VERIFY that your clients time is within 5 minutes of your DCs times.

Do this, and you’re off and running (sometimes.) ?

PS: Quick update from Jeff L. who suggested I also turn you on to this Microsoft KB article: http://support.microsoft.com/kb/816042

I'm not going to beat up Charlie Sheen in this blog post.  You'll see where the Charlie Sheen stuff comes into play. Lets get right down to GP bizness.

Lets pretend you had this setup. I have two GPOs linked to the East Sales Users OU: GPO 111 and GPO 222.

And, lets also pretend that they affect the same policy setting: Remove Games Link from Start Menu.

If we run a Group Policy Results report we can quickly see that BOTH GPOs (GPO 111 and GPO 222)

were correctly applied to the client machine (Win7Computer-32). As seen here.

Now, remember, I've said that GPO 111 and GPO 222 conflict on how they apply the Remove Games Link from Start Menu setting.

So, which one is going to win ?

Well, the quickest way to see the Winning GPO is to run the Group Policy Results report as seen here. In my not too complex (on purpose) example here we can see that GPO 111 is Winning over GPO

But what if we add something at another level, say the Domain level and Enforce those settings down?

If the GPO is Enforced, then that GPO should be the Winning GPO, and in my re-run GP Results report example here, that’s precisely what has occurred.

So, in short, the Winning GPO is the one which ultimately gets to express the setting upon the client computer.

If you can't figure out WHY a particular value is appearing on the client, look no further than looking for the one that's Winning !!

A fellow reader like you, named Dave King emailed me this screenshot.

Dave asked me a short, sweet question and included a killer screenshot.

First the question, then the screenshot

Jeremy..

If I set a GPO to be applied at the SITE level and it is working fine, and set another at the DOMAIN level and it is working fine…

When I go to the node and look at the applied Policies it shows only the one linked at the DOMAIN level.

What happed to the SITE one?

It is there and working, and when I run a Resultant set of Policy on the node it DOES show the SITE GPO and the DOMAIN GPO.

But it does not show the SITE GPO’s influence on the Node without running the RSOP.

Is there any explanation for this behavior?

Thanks,

*Dave*

First,  Dave, THANK YOU for having this so clearly marked up, expressing exactly what your problem was, and how I can help. This makes the job of helping you MUCH EASIER. (That is to say, if you are looking for a little help, I would please first encourage you to use the GPanswers.com forums.. THEN ask for help.) And if you ARE going to ask for help or look to get a question answered, THIS is exactly how to do it.

Now, lets take a look at the screenshot. (Seriously.. this is the EXACT screenshot I got from Dave. I didn't make these markups.. he did. Thank you Dave !)

What Dave is witnessing is completely normal. Dave is noticing that Site-Linked GPOs (in this example Hide Screen Saver Option, linked to Default-First-Site-Name) is actually WORKING on the client. He explains this when he tells me that he sees it show up in the RSOP (gpresult /R) report on the client.

Cool.

So the question really is.. Why can't I see it here, in the Group Policy Inheritance tab?

The answer is simple. The GPMC itself cannot know WHO will be in that site at any given time. So, to avoid confusion it won't show site-based GPOs in the Group Policy Inheritance tab.  For instance, lets pretend that Default First Site was really named Detroit. And, lets also pretend that there was a second site named Dublin (either Ireland, or Ohio.)

Now, if there is a GPO linked to Detroit and others linked to Dublin what is the Resultant Set of Policy RIGHT NOW for anyone in the Human Resources OU? Answer? We don't know.

We don't know, because we don't know if we're talking about users in Detroit or Dublin. So, the GPMC Group Policy Inheritance tab simply doesn't show (ie: assume) where the user (or computer) is at that moment.

Therefore, you'll see the GPO in the RSOP reports on the computer (because the computer ITSELF knows where it's at).. but the GPMC simply cannot make any assumptions.

Mystery Solved !

Thanks Dave.. This was a fun one !

I thought I would tip the hat this week to a Microsoft Premiere Field engineer who attempts to answer the age old question:

Windows Group Policy vs. Logon Scripts. What's the right option?

Since in a previous blog post of mine, I demonstrated why I personally feel Group Policy has the advantage, I thought I would share what I recently found about a balanced rationale about why one might one to use the built-in AD Users and Computers, versus Group Policy for logon scripts.

Here's the link to his article. Enjoy.

https://blogs.technet.microsoft.com/mspfe/2011/03/15/windows-group-policy-vs-logon-scripts-whats-the-right-option/

PS: My remaining seats in my April 11 14th Denver class are melting away like snow on a warm spring day. Don't wait if you're still interested. Confirm your seat TODAY by using www.GPanswers.com/training and signing up online or call 302-351-4903 and Diane will help you with a PO. Discounts for large teams !

This came up today with a group of new friends I met today in Wisonsin at a K12 education conference.

Someone asked How can I prevent people from stopping login scripts as they run?

I thought about this for a second, and realized, he was using Active Directory Users and Computers and running an old school script like this.

It was an easy fix. Simply start using Group Policy Scripts, which can be found here:

Doing it this way, if you DID want to run Logon Scripts visible, you would need to set

User Configuration | Policies | Administrative Templates |System | Logon/Logoff

Run Logon Script Visible.

Hope that helps !