Installing Group Policy Preferences Client Side Extensions

In my previous post, I ran through a quick and dirty overview of Group Policy Preferences in Windows 2008.  One little tidbit of information to note is that in order to take advantage of Group Policy Preferences in your Windows 2008 domain, you need to have the Group Policy Preferences Client Side Extensions installed on your PCs and Servers.  The Client Side Extensions are installed on Windows 2008 systems by default, but they must be deployed to your XP, Vista, and 2003 devices in order to take advantage of Group Policy Preferences.

Like virtually everything in IT – there is more than one way to skin a cat.  The GPP Client Side Extensions are available as an update for Windows (KB 943729).  So if you have a method for centralized deployment of updates, you can push this update out to all of your machines.  If you’re using WSUS – 943729 is classified as a Feature Pack – so you will need to be synchronizing all Feature Pack updates in order to deploy this via WSUS.

If you don’t have an automated method for deploying updates, or if you’re just a bit sick & twisted like I am, we can configure our SBS 2008 domain so that all machines get the update installed automatically via a GPO startup script.  I personally like this approach for a few reasons.  First – once it’s set up, we don’t have to do anything special.  If we add a new machine to the domain, it will get the Client Side Extensions installed automatically at startup.  And considering the few reboots that happen when joining a PC to the domain via http://connect – the CSE will almost always be installed before the user logs in for the first time.  This is beneficial to relying on WSUS – because even if we have the update approved for installation, when the PC is first joined to the domain it has to check in with WSUS, and depending on our patching schedule, it could take several days until the CSE actually gets installed.  If we’re relying on Group Policy Preferences to handle our drive mappings, printer installations, etc. – it’s obviously preferable to have the CSE installed as soon as possible.

So, I’ve put together a little vbscript to handle the installation of the Group Policy Preferences Client Side Extensions.  This script can be used in a number of fashions – from running it manually on a device, to using your favorite Remote Monitoring & Management product (Level Platforms, Kaseya, etc.) to deploy it, or by using it as a startup script in a domain Group Policy Object.  

A few details regarding the script:

  1. The script assumes that the CSE installers are present on the LAN.  Therefore you will want to make sure each of the six variations of the CSE installer (both x86 & x64 for Vista, XP & 2003) are downloaded to a share on your network.
  2. You will need to edit the paths to the installers in the script.  The defined paths can be found on lines 47 – 52.  Note that these paths must be UNC paths to work.
  3. If you are going to use the script as a domain startup script, remember that startup scripts execute under the computer account’s security context – so you will need to make sure that your Domain Computers security group has read access to the share where the script and the CSE installers reside.

I’ve tested the script on a number of systems, and it has worked flawlessly on each.  However, as usual I make no warranties of any kind, and if you choose to use this script in a production environment, you do so at your own risk  smile_regular

The Death of IFMEMBER

Anyone who has heard me talk about service delivery standards knows that I’m a big advocate for standardizing everything you can.  One of my big pet peeves are SMB networks that are not using standard drive mappings – where each user has a different drive letter pointing to the same share on the server . . .    I’ve been surprised by the number of administrators & consultants who don’t know about the IFMEMBER utility from the Windows Resource Kit.  IFMEMBER has been a core building block of my login scripts for the past 10 years, allowing me to dynamically map network drives based on a user’s security group membership at login. 

Well, with the dawn of Windows 2008 – IFMEMBER is effectively dead.  I’ll admit that I’m probably a bit behind the curve here, but quite frankly – login scripts themselves are effectively dead in Windows / SBS 2008 and are replaced with Group Policy Preferences.  I finally got a chance to play with Group Policy Preferences, and I have to say they work pretty slick.

Let’s take a fairly typical example:  We have a site running SBS 2008, and each user has their own folder under the usershares share on the server, we also have a public share for common files, and we have an accounting share for our QuickBooks data and accounting specific spreadsheets & reports, etc.  We want each user to have H: mapped to their user shared folder, P: mapped to the public share, and Q: mapped to the accounting share.  We only want Q mapped for members of the Accounting Users security group we’ve created, and we want to force these mappings (so they replace any different drives users may have created using the same letters).  

Previously, our login script to accomplish this would have looked like:

net use h: /delete
net use h: \\server\usershares\%username%

net use p: /delete
net use p: \\server\public

IFMEMBER “Accounting Users”
if not errorlevel 1 then goto quit_acct
net use q: /delete
net use q: \\server\accounting

