Print and Document Services Architecture

Applies To: Windows Server 2012

This article provides an overview of the version 4 (v4) print driver model and the specific types of v4 drivers known as Print Class Drivers and Model Specific Drivers. Windows Server 2012 fully supports both version 3 (v3) and v4 print driver models. In addition, the different printer sharing types supported by Windows Server 2012 is covered.

Printer driver overview

At the core of the Windows Server 2012 printing experience is a new driver model known as the v4 print driver model. The v4 driver model includes changes to printer sharing known as enhanced Point and Print, eliminating the need to install cross platform drivers and eliminating the scenario where a Print Server is a driver distribution point.

V4 printer drivers

The v4 print driver model provides a simple but flexible management experience. V4 print drivers can be distributed via Windows Update or Windows Software Update Services (WSUS), but are not distributed to print clients from the print server.

Some of the benefits of v4 drivers are:

• Printer sharing does not require the installation of device specific drivers that match the client architecture

• Driver files are isolated from each other, preventing driver file name conflicts

• A single driver can support a single device or multiple devices

• Drivers are typically smaller than version 3 drivers, and installation times are faster than comparable version 3 drivers

• Administrators can deploy printer user interface separately from the printer driver

Print Class Drivers

Using the v4 driver model, IHVs can provide Print Class Drivers that support features that are common to a broad set of devices that use the same printer description language, such as PCL, PS, or XPS. The print drivers included with Windows Server 2012 are Print Class Drivers and will always have the text “class driver” in their display name.

Print Class Drivers also provide the following benefits:

• Driver packages are smaller and printer driver files are less likely to cause stability problems

• Administrators have fewer drivers to manage

• Class drivers can support future devices that haven’t been released yet

Model Specific Drivers

You can get model specific v4 drivers directly from the printer manufacturer’s web site or from Windows Update.

V3 printer drivers

Prior to Windows Server 2012, the Windows printer driver model had remained relatively unchanged since the introduction of v3 drivers in Windows 2000. The v3 model relies heavily on OEMs to produce customized drivers for each specific device to ensure that specific features of each print device can be accessed by Windows applications. Managing a printing infrastructure using the v3 driver model requires the administrator to manage a large number of drivers, and to manage drivers on client computers as well as servers, resulting in the requirement to manage both 32-bit and 64-bit print drivers to support both of these client and server architectures.

Changes to the printer driver model

Microsoft works closely with independent hardware vendors (IHVs) to obtain printer drivers for every release of Windows. Windows 7 includes 2100 print drivers with the operating system, and several thousand more printer drivers are available on Windows Update. Each driver is produced by the IHV, and is branded and customized to provide the best experience possible.

Print drivers have historically comprised a large portion of the files included with Windows, even if the user never connects to or uses a printer. In Windows Vista, print drivers accounted for about 1 GB of the total Windows installed files; in Windows 7, this was reduced to 538MB or about 60% of the overall driver files installed for Windows.

Print drivers take up a lot of disk space because the printer drivers in Windows have historically been model specific. Every device is associated with an individual driver and these drivers have no ability to support devices that will be released in the future. Additionally, the drivers that are available for each device lose relevance over time as new devices enter the market. While there may be code sharing between some devices, small variances between devices generally require that every device has its own data files or DLLs in order to precisely describe every attribute of the device.

DLLs are the largest proportion of the driver files. DLLs include not only code for tasks like PDL rendering or customized UI, they also contain the localized strings and image resources that support that UI. Windows configuration files, including GPD (Generic Printer Description) and PPD (PostScript Printer Description) files are the next largest group. These files describe the features and options a printer supports, and in some cases, how to render PDL for the device. The full breakdown is described in the table below.

Reducing driver size

To reduce the size of the operating system image and increase the long term relevance of the drivers that ship with Windows 8, it was necessary to change the paradigm. Many printers consume common formats known as PDLs (Page Description Languages) like PCL, PostScript or XPS. While every device needs to get a PDL it understands, the commonality of PDLs introduces an opportunity to reduce the number of drivers overall. Instead of focusing on providing model specific drivers that provide every feature available on the device, printer drivers in Windows 8 focus on providing print class drivers that support only features that are common to a broad set of devices that use the same PDL. By doing this, much of the code needed to support existing devices can be eliminated, while at the same time providing a baseline for new printers to target. New printers can specify support for a print class driver using an identifier known as a Compatible ID. The net result is fewer, smaller drivers targeting more devices, and fewer problems for Windows users.

