Now that you understand how printing works in standard Windows environments, let’s see how printing can be configured in MetaFrame XP environments. Before we get too far into the details of MetaFrame XP printing, we need to “redefine” some standard printing terms for the MetaFrame XP environment.

Even with the infinite number of printing scenarios available in the real world, there are only two major types of printing scenarios available in MetaFrame XP. All MetaFrame XP printing is a variation on one of the following two themes:

• Client Printers. These are printers that are connected to the ICA client device when a MetaFrame XP session is launched. Depending on the client platform, this can include printers that are physically attached to the client or printers that are logically mapped to the client through the network.
• Server Printers. Server printers in MetaFrame XP environments are printers where the MetaFrame XP server has direct access to the print queue. This can include standard network printers that are accessible via a \\servername\printername share. It can also include printers where the print queue is located locally on a MetaFrame XP server, even including printers that are directly connected to MetaFrame XP servers.

Figure 7.2: The various types of MetaFrame XP printers

It’s important that you understand the differences between client and server printers in MetaFrame XP environments. Each type has advantages and disadvantages is used or configured differently. For these reasons, we’ll look at client printers and server printers separately in this chapter, beginning now with client printers.

Client Printers

Different ICA client platforms support different types of client printers in MetaFrame XP. For that reason, we need to outline the differences of the various client platforms so that we know what client printer options are available:

• On 32-bit Windows ICA client devices, all printers configured in Windows before the user connects to the MetaFrame XP server are considered client printers. This is basically any printer that appears in the “Printers” folder on the client computer, including printers that are physically connected to the client computer, as well as network printers that are mapped by a logon script or user profile.
• On Windows CE, DOS, and Mac OS client devices, a client printer is a printer that is physically connected to a local port on the client device. This usually includes printers that are connected to the local LPT1 port. This is different from 32-bit Windows clients, because any network printers that are mapped by local users cannot be automatically used as client printers within MetaFrame XP sessions from these platforms.
• On other Citrix ICA client platforms, client printers cannot be directly used from MetaFrame XP sessions. Printing from these environments must be configured via server printers.

How Client Printers are used by MetaFrame XP

Before we can look at how client printers are configured in MetaFrame XP, we need to understand how client printers are used by MetaFrame XP. When a user with client printers connects to the MetaFrame XP server, the user’s local ICA client software automatically shares the printers that the user has installed locally. When the user needs to print a document from within a MetaFrame XP application, they invoke the print job as usual. From within their MetaFrame XP session, they will see the shares of their local client device’s printers. These printers will have the name \\clientname#\ printername. These printers are not fully installed locally on the MetaFrame XP server, they are just automatically shared on the client device by the ICA client software. When the user prints to one of his client printers, the process outlined in Figure 7.3 (facing page) takes place.

Figure 7.3: Printing to a MetaFrame XP client printer

1. The user prints from his application running on the MetaFrame XP server.
2. The application creates the EMF file on the MetaFrame XP server.
3. The EMF file is sent to the print spooler on the MetaFrame XP server.
4. The print spooler creates the spooled print job, using the proper drivers for the client’s printer. This is possible because the MetaFrame XP server has the appropriate printer drivers loaded on it for the client’s printer.
5. The spooled print job is sent from the MetaFrame XP server to the ICA client device. This spool file is sent as part of the ICA protocol, although at a lower priority than things like screen updates and the user interface.
6. The client device receives the spool file. Because the MetaFrame XP server had the drivers loaded for the client’s printer, the print job is spooled specifically for the client’s printer, and the client device can send the print job right to the printer.

One thing that is immediately obvious when looking at the client printer process is the potential for a severe performance problem. Spooled print jobs are usually quite large, and they can take a long time to transmit to the client’s printer, especially if the user is connected via a dial-up line. Additionally, the performance of the ICA session can be degraded because bandwidth is being consumed by the spooled print job that is being sent to the client.

One potential solution involves printing to clients’ network printers. If your users connect from 32-bit Windows clients, any network printers that they have mapped are also shared and mapped in their ICA session when they connect to a MetaFrame XP server. If you think about it, printing to a client’s network printer actually makes the problem worse, not better. Let’s look at what happens in this case.

Steps one through five are identical to steps one through five in Figure 7.3, when a client’s local printer is used. The only difference when a client’s network printer is used is shown in step six.

6. The client device receives the spool file. Because the MetaFrame XP server had the drivers loaded for the client’s mapped network printer, the client device can send the print job right to the network printer.

As you can see, if the client’s printer is a mapped network printer, the spooled print job is sent across the network to the ICA client. The ICA client then immediately sends the print job across the same network to the network printer.

