07.23.10
Posted in General Stuff, Group Policy Preferences, Security-related at 10:24 pm by Administrator
Microsoft recently announced a new security vulnerability in Windows shortcuts that affects all versions of Windows since XP! Its references here: http://support.microsoft.com/kb/2286198. This particular vulnerability takes advantage of the icon that appears in shortcut (.lnk and .pif) files on Windows. Within the article cited above, Microsoft provides a “FixIt” workaround for the problem that essentially removes the icon from the shortcut, leaving a blank icon in its place. In looking at what they are doing in the FixIt, it struck me that you could leverage GP Preferences’ registry extension to blow this fix out to your entire environment pretty quickly. So, what I did was create two new GP Preferences registry items, that update the appropriate registry values, and remove the data from those values. The values in question are:
HKEY_CLASSES_ROOT\lnkfile\shellex\IconHandler\@
HKEY_CLASSES_ROOT\piffile\shellex\IconHandler\@
Where @ represents the “Default” registry value. Each of these values needs to have no data in them in order for this fix to work (and you’ll need to restart the target machine).
The GP Preferences items were very easy to craft. The following screenshot shows an example of the one I did for the lnk files:
Note that the value data field is left blank. That, in combination with using the “Update” action on the GP Preferences item, makes it easy to blank out a registry value. I then repeated this same process for the piffile path in the registry. Since I created this policy under “Computer Configuration”, I targeted the GPO to my computer objects in AD by linking it to an OU containing my computers. During the next policy refresh, the fix applied and I was protected. When an update is provided by Microsoft, you can again use GP Preferences registry extension to update the registry value with its previous, default value, which is “{00021401-0000-0000-C000-000000000046}” for both lnkfile and piffile.
Cool! GP Preferences strikes again!
Darren
Permalink
06.22.10
Posted in Group Policy Preferences, Security-related at 10:47 pm by Administrator
Well, I’ve been crazy busy working on some new product releases but I wanted to take a moment to blog about some useful features in GP Preferences that often slip through the cracks. I saw a blog post today about how you could use a custom ADM file to remove administrative shares on Windows systems. This works pretty well, but I always prefer it when Group Policy makes it really easy for me to manage configuration, and GP Preferences does that time and again. With respect to shares, you may want to prevent users from publishing shares on their workstations, or you may just want to get rid of the administrative shares for security reasons. In either case, you’ll find that the Network Shares GPP feature can fill the bill. If you navigate to Computer Configuration\Preferences\Windows Settings\Network Shares, you’ll find this hidden gem. Right-click the Network Shares node to create a new share policy. The key to accessing the share removal feature is to choose the Delete action on the network share policy item you create, as shown below:
Note that within the policy, you can choose to remove all regular shares (i.e. those that the user creates), all hidden, non administrative shares (i.e. shares created by the user using the $ hidden marker) and admin shares (e.g. c$, admin$, etc.)
Obviously, you’ll want to use this feature carefully, especially when removing built-in administrative shares that are often used by remote management tools. But, the ability to remove user shares is especially useful in preventing your users from creating a peer-to-peer file sharing network under your nose, with little or no access controls!
Enjoy!
Darren
Permalink
11.29.09
Posted in Group Policy Preferences at 7:48 pm by Administrator
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
Permalink
02.26.09
Posted in Group Policy Preferences at 2:47 pm by Administrator
In a recent posting on the Activedir.org mailing list, I happened to mention that we’re getting ready to release v. 2.0 of our GPExpert(r) Scripting Toolkit. The Toolkit is actually getting a new name, but I won’t spoil the surprise for now. However, the key feature we’ve added to it is support for the new Group Policy Preferences (GPP) settings! This is pretty exciting because this now means that you can use PowerShell or .Net to automate the reading and writing of all of the GP Preference settings across GPOs. And even more exciting is the fact that we are also supporting the ability to do Item-Level Targeting through the Toolkit as well. This means that you can not only define GP Preferences settings but also target them using any of the many different ILT criteria. And if that weren’t exciting enough (I know, I’m easily geeked out!) how about the fact that you can run GPP scripts on XP or Server 2003 in addition to Vista and 2008. That’s right, even though you can’t normally edit GPP settings on anything other than Vista, SP1 or Server 2008, the Toolkit’s GPP support has no such limitation. So you can read and write GPP settings from any platform from XP on up! Double-cool.
As an example of how this comes in handy, we recently worked on a customer GPO consolidation/migration where they were consolidating a large number of GPOs spread across 3 forests into a single forest. They had not used GPP prior to the new deployment but did have another product in place for delivering drive and printer mappings (Scriptlogic’s Desktop Authority product in this case). We were able to use the new Toolkit with support for GPP to automate the process of converting their dozens of drive and printer mappings into GPP settings within a couple of GPOs. Cool!
Lets look at how you can write a PowerShell script to create a drive mapping policy that targets a particular user group:
=======================================================
#connect to the GPO
$gpo = Get-SDMgpobject -gpoName "gpo://cpandl.com/Marketing Drive Mappings Policy" -openByName
# now, connect to the GPP drive maps container
$driveMapSetting = $gpo.GetObject("User Configuration/Preferences/Windows settings/Drive Maps")
# define a new drive mapping
$map = $driveMapSetting.Settings.AddNew("P Drive")
# and set its properties
$map.Put("Action",[GPOSDK.EAction]"Update")
$map.Put("Drive Letter","P")
$map.Put("Location","\\MktgServer1\public")
$map.put("Reconnect", $true);
$map.Put("Label as", "Marketing Public Drive");
# save it!
$map.Save()
# now create a group-based ILT filter
$iilt = $gpo.CreateILTargetingList()
$itm = $iilt.CreateIILTargeting([GPOSDK.Providers.ILTargetingType]"FilterGroup");
$itm.Put("Group","Marketing Users")
$itm.Put("UserInGroup", $true)
$iilt.Add($itm)
# and apply my new ILT to the drive mapping
$map.put("Item-level targeting", $iilt)
$map.Save()
=======================================================
Pretty cool, huh? Well, I think so 
Now imagine that you can do this across any of the numerous settings within GPP and you’ll see why I’m excited about this new release of the Toolkit! I will be blogging when we get the bits out there. Right now we’re working on a big, thick user guide with a ton of examples of how you can use the Toolkit and PowerShell to automate any number of GP management tasks. Stay tuned….
Tags:
Group Policy, PowerShell, Group Policy Preferences, GPExpert Scripting Toolkit, Group Policy Automation
Permalink
02.12.09
Posted in Group Policy Preferences at 5:31 pm by Administrator
So, the other day I was trading some email with a friend and mentioned that I was working on a nifty little utility to allow someone to import the contents of a .reg file into Group Policy Preferences registry extensions using the command-line. He commented that it sounded interesting but that the GP Preferences UI already supported something like this. So I thought I’d play around with it and see exactly how this works. He was right of course (mostly because he was the original architect of the predecessor of GP Preferences 
).
Within the Registry portion of GP Preferences (Computer or User Configuration/Preferences/Windows Settings/Registry), you can, of course, deploy individual registry settings to your heart’s content. I find this to be a better alternative to writing custom ADM or ADMX files in most cases because its easier to do, and you can leverage the Item-level Targeting feature in GPP. But what I hadn’t tried was the Registry Wizard option that you get if you right click the Registry nodes and choose New, Registry Wizard. This is where it gets fun. From this wizard, you can browse the registry on either the local or a remote computer and choose the reg keys and values within the registry tree, that you’d like to deploy, as shown here:
Once you’ve chosen the keys and values you want, GP Preferences automatically creates the policy settings for those keys and lets you distribute them to all your target machines.
So, my friend was right, of course. I’m still going to build my command-line .reg import tool because, hey, its always better from the command-line, right? But this is a pretty cool capability within GP Preferences that lets you get going right away deploying registry modifications instead of having to write those pesky ADM files.
Tags
Group Policy, Group Policy Preferences, ADM
Permalink
09.04.08
Posted in Group Policy Preferences at 4:48 am by Administrator
I’ve seen a lot of interest in Group Policy Preferences since its release, and a lot of confusion about whether you can use it if you don’t have Windows Server 2008 in your environment (you can!) so I thought it would be useful to create a quick whitepaper on the basic requirements for this feature, and what things it can do. Check it out at the GPOGUY.COM Whitepaper page.
Enjoy!
Tags:
Group Policy Preferences, GPOGUY
Permalink
08.28.08
Posted in Group Policy Preferences at 11:03 am by Administrator
I frequently find that a lot of folks have not yet discovered all of the cool new Group Policy management features that Group Policy Preferences brings to Windows. As a result, I thought it would be worthwhile to do a couple of blog items about some of these features. Today, I’ll talk about Power Management.
When Vista shipped, Microsoft provided a way of controlling Vista Power options using Group Policy. Great! We’re all concerned about energy use these days and, as my friend Brandon might say, I’m as big a "tree-hugger" as there is, so I like seeing these built-in features that make it easy to conserve power. But unfortunately, you had to be running Vista to take advantage of this control. That left all those millions of XP PCs out in the cold (or hot, as the case may be), with the only option to buy a 3rd party product or install the very useful, but somewhat heavy, EZ-GPO client service, sponsored by the US Government (http://www.energystar.gov/index.cfm?c=power_mgt.pr_power_mgt_ez_gpo).
However, with the release of Group Policy Preferences, you can now control power options on both a per-computer and per-user basis, natively within Group Policy, for XP (and Server 2003) systems. These options are under Computer (or User) Configuration\Preferences\Control Panel Settings\Power Options, within GP Editor. Within this section, you have the option to control both "Power Options" and "Power Schemes". Power Options include global settings like enabling hibernation, and setting the behavior of Windows when the user presses the shutdown or sleep button or closes a laptop lid.
The Power Schemes section is where you can define the active Power Scheme in effect on a machine, and configure the specific options for it, such as how long the display and hard drives will run during inactivity before powering down, depending upon whether they are plugged in or on batteries. You can also use this section to define new custom power schemes that are right for your organization!
And, since this is Group Policy Preferences, you also get the advantage of the item-level filtering feature, which means that you can target specific power schemes to just laptops or just desktops, within a single GPO. And of course, I can’t fail to mention that the upcoming release of SDM Software’s GPExpert(tm) Scripting Toolkit will support GP Preferences, so you can now automate power management policy changes using PowerShell or VBScript!
Very cool stuff for this tree hugger! I hope you take advantage of this new "in-the-box" feature!
Tags:
Group Policy, Power Management, XP, Group Policy Preferences
Permalink
05.30.08
Posted in Group Policy Preferences at 11:09 am by Administrator
I have heard a lot of questions about the need to install the pre-requisite XMLLite package on XP and Server 2003 prior to installing the Group Policy Preferences Client Side Extensions to those versions of Windows. The fact is that XMLLite is currently not deployable via WSUS, which has made it hard for folks to mass deploy Group Policy Preferences. What I’ve come to learn is that while this deployment challenge for XMLLite is true, there are some mitigating factors that might help certain shops. Namely:
- Windows Server 2003, SP2 and Windows XP SP3 already include XMLLite, and thus its not required as a separate install before you install Group Policy Preferences on those versions of the OS
- Windows Server 2003, SP1 and Windows XP, SP2 with Internet Explorer 7 installed also do not need XMLLite, as it is included with IE 7.
So, bottom line is that if you are running 2003, SP1 or XP, SP2 without IE7, you will still struggle to deploy XMLLite through means other than "sneaker-net" but the good news is that, with these above exceptions, the number of those machines should get smaller and smaller over time.
And just a note that XMLLite is not required at all for GP Preferences on Vista.
Tags:
Group Policy, Group Policy Preferences, XMLLite
Permalink
