Citrix MetaFrame XP

Christa Anderson

Keep sponsor logos below here

RTM

tm

rea l t imepubl i shers .com

The Definitive Guide Totm

Chapter 7

Chapter 7: Managing Printers ......................................................................................................183

Background: How Printing Works...............................................................................................183

Using MetaFrame XP to Manage Printing.......................................................................185

Importing Network Print Servers.....................................................................................186

Managing Printer Drivers ................................................................................................188

Distributing Printer Drivers .................................................................................188

Using Driver Compatibility .................................................................................192

Mapping Mismatched Driver Names...................................................................193

Assigning Printers to User Accounts ...............................................................................194

Copying Auto-Creation Settings..........................................................................196

Auto-Creating DOS and WinCE Printers ........................................................................196

Throttling Bandwidth for Client Print Jobs .....................................................................198

Summary ......................................................................................................................................200

Chapter 7

Chapter 7: Managing Printers

If you’ve worked with server-based computing at all, your favorite task is probably managing printing—in roughly the same sense that your favorite pastime is having a root canal. Printing in a server-based computing environment is even more complicated than printing in a client-centric network. Not only do you have all the fun of installing and supporting printers, but you must also contend with the problems that arise from creating and printing from a shared computer. When you add support for mapping client-side printers to the mix, supporting printers in a server-based environment can really get problematic. This chapter will cover the following topics:

• How printing works in a server-based computing environment.

• The features of MetaFrame XP and FR1 that make it easier to manage printing and how to use those features, including

• Importing network printers so that you can manage them from the Citrix Management Console.

• Assigning printers to people.

• Bandwidth throttling tools.

• Printer driver distribution.

• The universal printer driver in FR1 and what it can and can’t do.

• How to selectively enable and disable automatic client printer mapping.

Background: How Printing Works It’s easier to understand why printing in a multi-user environment can get complicated if you’re familiar with how the basic Windows printing model works. There are four main parts involved in getting a print job from the computer on which it’s generated to a printer:

• Graphics device interface (GDI)

• Printer driver

• Print spooler

• Port monitor

When you send a print job to a printer, the GDI is the first point of contact. It’s responsible for creating visual output, whether that output is to a display or to a printer. The GDI calls the appropriate printer driver, providing information about the print device to be used and the data type used to generate the job—RAW or Enhanced MetaFile (EMF). Because we’re talking about a print job generated on a Win2K computer, the data type will always be EMF, meaning that the print job will be pre-formatted before it gets to the printer.

The topic of data types isn’t really germane to this discussion, but if you’re interested in more detail, I’ve explained the RAW and EMF data types in Mastering Windows 2000 Server (Sybex).

183

Chapter 7

The core Win2K OS is not designed to communicate directly with printers—if it were, Microsoft would have had to build into the OS support for every printer imaginable and apply patches every time a new printer was released. Rather, printer drivers play the role of middleman between OS and printer. Printer drivers are specific to a given OS, even among Win32 OSs. A printer driver isn’t monolithic. It’s actually three sub-drivers that work together as a unit. A printer graphics driver renders the GDI commands into Device Driver Interface (DDI) commands that can be sent to the printer. The printer interface driver provides the settings information about the printer and is the liaison between the printer graphics driver and the characterization data file. This file provides capability information about what a particular make and model of printer can do: resolutions supported, color capabilities, the use of double-sided paper, and so on.

When the printer driver has prepared a print job to be created on the appropriate printer, the printer driver passes the job to the print spooler, a collection of DLLs and device drivers that receive, process, schedule, and distribute print jobs. Like the printer driver, the print spooler is actually several pieces working together: a print router, spool file, and print processor. The client’s print router (on the computer generating the print job) communicates with the server’s print router via remote procedure calls (RPCs). When the print server’s print router gets the print request, it passes the request to the appropriate print provider—a local print provider if the printer is attached locally or the network print provider if the printer is network-accessible. To find the right print provider, the print router polls the Windows print provider. This provider then finds the connection that recognizes the printer name and sends an RPC to the print router on the print server. That local print provider then writes the contents of the print job to a spool file—a file containing both the file to be printed and the information required to print it—and tracks administrative information for that print job. After the print provider has created the spool file, the print processor works with the printer driver to send the spool file to the printer.

