The GPOGUY-- Group Policy Blog

In case you hadn't seen it, an article came out last week on Betanews that talked about the fact that MS will be removing GPMC (Group Policy Management Console) from Vista when SP1 ships. This story was blogged heavily, although I have yet to see any blogs that talked about the gross inaccuracies in this article by the author, Scott Fulton. Scott's got his facts about GP and GPMC so wrong that I have to wonder why he was reporting on GPMC in the first place. He even quoted my friend and fellow Group Policy MVP Derek Melber, who didn't even know he was being quoted for this article! I find that just the slightest bit lame, though I suppose its common practice these days.

In any case, rather than focusing on the errors in the article right now (I'll get to that in a bit), I think its worth talking about this decision in general. Its funny because this probably falls into one of those "you're damned if you do and you're damned if you don't" categories for Microsoft. Back when GPMC first shipped, out-of-band of the OS, I'm sure Microsoft heard complaints that it should be in the OS, since it became such a crucial part of managing GP for many shops. So, they went and did the most logical thing--they put it in the box in Vista. But to do that resulted in GPMC having to become part of the behemoth that is the Operating System release cycle at MS. This has obvious limitations if you know how glacially things move within MS when it comes to OS revs. Once inside the OS, they could no longer rev the GPMC and make enhancements to it on their own schedule. Everything had to be tied to the OS releases, which aren't exactly snappy if you hadn't noticed .

In addition, I'm sure more than a few large customers pointed out that having GPMC on every Vista install presented some...er...uncomfortable risks. Namely, in order for a normal user to process GPO's, they have to be able to read them. No biggie--its not like they can edit them. But, with GPMC installed on every desktop, any joe user with normal non-administrative rights in the domain can open GPMC and view the settings on any GPO they have read access to! Further, they can also backup all GPOs that they have read permissions on, to, say, their USB keys, and then take those backups to their friendly neighborhood hacker, who now has a pretty good picture of the security configuration of their AD environment (in the worst case scenario, that is).

So bottom line is that I think its a good idea, for the reasons I've mentioned and probably a few others, that GPMC will not ship in the OS and will require some kind of separate administrative install.

Now, to the Betanews article and the inaccuracies that lead one to believe that removing GPMC from the OS is tantamount to going back to NT 4. Let's see, where to begin...ok, how about this one:

Scott writes, "In fact, Microsoft's explanation appears to kick the whole notion of GPO ubiquitousness out the window, replacing it with its 1990s viewpoint that system security is best achieved when the tools everyday users are given are too difficult for them to bother with.

That conclusion can be drawn through the resumed reliance upon GPEDIT.MSC as the sole GPO mechanism in Vista."

Darren scratches his head incredulously and asks, "HUH?" Removing GPMC from Vista does absolutely nothing to reduce the manageability of GP. It just means that administrators have to explicitly download it. It will run on Vista, and Server 2008. The second part of his sentence is just bizarre. GPEdit.msc is just a MMC snap-in tool focused on the local GPO. It has absolutely nothing to do with the presence or absence of GPMC. In fact, with no GPMC installed on a system today, you can still launch GP Editor focused on an AD GPO fairly easily (see the FAQ item within the following section on my site: http://www.gpoguy.com/FAQs.htm#General), if you know what you're doing. They are two different tools, as anyone that has used them knows.

Here's another classic, "In other words, it will be considered more appropriate to edit and manage GPOs through Windows Server. That means a big network with an AD domain or forest. It also means, please don't expect to effectively manage a small network using Vista alone."

Darren continues to shake his head in wonder and notes that, again, GPMC will still be available for Vista--it will just be a separate install. So, no, no one is telling you you have to run GPMC on Windows Server. Also, the part about small networks is simply inaccurate. GPMC does and has always required AD to work. You simply can't use it on non-AD networks. In fact, if you don't have AD, you have to essentially touch each local GPO on each machine manually to affect configuration changes.

There are so many other basically wrong statements about general GPO function earlier in the article that its a wonder to me that this thing even got published. In any case, the news is out, so what do you think? Does it matter to you that GPMC will no longer be on every Vista system you roll out?

Technorati Tags

Group Policy, GPMC, Betanews, Windows Vista

Posted by gpoguy at 05:15 PM | Permalink | Comments (5) | TrackBacks (1)

Microsoft has publicly released their Group Policy Best Practices Analyzer (BPA) tool. This tool is designed to collect GP-related data from remote nodes and provide you with some ideas of things to be concerned about as it relates to Group Policy. I encourage everyone to check out the tool. In some respects, it seeks to do some of the same things that SDM Software's GPExpert Health Reporter does. I looked at the GP BPA when it was still in beta, and I must confess that I am, not surprisingly, partial to the Health Reporter for doing this kind of analysis. The problem I had and still have with the BPA is that it presents the information, while useful, in an almost incomprehensible format. It also presents so much information so as to not be very actionable. Hopefully MS will improve the tool over time but I would have a hard time recommending its use to anyone, unless they are truly a GP guru and can understand exactly what they are seeing.

In addition, I did some initial tests in my test environment using the BPA and I have to say that it appears to lack some QA before its delivery. For example, in one test I did against an XP, SP2 workstation, I got a number of warnings with the following text:

"GP_LINK is   for cpandl.com"

Clearly it was trying to tell me something about a gplink attribute on the domain level, but I couldn't figure out exactly what . It also warned me that GPrefresh was unsuccessful but returned with error code 0 (that usually means things worked ok) and then told me it took 60 seconds for the refresh. When I ran the same test from the Health Reporter tool against the same machine, it returned a red status and indicated that Folder Redirection had failed for the currently logged on user, something I did not get from the GP BPA. The GP BPA also presents some really confusing data--and I say that as someone who sorta gets what's going on under the covers in GP. For example, the screen shot below shows a report on that XP node, and frankly, I'm not sure what its trying to tell me, esp. when it says "Any  = true".

In any case, I'm happy that MS is putting *something* out there to help folks, and its free!. Check it out. 

Technorati Tags

Group Policy, Group Policy BPA, GPExpert Health Reporter, Group Policy Troubleshooting

Posted by gpoguy at 12:57 PM | Permalink | Comments (1) | TrackBacks (0)

A question that appeared on the newsgroups today prompted me to blog about Group Policy Resultant Set of Policy (RSoP) and its capabilities. RSOP was first introduced in Windows XP as a way of letting administrators find out what happened during the last GP processing cycle on a given Windows system. This mode of forensically checking GP processing is called RSOP Logging or RSOP Results. The RSOP infrastructure also provides a mechanism for doing what's called, RSOP Planning or Modeling, which lets you ask "what-if" questions about changes that you might want to make to your AD infrastructure that could affect Group Policy application on a given target computer or user. In both cases, this RSOP capability relies on some WMI enhancements that Microsoft made to XP, Server 2003 and later versions of the OS. These WMI enhancements are what is used by the RSOP engine to store resultant set of policy data in the WMI repository on each system, each time policy is processed. And, these enhancements are the reason that you cannot get RSOP data from a Windows 2000 machine--it doesn't include those WMI enhancements and thus cannot collect or report RSOP.

Now with that background in mind, let's look at how RSOP Logging works. When GP processing kicks off, each Client Side Extension (CSE) does work to process policy settings that apply to the computer or user. Each CSE is also responsible for logging RSOP data into the WMI repository on the machine where its running. That RSOP code is written into the CSE DLL that Microsoft (or a 3rd party) provides. What it does is basically send a list of the settings that its applying to WMI. This is an important point. RSOP does not check to make sure that each and every setting completed successfully. It does show if the CSE itself fails to run successfully, but it does not guarantee that every settting that was delivered was actually successfully applied (to the registry or elsewhere). So when you use GPMC or gpresult.exe to gather RSOP data, you are getting RSOP's "best guess" that everything was delivered as it was supposed to be. Most of the time, if the CSE ran successfully, then it is a pretty good guess that all the settings were installed properly. But of course, there is no guarantee of this! Still RSOP in XP and above is orders of magnitude better than what we had in Windows 2000, which was essentially a gpresult.exe tool that only gave partial information related to GP based on some rough assumptions about which policies applied to the system.

A quick word on RSOP Modeling as well. In order to use RSOP modeling from GPMC, you need to have at least 1 Windows 2003 (or 2008!) DC in your AD domain. That is because there is a special service that runs on this version of Windows Server that is used by the modeling engine to actually compute the RSOP what-if scenario. So you need to have that DC somewhere in your domain and you need to have rights on the domain to be able to run the model in the first place!

Technorati Tags

Group Policy, RSOP, GPResult

Posted by gpoguy at 08:49 AM | Permalink | Comments (0) | TrackBacks (0)

Just a quick note that if you want to see the GPExpert Scripting Toolkit (GPST) in action, cruise on over to Adam Bell's blog. Adam's been evaluating the Toolkit and has posted some sample PowerShell commands showing how you can use the GPST to modify policy settings.

Group Policy, PowerShell Tools, GPExpert Scripting Toolkit

Posted by gpoguy at 07:32 AM | Permalink | Comments (0) | TrackBacks (0)

In the vein of interesting desktop configuration management tools, the company that created the product ScriptStart, Entrigue Systems, announced that it is going to be open sourcing a version of their logon script based desktop configuration tool. While this is not a Group Policy-based solution, it nonetheless has some interesting capabilities similar to GP, like the ability to do Folder Redirection, IE config, Office config and drive mapping. In reading the press release, it appears that they still plan to offer a commercial version but will create a community around the free product for folks to contribute to. This is cool. I'm still partial to GP as a scaleable and robust way of managing desktop configuration but this is nice to see this capability going open source.

Technorati Tags: ScriptStart, Open Source, Group Policy

Posted by gpoguy at 04:30 PM | Permalink | Comments (0) | TrackBacks (0)