The blog of Darren Mar-Elia — the GPOGUY and founder of SDM Software
Despite once again having to fetch it from my spam folder, I did indeed get the coveted email from Microsoft yesterday indicating that I’d been made a Group Policy MVP for the 5th year in a row. Cool!
I am honored and happy to be an MVP for another year. I look forward to another year of community contributions!
I was playing around with some scenarios related to "item-level targeting" (ILT) in Group Policy Preferences and was reminded of a significant limitation in this newer as it relates to Resultant Set of Policy reporting. What I was doing was creating a GPO that contains some GP Preferences registry settings, and then using item-level targeting to control which machine groups got those registry settings. However, when I went into GPMC and ran a GP Results (RSoP) report against one of my test machine, it showed my test GPO in the "Applied GPOs" section of the report, even though I knew that it had not passed the item-level target filter.
This pecularity caused me to dredge up a distant memory about a limitation in the way GP Preferences interacts with RSoP–namely, RSoP is incapable of deciphering whether a machine has passed an item-level target. So, even though the registry setting was blocked from being processed by the machine because it was not in the correct group, RSoP saw no reason why the GPO should not apply, since it was linked and security group filtered (using normal security group filtering) in a way that told it that everything was good.
This could very easily bite you as you leverage GPP more, so I thought it would be useful to re-iterate it here for everyone’s benefit. In short, if you use ILT to control which policy settings apply to a computer or user, RSoP will not reflect whether the ILT filter passed or failed. It will only reflect the "normal" means of filtering through linking, security group filtering and WMI filters.
Darren
Well, I was very surprised and happy to receive an IM from a colleague this morning, directing me to http://windowsitpro.com/Windows/Articles/ArticleID/102984/pg/2/2.html, where I read that our SDM Software Group Policy Automation Engine won GOLD as Best Active Directory and Group Policy Product. This is really cool and a great acknowledgement of the work we’ve been doing. Its always nice to be recognized and especially to win in the Editor’s Choice category!
Cool!
Tags:
I found this issue recently–at first I thought it was just my environment, but have confirmed it on a couple of different environments. When you are on a Win 7 box (and probably R2 as well), in GPMC and viewing the setttings of a GPO that had previously been created and contains software restriction policies, you will get an error when GPMC tries to display those SRP settings. Specifically, the error looks like this:
| Software Restriction Policies Software Restriction Policies/Security Levels Software Restriction Policies/Additional Rules |
| The following errors apply to all of the above settings: |
| An unknown error occurred while data was gathered for this extension. Details: Unable to cast object of type ‘System.String[]‘ to type ‘Microsoft.GroupPolicy.Reporting.Extensions.Registry.UnknownType’. |
From the looks of it, it appears to be a bug in the way the Win 7 GPMC object model is parsing these settings. I’ve reported it to MS but wanted to let everyone know about it so you don’t think you’re going crazy. Not surprisingly, if I open the GP Editor on this GPO, all of the SRP settings appear fine. This is only an issue with the GPMC reporting of settings.
Tags
Group Policy, Windows 7, Software Restriction Policies
On my twitter site: http://twitter.com/grouppolicyguy
As many folks probably know, Group Policy slow link detection prior to Windows Vista relied on a series of ICMP pings to determine link speed between the client and domain controller. This process was fairly inprecise and was fraught with issues because many folks have turned off ICMP on their internal networks to prevent malware that leverages this protocol from exploiting this. The end result was that you either had to disable slow link detection, or watch GP processing fail completely.
When Windows Vista and Server 2008 shipped, they introduced a completely new way of detecting slow links for Group Policy processing that no longer leverages ICMP. The process uses the Network Location Awareness (NLA) service to determine the link speed between client and DC, but the explanation of HOW that works has been relatively undocumented…until now. Mike Stephens at Microsoft has written a great blog that describes this process in great detail. Check it out!
OK folks, our Group Policy Automation Engine (GPAE), the only automation solution available on the market for reading and writing settings within GPOs, is one of the finalists in the Windows IT Pro Magazine Community Choice Awards, in the "Best AD and GP Product" category! We obviously think that the innovative nature of our product is head and shoulders above the competition, and we’d love your vote!!!
Head on over to http://www.surveymonkey.com/s.aspx?sm=8koDpFvpDvDy3ZZZGP9O4Q_3d_3d and vote for the "SDM Software Group Policy Automation Engine" before September 16th.
HEY GPOGUY & SDM SOFTWARE FANS!! We need your help! Windows IT Pro Magazine is having their COMMUNITY AWARDS NOMINATIONS until this Friday, August 14th. If you like the freeware products we have on www.gpoguy.com and on www.sdmsoftware.com/freeware, please consider nominating your favorite SDM Software or GPOGUY freeware products in the BEST Active Directory and Group Policy PRODUCT category. Let’s show the world that FREEWARE is just as valuable as the commercial products costing thousands of dollars, that typically win these awards.
TO NOMINATE OUR PRODUCTS, GO TO http://windowsitpro.com/awards/CommunityChoice.html.
Remember to vote by this Friday, the 14th of August, 2009!!!!!
I thought this was cool. John Fontana over at Network World did a nice article on the challenges around the recent Microsoft zero-day vulnerabilities and SDM Software and yours truly got a nice mention on Page 2! Cool!
Darren
Recently, Microsoft announced a zero-day vulnerability in IE’s ActiveX video control, that required folks to react quickly to prevent exploits of this vulnerability. One of the possible routes for preventing this was to disable the affected ActiveX control in IE using so-called "Killbits" in the registry. This technique is described in general within a Microsoft KB article and specifically for this vulnerability within this document. Essentially, Killbits are a set of registry entries that must be enabled on a per-computer basis (i.e. within HKEY_LOCAL_MACHINE in the registry) that sets a flag on the GUIDs related to the given ActiveX Control. In the case of the recent video control vulnerability, there were something like 45 GUIDs requiring registry updates.
Someone asked me yesterday if Group Policy might not be a good way to push out these kinds of Killbits changes. And, not surprisingly, my answer was a solid, "YES!". Centralized registry change control, is, after all, the bread and butter of Group Policy for many enterprises. In this case, there are really two ways to skin this using Group Policy. The most obvious way is to create a custom ADM file (or ADMX for Vista/2008 environments) that hard codes the registry values in question. You can then add that ADM to a GPO in your AD environment and use it to target computer objects in AD for delivery of the Killbits values. Of course, the downside to that approach is that for any new ActiveX vulnerability that comes along, you have to create a new/modified ADM file with the new GUIDs.
Probably the easier way to handle this is to leverage our good friend, the Group Policy Preferences (GPP) feature that Microsoft introduced with Server 2008. Remember that you don’t need to have Server 2008 running in your environment to use GPP, but just need to have deployed the GPP Client Side Extensions (CSEs) to your XP, Vista and 2003 systems, and then you just need one Vista, SP1 or Server 2008 machine with GPMC installed to create and manage GPP settings. GPP includes a Registry extension (under either Computer or User Configuration\Preferences\Windows Settings\Registry) that lets you deploy "free-form" registry settings. One of the cool features of this Registry extension is the "Registry Wizard". The Wizard is designed to let you pick a bunch of existing registry values from the registry on a local or remote machine, and those are captured into policy without you having to manually enter anything! So, for example, you could apply the KillBits "Fix-it" package that Microsoft typically provides, to a test machine, and then use the Registry Wizard to capture those into a GPO, and push them out to all of your desktop machines. The following screen-shot shows an example of how this works with GPP and the Registry Wizard:
When you use the registry wizard in GPP to capture these registry entries, they are defined with a GPP Action type of "Update". This means that if these registry values exist already, they will be modified to conform to the KillBits value you specify. If they don’t exist, they will be created.
GPP provides a great mechanism for managing ActiveX Killbits settings, because they are centrally visible and manageable within the GP UI and you can use Group Policy’s built-in targeting mechanisms and even the more granular GPP Item-Level Targeting, to make sure all of the machines on your network receive the settings.
And of course, if you need to be able to automate reading or writing of these GPP Killbits registry settings, you can do that very easily with our GPExpert(r) Group Policy Automation Engine and Powershell!
Tags
« Previous Page — « Previous entries « Previous Page · Next Page » Next entries » — Next Page »