With Group Policy Preferences, we start by opening the Group Policy Management Console on our SBS 2008.  I decided to create a new GPO in the DOMAIN \ My Business \ Users \ SBS Users OU.  When the GPO is opened in the editor, you can see a clear delineation between Group Policies and Group Preferences:


There is still a separation between Computer configuration and User configuration.  Obviously, drive mappings will be a user configuration.  Expand User Configuration | Preferences | Windows Settings and select Drive Maps.  You can add a new drive mapping by either clicking the plus sign “+” icon in the toolbar, or right-click in the content pane and select New | Mapped Drive.


You will notice there are four different actions that the drive mapping group preference can take:  Create, Delete, Replace or Update.  Create and Delete are self-explanatory.  In the example in the screenshot, I’m mapping H: to the user’s shared folder on the server.  If the user was already using H: for a different drive, the Replace option will effectively remove the existing H: drive then create a new mapping based on the settings defined in this preference.  If we used the Update action, the preference would only change the attributes of the existing H: drive to match the settings specified, thus retaining any locally applied settings for the drive mapping that are not defined in the preference.  Both the Replace and Update actions will create a new mapped drive if it doesn’t exist when the preference is applied.

Most of the fields on this page are self-explanatory.  Note that we can specify a given account to use to connect to the share, and we can specify a custom label for the mapped drive as well, and take advantage of variables such as %username% in the path & label.

If we take a look at the common tab, we have a few more options, including the ability to enable item-level targeting which unleashes the true power and flexibility of Group Preferences.  Let’s take our basic example of wanting to map the Q: drive to the accounting share, but only for members of the Accounting Users security group.  On the Common tab, we would check to enable the options to run the preference in the logged-on user’s security context, and to enable Item-level targeting.  Then we click the Targeting button to specify the target:

In this case, we would click “New Item” and select the Security Group option.  From here, we can browse to select our Accounting Users security group.  Note that we can specify whether we are checking the user or computer’s membership, and using the Item Options, we can specify whether we want to check if the user/computer IS a member or IS NOT a member of the group.   In our example, this is all we would need to do to have our Q: drive mapped for members of the Accounting Users security group.

But while you’re in the targeting editor, take a look at all of the items we can check for.  Also note that we can add collections (groups of items) for nested targeting, and we can use AND or OR operators within our collections to specifically target exactly who or what we want to get this preference applied. 

Another preference that will get a lot of use in the SMB space is the ability to add mapped printers (and set default printers) via the preferences as well.  As an example of targeting, if we have a customer with multiple locations all on the same domain & linked via router-based VPNs, we can target based on the client PC’s IP address, so it only gets printers at its location installed.   

Regardless – I encourage everyone to really play with the new Group Policy Preferences – they’re going to make it much easier to standardize our client environments  smile_regular

Accessing the Windows Internal Database in SBS 2008

OK, so I’m a little behind schedule – but I’m finally getting a chance to really dive in to SBS 2008, and I should hopefully have some decent posts moving forward . . .    yeah, yeah I hear you – *any* post decent or not would be an improvement over the last year . . .    I’m workin’ on it, k?  smile_regular

So most of us running WSUS 3.0 or WSS 3.0 are familiar working with the Windows Internal Database, and know that we can connect to that instance via Named Pipes so we can actually use the nice GUI interface provided by SQL Management Studio (Express).   Well, if you’ve tried using the Named Pipes method to connect to your Windows Internal Database on your SBS 2008, you’ve probably noticed that it doesn’t work . . .

Here’s the deal:  When the Windows Internal Database is installed, the built-in administrator account is granted system administrator privileges to the SSEE instance.  As you’re aware – with SBS 2008 the built-in administrator account is disabled by default and we use a custom administrator account created during setup to administer the box.  The problem is that this custom administrator account is not granted SQL system administrator privileges to the SSEE instance by default.

The work around to get this to work was simple enough – all i did was enable the built-in administrator account on my SBS 2008, then log in using that account.  Once I was logged in, I was able to successfully connect to the Windows Internal Database via named pipes.  At that point, I was able to add my custom administrator account as a SQL system administrator for the SSEE instance;

Expand Security | Logins.  Right-click on Logins and select “New Login”

Click the Search button to find your custom administrator account in the directory

Accept the defaults on the General page

On the Server Roles page, check the  sysadm  role

Click OK to add the user

Now you can log back in to your SBS using your custom administrator account and access the Windows Internal Database instance via named pipes.  Just don’t forget to disable the built-in administrator account when you’re done!