Inside Windows Server 1002003 [Electronic resources] نسخه متنی

Printer Sharing

There's a high level of "print rage" among users. I think this is because users think that printing is a trivial thing that any numbskull should be able to get working. They don't realize that network printing involves a complicated set of technologies with devices and drivers and interface boxes from a myriad of vendors.

In this section, we'll take a look at how to configure network printing in Windows Server 2003 and how to avoid as much user wrath as possible by anticipating potential difficulties.

Functional Description of Network Printing

Figure 16.19 shows a diagram of a typical printing system layout. The fact that it resembles a game of Mousetrap is not coincidental. Rube Goldberg would have been astonished at the complexity of the transactions involved in turning a word on a screen to a word on a piece of paper.

Here is the sequence of events when a user sends a print job to a Windows print server:

• The user's application calls on Win32 to take the on-screen document and deliver it to the appropriate services for print rendering.




• Win32 works with the Graphics Rendering Engine to turn the document into an intermediate format called a metafile that can be transported quickly across the network. The job is spooled both before and after this rendering.




• The spooler hands the metafile to a network print provider, which then delivers it to the print processor service on a Windows print server.




• The print processor service renders the metafile into a set of printer commands and saves that to a file, which is spooled to disk.




• The spooler hands the file to a Printer Monitor service that delivers it to the print device.




• The print device applies toner/laser/sublimated dye to paper/emulsion/coffee mugs and, like an egotistical actor, takes credit for all the work done by the rest of the system.

Initial Job Rendering

The transactions in a network print job are set in motion when a user clicks the Print button inside an application. What happens at that point depends on the platform and the type of application:

• Native 32-bit Windows applications use Win32 API calls to render the page on-screen into a form that can be processed by a printer.




• 16-bit Windows applications use Win16 API calls that are interpreted by the Windows16-on-Windows32 subsystem, or WOW, that converts them into the equivalent Win32 API calls.

  When Is a Printer Not a Printer? If you are unfamiliar with Windows parlance, the term printer can trip you up. A physical printer is called a print device . In Windows, a "printer" is a logical object, not a physical one. You create a printer by configuring a set of drivers at a server or workstation. You would say, "I created a printer on this server using the HPLJ8000 driver." The nomenclature becomes even more convoluted when you talk about devices such as the HP JetDirect or the Intel NetPro. These are often called "print servers," but in Windows, a print server is a Windows server that hosts a printer. Microsoft does not have a consistent term for a JetDirect or NetPro card. I will call them network printer interfaces.




• DOS applications issue raw print commands. These are converted to Win32 API calls by the Virtual DOS Machine (NTVDM) driver.




• UNIX/POSIX applications running under Interix in Windows Server 2003 issue shell commands that are converted into Win32 API calls.

Itanium machines use Win64 API calls and have an additional emulator layer, Win32-on-Win64, or WOW64, that handles native 32-bit Windows applications. WOW16 and the NTVDM run inside WOW64.

Because most of the system filenames were not changed when Microsoft wrote the IA64 version of Windows, it was necessary to put the 32-bit versions of the files in their own directory. WOW64 hides this directory using a file system redirector. When a 32-bit application accesses a system file, it is redirected to \Windows\SysWOW64.

The Win32 API calls initiate a set of routines inside the Windows Executive that call on the services of the

Graphic Device Interface , or GDI. As you'd expect from its name, GDI controls all things graphical in Windows Server 2003, both on the screen and for printing. It is one of the three key components of the Win32 subsystem. User and kernel are the other two.

WOW64 maps the 8K memory pages used in the IA64 version of Windows Server 2003 to the 4K memory pages used by the IA32 version. This permits Win32 applications that do direct memory access to operate without compatibility issues. On multiprocessor servers with more than 32 processors, WOW64 also maps processor affinity for 32-bit application to maintain compatibility with the 32-processor limit of IA32 versions of Windows.

The printing engine wants to give control of the application back to the user as quickly as possible, so instead of taking the time to completely render the job into printer control commands, it renders the job into an intermediate format called an

Enhanced Metafile , or EMF. Each new version of Windows has its own metafile format revision. Windows Server 2003 and XP are up to version 1.008.

Enhanced Metafiles

When GDI receives a print job, it

renders the job into an EMF file. By first building an EMF file, the system can quickly return control of the system back to the user.

The EMF file is stored by the spooler while it waits for further processing. If the printer is located on a remote print server, the EMF file is sent across the network, not the fully rendered printer file. This conserves cycles at the client and bandwidth on the network.

The EMF file does not contain actual print commands. Instead, it consists of a series of native GDI commands that fully describes the printed page. Some printers are built to understand this native GDI language, but most have their own language so that vendors can add value and differentiate their products.

The EMF file is not completely independent of the printer driver. GDI needs general information about the printer so that it can design the page to match the printer's capabilities and specifications. For example, it would do no good to build a metafile with 1200dpi color output on an 11x17 page just to feed to a dot-matrix printer.