Of course the solution is to route the print job from the MetaFrame XP server directly to the print server, without channeling it through the ICA client. This is a commonly used alternative to the previously outlined scenario, which will be studied later in the “Server Printers” section of this chapter.

There are a few more downsides to client printer mapping, in addition to the performance impact. The first involves the printer driver requirement on the MetaFrame XP server. As you saw in Figures 7.3 and 7.4, a user’s print job is created, rendered, and spooled on the MetaFrame XP server when client printer mappings are used. Because of this, the server must have the necessary drivers for the client’s printer installed, so that the server knows how to create the print job. Remember, all of the work for printing is being done on the server, which means that the server needs the proper print drivers installed, not the ICA client.

Figure 7.4: MetaFrame XP printing to client network printers

If you have an environment in which your users have only a few different types of printers, then this might not be a problem. However, if you have hundreds of users with hundreds of different printers, installing and configuring printer drivers on your MetaFrame XP servers can be a nightmare. We’ll study the use and management of printer drivers a bit later in this chapter.

Another downside to client printer mapping is that in order for a user to be able to use a printer, it must be installed and configured locally on the client device. This could be the exact opposite of what you’re trying to do by using MetaFrame XP. Most likely, you want to move away from having to configure things on individual users’ workstations. If a user installs, deletes, or otherwise modifies their local workstation printers (not your problem), it will affect how they print from their MetaFrame XP session (definitely your problem).

Advantages of Printing with Mapped Client Printers

• Seamless connection of printers.
• Users see printers that they are familiar with.
• All supported local printers are available.
• Quick setup for existing client printers.

Disadvantages of Printing with Mapped Client Printers

• Poor print performance.
• Bandwidth intensive.
• Printers must be installed and configured on local clients.
• Users can update, modify, or delete their local printers, directly impacting the MetaFrame XP client printer mappings.

Configuring Client Printers

By definition, client printers are already set up and configured on the client devices, so there is nothing else that you need to do there. All client printer mapping configuration is done centrally at your MetaFrame XP servers. From a high level, allowing users to print to their client printers involves two steps:

1. Install the printer drivers on your MetaFrame XP Servers.
2. Configure your servers to use client printers.

Step 1. Install Printer Drivers

The first thing that must be done is to install the necessary print drivers on servers in the server farm. Because the applications are running on the servers and the print jobs are spooled on the servers, you need to have the drivers installed on every MetaFrame XP server for every different client printer. There are many issues associated with the installation and management of printer drivers on MetaFrame XP servers. We will look at the specific details in the “Managing Printer Drivers” section of this chapter.

If a MetaFrame XP server cannot find an appropriate driver for a client printer when a user connects, then that client printer will not be available from within that ICA session.

Step 2. Configure the MetaFrame Server to Connect Client Printers

After the printer drivers are installed, you need to configure MetaFrame XP to connect clients’ printers when their ICA sessions are started. You will have to configure: MetaFrame XP server permissions, the MetaFrame XP server connection, and the user’s domain account properties.

Verify MetaFrame XP Server Permissions for Printing

In order for users to be able to print on a MetaFrame XP server, they will need Read, Write, Execute, and List Folder Contents access to the print spooler’s directory, %SystemRoot%\System32\Spool.

Verify MetaFrame Server Connection Configuration for Client Printer Use

With the Citrix Connection Configuration tool, you can configure the client printer options for all users that use a particular connection. In the “client settings” area of the connection properties, make sure that the “disable windows client printer mapping” or “disable client LPT mapping” boxes are not checked. Obviously, checking either one of these boxes will prevent client printers from being mapped.

If the “Inherit User Configuration” option is checked, then you will need to verify that the user’s account is properly configured for client printer mapping.

Verify Citrix User Policies

If you’re leveraging the Citrix user policy feature of Feature Release 2, then you need to make sure that the effective policies for your users allow for the auto-creation of client printers. See Chapter 5 for more information about Citrix user policies.

Configure User Account Settings

You can configure client printer connection settings on a user-by-user basis. In Windows NT 4.0 domains, this is done by editing the user’s account properties with a copy of user manager for domains that came with Terminal Server (User Manager for Domains | User Configuration Button). In Active Directory environments, the client printer mapping properties are part of the user’s AD object (Active Directory Users and Computers | User Object | Environment Tab).

In either environment, selecting “Connect Client Printers at Logon” will cause the user’s client printer to automatically be created when they log onto a MetaFrame XP server. When the user logs off and all his print jobs have printed, the printer is automatically deleted. If you do not set the “Connect Client Printers at Logon” option, a user will still be able to manually map to his client printer, it just will not be created for him automatically.