The print monitor is the final link in the chain, getting the print job from the client application to the print device. It’s actually two monitors. The language monitor, created when you install a bi-directional printer driver that can send meaningful messages about print job status to the computer, sets up the communication with the printer, then passes control to the port monitor. The port monitor transmits the print job to either the print device or to another server. It controls the flow of information to the I/O port to which the print device is connected. The print job was already configured by the print processor, so the port monitor must only worry about shooting the print job out the correct port.

The process works much the same when the print job is initiated from an application running on a MetaFrame server instead of an application running on a client computer. From the client’s perspective, once a printer is available, printing from an ICA session is usually no different than printing from an application running on the local computer, whether the client is printing to a network printer, a local printer directly attached to the MetaFrame server, or a client printer attached to the client computer and automatically mapped to the ICA session.

People don’t necessarily connect to a single MetaFrame server for all their work, and there may be more than one printer on the network. In other words, every MetaFrame server needs to have drivers for all the printers on the network that the people using that MetaFrame server are using, whether those printers are shared on the network, attached directly to a MetaFrame server, or client-side printers mapped to an ICA session. That means that you must install drivers on all the MetaFrame servers and you must be absolutely sure that those drivers are safe to install. Buggy printer drivers can crash a computer. Crashes are a pain in a single-user computer, but when that

184

Chapter 7

computer is a MetaFrame server providing applications to some dozens of people, crashes are decidedly to be avoided. However, the way that Win2K works means that printer drivers get automatically installed when a connected printer is called on.

Speaking of mapping client-side printers to ICA sessions, that alone opens a whole can of worms. If the clients aren’t using Win2K Pro, the names of drivers installed on the Win2K-based MetaFrame server and the client may not match—and they must match for printing to work. If the print job is sent to a client-side printer mapped to an ICA session, the print job will travel along one of the ICA channels, such as sound or 24-bit color. Thus, print jobs sent over slow network connections will not only take a long time, but will impact the ICA sessions trying to use the same network path.

Using MetaFrame XP to Manage Printing Because this book is about MetaFrame XP, you won’t be surprised to hear that MetaFrame XP has some features designed to reduce or eliminate printing problems. MetaFrame XP doesn’t do everything when it comes to fixing printing, but it’s a start. It supports assigning printers to user accounts, throttling bandwidth to reduce impact on ICA sessions, and automatically distributing printer drivers. Installing FR1 adds support for another printing enhancement, a Universal Printer Driver that lets people print to any printer without installing a driver for that printer. (For more information about this Universal Printer Driver, see the sidebar “Understanding FR1’s Universal Printer Driver.”) The Citrix Management Console controls most printer management, including:

• Managing print servers on your network by importing their information into the console.

• Updating or discarding print server information.

• Copying printer drivers from one MetaFrame server to another.

• Maintaining printer driver compatibility.

• Assigning selected network printers to users at logon.

• Mapping client printer drivers to MetaFrame server printer drivers when the names don’t match.

• Auto-mapping DOS and WinCE client printers.

• Configuring auto-creation and driver usage for client printers (with FR1 installed).

• Throttling the bandwidth print jobs sent over an ICA connection.

185

Chapter 7

Understanding FR1’s Universal Printer Driver Although the Universal Printer Driver is only an option for those of you who’ve installed FR1, I’m going to be mentioning it often enough that you should know what it is up front. Essentially, the Universal Printer Driver is Citrix’s answer to two of the fundamental problems of printing to client printers mapped to ICA sessions: driver support and bandwidth restrictions. The Universal Printer Driver isn’t the only answer to this problem. One company attempted to resolve the difficulty of supporting client-side printers by printing all documents to an Adobe Acrobat file, which was then sent to the client for rendering and printing. Another approach compresses the UDF file generated on the server, then sends the file to the client to be made into a spool file and printed there.

The Universal Printer Driver approach is a little different from either of those. In this case, a Printer Control Language (PCL) driver installed on the printer will work with any printer, realize some bandwidth compression for print jobs sent to non-PCL client printers, and let clients print from applications in ICA sessions without needing a driver specific to their printer installed on the server. This last benefit is the real point here: Using the Universal Printer Driver can seriously reduce the number of print drivers in the data store. Because Universal Printer Driver-based print jobs are limited to 300dpi black-and-white documents, the Universal Printer Driver probably won’t replace the drivers for the high-end color printers. But 300dpi is perfectly acceptable for printing most documents so long as they don’t include photographs.

