Windows Server 2008 R2 and Windows 7 Printing Enhancements

A mobile workforce generates new challenges

As we move closer to a paperless world, with almost all of our data stored and accessed electronically, it might seem strange to write about new print features in Windows Server 2008 R2 and Windows 7—like I might as well write an article about why the Internet will be a big deal or whether slates will catch on. However, if you ask the person who sits next to the printer in your office whether we’re really printing less, he’ll probably tell you No (as he gasps for clean air in his ozone-swamped work area).

Considering the mobility of today’s workforce and the myriad of devices employees are using, it’s more important than ever that print options keep pace. In addition, users and organizations must enable the necessary features for a smooth and consistent print experience. Server 2008 R2 and Windows 7 offer several features that enhance the overall print experience.


The User Experience

Several client features help make the end-user experience more smooth. Two of the most important improvements, both of which focus on mobile users and accessing desktops from many different locations, include remote printing and default printer selection, which I discuss in detail in the following sections.

Printing to a Windows 7 remote desktop. Printing from a remote session over RDP was always painful with traditional Terminal Services. On each terminal server, you needed to install all the print drivers that the connecting clients might use, so that users’ local printers could be redirected to the remote session and content could be rendered correctly on the terminal server and then sent to the client for printing on the print device. All too often, printer drivers were missing or the wrong version, which resulted in printing not working (at best—or at worse, a small Peruvian rainforest being destroyed as page after page of random characters printed).

Server 2008 addresses this problem with Terminal Services Easy Print. This new driverless printing model leverages the Microsoft XML Paper Specification (XPS) format, which works similarly to PDF files and contains both the data and formatting. With TS Easy Print, when a print operation occurs, rather than the terminal server rendering to a printer-specific format, a generic XPS document is generated. This document is then sent over the RDP connection to the client device, which lets the client device generate the printer-specific rendering using the locally installed driver from the received XPS file. If a user in the remote session looks at printer properties, the RDP connection captures this request and displays the user’s local printer properties, then sends any format options back to the remote session. Therefore, no functionality of the local printer driver formatting is lost even though no actual driver exists on the terminal server.

Although driverless printing was a huge improvement for Terminal Server–based sessions, Windows Vista didn’t include this functionality. With Microsoft’s introduction of Virtual Desktop Infrastructure (VDI), and with remote sessions being increasingly used to connect to virtualized client OSs, having a driverless printing solution to connect to client OSs over RDP is a huge benefit. Windows 7 Enterprise and Windows 7 Ultimate support Remote Desktop Easy Print. (Terminal Services was renamed to Remote Desktop Services—RDS—in Server 2008 R2, hence the name Remote Desktop Easy Print rather than Terminal Services Easy Print.)

The Easy Print functionality no longer relies on the .NET Framework being installed on the client device. Instead, the XPS-to-GDI (printer format) conversion is now performed by the OS directly. With the Easy Print functionality, if you connect to a remote Windows 7 Enterprise or Ultimate OS instance and enable printer redirection, you’ll see the default printer and all the available printers. If you check the Model setting on the default printer, you’ll see that it’s using Remote Desktop Easy Print, as Figure 1 shows. If you select Printing Preferences from the context menu, you’ll see the advanced properties for your local OS. When the advanced properties of a printer are selected, the dialog box to show these properties is actually redirected to the client that has the full driver for the printer, because the advanced properties are driver-specific. A dialog box displays to advise you that the properties have been redirected, as Figure 2 shows. Because Easy Print is a feature of RDP 6.1, Windows Vista SP1 and Windows XP SP3 clients that have Remote Desktop Connection Client 6.1 or later and the .NET Framework installed can take advantage of Easy Print when connecting to a Windows 7 Enterprise or Ultimate OS over RDP.

Figure 1: Viewing printer preferences
Figure 1: Viewing printer preferences

As you can see in Figure 2, even though the driver isn’t available on the remote session, you can still see the advanced settings by transparently launching the properties locally on the client and then passing back to the remote session any selections and formatting changes. The Printing Preferences dialog box usually covers up the redirection notice dialog box—however, I moved it so you can see that it actually launches on top of the remote session window because it runs on your local client OS using your locally installed driver.

Figure 2: Showing printer property redirection with Easy Print
Figure 2: Showing printer property redirection with Easy Print

Determining which printer to use. Easy Print is a fantastic technology for exposing local printers to remote connections without worrying about drivers. The next challenge for our ever-mobile workforce is to determine which printer to use. I take my laptop between several office buildings, as well as to my house. Numerous times, I’ve just hit print from home rather than printing to a specific printer—and subsequently sent a personal document to my work printer by mistake. Then, I’ve had to get up extra early the next day to make sure I retrieved my document before anyone else got to the office. What we need is a default printer selection based on location.

Several corporate solutions exist for this problem, and the sophistication of these solutions has improved greatly in the past few years. Although this section deals with client functionality, we also need to discuss server components because the server capabilities are important when we consider our options.