The result is shown in the following diagrams. Whereas the v3 print drivers included in Windows 7 could provide customization (blue boxes) in most layers of the driver model, print class drivers are intentionally limited to providing only critical code—PDL rendering. Windows provides the rest of the functionality using common modules and data files provided by the hardware vendor.

Figure 1: v3 Print Driver Model with GDI Rendering

Figure 2: Print Class Driver (v4) Model

Driver isolation

First introduced in Windows 7 and Windows Server 2008 R2, the Windows Printing Driver Isolation feature removed an isolated driver from the print spooler process and loaded it into what is known as a shared sandbox with other isolated drivers, or a completely isolated sandbox to run completely isolated from the print spooler and any other drivers. If an isolated driver would experience a fault or otherwise unexpectedly terminate or crash, this condition would not affect the print spooler process and the other printers and drivers that were loaded. All drivers written for Windows 7 were required to support driver isolation, however drivers released prior to Windows 7 did not have a driver isolation attribute attached to them.

As was the case with Windows 7 and Windows Server 2008 R2, drivers are isolated in Windows Server 2012 in the following scenarios:

• The driver INF has the keyword DriverIsolation that indicates it supports driver isolation.

  DriverIsolation=2 indicates that the driver supports driver isolation. Setting DriverIsolation=0 indicates that the driver does not support driver isolation.

• The administrator specifically enables driver isolation for a particular driver

  This can be done using the Print Management console. Expand Print Servers, expand your print server name, select Drivers, right-click the driver name and select Set Driver Isolation.

  The administrator can configure the driver to use one of the following settings:

  • Shared

    Run the driver in a process that is shared with other printer drivers but is separate from the spooler process.

  • Isolated

    Run the driver in a process that is separate from the spooler process and is not shared with other printer drivers.

  • None

    Run the driver in the spooler process.

• The administrator specifically enables a group policy that controls the driver isolation behavior.

  The group policy name is: Computer Configuration\Policies\Administrative Templates\Printers\Override print driver execution compatibility setting reported by print driver and it works as follows:

  • If the policy setting is enabled, the print spooler isolates all print drivers that do not explicitly opt out of Driver Isolation.

  • If the policy setting is disabled or not configured, the print spooler uses the Driver Isolation setting indicated by the DriverIsolation keyword in the INF file.

By default, if the INF file that installs a printer driver does not indicate that the driver supports driver isolation, the printer class installer configures the driver to run in the spooler process. However, if the INF file indicates that the driver supports driver isolation, the installer configures the driver to run in an isolated process. An administrator can override these configuration settings and specify, for each driver, whether to run the driver in the spooler process or in an isolated process.

Ideally, a printer driver is able to run in shared mode. That is, it runs in an isolated process shared with other printer drivers but separate from the spooler process. A driver might need to run in isolated mode if it can run in a process separate from the spooler process, but has difficulty sharing the process with other drivers. For example, a poorly designed driver might have file names that conflict with those of related drivers or of different versions of the same driver, or the driver might fault frequently or have a memory leak that interferes with the operation of other drivers that run in the same process.

To support troubleshooting, the domain administrator can disable the driver isolation feature on a computer in the domain, or the administrator can force all of the printer drivers on the computer to run in isolated mode. In isolated mode, each driver must run in a process separate from the spooler and from the other printer drivers.

If driver isolation is disabled by group policy, the isolation is off for all printer drivers. The group policy name is Computer Configuration\Policies\Administrative Templates\Printers\Execute print drivers in isolation.

• If you enable or do not configure this policy setting, the print spooler runs print drivers in an isolated process by default.

• If you disable this policy setting, the print spooler runs print drivers in the print spooler process.

The following chart shows a decision map for choosing the driver isolation mode:

Application isolation

Application isolation isolates an application from a print driver so that if a print driver crashes, the application does not crash. This feature extends an existing Windows 7 feature (SplWoW64) to cover all printing scenarios in Windows Server 2012 and Windows 8. Applications that support isolation are more stable because the application is separated from the print driver by using a “process isolation” layer. All of the driver DLLs are loaded and hosted in a separate process, isolating the application from print driver crashes