Importing Network Print Servers A network printer installed on a MetaFrame server will be available to the people using that server, assuming that they have permission to use it. You don’t need to do anything special to get the printer to people. If you want to be able to manage the printer from the Citrix Management Console, however, you’ll need to import it into the farm. The print server does not need to be a member of the farm—or even need to have MetaFrame installed—to be imported. It can even be in a separate domain from the one that the MetaFrame server farm is in, so long as the two domains trust each other.

Not sure whether a print server will be available? See Chapter 3 for a brief discussion of how trust relationships work in Win2K.

To import a network print server into the farm, go to the Printer Management section of the Citrix Management Console, right-click the section’s icon, and select Import Network Print Server from the context menu to open the dialog box that Figure 7.1 shows.

186

Figure 7.1: Import network print servers to manage printers from the Citrix Management Console.

Chapter 7

This dialog box has a couple of oddities that can trip you up if you’re not careful. First, name the print server as I’ve done here—without using the backslashes (\\) that you would normally use to precede a server’s name in a UNC name. Second, the first time you attempt to import a network print server, the dialog box will automatically populate the Connected As field with the name and domain (but not the password) of the person logged on to use the Citrix Management Console. Filling in a name and password isn’t necessary, and in my experience, can lead to authentication errors. After you’ve successfully imported one network print server, the Citrix Management Console will try to use that account information to import other servers.

If you’re having trouble authenticating on the remote print server, try leaving the Connected As and Password text boxes blank. All the printers on the server that are available to everybody will be imported.

Imported print servers appear on the Network Print Servers tab of the Printer Management section of the Citrix Management Console, as Figure 7.2 shows. They’re also listed in the Printers section of the Printer Management section of the Citrix Management Console.

Figure 7.2: Imported network print servers will appear in the Citrix Management Console.

The imported print server information is not static. To update it from the remote print server, right-click the name of the server, and select Update Network Print Server from the context menu. You’ll be prompted for a user name and password again; fill in the information you supplied to connect to the server in the first place, and click OK. You won’t see any obvious feedback, but the date and time of the last update (visible on the Network Print Servers tab in Figure 7.2) will change.

187

To delete a print server from the farm entirely, just choose Discard Network Print Server from the context menu. A confirmation dialog box will ask you whether you’re sure that you want to delete the network print server. Assuming that you are, click OK.

Chapter 7

Managing Printer Drivers The process of installing a printer driver on a MetaFrame server is identical to installing a printer driver on any Win2K-based computer. You can go through the Add Printer wizard and add a connection to a local or network printer, deploy printers to computers using Group Policy Objects (GPOs), or add a printer programmatically with a script or batch file. Installing support for printers installed on a client computer and mapped to an ICA session is even easier—they should install without any intervention from you.

However, you won’t want to be quite this laissez-faire about installing drivers. First, it’s probably too much trouble to manually set up printer connections on all the MetaFrame servers. Second, manually installing all the printer drivers gives you less control over the choice of driver than you will probably want, particularly when it comes to those automatically-installed client printer drivers. Let’s chat about how to get drivers from one server to many servers (with the Replicate Drivers command) and how to control which drivers get installed (with Driver Compatibility).

Distributing Printer Drivers In Win2K Terminal Services and previous versions of MetaFrame (earlier than MetaFrame XP), you exercise some level of control over printer drivers by manually editing the registry to point to a specific driver server. However, doing so doesn’t actually replicate the drivers, it just points servers to a specific source for them. If you clone a working MetaFrame server, all the clones have the drivers installed on the original server, but any later edits are (obviously) not distributed. MetaFrame XP makes the process of installing and updating drives on MetaFrame servers much easier.

First, install the drivers that you’ll use in the server farm (including the drivers used by client-mapped printers, if possible) on one particular MetaFrame server. Test the drivers now to make sure that they won’t crash the server—the last thing you want to do is replicate buggy drivers.

When you’ve finished installing the good drivers on one server, you’re ready to replicate those drivers to the other MetaFrame servers in the farm. In the Printer Management section of the Citrix Management Console, there is a subheading for Drivers. Right-click the Drivers icon, and select Auto-replication from the context menu to open the dialog box that Figure 7.3 shows.

188

Chapter 7

Figure 7.3: When you start, no drivers are automatically replicated among MetaFrame servers.

The first step here is to pick the platform from the drop-down list at the top of the dialog box. Win2K and WTS do not use the same drivers, and replicating mismatched drivers could hurt the MetaFrame servers. Only the OSs found in the server farm will be listed, so if you’re running nothing but Win2K you needn’t worry about this step.