Enable Auto-created Printers

Once you have everything set up, you will need to ensure that auto-created client printers are enabled in your server farm. (CMC | Right-click on Printer Management | Properties | Printers tab). If you’re using Feature Release 2, you can also use this screen to configure the properties of auto-created printers, including how you want the properties to be updated, whether users can specify their own settings, and whether unfinished print jobs should be deleted when a user logs off.

Auto-created Client Printer Names

When a printer is auto-created from an ICA client device, the printer will have the name \\clientname#\printername. The comment field will read “Auto Created Client Printer.” If you modify or delete the text of the comment, MetaFrame XP will not realize that the printer was auto-created, and will not delete it when the user logs off. Upon subsequent logons by the same user, MetaFrame XP will use the existing printer information without modifying it. If a user changes his printer settings, those changes are not maintained. While this can be useful for preserving custom print settings, it will also cause all of the printers to remain installed on the server.

Printer Driver Problems when Using Mapped Client Printers

Remember that your MetaFrame XP server must have the printer drivers installed locally for users to be able to print to their client printers, because the print jobs are rendered and spooled on the server.

When a user with client printer mapping enabled starts a MetaFrame XP session, the server checks the driver names of the user’s client printers. It then looks at all the driver names of its own installed printers. If there’s a match, the server knows that it has the appropriate drivers installed to support that printer and the printer is automatically mapped for that user’s session. If there is no match, then that printer is skipped and the MetaFrame XP server moves on to the next client printer. For example, if the MetaFrame XP server has a driver installed called “HP OfficeJet 40xi” and the ICA client has a printer called “HP OfficeJet 40xi,” the server will know that there’s a match. However, if the client has a printer installed called “Canon BJC-620,” then obviously the server knows that there is not a match.

This works fine if your ICA clients and your MetaFrame XP server are running on the same platform, since the exact same printer drivers will be installed on both ends. However, this leads to an interesting problem if your client platform is not the same as your MetaFrame XP server platform. For example, some printers have driver names in Windows 95 are not the same as in their Windows 2000 counterparts. If one of your users has a LaserJet 5P printer, the Windows 95 driver name of the printer on that user’s workstation might be called “Hewlett Packard LaserJet 5P.” However, the MetaFrame XP server will have the Windows 2000 version of that printer’s driver installed. Instead of being called a “Hewlett Packard LaserJet 5P,” the Windows 2000 driver might be called “HP LaserJet 5P.” To human readers, the driver names seem the same, but to MetaFrame XP, the fact that one starts with “HP” and the other starts with “Hewlett Packard” causes the two driver names to be different. Because MetaFrame XP interprets these names as being different, ICA clients using Windows 95 will not be able to print to their own local printer, because MetaFrame XP thinks that it doesn’t have a driver that can support it.

Solution: Printer Driver Mapping

To address this, it’s possible for you to correlate the driver names of client printers with the driver names of server printers. In this case, you would tell MetaFrame XP that the client printer “Hewlett Packard LaserJet 5P” is the same as the server printer “HP LaserJet 5P.”

In order to do this, you can place a file on your MetaFrame XP server called wtsuprn.inf. This file, which you should put in the %systemroot%\system32\ folder, contains server-name to client-name printer driver mappings. By default, this file does not exist. However, there is a template called wtsuprn.txt that you can modify. After you modify the template, you need to change its extension from .txt to .inf. Let’s take a look at that template now.

======================================================
; WTSUPRN.TXT
;
[Identification]
        OptionType = PRINTER
[ClientPrinters]
;
;     Client Name                  Server Name
;          |                           |
;          |                           |
;         \|/                         \|/
;”HP LaserJet 4/4M”            = “HP LaserJet 4″
;”HP LaserJet 4P/4MP”          = “HP LaserJet 4P”
;”HP LaserJet 4 Plus/4M Plus”  = “HP LaserJet 4 Plus”
;”HP LaserJet 4Si/4Si MX”      = “HP LaserJet 4Si”
;”HP LaserJet 4V/4MV”          = “HP LaserJet 4V”
;”HP LaserJet 5/5M – Enhanced” = “HP LaserJet 5″
;”HP LaserJet 5/5M – Standard” = “HP LaserJet 5″
;”HP LaserJet 5/5M PostScript” = “HP LaserJet 5″
;”HP LaserJet 5L (PCL)”        = “HP LaserJet 5L”
;”HP LaserJet 5P/5MP (HP)”     = “HP LaserJet 5P”
======================================================
 

Figure 7.5: The wtsuprn.txt template file

