Deploy Printers with Group Policy without using Local Loopback

Stupid printer tricks / /

I've been sorting through our group policies and rewriting them ready for a switch over to Windows 7. During my thorough investigation it turns out our current policies overlap a fair bit, and it's no wonder we have trouble tracking down why something we're sure we've set in GP turns up unset on logon aThis is going to get more technical than usual. Regular readers can tune out... Now.

So my big project has been going through our settings one by one, and deciding which of these categories they fall into:

  1. Common Computer settings - all the computers should get these as they are vital to the function of the network, or are likely to break something if they aren't explicitly set for our staff and students.
  2. Common User settings - everything else that just can't be set in the Computer policy.
  3. Staff Settings
  4. Student Settings
  5. Printers

The interesting trick I've learned about the printer GPs though is how to apply printers based on the computer's OU without using local loopback!

The Problem

The problem with managing printers in a school environment is that unlike corporations (which GP is clearly geared towards) people move around all the time but want to be connected to both their printers in their offices on the other side of the school, but also the local printer in the classroom they're in bthey also want the computer to magically know which one they want to print to by default each time it changes, but that's another story. Microsoft decided that without any extra tricks they would let you set a default printer for a user, but not for a room because Betty from HR will only ever use the one computer in her office.

The Old Trick

Then they told people you could get around this by enabling local loopback, which applies both computer and user policies to a user, so you could set the printer as default in a computer policy using the "user" section, then make the computer read the computer section at logon and apply the printer. The problem with this canecdotally at least, I can't find hard evidence is that it could slow down your logins, as it increases the number of policies it has to read and evaluate to prepare the desktop.

The New Way

In my quest to eliminate unnecessary policies, I wanted to kill local-loopback too. A bit of research turned up this page on using GP Preferences to assign default printers, which I already knew and was using, but it advocated using local-loopback.


Further down that page was a comment by Michael Moore who had this bit of advice:

Actually, if you Item Level target a group which has a computer in it, it will still install the printer even though these preferences are under the User Configuration Section of the GPO.
Try it, saved on loopback.

-- Michael Moore

So I followed the directions on that site (it has helpful screenshots) to create a printer policy and target specific computer OUs, but then instead of turning on local-loopback, I simply ticked Run in logged-on user's security context (user policy option).

Now my printers deploy and are set as default based on the current computer's OU without using local-loopback at all.

Asides   [ + ]

a. This is going to get more technical than usual. Regular readers can tune out... Now
b. they also want the computer to magically know which one they want to print to by default each time it changes, but that's another story
c. anecdotally at least, I can't find hard evidence

Published by screenbeard

🚀 U R2 F2 R2 U' D F2 R2 F2 D

11 replies on “Deploy Printers with Group Policy without using Local Loopback”

  1. That's correct, but if you're using Computer Configuration then you can't use AD Printers anyway (not without adding them by IP).

  2. I too am looking for a way to get rid of loopback processing. Client log-in times are near 5 minutes depending on the number of printers involved. Despite following your directions though, my printers will not deploy unless loopback is enabled.

    My setup:
    Computers in an OU
    Group Policy Object linked to that OU that has the printers added in the preferences section. One of them is set to be default. All of the printers are targeted to that OU and set to run in the user's security context. Loopback is disabled but the printers do not install.

    Any thoughts?

  3. The problem with group policy preference printers is that the user cannot login until the printers/drivers are done loading. This can take a long time depending on the printers being loaded. Calling a vbscript or con2prt using loopback processing will load the printers in the background after the user has logged in.

  4. I wish I had found this MONTHS ago. We have several open labs for students where we have to assign printers by location and not by user. I fixed months of headaches in 15 minutes. For the first time in a year we are getting reliable, consistent printer delivery to our labs and classrooms.

  5. I'm glad this worked for you. I think my method was eventually abandonded when I left because it wasn't working reliably, but I think there were greater problems with the logins than my printer deployment. Its good to have an example of this method working in a reliable method in another environment.

  6. Works for me but if you log in under administrator, it won't install the printer for some reason. Try a different users and see how it goes.

  7. This is slightly different to deploying printers, but may be of use for you.
    We allow end users to install their own printers based on their location - we use a combination of GPO, GPP and Printer 'location' field to achieve this. I finally got around to writing it up in an article.

    One thing that I would be interested in doing next is creating a prompt for a user to pick a default printer (when they print for the first time in a new location). Anyone have any suggestions?

  8. I stumbled upon your folder redirection when I was troubleshooting a folder redirection issue: Folder Redirection for Unusual Paths [Group Policy]You didn' mention why your HOMESHARE%HOMEPATH%\Desktop didn't work. It may be due to the extra backslash this would resolve to. In a cmd prompt on the affected workstation what does "%HOMESHARE%%HOMEPATH%\Desktop" resolve to if you run this command:
    echo HOMESHARE%HOMEPATH%\Desktop

    In our environment homepath is a backslash already. Type "set" in a cmd prompt to view the other relevant variables.

Comments are closed.

I footnotes