After you’ve picked the OS, click Add to add a new driver to replicate, using the dialog box that Figure 7.4 shows.

Figure 7.4: Adding a new driver to replicate.

189

Chapter 7

This dialog box provides a list of all the drivers in the farm; you’ll only see specific servers named if you select a driver from the list. To choose a driver to replicate, first go to the drop-down list at the top of the dialog box, and select the server on which you’ve installed all the good drivers. This server will be the replication source.

Make sure that you choose a server to replicate drivers from, rather than sticking with the default of Any. Letting any server be the source of driver replication can lead to version problems and unnecessary traffic. The only reason to choose Any server is when the same drivers are available on more than one server.

Next, pick a driver to replicate. In the dialog box in Figure 7.4, there’s really only one option, since the PCL4 Universal Driver is automatically installed on any MetaFrame server running FR1 and servers not licensed to run FR1 can’t use it. Select the driver so that the servers it’s installed on appear in the right-hand pane. If you want the driver installed on this server to overwrite any other versions of the driver that may be installed on other MetaFrame servers—and because this server has all the drivers that you previously tested, you presumably do—select the Overwrite existing drivers check box in the lower left-hand area of the dialog box. When you’ve selected the driver to replicate, click OK to return to the Auto-replication dialog box as it appears in Figure 7.5, and click OK when you’re done adding drivers. You’ll see a dialog box telling you that the drivers will be replicated as server load allows.

Figure 7.5: Drivers chosen for replication.

That’s how you set up drivers for replication. Whether or not you should replicate drivers, and when you should do it, is another matter.

190

Chapter 7

We talked about the data store in Chapter 3. As you may recall, the data store includes entries for all the objects in the server farm. Among those objects are individual servers, printer drivers, and printer drivers on individual servers. In other words, adding one printer driver to one new server in a farm adds three entries to the farm’s data store. Installing three printer drivers on five existing MetaFrame servers adds eighteen entries—plus the entries for the servers themselves. The larger the data store, the longer it takes the IMA Service to begin, and the longer it takes MetaFrame servers to boot. A larger data store also increases the time and bandwidth required to replicate it.

Some increase in the size of the data store is inevitable—if you have a large MetaFrame server farm, you’ll have a large data store. However, just as you can often control your own weight gain by watching what you eat, you can control the data store’s size gain by watching what you put into it. First, don’t assume that every driver in the farm needs to be installed on every server. Perhaps it does, but that’s not the position you want to start from. This is true particularly if you’ve divided the server farm into geographically distinct zones. The people in the Washington D.C. office probably won’t often use the printers located in the Boston office—doing so would make collecting print jobs a major nightmare. For that matter, never install all the printer drivers to save time later. Installing a printer driver takes very little time, and certainly less than managing a data store that’s larger than it needs to be.

Second, see if you really need different drivers for each printer. If you’ll be supporting different printer types that can use the same printer driver, load only one printer driver and install all of the printers it supports to use it.

Third, if you stop using a printer, uninstall its driver and delete its registry entry (located in HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Windows NT x86\Drivers\Version-3\; look for the driver you’re no longer using). After you’ve done so, reboot the server. This process will delete the driver more thoroughly than just uninstalling it.

Before cloning a MetaFrame server, uninstall any drivers that other MetaFrame servers will not use. You can replace them on the source server later and not installing them may prevent you from widely distributing printer drivers that don’t need to be on the other MetaFrame servers; thereby, inflating the data store.

Finally, if you have FR1 installed on your server farm, use the Universal Printer Driver so far as you can. As I explained a little earlier in this chapter, the Universal Printer Driver probably won’t replace more specific Windows drivers in all cases. However, it’s a good basic print driver for black-and-white low-resolution printing, and having it around may enable you to lighten the printer driver load in the farm data store, particularly when it comes to supporting client-side printers automatically mapped to ICA sessions.

In addition to the stress that adding printer drivers puts on the IMA Service, you need to take into account the time required to replicate the printer drivers—a job done independently from routine IMA traffic. In small farms, this replication should take almost no time at all. According to Citrix, in a 50-server farm with a light user and network load, the printer driver replication subsystem can process about 50 driver replications per minute. Even in a large farm of 500 servers, the driver replication subsystem can handle about 20 entries per minute so long as the MetaFrame servers and the network aren’t too stressed. If the MetaFrame server supplying the drivers gets too busy, the printer driver replication subsystem will slow the replication speed. Therefore, to replicate drivers quickly it’s best to replicate when the network is not too busy. To