The printer driver names in this file are case sensitive and space sensitive. Basically, everything between the quotation marks must match the printer name exactly. As with many .inf files, the leading semicolon (;) indicates that the line is a comment and should be ignored. If you make any changes or additions or if you want to activate any of the mappings already in the file, you need to make sure that line does not start with a semicolon. When you use this file, be aware that you can have more than one client printer mapped to a single server print driver.

This wtsuprn.inf file must exist on every MetaFrame XP server where you want these print driver mappings to be applied. Keep in mind that you do still need to install printer drivers on your MetaFrame XP server when you use this file. This file merely tells the server which of its already installed drivers correlate to ICA client printer drivers.

Finding the Exact Printer Driver Names

In order to be able to map printer drivers between the MetaFrame XP server and clients, you need to know the exact printer driver name for both the server and the ICA client. You can get this information from the printer properties dialog box (Start | Settings | Printers | Right-click Printer | Properties | Details). On Windows 9x computers, the driver is listed in the “Print using the following driver” box. On Windows NT and Windows 2000 computers, the driver box is on the “General” tab. Because the name of the printer driver can vary on the workstation depending on the platform, make sure you have the right driver name for the each client platform that is being used. For example, if you see “HP LaserJet 4000 Series PCL 5/5e,” be sure to note all the punctuation, spaces, and case sensitivity.

If you already have the driver installed on your MetaFrame XP server, but you do not have a printer installed where you can check the properties, you can always begin the printer installation process. Just add the printer as a local printer on any port. When you get to the list of printers, browse to the manufacturer in the left pane. From there, you can view the full driver name in the right pane.

Once the driver names are added to your mapping file, your users will be able to print to their client printers from MetaFrame XP sessions. You do not have to reboot your server after you change the mapping file. Simply log the user off and then back on.

Sequencing of Client Printer Driver Mapping

When a user with client printers logs on to a MetaFrame XP server, the server goes through several steps to try to find an appropriate printer driver to use.

1. The server looks for the printer name in one of the text mapping files. First, the wtsuprn.inf file is checked for a clientname#\ printername entry, and then just a printername entry. If nothing is found there, the server looks for the same two entries in the wtsprnt.inf file.
2. The server looks for the client printer driver name in one of the text mapping files. Similar to the search for the printer name, the wtsuprn.inf is first checked for a clientname#\print drivername entry, and then for a printerdrivername entry. If this fails, the server looks for the same two entries in the wtsprnt.inf file.
3. If the server cannot find any mapping information in either of the two text mapping files, it checks to see if the driver is already loaded locally on the server. To do this, it looks at HKLM\System\Current ControlSet\Control\Print\Environments\Windows NT x86\Drivers\ in the registry.
4. If it can’t find the printer driver information in the registry, that means that the printer driver is not installed. As a last resort, the server will check to see if the client’s printer is one of the hundreds of standard printers that are available with Windows. To do this, it looks at the ntprint.inf file. If the printer is found and if the source files are available (usually via a CD or network share), then the print drivers are automatically and silently installed.
5. If the server is does not find the client’s printer in the ntprint.inf file, the client’s printer is not mapped for the ICA session. The MetaFrame XP server will start this entire process over again for the next printer on the client’s list.

Using MetaFrame XP to Map Printer Drivers

Now that we’ve seen how printer driver mapping works under the hood, you’ll be happy to know that there is an easier way to do it with MetaFrame XP.

During the MetaFrame XP installation, or whenever the IMA service is started on a MetaFrame XP server, the print driver mappings from the wtsuprn.inf or wtsprnt.inf files on the server are imported into the IMA data store. Any duplicate mappings are not written to the data store. Then, the server’s local wtsprnt.inf file is populated from the mapping information stored in the IMA data store. If the wtsprnt.inf file does not exist, the IMA service creates it. If it does exist, it is overwritten with the mapping information contained in the IMA data store. This allows the print driver mappings from all MetaFrame XP servers in the farm to be automatically populated to all other servers.

But wait, it gets better. In the MetaFrame XP environment, you can configure printer driver mappings via the Citrix Management Console, instead of having to manually edit any .inf files (CMC | Printers | Right-click on driver name | Mapping). When you configure printer driver mappings via the CMC, you must choose a platform for the mapping. In this way you can have different mappings for Terminal Server 4.0 and Windows 2000 MetaFrame XP servers. Add the driver name of the client printer driver that correlates to the server printer driver name.

In addition to these methods, you can also manually import existing wtsuprn.inf or wtsprnt.inf files using MetaFrame XP’s qprinter command line utility, available on the MetaFrame XP CD.

Printer Driver Compatibility Problems

