Setting the Default Printer when Deploying Printers

I have a client that wants to deploy printers using group policy.
Windows 2003 R2 Active Directory has this capability, all you need is at least one 2003 R2 domain controller.

Most of what you need can be found here, but there are a few things I found out in real life.

First, I found out that it doesn’t work when assigning printers to users via group policy, but it does work when assigning them to computers. That’s ok for me, because my clients care about assigning printers to computers, not users. By that I mean we want the printer in Room 212 assigned to the computers in Room 212, no matter who sits down and logs on.

One missing function of deploying printers via group policy is assigning the default printer. So this is one of the main reasons I write this blog entry.

In order to assign the default printer, we have to take the group policy that assigns the printer and run a script when the user logs on (no matter who the user is)

In order to make this happen, we have to turn on a very important feature in group policy called “loopback” mode. Loopback mode allows you to assign a group policy to a workstation, and not only run the “computer configuration” portion, but also run the “User Configuration” portion when the user, no matter who it is, logs on.


Here are the three things this group policy does.

The “pushprinterconnections.exe” I copied from the W2003 R2 server (c:\windows\system32) to the NETLOGON share on any of the domain controllers. This needs to run on all XP machines in order to push printer using group policy. Vista does not need this (like who uses vista…?) This piece is explained well in the link i provided at the top of the blog.

The Loopback mode is set to Enabled and Merge. The Merge setting (rather than Replace) still allows group policies assigned to user to work and apply.

The Script to set the default printer, is called “Default-Printer.vbs”

The contents of the “Default-Printer.vbs” is seen below

‘ Set Default Printers
Wscript.Sleep 30000
defaultP = WScript.Arguments.Item(0)
Set WshNetwork = CreateObject("Wscript.Network")
WshNetwork.SetDefaultPrinter "\\server-name\" & defaultP

The nice thing about this script is that you can have ONE script to set the default printer for any printer. The implementation of this script is seen below, you type the printer name in the “Script Parameters” field, this is what the “Item(0)” is all about in the script. Item(0) is like %1 in the old dos batch programming.

Also, I found that the Wscript.Sleep 30000, which means to pause for 30 seconds, allows the group policy to deploy the printers. If i didn’t wait this long, then it sometimes errors out (on a new profile) because the printer is not finished installing and the script errors out because the printer is not seen as installed yet.


It works pretty well. My clients have a group policy assigned for each printer or groups of printers, they put the computer objects in OUs and assign the group policies to those OUs. For example, all the workstations in room 112 are in an OU called Room112, which has the group policy PrinterRoom112 assigned to it. This group policy assigns the printer or printers in room 112 to all these workstations, no matter who logs on.


Windows Time in a domain

Understanding time synchronization in a domain.
The domain controller that is the pdc emulator is the “primary time server” for the domain.
All other domain controllers get their time from the pdc emulator, and the workstations and member servers get their time from any domain controller. So think of the structure like a pyramid with the pdc emulator dc on top, other dcs at the second level, and workstations and member servers at the third level.
This server should be getting it’s time from an external time source.
The best one these days is the multi-server (520 servers), round robin, “”.
A little side note, don’t use, it sucks, don’t use military sites or university sites as they have turned off external traffic to their time servers. I used to point to the server, but that was 6 or 7 years ago. I suggest if you want to know more, go to
So, on the cmd prompt on the pdc emulator domain controller, run this command.
W32tm /config / /syncfromflags:manual /reliable:yes /update
It should spit back “command completed successfully”
Then stop and start the w32 time service, either in the services control applet or the cmd line like this:
Net stop w32time & Net start w32time
(the & sign means if the first line complete successfully, then run the second line…. That was new for me too when I first saw it… I didn’t know you could throw Boolean logic at the cmd prompt) You could also do a two liner by typing “Net Stop w32time”, hit enter, then type “net start w32time”.
Then look in event viewer, you should see this:
That’s good.
Then at the other domain controllers and member servers and workstation, if you restart the time service (not necessary but a way to check it) you should see this:
What if it’s messed up? And you see something like this?
Or this?
Well, to fix all other servers, I issue this command:
w32tm /config /update /syncfromflags:DOMHIER
Similar to the other one, but this one says use the DOMAIN HEIRARCHY….
Then restart the time service
Net stop w32time & Net start w32time
Check the event viewer and all should be good.
I did see some ODD and incorrect things setup in Group Policy at PIC.
I saw this in the “General Client Policy” for the workstations:
Oh no…. I said…. And then I changed this setting to “Not Configured”
There is no need to modify this setting and you should use the normal domain hierarchy process.
This is why all the client machines time was different than the server.
I also saw the time service stopped on two server…. That’s a big no no.
Kerberos is a time sensitive authentication protocol, if the clocks are askew by more than 5 mins, the workstation /user can’t authenticate.