Quick Queue

Managing printers is a task that most systems administrators love to hate. It’s not enough that sysadmins have to install and configure print servers; usually they also must fix paper jams and replace toner.

Now, developments in Microsoft Windows Server 2003 (Release 2) have made managing networked printers easier via group policy. With the increase in notebook computer use and remote workers, most administrators must oversee both networked machines and end users’ own machines that are connected to the company network.

To give end users rights to install printers (only where preapproved and digitally signed drivers are made available) without relying on the information technology department for the manual install of local printers and drivers, BizTech suggests this method for installing the correct drivers in the background when a device is connected for the first time.

Step 1
Making third-party drivers available to Windows

The first task — if you haven’t done so already — is to collect all the driver files for the printers you support and make them accessible on a network share. The driver files (.inf and all other related files) must be dropped in to the root of the network share.

The next step is to try and remove the need for an administrator (or users) to manually install any printer drivers. Most modern printers are plug and play. With Windows XP, it is generally considered better to install the printer driver before connecting the device. (If the driver isn’t available to Windows when the printer is initially connected, Windows sometimes detects an incorrect driver or generic driver, and the printer won’t work.)

To make sure the driver is available to Windows when the user connects to the printer, you can modify the system registry to include the network path where you store drivers. The DevicePath registry key needs to be modified to:

hkey_local_machines\software\
microsoft\windows\currentversion\devicepath

The default value for this key is %system root%\inf, which is where Windows stores built-in drivers. But you can add to this default string. For instance, if you store your drivers on a network share, you can modify the key as shown:

%systemroot%\inf;\\servername\drivers

Use RegEdit to modify the DevicePath key. Don’t forget to include the semicolon separating the two values in the string.

Step 2
Modifying the registry across multiple machines

To modify a registry key across multiple machines, there are various scripted methods that you can deploy using group policy. For simplicity’s sake, you might want to use the free Policy Maker Registry Extension tool from DesktopStandard, a Microsoft subsidiary. To download it, go to www.desktopstandard.com/ PolicyMakerRegistryExtension.aspx.

Install the extension on a system that you use to administer your domain and create a new group policy object called “DevicePath.” In the Group Policy Object Editor under Computer Configuration > Computer Settings, right click Registry and select New > Registry Wizard. Select the computer for which you modified the DevicePath registry key (either a local or remote system) and select Next. Finally, navigate to the DevicePath key and choose Finish (see Screenshot 1).

Screenshot 1

If you fully expand the new setting in the Group Policy Object Editor, you should see that the default action is to update the registry key. The registry extension can also be used to delete, create and replace registry keys — along with some other useful features.

Before you link the policy to an organizational unit, you will need to deploy the Registry Extension Client Side Extension to all machines that will be affected by this policy. This can be achieved using the included MSI package and a group policy object. You’ll find the MSI package for the client side extension located on the machine where you installed the original registry extension:

c:\program files\desktopstandard\policymaker\
client\polregcl.msi

If you don’t already have a network share for distributing software, create one. Next, set up a group policy object to install the Registry Extension CSE, called “Reg Extension,” and edit the policy. Under Computer Configuration > Software Settings, right click Software Installation and select New > Package. Browse to the polregcl msi package on the appropriate network share and select Open. Set the deployment method to Assigned and select OK. You should now see the assigned package in the right-hand pane of the Group Policy Object Editor.

Once you’re happy with the policy settings, link it to the organizational unit where your workstation computer accounts are located (see Screenshot 2). The client extension will install automatically the next time machines affected by the policy boot.

Screenshot 2

Once the Registry Extension CSE has been installed across your systems, the Device­Path group policy can be linked where necessary. You should note that once the registry key has been updated, users must reboot before their systems will detect drivers in the new location.

Step 3
Making drivers available offline

Now that you have updated the DevicePath registry key across all your desktop and notebook systems, you need to ensure that the “drivers” share is always available — even when the notebooks are not connected to the network. Chances are that your users will connect their shiny new printer at home. Again, using group policy, it’s possible to force a share to be available offline.

Most sysadmins will be familiar with the concept of offline files. This is the same concept, but you are forcing the share to be synchronized for offline use on all systems where offline files are enabled — most likely, users’ notebooks.

Edit your DevicePath group policy object. In the Editor, configure the setting “Administratively assigned offline files,” which can be found under Computer Configuration > Administrative Templates > Network > Offline Files. Open the setting and enable it. Click the Show button and add the UNC path to your network share in the top box and then press OK (see Screenshot 3). Assuming offline files synchronization is working on your notebooks, the share should now be available even when the notebook is disconnected from the network — as it is cached locally.

Screenshot 3

Now you can drop driver files into the share on your server, and your users can take their notebooks home and connect plug-and-play printers. The correct driver will be installed without the need for any user interaction.

Are there any restrictions to this method? Yes. Drivers must be digitally signed for a standard user to complete printer installation. If the drivers are not signed, the installation cannot be completed until an administrator logs on. Don’t assume that this method will work for every printer model. Although in theory there is no reason why it shouldn’t work, I recommend you test each printer before making promises to users about hassle-free home installation.

Another restriction is that all the driver files must be dropped into the root of the network share that you create for drivers. This makes it difficult to manage the files. Optionally, you could add a separate UNC path to the DevicePath registry key for each device. That approach also could become difficult to manage. Some devices — especially varieties that can scan, fax and make tea — potentially require software in addition to the driver for full functionality. Consider these alternate methods:

1. Use printui.dll to pre-install drivers for a local printer. This requires that you know in advance if a printer will be connected to a specific machine and that you run a script or batch file with the necessary command lines.

2. Find a way to add the driver files to the %systemroot%\inf path on each machine. This is easy to do if you have a standard image for deploying Windows, but it can be difficult to update and maintain.

Best Practices

Ideally, your IT policy should state which printers the company supports. That will ensure the IT department can effectively maintain the hardware and make it easier to resolve technical difficulties. Approve printers only when the manufacturer provides digitally signed drivers. Also avoid devices where additional software is necessary, especially if it cannot be run under a standard user account.

Finally, ensure that you test everything thoroughly in a preproduction lab before making changes to your live systems. Group policies and registry modifications should always be deployed with caution.