191

Chapter 7

start replicating drivers in the server farm, go to the Printer Management section, and click the button that looks like a gear with three arrows pointing out from it.

Curious to see the replication process? If you select a driver on the Drivers section of the Printer Management section of the Citrix Management Console, the list of MetaFrame servers on which that driver is installed will appear in the right-hand pane. There is also a utility called qprinter on the MetaFrame XP FR1 CD-ROM that you can use to monitor replication from the command line with the /replica switch.

Using Driver Compatibility Getting good drivers to the MetaFrame servers is important; equally important, however, is keeping bad drivers off the MetaFrame servers. Bad drivers are particularly a problem when it comes to supporting client printers mapped to ICA sessions, because in that instance, you don’t have a whole lot of control over the process. Using MetaFrame XP, you can configure a server farm either to accept new drivers only from a preset list, forcing everyone else to use the UPD if it’s available, or to accept any drivers except those on a preset blacklist. Here’s how.

Right-click the Drivers icon, and select Compatibility from the context menu to open the dialog box that Figure 7.6 shows.

Figure 7.6: You can restrict the printer drivers installed to support client printers.

Again, choose the server platform; if you’re running a Win2K-only server farm, this selection has already been done for you. Next, decide how you want to structure the blacklist: permitting only the drivers you list or permitting any drivers but the ones you list. (For obvious reasons, you

192

Chapter 7

need to be careful to pick the right one or your driver restriction list will be backwards.) Click Add to open the dialog box that Figure 7.7 shows, in which you’ll type the names of drivers that you want to specifically allow or exclude.

Although you can also choose drivers from the drop-down list, the only drivers listed here are those already installed. The drop-down list is useful only if you’re creating a list of drivers that must be used, not a list of drivers that mustn’t.

Figure 7.7: Type the name of the drivers that go on your restricted list or choose installed drivers from the list.

When you’ve picked a driver, click OK. You’ll need to re-open the Add Driver dialog box for each driver in the list.

Mapping Mismatched Driver Names For client printer mapping to ICA sessions to work, the drivers used on the client and server need to have the same name. This requirement won’t cause any problems if both client and server are running Win2K, but may not work properly if the client is running an operating system that is not NT-based, say, Win98. Those using RDP-based terminal services without MetaFrame will need to manually edit a printer information file to, in effect, tell the server “Now, when I say this driver name I really mean that one.” In MetaFrame XP, you need to do the same thing, but MetaFrame XP is set up to let you do it through the Citrix Management Console.

To map mismatched client and server driver names, go to the Drivers section of Printer Management. On the Drivers tab, right-click any installed driver, and select Mapping from the context menu to open the dialog box that Figure 7.8 shows.

193

Chapter 7

Figure 7.8: You can now perform driver mappings from the Citrix Management Console.

Click Add to open the dialog box that Figure 7.9 shows, and type the name of the client and server drivers you’re mapping. (You can choose drivers already installed on the server from a drop-down list.) Type the driver names carefully or the mapping won’t work. Notice that with FR1 installed, one of the server-side options is the Universal Printer Driver.

Figure 7.9: Type the name of the client driver and choose the name of the installed server driver to associate with it.

When you’re done with each mapping, click OK in the Add Mappings dialog box to return to the Driver Mapping dialog box. The drive mappings you’ve created will appear in the list.

Assigning Printers to User Accounts MetaFrame XP lets you associate farm printers with user accounts. I’m not convinced that this method is the better approach, because the printer you normally want to use often has more to do with your physical location than your identity, and someone connecting via ICA connection may be using the MetaFrame server from more than one computer--even more than one building, or more than one city. At the very least, I’d like the option of associating printers with client computer identity instead of just user identity. That said, associating a printer with a particular

194

Chapter 7

user means that that user can print to the same printer from all the published applications that the user is using, regardless of which MetaFrame server in the farm the user is using. Not a bad plan.

To associate printers with user accounts, go to the Printers tab of the Printer Management section of the Citrix Management Console. Right-click an installed printer, and select Auto-Creation from the context menu to open the dialog box that Figure 7.10 shows. (The Add List of Names button is only visible if you have FR1 installed, and the same goes for NDS domains in the Look In drop-down list.)