There’s also another issue that can arise when you use client mapped printers. Think back to process that MetaFrame XP uses to create client printers. The very last thing the server tries before giving up is to locate a default driver for the printer. If a default driver is found and the Windows source files are available, the driver is automatically installed onto the MetaFrame XP server, allowing the user to access their client printer. While this may seem like a convenient way to install printer drivers, it actually tends to cause two major problems:

• Users connect with untested client printers. Most user communities are uncontrolled. It’s likely that a user could connect to your MetaFrame XP server with almost any printer drivers installed locally. By default, this will cause the printer driver to automatically be installed on the server, even if you have never tested (or even heard of) that printer. In some cases, users printing to unsupported drivers may crash the server. This is more of a problem if your MetaFrame XP servers are running on Terminal Server 4.0, because regular Windows NT 4.0 printer drivers are not automatically compatible with Terminal Server. In Windows 2000, this is less of a problem, but you still don’t want untested printer drivers on your server.
• Automatically installed printer drivers are not automatically removed. One of the big concerns that many MetaFrame XP administrators have the number of printer drivers that are installed on their servers. If users with all types of printers are causing drivers to be installed on the MetaFrame XP servers, the servers will need to manage a lot of drivers. Additionally, if driver auto-replication is used (discussed later in this chapter), the printer driver replication process will take even longer.

In order to prevent these two situations from occurring, there are three options that you can implement:

• Use the CMC to mark certain printer drivers as “incompatible.”
• Configure your MetaFrame XP servers to only use trusted drivers.
• Manually map known bad drivers to known good drivers.

Solution 1. Use the CMC to Set Printer Driver Compatibility

You can use the Citrix Management Console to prevent certain printer drivers from being used with client printers. This is done by configuring printer driver compatibility. In the printer driver compatibility box, (CMC | Printers | Right click on driver | Compatibility), you can add printer drivers that you will explicitly allow or explicitly prevent on your servers. In order to add a driver that is allowed, it must already be installed on one of your MetaFrame XP servers in the farm.

If client printer mapping is enabled, the MetaFrame XP server checks the client print driver compatibility list before it sets up any printers every time a user logs on. If a printer uses drivers that are on the prohibited list, the server does not set up that printer. It sends a message to the user and writes a message in the server’s event log.

These compatibility settings only affect client mapped printers, not network printers. This is because the drivers for network printers must be manually installed by an administrator-there is no way for them to be automatically installed by the server. The idea here is that if you are manually installing printer drivers, then you know which are compatible and which aren’t.

Advantages of Setting Printer Driver Compatibility

• Settings are automatically applied to all servers in the farm.
• Easily configured, changed and updated.
• Choosing to “explicitly allow” printer drivers is an easy way to limit the total number of drivers installed.

Disadvantages of Setting Printer Driver Compatibility

• In order to prevent certain drivers from being used, you need to know which ones are bad.
• You cannot have different driver compatibility settings for different servers in the farm.
• Only applies to client mapped printers.

Solution 2. Use Only Trusted Drivers

Another interesting solution to the automatic printer driver installation problem is to configure your MetaFrame XP servers so that they only load drivers from a trusted source. Basically, you configure a network path in the registry of each of your MetaFrame XP servers, and your servers will only be able to load printer drivers from that path. Many people leverage a trusted driver path by creating a network share and then dumping the approved printer drivers into that share. If a driver is not in that share, it cannot be installed. This applies to drivers that would be automatically installed as part of the client printer mapping process, or drivers that you manually install as an administrator.

To configure your MetaFrame XP server to use trusted drivers, you need to configure two registry keys. This process is the same for Terminal Server 4.0 and Windows 2000. (Technically, Terminal Server 4.0 requires Service Pack 5 in order for this to work, but MetaFrame XP also requires Service Pack 5, so that shouldn’t be an issue in your environment.)

Key: HKLM\System\CurrentControlSet\Control\ Print\ Providers\LanMan Print Services\Servers
Value: LoadTrustedDrivers
Type: REG_DWORD
Data: 1

A value of “1” enables the trusted driver usage, indicating that printer drivers can only be installed from the share specified in the following registry value:

Value: TrustedDriverPath
Type: REG_SZ
Data: \\servername\sharename

After making this configuration, you must reboot in order for it to take effect.

The easiest way to produce the trusted printer driver files is to copy them from a server that already has the printer drivers installed. For complete details about the paths of driver files, see the “Managing Printer Drivers” section of this chapter. When you copy the drivers into your trusted source share, they must be under the version number folder. For example, if you copy the drivers from the “3” folder, then your drivers must be copied to a “3” folder in the sharename folder.