Microsoft Printer Drivers

A

printer driver is required to convert an EMF file, which contains only raw GDI commands, into a print job containing printer control commands.

GDI resides in kernel space. Starting with NT4, print drivers were required to live in kernel space as well so GDI could access them directly. This made NT-style printer drivers highly privileged, something many administrators found to their dismay as they tried to implement cantankerous drivers and suffered through blue screen stops, erratic performance, and data corruption.

Windows Server 2003, XP, and 2000 finesse this problem by permitting a device driver to run in user space rather than kernel space. It took a long time for developers to learn the ins and outs of kernel mode writing, so they have not shown any particular eagerness to go back to user mode drivers. Microsoft dangles a carrot by offering more stack space, access to other device drivers, easier debugging, and better floating point performance in user space. It also wields a stick, warning that it may eventually stop supporting kernel-mode drivers.

You could potentially encounter a problem when connecting to printers hosted by the IA64 version of Windows Server 2003. The IA64 printer drivers will work on IA32 versions of Windows Server 2003 and XP but not with Windows 2000. You will need to configure Windows 2000 printer drivers at shared printers on IA64 servers.

Print Driver Group Policies

You can get a head start on Microsoft by implementing a group policy in Windows Server 2003 and XP called Disallow Installation of Printers Using Kernel-Mode Drivers. The policy is located under Computer Configuration | Administrative Templates | Printers. If you set this policy, users and administrators will be blocked from installing printer drivers that contain kernel-mode DLLs. The error will state this clearly and prompt the user to contact an administrator to get approved drivers.

Most printer drivers written by Microsoft and supplied with Windows Server 2003 have user-mode DLLs. The drivers are also digitally signed, indicating that they have been through logo certification. You can set a group policy to block drivers that do not have a digital signature. This also prevents Trojan horse programs from entering a system disguised as printer drivers. The policy is called Code Signing For Device Drivers. It is located in User Configuration | System. Enabling the policy blocks unsigned drivers.

Master Printer Drivers

The print driver design in Windows Server 2003 and Windows 2000 relieves a vendor of the majority of the coding work. Microsoft provides three master printer drivers:

• "Universal" printer driver, Unidrv.dll.
  This driver handles raster printers that use some derivation of the HP Printer Control Language (PCL).




• Postscript printer driver, Pscript.dll.
  This driver handles Postscript printers up to and including Postscript version 3 and Document Structuring Convention 3.1.




• Plotter driver, Msplot.dll.
  This driver handles pen plotters and plotter equivalent printers using inks or electrostatics.

These drivers are capable of handling just about any printer on the market. Vendors need only provide user interface plug-ins, rendering plug-ins, and one of the following types of printer data files:

• Generic Printer Description (GPD) files.
  These are text-based files that deliver configuration information to the Unidrv raster image processor.




• Postscript Printer Description (PPD) files.
  These are text-based files that deliver configuration information to the Pscript processor.




• Plotter Characterization Data (PCD) files.
  These are DLLs that deliver configuration information to the Msplot driver.

When you install a printer, the drivers are stored in the \Windows\System32\ Spool\Drivers folder. This folder is shared so network clients can download their drivers directly from the print server.

Viewing Driver Details

You cannot look at the driver files and tell the drivers associated with each printer on a server. You also cannot determine the driver versions, which is important to know if you have a driver that is known to cause problems. You can view details about the suite of drivers loaded for a particular printer as shown in Procedure 16.10.

Procedure 16.10 Viewing Printer Driver Details

1. From the Printers and Faxes menu, select F

   ILE | S

   ERVER P

   ROPERTIES .

2. Select the Drivers tab (see Figure 16.20).

   Figure 16.20. Drivers tab in print server Properties window showing the list of printers loaded on a print server.

   

3. Highlight a printer and click Properties to open the Driver Properties window (see Figure 16.21).

   Figure 16.21. Printer Driver Properties window showing details about the drivers that are installed for a particular printer.

   

4. To see the version of a DLL, highlight it and then click Properties and select the Version tab.

You can also use this interface to remove a printer or change the driver.

Spooler

The Spooler service behaves like a school crossing guard watching over the hustle and bustle of print jobs going to and from the rendering engine, the disk, and the printer monitors on their way to the print devices.

Spooler is a client/server system. The client portion, Winspool.drv, takes a print job from an application and delivers it to the server portion of the spooler, Spoolsv.exe, which contains the core spooler code. Spooler also accepts jobs submitted across the network via Win32spl.dll.

You can stop and start this executable with the NET command. The syntax is net stop spooler and net start spooler.

Spooler stores pending jobs in the \Windows\System32\Spool\Printers folder. It saves two files for each print job:

• Spool file.
  These files have an .spl extension. They contain the contents of the print job itself, either the initial EMF file or the fully rendered job.




• Shadow file.
  These files have an .shd extension. They contain information and instructions concerning the job, such as the destination print device, print priority, and originating user.

