Group Policy Preferences in a mixed environment

We were recently directed to push Windows 7 out to the network which triggered the previous post on Windows 7 deployment. In order to make this happen we made a significant investment in hardware. The targeted group of computers, approximately 150, have been upgraded to 4gb of ram and at least a 150gb hard drive.

With the introduction of UAC in Windows Vista it is no longer possible to allow a regular user to install print drivers or any driver. So you have to decide on how you want to manage your users, do you want them to be admins and let UAC do it’s job, or not. For the time being we have opted to not let them be admins. Which means we’ve had to find different ways to make things work, so we’re looking to GPO Preferences to solve some of our issues.

I have to admit it’s been rather frustrating trying to map printers and drives after Windows Vista. I wrote a pretty awesome logon script that would map any object in AD with a UNCPath property. In order for us to have a single printer in more than one place in AD we opted to use the Shared Folder object for printers and, well shared folders. This method worked for a long time under Windows XP, but as we started bringing Windows Vista into the fold we had to change our thinking.

With Preferences you are able to do a great many things, but in testing they don’t appear to work as advertised. We are having limited success with drive and printer mappings. So we took a mixed bag approach, we are able to deliver drive mappings using GPO Preferences but the only luck we’ve had with printers is using the Deploy Printer method from our Windows Server 2003 R2 print server.

The only issues with that method of deployed printers is if you routinely move workstations around, the printer connections can get tattooed to your client’s registry. It’s not that big of a deal as you can write a startup script that nukes that portion of the registry.

Unified Startup Script

Following along with the Unified Logon Script, there is also a Unified Startup Script. Again with the release of Windows 7 much of what we did via script technologies is now handled differently but I wanted to document what the purpose of this script was as well. It is also quite long so you can find it in my public repo at the following URL:

While we had a single logon script to handled the balance of our user experience we had a couple of places to handle the things that make all of our software go. Around the same time as I created the Unified Logon Script I also began working on a Unified Startup Script. This script runs at computer startup and therefore runs in the SYSTEM context of the computer. This script is responsible for defining all of the environment variables for licensing that allow the over 100 engineering applications to work. Additionally it sets up two folders on the computer that are required for some software to work, it also clears those folders. To add to that we also can define who is to be local users on the workstation as well as defining the administrator account password which is passed in as a parameter from the GPO.

As this script runs only at startup we force a reboot of lab machines once a week.

It is similar in structure to the Unified Logon Script, but lacks the AD portion as it’s not necessary to the functionality of the script.

Unified Logon Script

This script is entirely too long to publish as a page, you can find it in my public repo at the following URL.

This script is the culmination of roughly two years of tweaking. It started out in May 2008 and was tweaked throughout that summer, it’s final update was at the beginning of December 2009. The script above was created in August of 2009  and we never actually pushed it out to the labs. Sadly this script will never make it into production due to our current move to Windows 7, many of things that were once easy are now complex.

But let me tell you about the really cool features of that script, firstly if you cruise through my VBS book you will find many of the functions that I use in random scripts are present in this one. The script itself is fairly well documented as to what it is doing. The best part of it is how it works the Active Directory to get done the things that need done.

We manage several labs between two buildings, these labs make up about 50% of the computers we maintain. Lab students are provided with a consistent user experience across our labs regardless of where they logon from. The large portion of this is done through redirected profiles, which could be an article all on it’s own! The other part of the equation are drive and printer mappings. All lab computers receive the same set of drives:

  • U: user drive and personal information is stored here
  • L: a drive used by some classes for storing data to be shared
  • R: a project drive for the various project groups within the school
  • P: a publicly available read-only drive that stores backgrounds, bug fixes and some documentation

These drives need to be available on all computers, historically this had been managed through batch files. While useful you are limited to what you could do with a batch file. So we started using AD and scripting to do some of the work for us. We created 4 shared folders at the root of the Labs OU, the name of each object was the drive letter, and the path was the path to the share on the server. In a similar fashion we did the same thing with printers, we created those as shared folders as well, this allowed us to have one printer in multiple OU’s. Each lab has an OU and one or more printers are then created in that OU.

This is where the cool part of the script kicks in! A user logs into any lab computer, the script asks the computer what OU it’s in. It then searches that OU for any object with a UNCname property and then passes that object off to a procedure that will map it. We determine what it based on what server the object points to. Once it’s done in the home OU, it then works it’s way up to the OU’s in the tree above until it reaches the root of our AD. Along the way it maps any object it runs across, if your user account is a member of a group that had read access on the object you can map it, otherwise it doesn’t map.

With only a few minor changes this script can be placed in almost any AD and work through mapping printers and drives. Sadly, with the release of Windows Vista and UAC much of what the script can do has been mitigated.