Advantages of Configuring a Trusted Driver Path

• Allows you to control which printer drivers are installed.
• Applies to all printer drivers, no matter how they are installed.

Disadvantages of Configuring a Trusted Driver Path

• Must be configured manually on every server.
• You still have to install the drivers before they can be used.

Solution 3. Manually Choose Alternate Printer Driver Mappings

Sometimes you will know that certain printer drivers are not compatible with Terminal Servers, but users will need to be able to print to their printers anyway. In these cases, you might be able to find “alternate” printer drivers that would work for the user.

For example, if you have clients with Hewlett Packard 8000N drivers that cause your MetaFrame XP servers to crash, you can configure your servers to use HP LaserJet 4 drivers to print to the 8000N printer. For this configuration, all you have to do is map the client driver “Hewlett Packard 8000N” to the server driver “HP LaserJet 4.” Nowhere does it say that the printer mappings must be for the exact same printers. In fact, there are some generic printer drivers, such as “HP LaserJet” or “HP DeskJet” that will work with hundreds of printer models.

An added benefit to mapping alternate drivers is that you can control the physical number of printer drivers that are installed on your MetaFrame XP servers, because you can map one server printer driver to multiple client printer models. Imagine how nice it would be if you could map 42 different laser printers to work with one generic “HP LaserJet” driver.

In some cases, mapping alternate printer drivers can also increase performance. This can happen because the spooled print file, which is transmitted via the ICA protocol to the ICA client, is created with the printer driver. All printer drivers are not created equal. Some printer drivers are very efficient, and create very efficient spool files. This is usually the case with name-brand printers. However, the whole reason that we need to use client printer mapping in the first place is because we, as administrators, do not have control over the printers that our users have connected locally to their ICA clients. They didn’t buy the name brand printer that we recommended. They bought the cheapest $25 printer that they could find at the Price Club. These printers tend to have very inefficient drivers, which means that they can easily create spooled print files that are several megabytes per page. (To be fair, the people who created these drivers probably never imagined that anyone would actually want to transmit the spooled print files across a slow network.) To combat this, you can usually find “alternate” drivers that work for some printers that are much more efficient than the printer’s native drivers. You can also use alternate black and white drivers for color printers. By definition, black and white drivers will produce smaller spool files because they will be monochrome instead of full color. Of course, your users will not be able to print in color, but monochrome is better than nothing.