Changing Spool File Location

You can change the location of the default spool directory by following Procedure 16.11.

Procedure 16.11 Relocating the Default Spool Directory

1. Open the Printers window using S

   TART | S

   ETTINGS | P

   RINTERS AND F

   AXES .

2. From the menu, select F

   ILE | S

   ERVER P

   ROPERTIES .

3. Select the Advanced tab (see Figure 16.22).

   Figure 16.22. Print Server Properties window Advanced tab showing spool location.

   

4. Under Spool Folder, enter the local path to the new spool directory. Ensure that proper access rights have been granted so that authenticated users can print.

5. Click OK to save the change.

6. Stop and start the Spooler service using net stop spooler then net start spooler.

Print Processor

Responsibility for generating a final print job based on the contents of the EMF file falls to the

Local Print Provider , Localspl.dll. This driver combines the functions formerly performed by Winprint.dll, the print processor, and Localmon.dll, the local print monitor. (This change to the print architecture was made in Windows 2000 along with other changes designed to speed up booting.)

One of the key functions of Localspl is to assign a

data type to a job. This defines how the job will be handled as it is converted into printer commands. Ordinarily, you never need to worry about the data types. They are handled in the background and that's that. But one day you will try to print to a print server running Windows Server 2003 using a non-Windows client and if you run into formatting problems, you'll need to know how the data types are assigned so you can change them, if necessary. Here are the data types:

• Raw.
  The print job has been fully rendered into native printer commands and requires no further processing.




• Raw (FF appended).
  A form-feed command is appended to the end of the rendered print job. This is useful for DOS applications that don't kick out the final page after they finish printing.




• Raw (FF auto).
  A form feed is appended to the rendered print job if one is not already present. Use this option if you get two blank pages at the end of every job. (The Help Desk call typically goes something like this: "We're printing a 300-page report and getting two blank pages at the end. We're tired of you IT people wasting paper.")




• NT EMF 1.003, 1.006, 1.007, and 1.008 (Enhanced Metafile).
  These are EMF versions for Windows Server 2003/Windows 2000, NT4 through several service packs, and Windows 98. Earlier versions of Windows and NT 3.5x use Journal files, which cannot be sent across the network.




• Text.
  This indicates a pure ANSI-compliant text job that contains no control codes. This data type should be assigned to Postscript jobs coming from UNIX clients.

Localspl assigns data types to the incoming byte stream based on the criteria in Table 16.1.

Print Providers

Spooler also contains a

router component, Spoolss.dll. The router decides which

print provider to use for communicating with the printer service that eventually prints the job. Local print jobsthat is, jobs destined for locally-attached printersare handled by the Local Print Provider, Localspl.dll. This provider also handles print jobs destined for network print devices such as JetDirect and NetPro and Castelle boxes and cards.

Print jobs destined for network print servers are handed over to network print providers, which are as follows:

• Windows (SMB) Network Print Provider (Win32spl.dll).
  This provider handles print jobs destined for Windows-based print servers. For print servers running Windows Server 2003, XP, Windows 2000, or NT4, Win32spl sends the EMF file directly. Otherwise, it works with Localspl to fully render the job into printer commands prior to sending it to the server.




• Internet Print Provider (Inetpp.dll).
  This provider handles print jobs destined for Internet Printing Protocol (IPP) print servers.




• NetWare Network Print Provider (Nwprovau.dll).
  This provider gets jobs destined for NetWare print servers. The jobs get a RAW data type, meaning that the final rendering is done at the client.




• UNIX print jobs .
  Jobs intended for UNIX hosts are handled by the Line Printer Protocol (LPR) provider.

You can see both of these providers in the A

DVANCED | A

DVANCED S

ETTINGS properties window of the Network Connections window. Select the Provider Order tab.

Port Monitors

After a job has been rendered into native printer commands, Spooler hands it over to a

port monitor . This is a user-mode driver that communicates with the print device via a paired kernel-mode device driver.

For example, print jobs destined for a locally-attached printer on a parallel or serial port are sent to Localspl, which does double duty as a port monitor and the local print provider. If a job uses Printer Control Language (PCL), it is also sent through a

Language Monitor , Pjlmon, for additional bidirectional print control. (PJL stands for Printer Job Language.)

Print monitors are exposed to the UI as

ports . For example, when you install a Universal Serial Bus (USB) printer, the Usbmon port monitor is activated and a virtual printer port is created at the USB interface.

There are print monitors for network print devices, as well. For example, the Tcpmon print monitor controls jobs destined for TCP/IP-based network print devices. This is the default printer monitor for network printing. (The older Hpmon interface for DLC printing has been eliminated. DLC is no longer supported in Windows Server 2003.) The Lprmon print monitor handles print jobs destined for the LPD service on a UNIX host. There are also print monitors for fax printers, Internet printing, and for bus interfaces such as IrDA and FireWire.

Final Print Job Delivery

After