Printer Driver Management

Printer Driver Management

Even though MetaFrame supports what may at first appear to be a wide and confusing array of printing options for the end user, one common factor that does not change is the need to have a suitable printer driver available on a MetaFrame server before a user is able to send print jobs to the desired printer. MetaFrame supports a number of options for managing the replication and even substitution of printer drivers. In the following sections, we review all these management choices.

Installing Printer Drivers

A couple of different methods exist for installing printer drivers on a MetaFrame server. The methods are summarized as follows :

• Install the printer driver using one of the standard Windows printer driver installation methods. This can include creating a local printer on a MetaFrame server using the familiar Add Printer Wizard. During the printer installation, the necessary driver is added to the MetaFrame server.

  You can also manually add drivers to a server from the Drivers tab of the Print Server properties. Open Printers and Faxes on a Windows Server 2003 server (or Printers from a Windows 2000 server) and choose Server Properties from the File menu to access this dialog box. Here, you find the Drivers tab, where you can choose to add, delete, reinstall, or modify the driver properties.

• Use driver replication to deploy the driver to the desired MetaFrame server. When a printer driver has been installed on at least one MetaFrame server in the farm, you can use the driver replication feature to replicate the driver to any other MetaFrame server in the farm. This provides a fast and reliable method of adding printer drivers to all required MetaFrame servers without having to manually install the drivers on each server.

  Automatically install a native printer driver during client or network printer auto-creation. MetaFrame supports the ability to automatically install a native Windows printer driver if a driver does not already exist for an automatically created client or network printer. This option is enabled by default and is found under the Drivers section of the Printer Management properties. It is important to note that this feature allows only the automatic installation of printer drivers that are natively supplied with Windows. Third-party or updated printer drivers must be manually installed and replicated. The automatic installation of native printer drivers is also performed only during the automatic creation of client or network printer connections. Printers that are mapped by other means such as logon scripts do not have native drivers automatically installed. Client and network auto-creation are discussed in the "Printer Configuration" section later in this chapter.

Replicating Printer Drivers

To replicate a printer driver, highlight the desired driver from within the Management Console and choose Replicate Drivers from the Printer Management Actions menu (or from the context menu when right-clicking the driver). This opens the Replicate Driver dialog box, where you see the following information:

• Platform This is the version of Windows for which this printer driver is intended. Printer drivers are replicated only to servers running the matching platform version. This ensures driver compatibility.

• Server(s) This is the name of the server that will be the source for the driver replication. The driver information is taken from this server and used to replicate to the target MetaFrame servers. If the server choice Any was selected, it will appear here instead of a specific server name . Choosing Any causes MetaFrame to replicate the printer driver from any available server that has the driver installed.

• Driver This is the name of the printer driver that will be replicated.

In the middle of the Replicate Driver dialog box are two radio buttons from which you choose how the driver will be replicated. The default option is to replicate this printer driver to all other servers in the farm running the same Windows version and also to add this driver to the auto-replication list. Auto-replication is discussed in the next section.

The second option allows you to choose the desired target server for the replication. Only servers running the same platform version appear in the list. When specific servers are chosen as targets for replication, the operation is performed only once, and an auto-replication task is not created.

The final option on this screen is the check box that enables or disables overwriting existing drivers. By default, if a server already has a printer driver with the same name, it is not updated. Enabling this option forces the replacement of the printer driver, regardless of whether it exists or not. This option would normally be used if you were deploying an updated version of a printer driver or wanted to ensure a consistent driver version across all target MF servers.

Auto-Replicating Printer Drivers

MPS allows you to configure the auto-replication of printer drivers to all MPS servers running the same Windows platform. Auto-replication ensures that all new servers added to the farm are automatically configured with the necessary drivers to support the end user's printing needs.

You manage auto-replication by highlighting the Drivers tab for Printer Management and choosing Auto-replication from the Actions menu. This opens the auto-replication dialog box, which shows all the drivers currently configured for replication (broken down by platform). From this dialog box, you are able to add or remove driver entries, but you are not able to directly edit an existing driver's settings. If you want to change the source server or the overwrite setting for a driver, you must delete and then re-add it.

You can set up a driver for auto-replication directly from this dialog box, or by choosing to replicate the driver either from the Drivers node for Print Management or the Printer Drivers tab for an individual server.

Printer Driver Compatibility

Unfortunately, not all printer drivers are suitable (or desirable) for use in a MetaFrame environment. Some printer drivers can cause severe server issues such as a full system crash (blue screen of death STOP error), whereas others may just prove to be extremely slow or buggy . Whatever the reason, a mechanism must exist to ensure that these types of drivers can be prevented from operating on a MetaFrame server. This is why Citrix provided the Driver Compatibility feature, which allows an administrator to quickly control what printer drivers are and are not allowed to be used for auto-created client sessions.