When looking for alternate print drivers, whether for compatibility or for performance reasons, you can try to find these drivers through trial and error on your own. However, most administrators have better things to do and there are many resources on the Internet that maintain lists of alternate printer drivers and the printers that they seem to work with (try http://thethin.net).

The only drawback to using alternate printer driver mapping is that some of the functionality of the original printer driver on the MetaFrame XP server may not work on the printer. These functions are usually minor, like multiple paper tray settings, stapling, or duplexing options.

Advantages of Alternate Printer Driver Mapping

• Allows users to print to printers whose native drivers are not supported.
• Controls the total number of printer drivers in your server farm.
• Allows you to substitute efficient printer drivers for inefficient ones.

Disadvantages of Alternate Printer Driver Mapping

• Some printer functionality could be lost by using alternate drivers.
• You need to figure out which alternate drivers work for each printer.
• You must manually map the generic driver to the exact name of every driver it is to replace.
• If you make this change on one server, it needs to propagate to the other servers.

Configuring Printer Auto-creation for DOS or WinCE Clients

The DOS and Windows CE ICA clients only support the auto-creation of printers that are physically connected to the client device. In the real world, this is most often seen with Windows-based terminals or thin client devices at remote offices that connect to corporate MetaFrame XP servers. Auto-created client printers on these platforms will have the name clientname#LPTx, where clientname is the user’s ICA client device name and “x” is the LPT port that has the printer attached.

You can configure printer auto-creation settings on a client-by-client basis, using the Citrix Management Console (CMC | Right-click on printers | Client Printers). Use the Client Printers dialog box to add, remove, reset, edit, and delete the configuration for DOS and Windows CE client printers. These client printers are only available to the users of each individual client device.

After you configure a client printer, the ICA client software on that device downloads its printer configuration the next time an ICA session is started. This configuration is maintained in the IMA data store and can be downloaded by the client when it connects to any MetaFrame XP server in the farm. You can view the status of DOS and Windows CE client printers in the “Client Printers” dialog box in the CMC. Here, the word <downloaded> appears in the list when information for the client printer setup has been successfully sent from the MetaFrame XP server to the client device.

The fact that you can manage client printers centrally for DOS and Windows CE clients is a new feature of MetaFrame XP. Previous versions of MetaFrame required that users manage their client printers themselves, by running a Client Printer Configuration Utility from a MetaFrame server via an ICA session.

Improving the Performance of Client Printing

As discussed previously, the architecture behind the use of client printers is fundamentally inefficient, because large spooled print jobs must be sent via the ICA protocol to the ICA client to be printed. Even though some of the other printing methods that we’ll discuss later (such as server-based printers) are much more efficient than using client printers, the convenience of client printers is a compelling reason to use them. Because of this, there are some aspects of their performance that can be addressed, including:

• Limiting the bandwidth used by client printing.
• Configuring the Universal Print Driver.

Limiting Client Printing Bandwidth

Because the entire spooled print job must be sent to the ICA client when Client Printer Mapping is enabled, users with slow connections may see degraded ICA session performance. This occurs because the available bandwidth is consumed by the print job, leaving no room for the remaining ICA traffic. In order to combat this, set a limit on the amount of bandwidth that an ICA print job can take, effectively increasing the bandwidth available to the more crucial ICA functions. The bandwidth settings can be configured through the CMC, on a farm-wide basis (CMC | Printer Management | Bandwidth) or on an individual server basis (CMC | Server name | Properties | Printer Bandwidth).

Limiting bandwidth will not help print jobs finish any faster. In fact, it might cause them to be slower. However, it can lessen the impact that printing has on a user, allowing them to do other work while they wait for the print job to be spooled to their local printer.

Advantages of Limiting Client Printing Bandwidth

• Increases overall ICA session performance while printing, especially over slow connections.
• Can be configured on a farm-wide or server-wide basis.

Disadvantages of Limiting Client Printing Bandwidth

• Client print jobs could take longer.

Configuring the Universal Print Driver for Client Printer Mapping

If you’re using Feature Release 1 or 2 and your ICA clients are running on 32-bit Windows platforms, you can use the universal print driver to increase client printing speed and decrease your management of printer drivers. The universal print driver is made up of two components: the print driver that is loaded on your MetaFrame XP servers and the ICA client component that renders print jobs on the client device.

Server Component. The universal print driver is automatically installed when Feature Release 1 or 2 is installed. It is a “generic” printer driver, capable of generating 300dpi monochrome print jobs that can be sent to any printer. This driver receives print jobs that are printed to it, and sends them to the ICA client to be spooled and printed.

Client Component. Support for the universal print driver is built in to the Windows 32-bit ICA client version 6.20 and newer. The ICA client receives unspooled print jobs from the MetaFrame XP server, spools them, and sends them directly to the user’s printer.

How the Universal Print Driver Works

With regular client printing in MetaFrame XP environments, the print job is created and rendered for the printer on the MetaFrame XP server. As you recall, this involves creating the enhanced metafile, which is then translated to a printer-specific spool file. This large spool file is then transmitted to the ICA client device. When the universal print driver is used, this process changes a bit, as shown in Figure 7.6.

Figure 7.6: The universal print driver in action

• The user prints from their application running on the MetaFrame XP server with Feature Release 1 or 2.
• The application creates the EMF file on the MetaFrame XP server.
• The EMF file is sent to the print spooler on the MetaFrame XP server.
• The print spooler uses the appropriate printer driver to create the spool file in preparation for printing on the client’s printer. In this case, the driver used is the Citrix “universal print driver.” This driver creates a very efficient PCL4 file, instead of a standard print spool file.
• The universal print driver sends the PCL4 file to the ICA client via the background printing channel in the ICA protocol. The PCL4 file is not printer-specific. It is very small and efficient.
• The Windows 32-bit ICA client, version 6.20 or newer, receives the PCL4 file. It transfers the file to the ICA client’s universal print driver component.
• The client’s universal print driver component produces the print job’s spool file, based on the client’s local print driver.
• The print job is sent to the appropriate printer.

As you can clearly see, with the universal print driver, client printers can be used with much more efficiency than when regular print drivers are used. Because the universal print driver is not printer-specific, it can be used to print to virtually any printer. This means that you do not have to worry about managing too many printer drivers on your MetaFrame XP servers. The more printers that can use the universal print driver, the fewer drivers you will need to install.

Of course there is a down side to this added convenience and performance. In this case, the universal print driver can only generate print jobs in black and white, and they are limited to 300 dpi. This does not mean that users can’t print to 1200 dpi color printers. It just means that those printers will only produce 300 dpi monochrome output when used with the universal print driver.

In the real world, 300 dpi monochrome should be sufficient for most business documents. If your users have needs to print in color or at higher resolution, you’ll need to either use the printer’s regular driver or connect to the printer as a server printer (covered in the next section).

Advantages of the Universal Print Driver

• Significantly increases print speeds, especially over slow connections.
• Prevents you from having to install and manage individual print drivers on all of your MetaFrame XP servers.

Disadvantages of the Universal Print Driver

• Requires Feature Release 1 or 2.
• Requires Citrix ICA clients version 6.20 or greater.
• Only works with the 32-bit Windows clients.
• Limited to 300 dpi, monochrome.
• Does not use advanced features of printers.

Configuring the Universal Print Driver

All universal print driver configuration is done via the Citrix Management Console (CMC | Right-click Printer Management | Properties). In addition to specifying whether or not you want to auto-create client printers at logon and what type of printers you want to create (default only, non-network, all, or inherit user configuration), you can control how you want the universal print driver to be used. There are four options:

• Native Drivers Only. This setting will disable the universal print driver. If the server cannot find the native printer driver for a user’s client printer, then that printer will not be available during the user’s session.
• Universal Driver Only. This setting will cause the MetaFrame XP servers to ignore any print drivers that are installed when connecting to users’ local client printers. If you use this, then you do not need to have any printer drivers installed on your servers to support client printers, other than the universal print driver.
• Both Universal and Native Drivers. Selecting this option will create a printer object for each client printer using the universal print driver. In addition, for any printers that also have regular printer drivers installed, another printer object will be created. This means that some printers will show up on the user’s list twice. The only difference is that the printer using the universal print driver will have the text [MF:PCL4] at the end of the printer name. The idea behind this is that it gives users flexibility by letting them choose the driver to use. However, it can be confusing to users because they see the same printer on the list twice. Most likely they will end up printing to the printer using the regular driver, because that will show up first in the list (alphabetical order). In case you’re wondering, you might have read some of the Citrix ad copy advertising that users were able to switch between the universal driver and the regular driver at any time. This is not some sort of fancy feature of the ICA client software, rather, it’s possible when using this option, because the user can choose which printer driver to use at the time of printing.
• Universal Driver Only If Native Driver Unavailable. This option is the default, and probably works best for most real world situations. Many people use this as a sort of “catch all,” allowing users to print with the universal driver if they connect to the server with an unsupported printer.

Server Printers

Instead of dealing with the many complexities of client mapped printers, you can instead choose to use server-based printers for printing in your MetaFrame XP environment. A server printer in a MetaFrame environment, just like in any environment, is any printer that is directly available via a server’s print queue. This print queue can be Windows or NetWare, client or server based. Basically, any printer that can be accessed via a \\computername\ printername sharename is a server printer.

From within ICA sessions running on MetaFrame XP servers, users can set up their own server printers if they have permissions to connect to them. As an administrator, you can configure server printers for your users with logon scripts or roaming profiles. Actually, server printers are used and accessed in MetaFrame XP sessions just as they are in any Windows environment.

A server printer can also be a printer that has a print queue directly on a MetaFrame XP server. This could be a printer that is physically connected to the local LPT port of a MetaFrame XP server or an IP printer that has a print queue locally on a MetaFrame XP server.

Remember, if a user has a server printer mapped on his own computer before he launches an ICA session on a MetaFrame XP server, that server printer can be available during his session. However, that printer would be a client mapped printer (as covered in the previous section in Figure 7.4), not a true server printer. A true server printer is mapped directly to the print queue from the user’s session on the MetaFrame XP server, as shown in Figure 7.7 (next page).

Figure 7.7: Server Printers: in a MetaFrame XP environment

You’ll notice when using server printers that if the print servers are on the same network as the MetaFrame XP servers, then printing performance is excellent. In fact, printing in this type of environment is no different than printing in any network environment. This is most often seen when the users, MetaFrame XP servers, and printers are all located in the same building.

• The user prints from his application running on the MetaFrame XP server.
• The application creates the EMF file on the MetaFrame XP server.
• The EMF file is sent to the print spooler on the MetaFrame XP server.
• The print spooler creates the spooled print job, in preparation for printing on the network printer. The MetaFrame XP server has the proper drivers loaded for the network printer.
• The spooled print job is sent to the network print server.
• The network print server queues the print job to the printer.

Unfortunately, server printer performance is not as good in remote environments, where the users and printer are located in one building and the MetaFrame XP servers are located in another.

Advantages of Using Server Printers

• Good performance.
• Reliable.
• Users receive the same printers no matter where they log in.

Disadvantages of Using Server Printers

• No local printer support.
• Users must browse the network for printers that are not configured.
• Printers must be configured for each user.
• To get good performance, the print server must be located in the same building as the user.

Thankx to Brian Madden…