Before you can begin using the Print Management Component, you need to perform a number of steps. First you will have to update your Windows Server™ 2003 schema to match the Windows Server 2003 R2 schema. If you want to use Windows Server 2003 to perform printer management, you need to load the Print Management Component on Windows Server 2003. On the other hand, if you want to use Windows® XP for printer management, you need to load the Windows Server 2003 Administration Tools Pack onto your management station. In order to update the schema you’ll need approval from your Active Directory® Schema Administrator. Once you have the approval, this operation is best performed directly upon the Schema Master in your domain.

You need to do the schema upgrade so that printer connection objects get a new fast query lookup via LDAP in Active Directory. This way, the Print Management Console (which I’ll explore shortly) doesn’t have to inspect every Group Policy Object (GPO) in the domain to determine where printers are deployed.

When you pop in the R2 disks, you’ll be presented with the option to continue Windows Server 2003 R2 setup. If you do, however, you’ll get the message stating that setup can’t continue because the Active Directory schema version of the controller is not compatible with Windows Server 2003 R2 and that you must upgrade the schema. You are also instructed that you can upgrade the schema by running adprep.exe /forestprep on the schema operations master. Adprep.exe can be found in the Cmpnents\r2\adprep directory on the Windows Server 2003 installation disk 2. To update the schema, start out by locating Windows Server 2003 R2’s disk 2. In the \Cmpnents directory, run adprep/forestprep. Once this is done, you can continue the installation of R2 by clicking R2Auto.exe on the root of the R2 CD-ROM. The rest of the installation should be a piece of cake.

For the rest of the article, I’ll assume you’re using your Windows Server 2003 and have upgraded it to R2. I’ll also assume that you want to manage your printers from that server, as opposed to a Windows XP management station.

Next load the Print Management Component by going to Add/Remove Programs | Windows Components | Management and Monitoring tools and selecting Print Management Component, as you can see in Figure 1. Note that next time the Configure Your Server Wizard appears, you’ll see that it’s been installed.

Now that the Print Management Component has been loaded, you’re ready to deploy printers to your users or your computers. You can do this either by hand using the regular Group Policy editor snap-in or by using the tools provided in the Print Management console.

To push a printer down to your users or computers, you start by creating a GPO and linking it to an organizational unit (OU) containing either users or computers, for example, the Sales Users OU. When you edit your next GPO, you’ll see a Deployed Printers node in both the computer and user half of the GPO along with a new Action called Deploy Printer in the Action menu, as seen in Figure 2.

Note that if you don’t see the Deployed Printers node, it’s likely that you don’t have the updated Adminpak tools on your management station (the computer from which you’re editing this GPO). To get the latest tools, download the Windows Server 2003 Administration Tools. This isn’t one huge file like Adminpak.msi; instead it’s a collection of smaller files for specific updated components, such as the Print Console.

Once you select User Configuration | Deployed Printers | Deploy Printer (as seen in Figure 2) or Computer Configuration | Deployed Printers | Deploy Printer, you’ll be ready to blast new printer assignments down. Just type \\server\printer into the Enter printer name dialog (shown in Figure 3), click Add, and it appears that you’re finished. However, you need to go the extra mile to tell your users or computers to actually accept this newly chosen printer.

Pushprinterconnections.exe is a new R2 command that users or computers need to run. If you’re deploying printers to users, the .exe needs to be run in the user’s Login Script. If you’re deploying printers to computers, it needs to be run in the computer’s Startup Script.

The pushprinterconnections.exe program is found on your R2 server in the \windows\PMCSnap directory along with some other bits associated with the Print Management console (which I’ll talk about in a minute). You can see that in Figure 4. However, this isn’t where you run it. Your job is to take the file and plunk it directly into the GPO itself.

While editing the GPO, drill down to the script type (User Login or Computer Startup). Click the Show Files button. Next, copy pushprinterconnections.exe into the window that opens. Back at the properties of the script, click Add and locate and select the pushprinterconnections.exe file. Then click OK. If you want to enable the logging of troubleshooting information, type –log in the Script Parameters box. A per-user debug log file will be written to %temp% and a per-machine debug log will be written to %windir%\temp (these are totally different directories). It’s worth noting that you shouldn’t use the –log parameter in a production environment—unless you want the utility filling up your client machine hard disks with megabytes of log files.

If you are using Windows Vista™, you’ll see that this utility isn’t required; the ability to push down printer connections is built in. As a result, the first thing that PushPrinterConnections.exe does when you run it is to check if it is running on Windows Vista. If so, the utility simply exits. Network administrators don’t have to worry if Windows Vista clients accidentally ran pushprinterconnections.exe.

At this point, you should see the printers when you log in as the user or restart the computer. Note that these printers won’t change during background refresh after you’re already logged in because the pushprinterconnections.exe utility only runs at login or startup.

There is an alternative to deploying printers by hand using the Group Policy editor: the Print Management Console, which displays printers deployed via GPOs. In Figure 5, you can see each of my printers (HPLaser1 and HPLaser2), the GPOs they’re assigned in, and which side—user or computer—is being forced.

The Print Management Console also has the ability to push printers directly by creating GPOs of its own. Just drill down to Print Management | Custom Printer Filters | All Printers, locate the printer you want to push down to a computer or user, and select Deploy with Group Policy, as shown in Figure 6. The process begins simply enough, as you can see in the Deploy with Group Policy dialog box in Figure 7; however, after that things get difficult.

The interface from there on is almost a throwback to the days before the Group Policy Management Console (GPMC), and we all hated those days. The idea is to click Browse and either find a GPO you happen to know is linked to a Site, Domain, or OU or drill down into an OU and choose to create a new GPO that’s linked to the level to which you drilled. You can see this in Figure 8. The icon being pointed to in the figure is used to create a new GPO and link it.

Once you’ve created and linked the GPO, it’s time to deploy the printer. Here you select which group you want to deploy to: users, computers, or both. Make your choice, then click the Add button, and click OK. Just make sure you don’t miss that Add button. I missed it several times and was driving myself completely nuts!

The important point to remember here is that deploying printers via the Print Management Console doesn’t complete the whole job. While it puts the printer in place in the Deployed Printers node, it doesn’t put the pushprinterconnections.exe app into the Logon Script or Startup Script. This means you have to go back in, via the GPMC, edit the GPO, and put in pushprinterconnections.exe. It can be frustrating, but after you’ve done it a few times it will become part of your routine.

Clearly, this ability to push printers down to either users or computers is a nice leap forward. But, unfortunately this new magic isn’t built on the client-side extension of Group Policy. Rather, this is a little trick to push printers down to users. I’d like to see the ability for users to get a changed GPO and have the printers change on the fly with the background refresh interval. It’s not there yet, but appears to be coming soon with Windows Vista. Just remember when you’re planning to use this technique that Windows 2000 only supports per-user printer connections, while Windows XP and Windows Server 2003 support per-user and per-computer printer connections.

For more on the Print Management Console, see "Print Management Step-by-Step Guide for Windows Server 2003 R2".