Last year I talked briefly about how loopback policy works. This is the system that Microsoft has built into Group Policy to enable a user policy to be applied to a computer that is dependent on the OU that the computer’s account is stored in. This is a great system because it enables a policy to be applied to a user that can be targeted by according to the physical computer that they are logging onto. One obvious example of this is to set a default printer for a user that changes depending on where the nearest printer to the room they are in, is located. Because the setting is set for each user individually, it can’t be done in an ordinary GPO, because the computer account does not set user policy settings; these are set by the directory location of the user account.
Previously to set the default printer, we would have a mandatory profile with the printer default defined in it. The best we could do with this is to define that users in one particular part of the school would have a particular mandatory profile for the nearest printer to their home room. But if that user or users went to another part of the site, their default printer could not change to reflect the fact that they had moved, so this system has obvious limitations.
One important issue to deal with when using loopback policy is the way in which it becomes retroactive on other GPOs in the same branch of the directory tree. When I did my MOC training classes at the local polytech, all the material showed the use of the same OUs to store both computer and user accounts. Naturally this is the method that I followed to set up our school’s directory tree for users and computers. However this gets messy when a loopback policy is applied to an OU because the user policy is combined with other user policies and these policies get applied to every user, not just the users they were targeted at. For example, in a school, commonly pupils are going to get a locked down desktop with a restricted Start menu and limits on local hard drives, say. A teacher or technician on the other hand might not have the same restrictions and they should have a full Start menu and be able to access all drives. If your user and computer accounts are in the same branch of the GPO tree then applying a loopback policy to a computer in that branch will also result in the rest of the user GPOs applying to every user who logs in to a computer in the branch, regardless of the user accounts being in different OUs or some of them (not all) being in different branches. The fix for this is to put computer and user accounts into different OUs that are in different branches and then the loopback policy will only have effect on specific user GPOs.
Setting the default printer itself is easy, just two lines of VBScript code in a logon script:
Set objNetwork = CreateObject("WScript.Network")
objNetwork.SetDefaultPrinter "\DC0218_Colour_Printer_4050_Vista"
One thing to watch out for is that the default setting will not show up in your printer list (i.e. a checkmark next to a named printer). This fooled me in the past when I did this in a login script because it looked like the script wasn’t working. This time around I tested it out and it does indeed work, but the lack of visual confirmation in the user interface is offputting. There are several ways of setting the default printer including registry settings but the login script is probably the simplest to apply across a site using GPOs and thereby leveraging the advantages of centralised administration with the server tools.
UPDATE: If you are using printer deployment policy on Windows Server 2003 R2 you may find your default printer connection script fails with a message saying the printer cannot be found. The solution I have found to this is to insert a new second line in the above script so that in this example it reads:
Set objNetwork = CreateObject("WScript.Network")
objNetwork.AddWindowsPrinterConnection "\DC0218_Colour_Printer_4050_Vista"
objNetwork.SetDefaultPrinter "\DC0218_Colour_Printer_4050_Vista"