Initial attempts at automated printer assignment were via logon scripts that checked machine attributes, such as IP addresses, then added specific printers that were maintained through the scripts, which were very cumbersome to manage in large environments. The first real breakthrough came with Windows Server 2003 R2’s introduction of the Print Management Console (PMC). In addition to providing a centralized management point for Windows print servers and automated discovery of printers, the PMC also allowed for deployment of printers using a combination of listing printers in Group Policy Objects (GPOs) and an executable file called PushPrinterConnections.exe. This executable file was added to the user logon or computer startup process, and it checked the GPOs for printers and configured them on the machine. Because GPOs can be linked at the domain, organizational unit (OU), and site levels, the solution provided flexibility in assigning printers. The PushPrinterConnections.exe file was required because there was no Client Side Extension (CSEs) for the printer configuration parts of the GPO.

Server 2008 takes this printer deployment capability to the next level, with CSEs for the PMC printer deployment. CSEs remove the need to use PushPrinterConnections.exe. Setting various GPOs at site levels enables a fluid default printer transition as users move between locations, with the correct default printer configured automatically.

The PMC’s Deployed Printers capability is useful; however, Server 2008’s Group Policy Preferences introduced an even better way to assign printers to users in a flexible way that for many organizations removes the use of Deployed Printers through the PMC. Unlike Group Policies that configure a client setting that can’t be modified, Group Policy Preferences allow machine configurations that can be modified by end users. This capability lets you create an initial configuration that isn’t set in stone. With Group Policy Preferences, we can periodically reimplement preference settings to overwrite any changes a user might have made, or we can set preference settings initially and forget about them, allowing users to do whatever they want.

To use Group Policy Preferences for printers on a user level, open a GPO and navigate to \User Configuration\Preferences\Control Panel Settings\Printers. (You can also configure this setting at a computer level if desired.) To add a new printer, right-click and select New, then select the type of printer. As Figure 3 shows, the type of printer can be shared, TCP/IP, or local.

Figure 3: Using Group Policy Preferences to add a new printer
Figure 3: Using Group Policy Preferences to add a new printer

If you select Shared Printer, you can select a printer from Active Directory (AD—assuming you’re publishing printers in AD, which is easy with the PMC). You can also indicate whether you want the printer to be the default and whether you want it to be the default only if no local printer is present, as Figure 4 shows.

Figure 4: Configuring a shared printer
Figure 4: Configuring a shared printer

Because Group Policy Preferences are part of GPOs, we can link them at site, OU, and domain levels. If we want to deploy based on location, we can link the GPO at the site level; when clients update their policies, they’ll get printers assigned based on their current site. However, we can go a step further with Group Policy Preferences.

The Shared Printer Properties General tab lets you select a shared printer and default printer options. The Common tab, as the name suggests, is common to all Group Policy Preferences configurations but opens a whole other level of targeting through the Group Policy Preferences item-level targeting capabilities. Select a new printer’s Common tab in Group Policy Preferences, then select the Item-level targeting option and click the Targeting button to open a new Targeting Editor that lets you create very granular rules for when this preference is applied, as Figure 5 shows.

Figure 5: Targeting in Group Policy Preferences offers almost infinite possibilities
Figure 5: Targeting in Group Policy Preferences offers almost infinite possibilities

Best of all, this targeting applies to a specific preference setting (i.e., just one printer, not the entire GPO), which lets you define multiple printers in one GPO, each targeted differently. Looking at the targeting criteria in Figure 5, you can see just how flexible printer targeting can be. We can deploy printers based on IP address range, which is essentially the same as AD site but might let us be more specific than using our AD site configurations. We can also set definitions based on group membership, which is a very messy process with normal GPOs. We can target based on the time of day, type of computer, or network connection type—we have a lot of flexibility. If you haven’t yet played with Group Policy Preferences, I suggest that you take a look. If you have a lot of custom scripts, you should be able to use Group Policy Preferences to get rid of most of them.

Setting the default printer within a corporate environment is quite simple with some up-front administrator design and configuration. But what if you connect to multiple personal networks, or if users want to manage their own default printers based on different locations? Windows 7 introduces a new feature, called location-aware printing, that takes advantage of the network location awareness services introduced in Server 2008 and Vista. Based on various network characteristics (e.g., wireless networks, availability of domain controllers—DCs), we can identify the various networks that can be used for Group Policy application, firewall settings, and more in Server 2008 and Vista. In Windows 7, we can use the same identified networks to set different default printers, through location-aware printing.

Configuring location-aware printing is very simple. Select Devices and Printers from the Start menu, then click the Manage default printers action to open the dialog box that Figure 6 shows. You can then select the option to always use the same default printer, which essentially disables location-aware printing, or you can select the option to change the default printer, in which case you can set a default printer for each known network. When you connect to a new unknown network, the current default printer is automatically set as the default for that network. You can change this setting, however.