Figure 7.10: You can choose group or user accounts from any trusted server or domain.

This dialog box works like most of the rest of its kind; if you’ve used Win2K at all you’ve used dialog boxes like this one. To add a printer for the use of a group in a domain or on a server, double-click the icon for the domain or server to display all the groups. To show individuals within groups, select the Show Users check box. You must add individuals or groups to the Configured Accounts text box; to do so, just click Add, which is enabled when you select a group or individual account from the list. The added users or groups will appear in the Configured Accounts box.

For the FR1-using folk intrigued by the Add List of Names button, it’s for adding individuals without having to know which group they’re in. When you click the button, you’ll open a dialog box like the one in Figure 7.11. Type the name in an acceptable format (domainname\username for NT 4.0-style domains; username@domainname.com for Win2K-style account names; and ndstree\account for NDS account names). To be sure that you typed the account names correctly, click Check Names. The Citrix Management Console will make sure that you formatted the account name correctly, then check with the security database for the domain or directory tree and either tell you that the names checked out or that they did not.

195

Chapter 7

Figure 7.11: Manually type in domain and user account information.

When you’re done, click OK to return to the Auto-Creation Settings dialog box for the selected printer. The user names you added will be in the Add List of Names dialog box. When you click OK, the printer will be assigned to the users and groups you chose.

You can add users both from the drop-down list and from the Add List of Names dialog box—the two won’t cancel each other out.

Copying Auto-Creation Settings If you want the users and groups you’ve got using one printer to get support for another one, you don’t have to start from zero. Rather, you can copy the Auto-Creation settings from one printer to another. From the Printers tab we started at, right-click the printer that you just configured, and select Copy Auto-Creation Settings from the context menu. From the dialog box that opens, pick the printers to which you want to copy the settings, then click OK.

Auto-Creating DOS and WinCE Printers By default, Win32 client printers are automatically mapped to any ICA sessions initiated from that computer, and the printers and drivers available to those clients depend on the server they connect to. Sessions initiated from DOS and WinCE clients are different—ICA won’t automatically use any printers local to the client computer. You can create the mappings manually, however, and once you’ve done so the Citrix Management Console will automatically map the ICA sessions for those client devices to the locally installed printers.

To auto-create client printers, right-click Printers in the Citrix Management Console, and select Client Printers from the context menu to open the dialog box that Figure 7.12 shows.

196

Chapter 7

Figure 7.12: You’ll need to manually associate DOS and WinCE devices with their client printers.

As you can see, by default, there aren’t any manual client printer mappings. To create one, click Add to open the dialog box that Figure 7.13 shows, in which you’ll name the client device and its printer and—more important—pick the driver and any necessary driver mappings to use. Also, DOS and WinCE printing require an explicit port assignment, so choose that as well. When you’re done, click OK to return to the Client Printers dialog box. The next time a user using the client you named initiates an ICA session, the user’s client printer will be mapped to his or her session.

Figure 7.13: You’ll need to use driver mappings to make DOS printers map to a MetaFrame XP session.

197

Chapter 7

You can change the way that printers are assigned to all ICA sessions—DOS, WinCE, or Win32—by right-clicking the Printer Management icon, and selecting Properties to open the dialog box that Figure 7.14 shows.

Figure 7.14: Edit the client printer mapping settings from Printer Management.

Most of these settings are pretty straightforward. The default settings you see here will auto-create client printers at logon (and thus install the appropriate printer driver on the MetaFrame server if it isn’t already there), has server-specific connection settings for printer availability, and installs the Universal Printer Driver available with FR1 only if the other driver is not available on the MetaFrame server—a definite possibility, depending on just how old the printer is. One of my favorite tweaks to do here is edit the settings to make the client printers use the Universal Printer Driver on the server. Doing so eliminates any problems from buggy printer drivers and also keeps one-time use printer drivers out of the data store. The other obvious setting here is the check box at the top of the dialog box: clear this Auto-create client printers when user logs on check box and you don’t have to worry about any of this. (People won’t be able to print to their local printers from their ICA sessions either, but that’s not always necessary.)

Throttling Bandwidth for Client Print Jobs The last new addition to printing that MetaFrame offers is bandwidth throttling, the ability to limit the amount of bandwidth available to print jobs. As we discussed earlier in this chapter, this feature is important because of the amount of bandwidth print jobs can use. Any time you print a file, the spool file created for the print job is much larger than the file it’s based on, and that spool file usually isn’t processed locally, but has to get to a client’s mapped printer or a network printer. It gets to that client printer via ICA channels, using the same network connection that the ICA connection is using. In other words, printing to client-side printers represents a potential