You open the Driver Compatibility dialog box by selecting the Drivers node under Printer Management and selecting Compatibility from the Actions menu. By default, all printer drivers are permitted, but you can configure the farm to allow or restrict the use of specific drivers based on the options that you choose. These two options are available:

• Allow Only Drivers in the List This option blocks all client printer creation unless a client printer uses a driver that is specifically shown in the "allowed" list.

• Allow All Drivers Except Those in the List This is the default configuration, allowing all client printers to be automatically mapped unless the corresponding printer driver is included in the list.

To add a driver to the list, simply click the Add button and either type in the exact name of the client printer driver, or choose one from the list of drivers that have already been installed in the farm.

If the driver is currently not installed but you want to ensure that it will never be used, type in the exact driver name. Make sure that all spacing, punctuation, and capitalization match exactly; otherwise , MetaFrame cannot make a proper match. You can edit or delete an existing entry at any time by highlighting and clicking the appropriate button (Edit or Delete).

Whenever MetaFrame attempts to create a client printer, it first checks the include/exclude list and verifies the acceptance of the required driver before the client printer mapping is finalized.

Note

The entries in the Driver Compatibility list have no impact on the auto-creation of network printers or the mapping of printers through logon scripts. If a network-based or local printer is causing server issues, it is advised that the auto-network mapping be terminated and the access to the offending printer's queue be restricted or eliminated to ensure users are not able to connect.

Printer Driver Mapping

For you to be able to properly connect client printers within a MetaFrame session, the server needs a process by which it can identify and select the appropriate printer driver. This identification process involves comparing the name of the printer driver on the client with driver names on the server to find a match. If a name match is found, the printer is created within the user's MetaFrame session. If a match is not found, depending on the configuration of the server, either an attempt is made to use a MetaFrame universal printer driver, or the client printer mapping fails. Universal printer drivers are discussed in the next section.

This name matching process is reliable when the client and server are both running similar versions of the Windows software (Windows 2000 Professional and Windows 2000 Server or Windows XP and Windows Server 2003). In these situations, the same drivers are used on both the client and server, so the names almost always match each other. The matching process breaks down when the same printer has different driver names on the client and server. This is common when using an older Windows client such as Windows 95 or 98. Many Windows 9x printer drivers have slightly different names from the equivalent Windows 2000 Server or Windows Server 2003 printer driver.

To overcome this problem, Citrix created the driver mapping feature, which allows for the creation of an association between client and server driver names that do not match. You configure printer driver mapping by selecting the Mapping action for the Drivers node under Printer Management. This opens the Driver Mapping dialog box shown in Figure 12.8, which shows two existing printer driver mappings. When opened for the first time, the Driver Mapping dialog box is empty. Separate mappings for both Windows platforms are maintained to allow for discrepancies between Windows 2000 Server and Windows Server 2003 printer driver names.

Figure 12.8. The driver mapping feature allows you to match up client and server drivers that do not have matching driver names.

You create a driver mapping simply by choosing the desired platform, clicking the Add button, and then providing the name of the client and corresponding server driver names. If the server driver is already installed, you can select it from the drop-down list box. You are always required to type in the appropriate client driver name. You must ensure that the name matches exactly with the name of the driver on the workstation. All capitalization and punctuation must be identical; otherwise, the mapping will not be successful.

These steps summarize the printer driver identification process that MetaFrame follows when attempting to connect a client printer:

1.	A user with client printer mapping enabled connects to a MetaFrame server.
2.	The MetaFrame server retrieves the name of the local printer driverfor example, a driver called HP LaserJet 5P/5MP (HP).
3.	The server scans the driver mapping list for the appropriate platform, attempting to find a mapping for the client driver. If a mapping is found, the corresponding server driver is used to create the client printer. If a driver mapping entry was created but the corresponding server driver does not exist, the mapping fails. MetaFrame does not attempt to continue by looking for an exact driver match.
4.	If a mapping entry does not exist, the server searches through the printer drivers installed on the server, attempting to find a matching client driver name. If a match is found, the printer is created within the user's session using the matching printer driver. If a match is not found, depending on the configuration of the server, either an attempt is made to use a MetaFrame universal printer driver or the client printer mapping fails.

Note

Because MetaFrame consults the driver mapping table before it searches for locally installed drivers, you can use this to enforce an alternative driver be used for a particular client printer instead of the matching driver that may have already been installed on the server.

