Windows 2008 Printer Deployment, or The Intricacies of GPO and OU Relationships

I’ll say it again – I’m not an Active Directory guy. That said, my customer had me out to implement a VDI solution for them and, as we all know, that’s highly dependent on Active Directory (at least, if you’re using Windows desktops). This particular customer didn’t have any printer deployment solution in place; instead they sent out a member of their IT team to configure each user’s printers manually. Needless to say, that printer solution doesn’t scale very well into a Nonpersistent Floating desktop pool scenario, and just as obviously, it fell upon me to guide them to a better solution.

This customer is using Windows 2008 R2 print servers and has Windows 2008 Domain Controllers. There’s some pretty cool GPO based printer deployment solutions in this version of windows, so the first solution that I attempted was to just use Active Directory to deploy printers when people log in. I was able to get this working without too much difficulty, but in the Floating environment, it added about 20-30 seconds to each login as Windows installed the appropriate printers. I’m currently experimenting with ThinPrint and, failing that, will deploy a login script, but I wanted to take a moment to document what I’ve learned about using GPO to install printers (even though I don’t think it’s an ideal fit in this situation).

There are several places where you can define Group Policy to distribute printers. You can use the Print Server itself to create the policies, or you can create them yourself in the same location under User Settings -> Policies -> Windows Settings -> Printer Connections. I ended up preferring a slightly different solution – I added my printers under User Configuration -> Preferences -> Control Panel Settings -> Printers. I went this route because it gives you an easy, GUI based method to control some pretty granular settings around the printers.

When you navigate to that GPO, you can right click and create a new Shared Printer, TCP/IP Printer or Local Printer. Since we’ve got a Print Server, I made Shared Printers. The first setting that you can select after creating a new Shared Printer is the Action that this policy will perform. There are 4 actions available: Create, Replace, Update and Delete. “Create” will create a new printer on the system but will not change an already existing printer. “Replace” will change an already existing printer but will not create a new one. “Update” will create a new printer if one does not already exist and will replace a printer that already exists. “Delete” removes printers. I chose “Update” as I wanted to ensure that my settings would take precedence.

Next, you enter a UNC “Share path” like you would expect. \\Server\Printer is the proper syntax. You’ve got two great checkboxes that you can enable – “Set this printer as the default printer…” and “… only if a local printer is not present”. Once again, they are very self-explanatory, but give you some really great control over the environment in a really easy fashion. I never played around with the “Map to local port” section and can only make guesses about possible use cases.

On the “Common” tab, there are some extra options that can be set. I can guess at what most of them do based on their names, but the only one that I used was “Run in logged-on user’s security context (user policy option)”, as I wanted each user to get a customized set of printers.

And, that’s where my first challenge came up. I want this policy to apply to only a set of users, not all users. GPOs are set on OUs and apply to all objects within that OU, so how could I restrict the application of this GPO? Pretty easily, as it turns out. On the “Scope” tab of the GPO, in the bottom half of the screen is a section titled “Security Filtering”. It’ll default to having “Authenticated Users” in there – only objects that are listed there will receive this policy. Simply create user groups around each collection of printers and then enable Security Filtering for each policy so that it is only applied to its group of printers… I thought. There was a flaw in my logic.

I had assigned my GPO on the OU that held my View desktops, as I didn’t want to make these changes to the users’ physical machines. My thought was that the policy would load up on all View VMs and then would selectively apply based on the group membership of the user who is logging into said desktop… but that’s not how it works. It turns out that Security Filtering takes place on the objects within the OU on which the GPO is applied. Since I only had Computer objects in my OU and my “Security Filtering” groups only contained user accounts, none of my policies were applying to anything. I was telling the system that the policies can only apply to user accounts, but the OU on which the GPO was set did not contain any. Oops.

Once I realized this, I knew that my ideal situation of only applying within the View environment was out the window. Since the plan was to prove the printer distribution solution in VDI and then roll it out to the rest of the environment, this wasn’t necessarily a show stopper. My plan changed to apply my GPO on the OU that actually has the user accounts, using the same Security Filtering logic that I had already created. Before rolling this out, I decided to perform a small scale test on a test user account.

I created a test user account in my View Desktops OU (as I said, it was a temporary test) and added that user to one of my printer groups. I logged in as the user and, after a longer than desirable wait, I found that I had my full list of printers installed. Unfortunately, it had that “longer than desirable wait” part, so I started experimenting with ways to speed up printer deployments. The first thing that I did was to preinstall all of my printer drivers on the View Desktop. This helped, but it still took about 10-15 seconds to install each printer. My next thought was to just install all printers into my Default profile on the View desktop and use Group Policy to set an appropriate Default Printer (mainly as a test). Technically, this worked… but it’s ugly and scales terribly. Eventually, this VDI solution is going to be used by people on any of 16 floors in this building, plus users in other, remote buildings. If I go with the “printers installed in the Default profile” approach, it means that either everyone is going to have every printer in the environment installed and visible, or I’m going to need to maintain a fleet of master images.

Literally, as I type this, I realize that I do have one other approach that I hadn’t considered. Install all printers in the Default profile, then use GPO to Delete all printers except for the desirable ones. I don’t know how swiftly the printer deletion process proceeds, but that might be feasible and is another experiment worth doing if my current strategy fails.

Regardless of other options, I’ve been unhappy with my initial experiments with GPO-based printer deployment in a Nonpersistent Floating environment (where it has to install those printers every time a user logs in, rather than just the first time). Right now, I’m getting VMware’s ThinPrint implementation up and running – I’m going to do another post on that once I’ve figured it out (the documentation leaves a bit to be desired) and examined its effects on the environment.