Printer Sharing Technical Details
Applies To: Windows Server 2012
This topic focuses on the various printer sharing technologies supported in Windows 8. It provides a quick overview of the various technologies, and why they might be used in certain scenarios.
There are a number of other features in Windows 8 that can be used to help augment or improve the printer sharing features in Windows 8. These features often provide more flexibility to IT administrators, or allow the user experience for printer sharing to be more tailored to a given environment.
Finally, this topic covers deployment scenarios for the various printer sharing features and technologies supported in Windows 8. This section is designed to allow IT administrators to start working with print servers quickly without needing to cross reference a number of other sources for basic print server functions.
Types of printer sharing in Windows Server 2012
Windows Server 2012 supports a number of different sharing mechanisms that enable deployment of print shares to meet various user and business needs. These include Enhanced Point and Print, Package Aware Point and Print, Legacy Point and Print, and Internet Print Protocol (IPP). In most cases, the administrator is not in direct control over the type of sharing that can be used; they are only able to “share” the printer. The drivers installed on the server, the client operating system version, and the connectivity mechanism dictates what type of sharing is available.
The following table shows which printer sharing technology is available based on operating system and driver versions being used from the print server side.
V4 printer driver |
V3 Package Aware printer driver |
V3 Legacy printer driver |
|
Windows 8/Windows Server 2012 |
Enhanced Point and Print |
Package Aware Point and Print |
Legacy Point and Print |
Windows 7/Windows Server 2008 R2 |
N/A |
Package Aware Point and Print |
Legacy Point and Print |
Windows Vista/Windows Server 2008 |
N/A |
Package Aware Point and Print |
Legacy Point and Print |
Windows XP/Windows Server 2003 |
N/A |
Legacy Point and Print |
Legacy Point and Print |
The client operating system is also a factor, and can impact the type of connection used beyond what the server makes available. This table shows which mechanism a client attempts to use when connecting to a specific type of print share.
Enhanced Point and Print on server |
Package Aware Point and Print on server |
Legacy Point and Print on server |
|
Windows 8/Windows Server 2012 |
Enhanced Point and Print |
Package Aware Point and Print |
Legacy Point and Print |
Windows 7/Windows Server 2008 R2 |
Enhanced Point and Print |
Package Aware Point and Print |
Legacy Point and Print |
Windows Vista/Windows Server 2008 |
Enhanced Point and Print |
Package Aware Point and Print |
Legacy Point and Print |
Windows XP/Windows Server 2003 |
n/a |
Legacy Point and Print |
Legacy Point and Print |
When the server has IPP sharing enabled, all print shares will automatically be available through IPP. When a Point and Print connection is possible, all Windows clients will create a Point and Print connection even if the user is attempting to create an IPP connection. Since IPP connections can be manually configured so that clients and servers can communicate even while using different drivers, any client can theoretically connect to any server using any driver capable of being installed on the client. It is important that the drivers are similar enough, so the server driver can accept and route the output of the client driver to the device. There is no programmatic way to test for driver compatibility in IPP scenarios.
Enhanced Point and Print
New to Windows 8/Windows Server 2012, enhanced Point and Print allows a server running Windows 8/Windows Server 2012 to share a printer with any other supported Windows client without the use of additional drivers. This feature is only available when the print server is using a v4 print driver for the print share.
Enhanced Point and Print enables v4 drivers to be used in Point and Print scenarios where client computers may not have any access or ability to use the same driver that is available on the print server. This is accomplished by using an enhanced Point and Print driver on Windows 8 and previous operating systems that can access the configuration of the printer from the print server and mimic the printer’s capabilities without using any device specific code. Only Windows 8 and Windows Server 2012 print servers are capable of creating enhanced Point and Print shares, but any Windows client is capable of connecting to them.
A v4 driver can expose features that require user interface to configure. For standard features supported in the operating system, all of these features should be accessible to all client computers through standard user interface provided as part of that operating system’s basic printer extension. For non-standard features, custom user interface must be provided by the Independent Hardware Vendor (IHV), and installed so the user can access those options. This user interface can be packaged in a Windows Store device app for use in the new Windows user interface print workflows, or as a Printer Extension when the user is printing through a desktop workflow. Printer Extensions can be bundled in a v4 print driver, or installed as a standalone application. All Windows Store device apps must be installed from the Windows App Store, or distributed through enterprise tools designed to deliver Windows Store apps.
The following is a high level diagram of enhanced Point and Print scenarios. The black arrows indicate the required Point and Print data flow to enable connections. The tan arrows show data flow for optional extensions that can extend or improve the printing experience. Since printer extensions are simply Windows applications, they can be installed from media or deployed just like any other application. The print server can also provide an URL that will be shown to users as part of the printer properties. The intension of this link is to provide a simple mechanism for print administrators to direct their users to Printer Extensions for their print share.
.jpeg)
Figure 1: Overview of enhanced Point and Print data flows in Windows 8 printer sharing
Supported Servers
Windows 8/Windows Server 2012 (all versions including x86 and x64 architectures)
Supported Clients
Windows 8/Windows Server 2012(All)
Windows Server 2008 R2 (All)
Windows 7 (All)
Windows Server 2008 (All)
Windows Vista (All)
Advantages
Only mechanism to share printers using v4 print drivers on the server
Only mechanism to directly share a printer with an ARM architecture Windows client
Simple driver management
Enables basic printer sharing without any additional steps
Integrates with Windows Store apps printing workflows on Windows 8 clients
The print server no longer distributes device specific drivers to clients
Windows 8 clients have an inbox Enhanced Point and Print driver to support connections
Limitations
Not available while using v3 print drivers
Requires distribution of Printer Extensions to access advanced features of the printer
Server Side Rendering is forced on all downlevel clients
Windows 8/Windows Server 2012 still requires access to a matching v4 print driver to enable Client Side Rendering
Driver distribution for Windows 8/Windows Server 2012 clients handled through Windows Update/Windows Server Update Services (WSUS)
Package Aware Point and Print
Package Aware Point and Print was introduced in Windows Vista to enable print servers to distribute signed driver packages to client machines. This improves security, and eliminates the need for security prompts that are necessary in legacy Point and Print support. This feature is only enabled on Vista and later print servers when a Package Aware print driver is used for the print share. This feature will automatically downgrade to legacy point and print when downlevel clients connect to the share (Windows 2000, Windows XP, Windows Server 2003) or when non-Package Aware drivers are in use.
Supported Servers
Windows 8/Windows Server 2012 (All versions, x86 and x64 architectures only)
Windows Server 2008 R2 (All)
Windows 7 (All)
Windows Server 2008 (All)
Windows Vista (All)
Supported Clients
Windows 8/Windows Server 2012 (All versions, x86 and x64 architectures only)
Windows Server 2008 R2 (All)
Windows 7 (All)
Windows Server 2008 (All)
Windows Vista (All)
Windows Server 2003 (All in legacy Point and Print mode)
Windows XP (All in legacy Point and Print mode)
Advantages
Allows print servers to distribute full driver packages to Package Aware clients
Client Side Rendering is an option on all connected clients
All user interface and rendering capabilities are part of the v3 driver payload
Limitations
Print server administrator must stage print drivers on the server for all supported architectures
When used in a Windows Store app print workflow, users are forced into a desktop experience when custom user interface is required
Print server acts as a distribution point for v3 print drivers
Does not support v4 print drivers
Does not support ARM clients
Legacy Point and Print
Point and Print as it works today was introduced in Windows 2000, and remains largely unchanged. It is now referred to as Legacy Point and Print to differentiate the basic functionality from later extensions like Package Aware Point and Print and enhanced Point and Print. In Legacy Point and Print, the server’s spooler provides the client with just enough information to copy down the required v3 printer driver files from the server, and what settings to use. Since the driver is not kept intact, there is no way for a client to validate that the driver has not been altered. Architecture specific drivers must be installed on the print server to support clients with different architectures.
Supported Servers
Windows 8/Windows Server 2012 (All versions, x86 and x64 architectures)
Windows Server 2008 R2 (All)
Windows 7 (All)
Windows Server 2008 (All)
Windows Vista (All)
Windows Server 2003 (All)
Windows XP (All)
Supported Clients
Windows 8/Windows Server 2012 (All versions, x86 and x64 architectures)
Windows Server 2008 R2 (All)
Windows 7 (All)
Windows Server 2008 (All)
Windows Vista (All)
Windows Server 2003 (All)
Windows XP (All)
Advantages
Does not require any special print driver or operating system support
Limitations
Print server administrator must stage print drivers on the server for all supported architectures
When used in a Windows Store app print workflow, users are forced into a desktop experience when custom user interface is required
Print server acts as a distribution point for v3 print drivers
Does not support v4 print drivers
Does not support ARM clients directly (ARM clients may be able to connect to the printer directly if it is a network attached device)
Internet Print Protocol (IPP)
This mechanism for printing over HTTP was introduced in Windows 2000, and has largely been unchanged. Print Servers that have IPP enabled will automatically make a shared printer available through the relevant Point and Print sharing mechanism, as well as IPP. Windows also exposes additional functionality to enhance the usefulness of Windows IPP print servers. Print servers will publish a webpage that lists available IPP shares, and Windows clients connecting to those shares can download available v3 drivers directly from the print server. This is additional functionality that is not a part of the IPP 1.0 standard supported by Windows. Enhanced Point and Print shares will not be published to the print server’s webpage in a way that allows the client to download the driver and automatically connect to the IPP share.
Windows clients can install IPP print shares from that webpage if the proper drivers have been staged onto the print server. In the case where proper drivers are not available on the server, or when a v4 print driver is being used, clients can still create an IPP connection by building the connection manually in the Add Printer Wizard (APW). When possible, clients will connect over Point and Print instead of IPP even when an IPP connection is attempted.
Point and Print in all of its variations is preferred by Windows over IPP. IPP is primarily used to solve one of two problems:
Allows non-Windows clients to connect to the print share
Allows communication over HTTP (Point and Print relies on RPC which may not be available in some network configurations)
Supported Servers
Windows 8/Windows Server 2012 (Server versions with Print Role and IPP enabled)
Windows Server 2008 R2 (All versions with Print Role and IPP enabled)
Windows Server 2008 (All versions with Print Role and IPP enabled)
Windows Server 2003 (All versions with Print Role and IPP enabled)
Supported Clients
Windows 8/Windows Server 2012 (All versions, ARM not supported through server page)
Windows Server 2008 R2 (All)
Windows 7 (All)
Windows Server 2008 (All)
Windows Vista (All)
Windows Server 2003 (All)
Windows XP (All)
Advantages
Allows access to printers over HTTP
Allows non-Windows clients to connect to a print share
Limitations
Driver used on client must be compatible with driver used on server
May be subject to v3 or v4 limitations depending on the client driver used to connect to the print share
Print server acts as a distribution point for v3 print drivers
Does not support v4 print drivers through the server page
Technologies to Augment Printer Sharing
Branch Office Direct Printing
New to Windows Server 2012, Branch Office Direct Printing is an extension to existing printer sharing technologies. Standard mechanisms are still used to create and maintain a Point and Print connection (enhanced, Package Aware and legacy Point and Print are supported). Once the connection is established, client computers submit print jobs directly to the print device instead of submitting print jobs to the print server.
The goal of Branch Office Direct Printing is to help support network topologies where the print device and client computer are on the same local network, but the print server is separated by a slow or intermittent network connection. Once a client computer has established a Point and Print connection to the server, it is capable of printing directly to the device even if contact to the print server is lost. The print job is not uploaded to the server through a slow/intermittent connection, only to have it resent across the same network connection back to the device. This significantly reduces network traffic, and improves the resiliency of centralized print servers managing geographically separate branch offices.
If Branch Office Direct Printing is enabled, it overrides the default Server Side Rendering (SSR) mode for systems like laptops and tablets. Typically, these portable systems running Windows 8 force SSR to conserve battery power while printing. When Branch Office Direct Printing is enabled on a queue, it is assumed that bandwidth is more valuable than extended battery life, and the portable client computers will switch to Client Side Rendering (CSR) to take advantage of the Branch Office Direct Printing feature. Connections using enhanced Point and Print must be using the device specific v4 driver, which enables CSR, to work with Branch Office Direct Printing environments. Connections using the enhanced Point and Print driver (SSR only) will always fall back to printing through the print server.
For more information about Branch Office Direct Printing, see Branch Office Direct Printing Overview, and Branch Office Direct Printing Technical Details.
WSD Secure Printing
New in Windows Server 2012, print servers have the option to connect to Web Services for Devices (WSD) devices securely without additional network technologies like IPsec. The print device must support WSD Secure Printing, and a domain is required to manage permissions. The Active Directory for the Domain acts as a trust arbitrator between the print server and the print device. While WSD Secure Print does not directly impact sharing, it does allow for print servers to create a private secure channel to the device on the network. This prevents Man in the Middle attacks from intercepting the print job, and prevents snooping of the printed content on the network between the print server and the print device. This feature has no impact on client connections to the print server.
Supported Servers
- Windows Server 2012 (All versions)
Supported Clients
- N/A
Advantages
Enables secure network communication between print servers and print devices
Provides a mechanism to ensure the identity of the network resources involved (print server and print device)
Limitations
Only available on servers running Windows Server 2012
Only available with devices that support WSD Secure Printing
Requires a Domain (Active Directory) to work
AD Printer Publishing
Introduced in Windows 2000, AD printer publishing allows servers joined to a domain to publish available print shares into an AD print directory. This directory is accessible to other client computers in the domain, and they can easily discover published printers through various operating system entry points.
Supported Servers
Windows Server 2012 and Windows 8 (All versions that support domains)
Windows Server 2008 R2 (All)
Windows 7 (All versions that support domains)
Windows Server 2008 (All)
Windows Vista (All versions that support domains)
Windows Server 2003 (All)
Windows XP (All versions that support domains)
Supported Clients
Windows Server 2012 and Windows 8 (All versions that support domains)
Windows Server 2008 R2 (All)
Windows 7 (All versions that support domains)
Windows Server 2008 (All)
Windows Vista (All versions that support domains)
Windows Server 2003 (All)
Windows XP (All versions that support domains)
Advantages
Allows easy discovery of printers in a domain environment, and is not subject to subnet limitations like network attached printers
Provides IT administrators a central directory to manage all approved printers
Limitations
Client computers must be part of the domain to read the directory
Client computers must still be able to create Point and Print connections to the print server to leverage the published printer
Push Printer Connections
Introduced in Windows 2000, Push Printer Connections allow an IT administrator to create printer connections on client computers in a domain through Group Policy. Pushed printer connections are added to systems in the domain when the user logs in or when the system restarts depending on the specific deployment script used. These connections are not removable by the user, and provide IT administrators an easy way to provide printer access without requiring users to create their own connections manually.
Supported Servers
- See Point and Print sections for viable server list; any Point and Print connection can be pushed
Supported Clients
Windows Server 2012 and Windows 8 (All versions that support domains)
Windows Server 2008 R2 (All)
Windows 7 (All versions that support domains)
Windows Server 2008 (All)
Windows Vista (All versions that support domains)
Windows Server 2003 (All)
Windows XP (All versions that support domains)
Advantages
Allows IT administrators to ensure all client computers/users have standard printers available automatically
Users in the domain do not need to manually create printer connections to use domain print shares
Users cannot delete pushed printer connections without Domain Admin credentials
Limitations
- Pushed printers are created as a per computer connection, and are not managed per user
Deployment Scenarios
Legacy and Package Aware Point and Print
These technologies have not changed in Windows Server 2012, and will continue to operate as they did in Windows 7 and Windows Server 2008 R2. Extensive information is already available on how to setup, maintain, and manage these types of print servers and connections.
IPP
IPP is largely unchanged, but some combinations of print shares and client operating systems can create new deployment issues with the introduction of ARM support, and v4 print drivers.
The IPP protocol does not support a standard for the client and server to share or exchange driver information. Windows has custom extensions it uses to exchange driver information during the setup of an IPP connection. These additional features allow Windows clients and servers to exchange v3 drivers in some situations. This has enabled the automatic deployment of v3 print drivers to support IPP in a fashion very similar to legacy point and print. IPP enabled print servers host a web page that lists available IPP print shares, and allows client computers that support the ActiveX control to install those connections from the web page without any additional configuration. Connections can also be made through the user interface or programmatically without relying on the driver provided by the print server.
The extensions made to IPP to enable v3 driver distribution are not compatible with enhanced Point and Print, and do not extend to v4 drivers. Print shares using v4 drivers will not be installable through the server’s IPP print share page. Connections to v4 powered IPP print shares must be done manually through the user interface, or programmatically through an app or script.
Using v3 print drivers for IPP
Publishing IPP printers for queues using v3 print drivers is unchanged from Windows Server 2008 R2. All previous documentation is valid for Windows Server 2012.
Similarly, x86 and x64 client computers running Windows 8 will continue to support IPP connections to v3 enabled print servers without changes. The ActiveX control required to connect to IPP print shares from the server’s IPP print share page will not run in Internet Explorer, and must be used from Internet Explorer for the desktop on Windows 8.
Using v4 print drivers on the Server
For print queues with v4 print drivers, sharing the queue via IPP remains unchanged. Once the IPP services are installed and running on the print server, all shared queues with v4 print drivers (enhanced Point and Print) will be made available for IPP connections as well.
Unlike shares with v3 print drivers, client computers will not be able to connect through the server’s IPP print share page. All connections to v4 IPP print shares must be done manually through the user interface, or programmatically created through an app or script.
Whether you are manually connecting to a v4 IPP share, or scripting it for broad deployment, the main requirement is that client computers have access to a print driver that can generate device-ready output for the target device. It is possible for the driver on the server to interact with the print information sent by the client computer, so testing is essential before deploying any manually configured IPP connections. As long as the driver on the server and device generate the same PDL (PostScript, PLC6, XPS, and so on.) there should be very little chance for problems, but print drivers can be quite large and complicated. Without testing, there is no guarantee that two different drivers will be able to work with each other through an IPP connection. Ideally, the same driver would be used on both the server and client computer, but this may not be possible depending on the architectures and operating system versions being used. The following is a list of scenarios where manual configuration is required to create connections because the client and server cannot use the same driver.
Windows 7 and earlier systems must use a v3 driver to connect to a v4 IPP print share on Windows Server 2012
Client computers running Windows 8 must be configured to connect to a v4 IPP print share on Windows Server 2012, but the same driver can be used on the client and server
Windows ARM clients must use a v4 driver to connect to a v3 IPP print share on any print server
Even when it is possible for a client computer and server to use the same driver to connect to an IPP print share, it is not required. The same process can be used to specify a driver when creating a manual IPP connection, even when the client could automatically get the driver from the server. This is true for Windows 8, as well as for computers running previous Windows operating systems.
Manually Creating an IPP Connection in the User Interface
IPP Connections can be created manually using the Add Printer Wizard. To start the Add Printer Wizard, type Advanced Printer Setup at the start screen, click Settings, and the click the Advanced Printer Setup tile.
.jpeg)
Figure 2: Advanced Printer Setup
There are several different start screens depending on your system’s configuration. Click The printer that I want isn’t listed. Under Find a printer by other options, click Select a shared printer by name and type the URL for the IPP print share.
.jpeg)
Figure 3: Add Printer
The URL for the IPP share uses the following format:
https://<server>/printers/<share>/.printer
Where <server> is replaced with the name of the print server, and <share> is replaced with the name of the print share.
If the server does not have a viable driver for the client (for example, different architecture, the server is using a v4 driver, or if it is not a Windows print server), the user is prompted to choose a driver on the local system to use. After selecting a driver, the connection is complete. Users can choose to print a test page, or make the new IPP printer connection their default printer.
Enhanced Point and Print
Enhanced Point and Print is new in Windows Server 2012, and introduces a lot of new concepts into printer sharing. One of the ultimate goals is to simplify the administration of Print Servers moving forward.
The functionality of enhanced Point and Print can be broken down into three major areas:
.jpeg)
Figure 2: Basic v4 sharing
Basic – This is the foundation of enhanced Point and Print. It provides universal access to common functionality using default user interface and rendering is performed on the print server.
Custom user interface (Optional) – Advanced features not supported in the default user interface can still be accessed if the client has an application installed that can present the proper user interface. There are separate desktop and Windows Store app versions depending on the workflow being used to print.
Rendering (Optional) – Windows 8 print clients can identify and install v4 print drivers that match those being used on the print server, enabling client side rendering (CSR).
Basic Deployment of enhanced Point and Print shares
Enhanced Point and Print relies on two drivers:
The enhanced Point and Print driver for use on client computers running Windows 8.
The enhanced Point and Print compatibility driver for use on client computers running previous Windows operating systems.
Both of these drivers ship with all versions of Windows 8. 64-bit versions of Windows 8 also include the 32-bit version of the enhanced Point and Print compatibility driver, enabling any client computer running a previous Windows operating system to connect to a v4 share. Client computers running a previous Windows operating system will download the enhanced Point and Print compatibility driver directly from the print server, just like they would download a driver from the server for any Point and Print share.
Client computers using either of these drivers to connect to a print server will be given a basic user experience by default. Rendering will always happen on the server (SSR mode). Any print share hosted on a Windows Server 2012 print server using a v4 driver will be shared through this mechanism. If the basic user experience is sufficient, no other work is required to make this print share available to all supported client computers running Windows 8 and previous Windows operating systems, regardless of operating system architecture (IA64 is not supported through enhanced Point and Print).
Printers can be shared through the Print Management Console, print spooler API’s, or directly through Printer Properties on the device just as an administrator would share any device using a v3 driver. There is no choice to enable enhanced Point and Print specifically, since that choice is dictated by the driver model (v3 versus v4) used to connect to the print device locally on the print server.
Custom User Interface for enhanced Point and Print Shares
For situations where additional user interface is required to expose advanced functionality in the device that is not available in the basic user interface, IT administrators will need to deploy additional applications to complete the user experience. There are two types of applications that can add additional user interface to an enhanced Point and Print connection:
Printer extension applications for desktop printing workflows
Windows Store device apps for the new Windows user interface printing workflows
The additional user interface is provided as a Windows application that can register with the spooler to handle certain aspects of the print driver’s user interface. This can extend the functionality of the basic user interface by adding a customized Printer Preferences page, as well as providing custom user interface for dealing with driver defined events. Each app is only used in its respective workflow (desktop or new Windows user interface) for displaying Print Preferences. Custom notifications are always handled by the Windows Store device app first if it is installed since there is a unified notification system across the new Windows user interface and desktop experiences.
Note
Connections to enhanced Point and Print (v4) shares are not supported on Windows XP and Windows Server 2003.
Deploying Desktop Printer Extension Apps as an Application
Printer extension apps are desktop applications that can be deployed to Windows 8, Windows 7, Windows Server 2008 R2, Windows Server 2008, and Windows Vista client computers to extend the basic desktop user interface for an enhanced Point and Print share. These apps can be deployed as part of a client image, or using standard application deployment tools. Printer Extension apps can be installed before or after a connection to the print share is made. Printer extension apps can also be installed manually from a share or media.
Deploying Desktop Printer Extension Apps in a v4 Driver
Client computers running Windows 8 can also receive a Printer extension app as part of a v4 driver installation. This can introduce complications if other deployment mechanisms are also being used. Refer to Enabling CSR for Client Computers Running Windows 8 for more details.
Deploying Desktop Printer Extension Apps in Print Preferences
IT administrators can update the metadata on the print share to provide users an URL to obtain a printer extension app. The clickable link for the URL will be on the Printer Preferences page when users have a connection to an enhanced Point and Print share with this value set. If a printer extension app is already installed on the client computer, it will receive that user interface instead of being given a link to the share. The registry key for this URL is:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers\<print queue name>\PrinterDriverData\PrinterExtensionUrl
All v4 print drivers can specify a default URL provided by the manufacturer that links users to a manufacturer website with instructions for installing a Printer Extension app. By default, any manufacturer specified URL will be provided to users connecting to a v4 print share if they do not have any other Printer Extension installed.
The URL specified can link to a file share with the printer extension on it, a web page with help content, or any other valid URL target.
Blocking Desktop Printer Extensions
Some enterprises may also choose to block printer extensions altogether. This is supported by a group policy called Computer Configuration\Administrative Templates\Printers\Do not allow v4 printer drivers to show printer extension applications.
Deploying Windows Store Device Apps
Windows Store device apps are used to extend the basic user interface for printing from a Windows Store app. Since it is specific to Windows Store apps, it can only be deployed to client computers running Windows 8, and it is distributed automatically through the Windows Store.
Enabling CSR for Client Computers Running Windows 8
In addition to using the enhanced Point and Print driver for basic SSR functionality, client computers running Windows 8 can use a v4 driver to render content on the client, as well as gain access to any printer extension app (desktop user interface extensions) that may be packaged in the driver.
All v4 drivers must report a Printer Driver ID to the operating system. When a print queue is shared through enhanced Point and Print, the Printer Driver ID provided by the print driver is shared with the Windows 8 print client. The Windows 8 print client will create a virtual PnP device using the Printer Driver ID as the virtual device’s Hardware ID (HWID). This triggers PnP to locate and install a driver for the device.
A matching driver is any v4 driver that reports to Windows 8 in its INF that it supports the Printer Driver ID of the driver used on the server. If a matching v4 driver is found, it is installed using the same mechanisms as a PnP device installation. CSR printing is enabled by default when a v4 driver is running on a client computer running Windows 8, unless CSR is disabled by some other policy (Group Policy, print server settings, power management profile, and so on.).
Since printer extension apps operate on a Last-Installed-Is-Active mode, there can be contention between printer extension apps installed by a driver, and those deployed through other mechanisms. To minimize conflicts in enterprises, it is often preferable to only use one mechanism to distribute printer extension apps to clients.
The following are recommendations that can help eliminate the use of unintended printer extension apps:
Do not distribute v4 print drivers that include printer extension apps, and always rely on standard software deployment tools to support the distribution of printer extension apps.
Use standard deployment tools to distribute printer extension apps to client computers running operating systems prior to Windows 8, and leverage the driver package’s printer extension app for all client computers running Windows 8.
Create deployment rules for printer extension apps that can detect when a different printer extension app has been installed, and replace it.
Only distribute printer extension apps that match (the driver uses the same printer extension app that is being deployed).
Typically, v4 print drivers are published to Windows Update and will be installed automatically when a connection is made if the client has Windows Update access, and if a matching driver is available. In an enterprise, there are other mechanisms that can be used; Windows Server Update Services (WSUS), DevicePath, and standard deployment tools.
Deploying v4 drivers with WSUS
If using the live Windows Update site is not an option for v4 driver distribution, then deploying drivers through Windows Server Update Services (WSUS) is the recommended option. Client computers running Windows 8 can be configured to search WSUS for driver updates, including v4 drivers used in Windows 8 for enhanced Point and Print connections
Client computers running Windows 8 can be configured to check WSUS for available drivers by configuring group policy. The systems must be configured to search Windows Update for drivers automatically, and to use the WSUS server. The new policy for Windows 8 is Specify the search server for device driver updates, available under Computer Configuration>Administrative Templates>System>Device Installation. By default, WSUS is never searched. The policy can be enabled to allow Windows Update only, WSUS only, and to search WSUS followed by Windows Update if no driver is available on WSUS.
The option to search WSUS only will prevent PnP from searching the Windows Update live site, but still allow the administrator to provide additional drivers on their internal WSUS server. The option to search WSUS first, and then Windows Update allows IT administrators to still leverage the breadth of support on Windows Update while allowing specific drivers to be deployed through their internal WSUS server first.
WSUS server is a standalone server role, and it is used as a feature of System Center Configuration Manager. General information about the installation and use of WSUS is available online at TechNet:
Windows Server Update Services
WSUS allows administrators to easily search and import driver packages from the Microsoft Update Catalog. If the v4 driver that needs to be deployed is not available in the Microsoft Update Catalog, it can still be distributed through WSUS using Local Publishing. Using Local Publishing in WSUS requires a high level of technical understanding and the ability to author update packages. This option is not recommended if a suitable driver is available on the Microsoft Update Catalog or in situations where Basic v4 Sharing with Customized user interface would be sufficient. Information on the use of Local Publishing is available on MSDN:
For more information about deploying WSUS, see Windows Server Update Services Overview.
Deploying v4 drivers with DevicePath
DevicePath is a feature in PnP behavior that allows additional drivers to be discovered on a file share or local folder. DevicePath is searched after PnP searches the local driver store, but before a Windows Update check is started. DevicePath is always searched for all PnP driver searches, and it is not indexed in any way. Because of this, performance of all PnP driver searches will be degraded if the connection to the folder is slow, or if a large number of drivers are published on the share. DevicePath use should be restricted to cases where a very small number of drivers need to be distributed, and Windows Update/WSUS are not viable options.
The first step in using a DevicePath deployment strategy is to create a file share on the network that is accessible to all of the necessary client computers. Once that is done, each client computer needs to be configured to search the DevicePath. Information on setting the DevicePath is available on MSDN at:
Modify the DevicePath Registry Key
Drivers published on the DevicePath share must still be signed to avoid prompts and elevations during installation, or additional configuration of the clients may be necessary to suppress elevations and prompts.
Deploying v4 drivers with standard deployment tools
Most deployment tools are designed to distribute applications. To deploy a v4 driver as an application, it must be wrapped in an install package that will add the driver to the local driver store when it is run on the client computer. No other actions are required. Once the driver is in the driver store, it will be available for PnP to discover it when the connection is made.
If your deployment tool supports driver deployments directly to client computers, there is no need to create an install package for the v4 driver.
The v4 driver must be in the local driver store when the connection is made to ensure it is used by the local spooler when creating an enhanced Point and Print connection to a print share. Drivers deployed to the driver store after the connection is made will not be used unless the connection is recreated, or a driver update is invoked on the queue.
Windows on ARM in Enterprises
The two main mechanisms for connecting to printers in an enterprise environment for Windows on Arm clients will be to connect to the printer directly, and to connect through a Windows Server 2012 print server using enhanced Point and Print. Other options are available, but extra care must be taken for those mechanisms to function properly.
Connecting Directly to the Printer
Windows 8 on ARM clients can connect directly to printers in enterprise environments using v4 class drivers. To support direct connections, the following conditions must be met:
Ensure the printer is supported by Windows Server 2012 drivers
Ensure the device is configured to accept print jobs from any IP address/user on the network
Ensure the clients can communicate with the printer on the network (they must be on the same network, and not be blocked by any other technology like firewalls, or IPsec).
Publish the IP address of the printer so that clients can connect to it directly (typically requires the user to go through the Advanced Printer Wizard since printers are rarely on the same subnet as the user). Links to the printer’s IP address can be configured to create a connection automatically.
The disadvantages of direct connection is that IT Administrators do not have the option of using a print server to audit print jobs, service drivers, or establish custom default settings profiles. Each client computer independently connects and submits print jobs directly to the print device. Any auditing or archival solutions will need to be enabled directly on the client computer or the print device.
Connecting to v4 Shares
Windows 8 running on ARM systems can connect to any v4 print share using enhanced Point and Print. All of the deployment options available to other Windows 8 clients apply to Windows 8 running on ARM clients, so refer to the section on enhanced Point and Print for more details. The one exception is that ARM systems can only use the print drivers that ship with the operating system as well as basic enhanced Point and Print support. This may restrict the choices available to allow CSR, and deployment of custom user interface will not be possible through the Windows Update/WSUS driver channel.
Since an ARM client cannot join the domain, it will not be able to retrieve the list of published print shares from the Active Directory (AD). Connections to shares can still be established by opening the URL for the share, clicking on a link to the share, or by navigating to the print share in Explorer. Connections can also be created through the APW, but users will still need to know the URL for the print share.
Connecting to v3 Shares
Windows 8 on ARM systems cannot connect to v3 print shares (legacy Point and Print, Package Aware Point and Print). If a connection to a v3 print share is attempted, the Windows 8 on ARM system may prompt the user to provide a driver. Since there are no v3 drivers for ARM, this dialog should be dismissed.
Connecting to IPP Shares
ARM systems can also be configured to print to IPP print shares, if a compatible device driver is available in the local driver store. This follows the same manual process for creating an IPP connections described in the IPP Deployment Scenarios section of this topic. Creating connections to IPP print shares from an ARM client are not supported through the server’s print share web page.
Branch Office Printing
For more information about Branch Office Direct Printing, see Branch Office Direct Printing Overview.
WSD Secure Printing
WSD Secure Printing is intended to enable secure channel communication between a Windows Server 2012 print server and a WSD Secure Print enabled device. This does not rely on IPsec, or any other additional network services to provide a secure channel. Instead, it uses Secure WSD to establish a communication channel between the device and the print server. Unlike standard HTTPS communication, the WSD Secure Print feature can leverage self-signed certificates to secure the communication channel by relying on Active Directory (AD) to arbitrate trust between the two end points.
Requirements for deploying a WSD Secure Printer
A print device that supports the WSD Secure Print feature
A Windows Server 2012 print server
An Active Directory Domain that both the server and device can join
Steps to deploy a WSD Secure Printer
To deploy a WSD Secure Printer, an IT administrator must:
Ensure the Active Directory has the WSD Secure Print updates. Windows Server 2012 Active Directory already contains the updates. The specific script to add the appropriate fields to an older Active Directory deployment is available in the following MSDN topic: Building a WSD Secure Print Device for Windows
Create a machine account in the domain for the WSD Secure Print device.
Ensure the WSD Secure Print device is attached to the network, and is functional.
Provide the WSD Secure Print device with the computer credentials per the manufacturer’s instructions. The device will automatically authenticate with the Active Directory and update its computer account with the necessary information.
Add the WSD Secure Print Device to the print server using directed discovery. The print server must be in the same domain as the WSD Secure Print device, and have access to the Active Directory at the time making the connection. Adding a device through directed discovery can be accomplished a number of ways, but the primary user interface path is described below:
In the Print Management Console, select the print server you want to use.
Under Action in the tool bar, choose Add Printer.
Choose the radio button for Add a TCP/IP or Web Services Printer by IP address or hostname, and click Next.
In the drop down box, select Web Service Secure Printer, and specify the IP address or host name of the device in the text box below. When done, click Next.
Share the WSD Secure Print queue normally, and manages it like any other print queue. Once the connection is made, there are no special steps in managing a Secure WSD Print device.
Notes on WSD Secure Print scenarios
Multicast discovery is not supported over HTTPS. All connections to WSD Secure Print printers must be done through directed discovery.
If the WSD Secure Print device is using a self-signed certificate, it will not be possible for the device to provide events back to the print server. The print spooler will poll the WSD Secure Print device for events and status directly. This can introduce minor delays in status updates on the print server and clients. This is expected behavior.
WSD Secure Print devices do not require the deployment of trusted certificates to secure the connection between the print server and the device. Supporting deployment of trusted certificates can enable two-way communication between the device and print server, providing better status and event handling, but this is an optional feature. Check with your manufacturer if your policies require the use of trusted certificates.