The driver mapping information is stored not only within the server farm's data store, but it is also stored locally on each server in a plain text file called WTSPRNT.INF . For a default Citrix MPS installation, you can find this file in the %ProgramFiles%\Citrix\System32 folder. For the mappings defined in Figure 12.8, the corresponding entries in WTSPRNT.INF would look as follows:

 ; ;       WTSPRNT.INF  DO  NOT  CHANGE ; ;This file is supplied by Citrix as a reference and best guess for ;client printer selections. The file wtsuprn.inf is the user file ;for client printer mapping and takes precedence over this file. ;An example file, wtsuprn.txt is supplied as a template. ; ;This file is changed automatically when the admin makes changes to ;the farm wide driver mapping settings. ;This file may be overwritten during software upgrades! [Identification] OptionType=PRINTER [ClientPrinters] "HP LaserJet 5/5M - Enhanced"="HP LaserJet 5" "HP LaserJet 5/5M - Standard"="HP LaserJet 5" 

Do not modify this file directly because it will be overwritten the next time modifications are made to the driver mappings within the Management Console.

Note

Changes made to the wtsuprn.inf file are implemented by the MetaFrame server; however, the mappings do not appear in the Management Console.

MetaFrame Universal Printer Drivers

Since Feature Release 1 of MetaFrame XP, Citrix has provided the universal printer driver (UPD) as an alternative to maintaining drivers for many different printers in a large MetaFrame environment.

Three variations of the UPD are supported in MPS 3.0. One supports PostScript (PS) language, and the other two support different versions of the Printer Control Language (PCL5c and PCL4, respectively).

Instead of using a native printer driver, MetaFrame can be configured to employ one of these three universal drivers in its place. The generic driver is still responsible for creating the print data stream, spooling the job and directing it to the client. The client then renders the data stream using the corresponding interpreter for the UPD language (PS, PCL4, or PCL5c). Finally, the client redirects the data stream to the appropriate local printer for output.

Alert

Two common misconceptions may trip you up on the exam. First, the UPD is employed only on the MetaFrame server and only for client-mapped printers. The UPD is not used at all by the client. Second, the UPD driver is not intended to be employed as an alternative driver for local MetaFrame printers or network printers (mapped manually or using logon scripts).

The use of universal printer drivers can reduce or eliminate the need to manually install and replicate native or custom printer drivers. Manual driver installation would be required only when an application required access to special printer-specific features not available through one of the UPDs.

Besides simplifying driver maintenance in very large MetaFrame implementations , universal printer drivers can help to reduce the impact of certain native driver- related issues such as

• The transmission of large print job files generated by native drivers that do not employ advanced printer languages such as PCL or PS.

• Ill-behaved drivers in a MetaFrame environment causing failures of the print spooler service, which impact all users on the server. Although less common now compared to a few years ago, some third-party native printer drivers do not function well in multiuser environments such as MetaFrame.

You manage the use of universal printer drivers in client printer creation from within the properties of the Printer Management node. Figure 12.9 shows the default driver settings within the Printer Management properties.

Figure 12.9. The behavior of universal printer driver use is managed farmwide within the Printer Management node's properties.

The printer driver choices are

• Native Drivers Only This setting allows only native drivers to be selected when mapping client printers. If a native driver cannot be found, the printer is not connected.

• Universal Driver Only The opposite configuration always uses one of the universal drivers. When this setting is enabled, native drivers are never searched during the client printer connection process.

• Use Universal Driver Only If Native Driver Is Unavailable The default behavior attempts to fall back on using a universal driver only if a native driver cannot be found.

• Both Universal and Native Drivers When this choice is selected, it actually attempts to create two client printers, one using the native driver and the other using a universal driver. If the native driver does not exist or has been excluded using printer compatibility, only the UPD-based client printer will be created.

Alert

You can override the printer choices for the farm with MetaFrame user policies. This allows you to define different driver requirements based on the class, type, or location of the users. Unexpected driver behavior usually indicates that a policy is involved.

The final option on this screen is used to control whether MetaFrame will attempt to install a native Windows driver when required during auto-creation of client and network printers. If you want to have complete control over the drivers added to a server or you are going to support only the UPDs, you should disable Automatically Install Native Drivers for Auto-Created Client and Network Printers.

You can quickly identify a client printer created using a UPD because the suffix [UPD:<driver type>] is added to the printer name. Figure 12.10 shows how this name would appear. In this figure, you see two printers using the PCL5c universal printer driver, whereas the other uses the PS UPD.

Figure 12.10. Client-mapped printers that use a universal printer driver have [UPD:<driver type>] appended to the end of the printer name.

The universal driver that is employed depends on the client's version and Windows platform. The MetaFrame server automatically determines the highest UPD version supported by the client. The specific client versions compatible with the different UPDs are as follows:

• PCL5c The client must be running either the Macintosh or Win32 client at version 7.0 or higher to use this driver. The PCL5c driver supports both color and black-and-white printing up to 600 dots per inch (dpi).

• PCL4 Older versions of the ICA client utilize this driver. The PCL4 driver supports only black-and-white printing with a maximum resolution of 300 dpi.

• PS The PostScript driver is intended for use with version 7.0 or higher of the ICA client for UNIX.