Splwow64 is a 64-bit process that hosts print drivers on behalf of the 32-bit applications. These applications are able to call standard printing functions and act without any knowledge of Splwow64. Behind the scenes, the calls are thunked back and forth between the client application and Splwow64.  A side effect of this solution is that these applications are isolated from print driver crashes.

In Windows Server 2012 and Windows 8, with the group policy enabled, Splwow64 hosts the driver DLLs for all applications that support this feature.

Application isolation is controlled by the following Group Policy setting:

Computer Configuration/Administrative Templates/Printers/Isolate print drivers from applications

The Isolate print drivers from applications setting has the following description:

Determines if print driver components are isolated from applications instead of normally loading them into applications. Isolating print drivers greatly reduces the risk of a print driver failure causing an application crash.

Not all applications support driver isolation. By default, Microsoft Excel 2007, Excel 2010, Word 2007, Word 2010 and certain other applications are configured to support it. Other applications may also be capable of isolating print drivers, depending on whether they are configured for it.

If you enable or do not configure this policy setting, then applications that are configured to support driver isolation will be isolated.

If you disable this policy setting, then print drivers will be loaded within all associated application processes.

V4 driver model design and architecture

The past 10 years have seen the evolution of the v3 driver model from generic printer description (GPD)/PostScript printer description (PPD)-only configuration and rendering to XPSDrv, auto-configuration, and full UI replacement. These changes supported the demands of customers and partners, but also added complexity and management overhead. The following are some, but not all of the difficulties associated with the v3 driver model:

• Printer drivers are a top cause of crashes and hangs in Microsoft Office.

• Administrators spend a lot of time managing print driver updates and consolidating print queues, and end users struggle with cross-architecture drivers.

To help mitigate these issues, many partners have tried universal or class drivers, but the v3 driver model falls short in a number of key scenarios that would enable partner success.

The v4 printer driver model improves the quality of the device experience for all users by mitigating known issues in the v3 driver model and developing easier-to-implement extensibility points. While v4 print drivers continue to use GPDs, PPDs, Bidi, and Generic Descriptor Language (GDL)-based autoconfiguration, some of the layers available in the past have been removed or replaced.

One new aspect of the v4 print driver model is a focus on providing print class drivers. These special v4 print drivers, which implement only functionality that is common across a broad class of devices, are shipped with Windows and are marked as generic. As a result, Windows can automatically replace the driver with a better option from Windows Update, providing the end user with a better experience as soon as it is available.

V4 driver design

The following were design considerations for the new v4 model:

• Windows Store Apps

  The new Windows experience and the new Windows Store app models introduce new design considerations regarding UI behavior and security context. V4 print drivers are very important in the Windows user interface with deep integration, seamless behavior, and rich extensibility.

• Windows on ARM

  Running Windows on an ARM processor changes the paradigm with regard to power utilization and driver behaviors. The v4 print driver model supports printers on ARM with print class drivers while still allowing rich end user experiences thanks to a decoupled UI development model. There is no v3 driver support for Windows on ARM.

• Ease of Driver Development

  The v4 driver model supports existing investments in v3 and the XPSDrv architectures, while making drivers easier to develop and test. The v4 driver model supports driver development using Visual Studio, and supports a number of templates that make drivers easier to build. V4 print drivers also include support for building customized UI as a simple Windows application, enabling developers to use the most up-to-date frameworks and toolsets to keep their experiences fresh.

• Printer Sharing

  Printer sharing is a major value proposition of Windows print servers, and v4 print drivers are designed to make printer sharing even better. In particular, they reduce management costs, eliminate cross-architecture driver management, and support all client operating systems from Windows Vista to Windows 8.

  Note

  Operating systems prior to Windows 8 do not support the v4 driver model but can print to a v4 queue shared from a Windows Server 2012 print server by using the enhanced Point and Print Compatibility Driver which is hosted by any print server running Windows Server 2012.

V4 driver architecture

The following is a high-level representation of a v4 print driver. With the exception of the rendering filters and user interface applications, all code is Microsoft provided. V4 print drivers rely heavily on data files and JavaScript for extensibility. The blue boxes represent existing files that were used in the v3 driver model, and the green boxes represent new places to plug in.

