Microsoft KB Archive/939804

= The ability to configure undefined printers in SNA Manager is no longer available in the Host Print Server environment in Host Integration Server =

Article ID: 939804

Article Last Modified on 12/4/2007

-

APPLIES TO


 * Microsoft Host Integration Server 2006
 * Microsoft Host Integration Server 2004 Standard Edition

-



INTRODUCTION
Starting with the release of Microsoft Host Integration Server 2004, the ability to configure undefined printers in SNA Manager is no longer available in the Host Print Server environment.



MORE INFORMATION
In earlier versions of Host Integration Server, you were able to type a UNC path that resembles the following in the Host Integration Server print session properties:

\\printserver\printshare

The UNC path points the session to a shared printer even though a physical printer is not installed on the computer that is running Host Integration Server. This configuration has been known to cause issues in several areas.

In addition, many people mistakenly think that print rendering occurs on the remote print server. This is not true. Print rendering always occurs on the local computer. Also, drivers are downloaded locally, and then version checking occurs. Because of this process, the following two issues have been known to occur and to cause problems:  When you use undefined printers, problems with multiple versions of print drivers across multiple print servers can cause corruption of the print output. Undefined printers can also cause problems within the print spooler of the local server or of the remote print server. For example, the print spooler service or the SnaPrint service may intermittently and unexpectedly shut down or stop responding.

For an example of a versioning problem that may occur, consider the following scenario. In this scenario, there are three print servers. Each print server has one printer. The print servers and printers are defined as follows:  \\printserver1\printer1 \\printserver2\printer2 \\printserver3\printer3

All the print queues are set up by using an XYZPrinter printer name. But each print server uses a different version of the print driver.

Printserver1 uses a driver that is marked as version 1.0.0.4. Printserver2 uses a patched driver that includes some DLLs that are marked as version 1.0.0.4, some DLLs that are marked as version 1.0.0.6, and some DLLs that are marked as version 1.0.0.7. Printserver3 uses drivers that are marked as version 1.0.0.5. (The driver that printserver3 uses is in fact an update of the driver that Printserver2 uses.)

When the Windows-based server downloads the driver from \\printserver1\printer1 for use by the Host Integration Server print server, all DLLs are marked as version 1.0.0.4.

When the Windows-based server makes a connection to \\printserver2\printer2, only DLLs that are marked as version 1.0.0.6 and as version 1.0.0.7 are downloaded. The downloaded DLLs overwrite the DLLs that are marked as version 1.0.0.4.

When the Windows-based server makes a connection to \\printserver3\printer3, any remaining DLLs that are marked as version 1.0.0.4 are updated to version 1.0.0.5.

In this scenario you have the following types of DLLs on the computer that is running Host Integration Server:  DLLs that are marked as version 1.0.0.5 DLLs that are marked as version 1.0.0.6</li> DLLs that are marked as version 1.0.0.7</li></ul>

These DLLs do not match any of the print drivers that are installed on the three print servers.

In some cases, this process may cause no problems. However, this process has frequently been known to cause problems such as spooler failures, SnaPrint failures, and incorrect printing.</li> When you use undefined printers, excessive network traffic is generated. For example, a print session uses an OpenPrinter API call to open a handle to a specified printer or print server. The Windows Spooler service then follows these steps: <ol style="list-style-type: lower-alpha;"> The Spooler service creates a temporary connection to the remote print server.</li> The Spooler service copies the print driver files to the local computer by using a remote procedure call (RPC) request that uses the remote print provider (Win32spl.dll).</li> The Spooler service caches the driver version information and then updates the registry to include that information.</li></ol>

After a print job is finished, the SNA Print service calls the ClosePrinter API function to close the handle to the printer when the option is configured on the print session. When this behavior occurs, the Spooler service deletes the cached information from the registry. However, the Spooler service does not delete the print driver files.

When the next print job is received from the host, the following steps are followed: <ol style="list-style-type: lower-alpha;"> The OpenPrinter API function is called to start the SNA print session.</li> The Spooler service detects the print driver. However, the information in the cache has been removed.</li> The Spooler service contacts the remote print server to compare the print driver files.</li> All the cached information is again copied in the registry.</li></ol>

The action of comparing driver files generates a high volume of server message block (SMB) traffic and of remote procedure call (RPC) traffic on the network. You can avoid this behavior by creating a permanent connection to the remote print server. Printers should be defined locally on the server for TCP/IP printing.</li></ul>

Also, Windows lets you connect to remotely defined network printers. Windows copies the drivers from the remote print server to the local print server. When Windows takes this action, Windows creates a local print queue. Although this scenario describes a supported method for Host Integration Server, the two issues that are mentioned here could still occur.

When the local print service uses network-defined printers, it keeps the latest version of the print driver locally. This process could cause problems similar to the first issue that is mentioned here. Additionally, the local print service regularly does a check similar to the check that is described in the discussion of the second issue mentioned here. The local print service takes this action to make sure that it has the latest copy of the print driver installed locally.

In the example scenario that is mentioned here, because the printers are all defined as XYZ Printer, the local print service does not keep three copies of the print driver.

We recommend that users install print drivers and print queues locally whenever possible to avoid these issues. For more information about how to define a printer locally, click the following article number to view the article in the Microsoft Knowledge Base:

300610 How to set up a print queue in Windows 2000

<div class="references_section">