It’s Day Ten of our Windows Server 2008 series. Seventeen Days to go. Today we’ll be talking about Client-Side Rendering.
Client-Side Rendering (CSR) is a new feature that allows print jobs to be fully rendered on the client when targeting a shared printer hosted on a Windows Vista or Windows Server 2008 computer acting as a print server. After being rendered on the client, the print job is sent to the print server for queuing and printing by the print spooler without additional server-side rendering. This feature is enabled by default on Windows Vista and Windows Server 2008, however it is not available on earlier versions of Windows.
With CSR enabled, the print job is first spooled as EMF on the client to provide quick return to the application. The client printer driver then converts the spooled EMF data to the Page Description Language (PDL), such as PCL or Postscript, for the printer. The RAW-format PDL data is then sent to the print server for queuing and printing by the print spooler. The RAW data type is device-specific and indicates to the remote Print Spooler that the print job has been rendered by the printer driver. The remote spooler can then send RAW data streams directly to the printer, or it can store them in spool files.
In addition to moving the processing requirements of print-job rendering from the server to the client, improving print server performance and scalability, CSR provides additional advantages such as:
- Elimination of driver mismatches. Because the computer that spooled the print job also rendered the EMF-format data, there are no inconsistencies that may be caused by client / server print driver mismatches.
- Support for Offline Printing. Print jobs targeted at a remote printer may be spooled even if there is no physical connection to the print server that hosts the printer. When the client computer establishes a connection to the print server, the rendered print job is automatically printed.
Client-Side Rendering functionality is implemented in win32spl.dll, which is the network print provider. Offline printing functionality is implemented in printcom.dll which provides the online / offline notifications to win32spl.dll. The client-side rendering components, printcom.dll and win32spl.dll, are both loaded in the Print Spooler service, spoolsv.exe, when it is started.
There are some registry values to consider when dealing with CSR. When a shared network printer connection is created on a Windows Vista or Windows Server 2008 "client", the connection is created in the same registry location, using the same naming convention used in Windows Server 2003: HKEY_CURRENT_USER\Printers\Connections\<connection>. The <connection> subkey in the registry is the name of the print server and printer, in the following format: ,,<servername>,<printersharename>. There are some additional values to be aware of in the <connection> subkey:
- DefaultDevMode: This is the per-user devmode for this connection. The DevMode data structure contains information about the device initialization and environment of a printer
- GuidPrinter: this is a random Globally Unique Identifier (GUID) assigned to the remote printer connection on the client. Each connection to a shared network printer creates a GuidPrinter that is used to identify the printer as a remote printer. Print jobs sent to a GuidPrinter are rendered as if they are being printed to a local printer but are then sent to the print server using the Client Side Port monitor (see below) instead of being written to a local port.
- LocalConnection: This is set to 1 if this is a locally created printer, as opposed to a "pushed" printer.
- Provider: The Print Provider for this printer connection. Typically this will be win32spl.dll
- RemotePrinterCache: This is a binary blob that contains the configuration of the print driver on the server the last time that the client printed to this printer connection
- Server: name of the server hosting the shared printer
When a Windows Vista or Windows Server 2008 client connects to a shared printer, a new subkey, with the name of the print server is created in the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\Servers. For each print server that a client has connected to, a new folder is created in the following folder, with the name of the print server: %systemroot%\System32\spool\SERVERS. This new folder is used on the client to spool the print jobs destined for that print server. The per-server path for the spool folder is specified in the DefaultSpoolDirectory value in the following registry key for each print server that the client has connected to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\Servers\<printservername>\Providers. CSR defines a unique "port monitor" for each shared printer connection on the client computer. Each CSR port is assigned a thread to process the print jobs sent to that port, and the virtual port monitor is used to identify the unique port for thread scheduling purposes.
As mentioned earlier, CSR is enabled by default on Windows Vista and Windows Server 2008 and is controlled by the print server that hosts the shared printer. CSR may be disabled via GPO or on the Sharing tab of the properties for specific printers on the print server as shown – unchecking the "Render Print Jobs on Client Computers" box turns Client-Side Rendering off for this printer.
Note that if you disable the CSR feature, the print-job rendering will be handled by the printer. This is a reversion to the spooling behavior on Windows Server 2003. Disabling CSR may have adverse effects on the performance of the print server.
To disable CSR via group policy, you would enable the Always render print jobs on the server policy setting in the following Group Policy container:
Computer Configuration\Administrative Templates\Printers
This policy changes the ForceCSREMFDespooling value in the registry to 1 in the HKLM\Software\Policies\Microsoft\Windows NT\Printers registry key. There is one scenario where it may be desirable to offload the rendering policy to the print server – and that would be on a Terminal Server. The Always render print jobs on the server policy setting is enforced regardless of the Render print jobs on the client computers per-driver setting for client-side rendering.
Before wrapping up this post, let’s take a quick look at some issues that may cause a client to revert to Windows Server 2003 type spooling behavior even though Client-Side Rendering is enabled. For example, in a situation where the printer driver uses a custom print processor but that print processor is not installed on the client, then client-side rendering is disabled automatically. In some cases, the print processor of a printer driver that is not configured as a driver package might not be installed on the client computer during Point and Print and client-side rendering will be disabled for that print queue. The recommended practice is to use a driver package for the printer driver to avoid this issue.
There are a couple of other scenarios which may result in CSR being disabled. If the print processor returns an error then client-side rendering for the print queue is disabled. If the printer driver itself has any issues with client-side rendering, then the print spooler will revert to server-side rendering, regardless of policies or settings. If client-side rendering fails, the print spooler retries the print job using server-side rendering. If client-side rendering is disabled for the print queue, the print queue will no longer have any of the client-side rendering benefits such as offline printing. There are no clear indications (events, errors etc.) that Client-Side Rendering is, or is not, being used when it is enabled. One way to check to see if CSR is being used is to check the Datatype for the print job. You can do this by printing a test page or by viewing the properties of the spooled document (on the General tab). For Client-Side Rendering, the Datatype will be RAW. For Server-Side Rendering, the Datatype will be NT EMF x.xxx.
That brings us to the end of this post. Tomorrow we’ll take a look at the WSD Port Monitor. Until next time …