Figure 3: v4 Driver Architecture

Rendering

The v4 driver model uses only the XPSDrv architecture in order to support rendering into device PDL. XPS direct devices do not need any filters, but all others must either include filters that render into the device PDL or take a dependency on an existing print class driver using the RequiredClass directive in the v4 manifest file.

Figure 4: Rendering Architecture

Configuration Layer

The v4 driver model supports a greatly simplified configuration layer. Unlike v3 print drivers where the user interface was strongly coupled to the configuration, v4 print drivers focus on providing PrintTicket, PrintCapabilities, and constraint functionality. A common configuration module, PrintConfig.dll, encapsulates the functionality that was previously available in the UnidrvUI and PS5UI core drivers.

The v4 driver model does not employ configuration plug-ins, so most of the device configuration are expressed in GPD or PPD files. In addition, v4 print drivers may provide a JavaScript file that supports advanced constraint handling as well as PrintTicket and PrintCapabilities support.

The Generic Printer Description (GPD) and PostScript Printer Description (PPD) file formats are unchanged with v4 print drivers. Existing GPD and PPD files are compatible.

Customized User Interfaces

V4 print drivers support customized user interfaces in both the Windows desktop and in the new Windows user interface. Due to the very different nature of these experiences, these UIs must be implemented as two different applications.

Printer extensions support v4 print drivers in the desktop and work with all existing applications. They also work in printer sharing scenarios with the enhanced Point and Print driver. Support is planned for all operating systems from Windows Vista through Windows 8.

Windows Store device apps support v4 print drivers in the new Windows user interface.

Printer sharing overview

The printer sharing implementation in Windows 8 was updated to meet the demands of modern users and to support the new v4 driver model being introduced in Windows 8.

The prior model relied on both the server and the client computers using identical drivers; given the different supported architectures for Windows (x86, x64, and SoC systems) getting the right matching driver can be a difficult proposition. Incompatibilities between driver versions can cause client connection errors, and establishing connections can take a significant amount of time.

The overall goal of both the new v4 driver model and the sharing implementation that supports it is to make the end-user and administrative experience as easy as possible.

There are several features that define the changes that were made to printer sharing in Windows 8. These can be summarized as the following:

• Clients can use enhanced Point and Print to generate print jobs that the server can use without using a device specific driver.

• Servers can encapsulate the configuration and capabilities of the printer and communicate that data to a client computer in a way that the client computers can use without needing a device specific driver.

• The print server is no longer a software distribution mechanism. Previous versions of Windows provided a mechanism by which print clients could obtain a driver from the print server. For reasons of security, compatibility, serviceability, and reliability, this functionality has been removed from the v4 driver model and enhanced Point and Print. Downlevel client computers will still be able to receive the enhanced Point and Print Compatibility driver from Windows Server 2012 servers to enable compatibility with v4 print shares. Client computers running Windows 8 have enhanced Point and Print support built into the operating system, and they can use standard point and print mechanisms to obtain matching v3 drivers if the administrator wants to continue using older drivers. Device specific v4 drivers can also be deployed to Windows 8clients, or downloaded from Windows Update/WSUS in order to provide additional features or capabilities, such as client side rendering when connecting to enhanced Point and Print shares.

Architecture

There are three major changes to the sharing implementation in Windows Server 2012:

1. Enhanced Point and Print Compatibility Driver

   Windows Server 2012 servers provide the Microsoft enhanced Point and Print compatibility driver to clients running previous versions of Windows, and these clients can use the driver without the need for any updates or modifications to the client printing subsystem.

2. Disabling Driver Distribution from the Server

   Windows Server 2012 servers will not provide v4 drivers to clients (with the exception of the previously mentioned enhanced Point and Print compatibility driver). Clients running a previous version of Windows will still be able to connect to v4 print shares without issue. Servers running Windows Server 2012 using v3 drivers will behave the same way that Windows Server 2008 R2 behaves. No changes have been made to v3 printer sharing in Windows Server 2012.

3. Enhanced Point and Print

   Windows 8 clients must be able to connect to Windows Server 2012 servers sharing v4 queues. This involves the ability to procure and install a compatible driver, the ability to synchronize configuration settings with those on the server, and the ability to print to a printer shared with a v4 driver.