Figure 6: Setting default printers for multiple networks
Figure 6: Setting default printers for multiple networks

If you’re connected to multiple networks at the same time (e.g., wired and wireless), then the default printer for a wired connection to a managed network takes precedence over a wireless network that a user saved. Furthermore, a saved wireless network takes precedence over an unmanaged wired network. If you can’t seem to find the Manage default printers action on your desktop or server, that’s because it’s available only on mobile computers (i.e., laptops) running Windows 7 Home Premium or better but not on any Windows Server editions.


The Administrator Experience

Because printing is a user-initiated process, it shouldn’t surprise you that two of coolest Windows 7 printing features (i.e., Easy Print and the Group Policy Preferences location-aware printing) are so user centric. Server 2008 R2 and Windows 7 also offer administration improvements from a management perspective, as well as performance and reliability enhancements that reduce the amount of support necessary from the IT team.

The most obvious change in Server 2008 R2 regarding print services is that printing is now part of the Print and Document Services role. Within this role, the new Distributed Scan Server role service enables centralized management and monitoring of Web Services on Devices (WSD)–enabled network scanners in the same way that printers can be managed by print services. This article focuses on printing rather than scanning, so I’ll leave the Distributed Scan Server capability for future discussion. However, the Distributed Scan Server role will definitely help if you have a lot of scanners in your environment.

Printer driver isolation. I think the biggest performance and supportability change in Server 2008 R2 for printing is the new printer driver isolation capability, which is also known as sandboxing. Prior to Server 2008 R2, the print driver components were loaded in the same process as the print spooler. It was common for print drivers to fail, which would then cause the entire print spooler to fail, thereby shutting down the entire print service for all users and printers on the server. Printer driver isolation allows the print driver components to run in a separate process from the actual print spooler, which means a faulty print driver no longer brings down the spooler and affects every other printer on the system. We can go one step further by configuring particular print drivers to run in their own isolated process, which is great if we have new or known buggy drivers. These drivers, if running in their own process, can stop their own printers from working—but not other printers.

Figure 7: Configuring the isolation for a print driver
Figure 7: Configuring the isolation for a print driver

You configure printer driver isolation on the driver rather than the printer. Start the PMC, navigate to the Print Servers – – Drivers node, right-click the driver, and set the desired isolation, as Figure 7 shows. You can set isolation to one of several values, including:

  • None—Loads the print driver components into the print spooler process, which emulates pre–Server 2008 R2 behavior.
  • Shared—Loads multiple drivers into one process, which protects the spooler from the drivers. One bad driver in the shared process will affect all the others. Use the Shared value for known, well-behaving print drivers.
  • Isolated—Loads the driver into its own process space, protecting the spooler and other drivers from a failure of the isolated driver. Use the Isolated value for unknown or problem drivers.

Although printer driver isolation is the main reliability feature in Server 2008 R2 and Windows 7, other performance improvements include spooler changes on both the client and server to speed up logon times and to reduce server-side lag when dealing with notifications. A reduction in the frequency of certain types of print notifications makes the spooler more responsive and performant.

Administration help. The PMC is the first point of contact for print management. Server 2008 R2 and Windows 7 provide two main areas of improvement in the PMC, beyond the UI enhancements, to give more information in the Printers and Drivers view.

The first new piece of functionality is the ability to set default permissions that automatically apply to any new print queue created on the server. This functionality removes the need to manually repeat permission application for every new print queue that you add to a server. To set the default security that you want to apply to new print queues, open the print server’s properties and select the Security tab, as Figure 8 shows. Note that these changes don’t apply to existing print queues.

As Figure 8 shows, you can also assign Manage Printers, Manage Documents, and Manage Server rights to users. Users with these permissions automatically become delegated administrators for the print server. Alternatively, you can give users a subset of permissions—whatever best suits your organization’s requirements.

Figure 8: Setting the default security to apply to new print queues
Figure 8: Setting the default security to apply to new print queues

The other major addition is the ability to create filter views within the PMC based on printer and driver information. This powerful feature lets administrators create multiple views through the PMC’s Custom Filters node to tap into a huge number of printer and driver attributes. Items such as number of jobs in the queue, status, and location can be used to create views that let administrators quickly see information about devices for various groups and locations (e.g., devices in a certain state or above a certain number of items queued). Figure 9 shows filter definition options for both printer and driver filters. You can also see the capability to select multiple fields for each filter, including conditions and values on which each condition will operate.

Figure 9: Driver and printer custom filter options
Figure 9: Driver and printer custom filter options

Trouble-Free Printing

Although it’s easy to dismiss the importance of printing, this function is still critically important to organizations. Server 2008 R2 and Windows 7 provide new features that help print functionality keep up with a mobile workforce, including the variety of ways that users connect to services and access printing. Even as organizations’ printing needs evolve, printing should be a seamless process.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.