198

Chapter 7

traffic jam that can make ICA sessions less responsive since they’re competing for bandwidth with a print job.

One way to get around this problem is to compress the spool file itself, and that’s the approach the Universal Printer Driver takes—compressed in comparison to print jobs created for non-PCL printers, anyway. The compression doesn’t do anything for jobs for PCL printers. Another approach is to leave the size of the print job alone, but restrict the amount of bandwidth allocated to it. That’s MetaFrame XP’s other tack: restricting the amount of bandwidth that print jobs using ICA channels can use. With the bandwidth restricted, the print job may take a while, but it won’t interfere with the ICA session using the same network path as much as it would otherwise.

To restrict the amount of bandwidth that print jobs can use, turn to the Bandwidth tab of Printer Management. Initially, the screen will look like the one that Figure 7.15 shows—normally, all MetaFrame servers permit print jobs to client printers to use as much bandwidth as they need.

Figure 7.15: Normally, all MetaFrame servers in the farm can use unlimited amounts of bandwidth for print jobs.

To reduce the amount of bandwidth for a specific printer (perhaps the one reserved for the people connecting to the farm via a 56Kbps dial-up connection), right-click the server’s icon and select Edit (no, the menu item’s name isn’t very intuitive) from the context menu to open the dialog box that Figure 7.16 shows. As you can see, you will need to know just how much bandwidth you’re willing to allocate to print jobs using ICA channels. The restrictions are not percentage-based, but absolute—you will need to do your homework ahead of time so that you know how much bandwidth a given server has to work with. When you click OK, you’ll be back at the Bandwidth tab, with the space permitted to print jobs listed in the Bandwidth Limit column.

199

Chapter 7

Figure 7.16: You’ll need to know the bandwidth available to a server before you restrict it.

The amount that you pick may require some tweaking later. Too much bandwidth may cause print jobs to slow ICA sessions. Too little, and print jobs will take forever. The fewer ICA channels that sessions are using, the more you can allocate to printing. An ICA session not using mapped drives or sound requires less bandwidth than one going whole hog on ICA client features.

While the absolute use of bandwidth instead of percentages makes copying the settings a dicey business for servers not completely identical, you can do this. Right-click the server you’ve restricted, and select Copy from the context menu. From the dialog box that appears, choose the server to which you want to copy the bandwidth restrictions, and click OK.

Summary Email and the Web have done a little in this regard, but the paperless office never really happened. Like it or not—and we frequently don’t—we have to support printing. In this chapter, you learned about the ways that MetaFrame XP makes printing a little easier, with printer driver distribution, bandwidth throttling, client printer assignments, and (with FR1) a Universal Printer Driver that can reduce the impact that client-installed printers can have on MetaFrame servers.

That’s been it for basic MetaFrame server management. In Chapter 8, I’ll cover some more advanced management that you may not need when you first set up your MetaFrame server farm, but will undoubtedly get around to sooner or later—auditing, security, restoring the data store, and the like.

200

Chapter 7

201

Copyright Statement © 2001 Realtimepublishers.com, Inc. All rights reserved. This site contains materials that have been created, developed, or commissioned by, and published with the permission of, Realtimepublishers.com, Inc. (the “Materials”) and this site and any such Materials are protected by international copyright and trademark laws.

THE MATERIALS ARE PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. The Materials are subject to change without notice and do not represent a commitment on the part of Realtimepublishers.com, Inc or its web site sponsors. In no event shall Realtimepublishers.com, Inc. or its web site sponsors be held liable for technical or editorial errors or omissions contained in the Materials, including without limitation, for any direct, indirect, incidental, special, exemplary or consequential damages whatsoever resulting from the use of any information contained in the Materials.

The Materials (including but not limited to the text, images, audio, and/or video) may not be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any way, in whole or in part, except that one copy may be downloaded for your personal, non-commercial use on a single computer. In connection with such use, you may not modify or obscure any copyright or other proprietary notice.

The Materials may contain trademarks, services marks and logos that are the property of third parties. You are not permitted to use these trademarks, services marks or logos without prior written consent of such third parties.

If you have any questions about these terms, or if you would like information about licensing materials from Realtimepublishers.com, please contact us via e-mail at info@realtimepublishers.com