The changes to the spooler necessary to implement these new sharing features were made on both the client side and the server side, and the following sections separate the changes accordingly.

Server Changes

The following are the changes made to Windows Server 2012 for Printer Sharing and Setup.

• Compatibility Driver

  To support driver sharing to operating systems prior to Windows 8, the Microsoft enhanced Point and Print compatibility driver is provided with the operating system. The Microsoft enhanced Point and Print compatibility driver is a v3 driver that interfaces with Windows Server 2012 print queues that are shared using v4 drivers, and emits XPS as its PDL. The Microsoft enhanced Point and Print compatibility driver is compatible with Windows 7 and Windows Vista; Windows versions prior to Windows Vista are unsupported and blocked (the server does not attempt to block clients based on version, but the Microsoft enhanced Point and Print compatibility driver determines whether it is compatible with the client during installation.)

  By default, when a client using a previous version of Windows queries the driver (via GetPrinterDriver API) used by a printer shared with a v4 driver, it will appear as the Microsoft enhanced Point and Print compatibility driver for the processor architecture of the client, regardless of what the actual driver in use by the server queue is. As a result, when a connection is made the Microsoft enhanced Point and Print compatibility driver is downloaded from the server and installed on the client.

  The v3 model remains unchanged in Windows Server 2012 and sharing and setup of a print queue using a v3 driver remains unchanged regardless if the client is Windows 8 or a previous version of Windows.

• Disabling Driver Distribution

  As described previously, the Microsoft enhanced Point and Print compatibility driver is provided to clients running a previous version of Windows to enable printing to a queue shared with a v4 driver.

  There is no actual API used by existing clients to retrieve driver binaries from the server. Existing servers make driver files available under the \\server\print$ share, and the information about what driver is in use for a queue and what files are needed is retrieved by clients through the GetPrinterDriverEx API. Existing Windows clients call GetPrinterDriverEx for the remote printer to get details about the remote driver, and then simply use filesystem APIs to copy the files from the server share to the client over SMB.

  Instead of disabling the print$ share since it is still necessary for distributing the Microsoft enhanced Point and Print compatibility driver to downlevel clients, GetPrinterDriverEx does not provide the driver information so that clients will be unable to use the returned information to find drivers under print$, and are forced to try other methods of procuring drivers.

• Enhanced Point and Print

  Complementing the v4 driver model are changes to the printer sharing model. The updated printer sharing mechanism is referred to as enhanced Point and Print, and it allows print clients to print to v4 shares without downloading the manufacturer-provided device driver from the print server.

  When a computer running Windows 8 connects to a shared print queue on the server, it checks locally for a v4 print driver that has a HardwareID that is the same as the PrinterDriverID defined in the server's print driver. It may also check Windows Update at connection time or later for a matching driver on Windows Update. If it finds a match, the client downloads that driver and connects using client-side rendering (CSR). If the driver includes a customized UI, then that UI will be shown to the user.

  Otherwise, the client connects using the enhanced Point and Print driver. If the client does not have this driver already, it downloads it from the server. At this point, the client downloads configuration data files from the server and associates them with the client print queue. When the user prints, they are provided with a localized, Microsoft standard UI, unless the user acquires a printer extension or a Windows Store device app is automatically downloaded. The print job will be rendered on the client into XPS and include the user's settings as a PrintTicket. This is then sent to the server and rendered into PDL using the server's print driver.

  

  Figure 5: Enhanced Point and Print Diagram

Client Changes

The following are the changes made to Windows 8 clients for Printer Sharing and Setup.

• Driver Acquisition and Update Changes

  To achieve the goal of disabling driver distribution from Windows Server 2012 print servers, and in order to provide an optimal v4 driver experience, Windows 8 clients cannot use legacy v3 Point and Print Mechanisms to obtain a driver. Instead a new Point and Print mechanism has been implemented, leveraging Plug and Play for both the acquisition and installation of compatible print drivers, as well as the servicing/updating of these drivers.

  Note

  For more information on how to configure Windows Server Update Services (WSUS) to offer print drivers to clients, see Windows Server Update Services Overview.

For more technical details about printer sharing, see Printer Sharing Technical Details.

Appendix A: Terms and Definitions

The following table defines commonly used terms for Print and Document Services.