HP 4410t Thin Client Printing with the HP Universal Print Driver - White Paper - Page 5

Firewall settings, Printing over an RDP/ICA remote session, Microsoft Terminal Services - allow my computer

Get HP 4410t - Mobile Thin Client PDF manuals and user guides
UPC - 884962419915
View all HP 4410t manuals
Add to My Manuals
Save this manual to your list of manuals

Page 5 highlights

The other option for configuring a network-attached printer is to use the "Add Printer" wizard to locate the printer, however this is a much more complex task for an end-user to perform, since it requires knowledge of printer ports, TCP/IP ports, printer drivers and the fact that even though the printer is not directly connected to the system, the user must select the "local printer" option to be able to create the TCP/IP port. Because of its complexity, this option is not recommended for end-users. Firewall settings For printing to network printers or to through print servers, one important consideration applies: by default the software firewall (either Sygate Security Agent or Symantec Endpoint Protection, depending on image version) that ships with the OS image on the XPe or WES thin clients is set to block traffic needed to talk to network printers. In order to successfully use network printers, the firewall needs to be configured to allow traffic on three ports used for discovery and printing, UDP port 161 (SNMP), TCP port 9100 (JetDirect) and UDP port 5353 (mDNS). If traffic on any of those ports is blocked, discovery of and printing to network printers may fail. In the scenario of a thin client that has been added to a domain, and the users log-in with domain credentials, the UPD will perform an HTTP and an LDAP query looking for print policies (refer to the MPA documentation available at http://www.hp.com/go/mpa for more information). For these queries to work, traffic must be allowed on ports TCP 80 (HTTP) and TCP 389 (LDAP). For environments where the Windows Firewall is used, the only rule that needs to be added to the default firewall configuration is to allow mDNS traffic (UDP port 5353). Note: the printing add-on takes care of making the required changes to the configuration of the Symantec Endpoint Protection agent or Windows Firewall. If running other firewall solutions, consult your software documentation. Printing over an RDP/ICA remote session In order to print to a local printer from a Microsoft Terminal Services or Citrix Presentation Server session, the printer must be configured in the thin client first; that is, a print queue must exist in the "Printers and Faxes" folder such that printing from applications running on the thin client works. With that pre-requisite satisfied, there are specific considerations for Microsoft Remote Desktop and Citrix Presentation Server as follow: Microsoft Terminal Services When a client connects to a Windows 2003 Server Terminal Services session, if the local printer auto-creation is enabled (the default setting), the server will attempt to create a print queue for each of the user's local printers. When attempting to create a printer, the system tries to find the exact same driver that is used for this printer in the client's machine. If that driver is installed on the server as well, the print queue will be created and made available for the duration of the user's session. If the exact same driver is not available in the server, the print queue is not created and an entry is logged in the system event log notifying the failure. The recommended approach under Microsoft Terminal Services is to have the original UPD (www.hp.com/go/upd) installed in the server. To ensure compatibility with the widest array of HP printers, it is recommended to use the PCL5 version of the UPD on the server. One exception for this recommendation is if your environment has standardized in postscript printers, in which case it might be more effective to use the postscript version of the UPD on the server. Driver mapping Clients using the UPD for Thin Clients driver version 4.7 or earlier need to use driver mapping because while the driver is based on the original UPD, it has a different driver name and won't be seen as such by the system. To get around the need of having a multitude of different drivers installed on the server-side, it is possible to use a smaller set of print drivers and configure mappings that instruct the system to use alternate drivers for certain given client drivers. 5

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
5
The other option for configuring a network-attached printer is to use the “Add Printer” wizard to locate
the printer, however this is a much more complex task for an end-user to perform, since it requires
knowledge of printer ports, TCP/IP ports, printer drivers and the fact that even though the printer is
not directly connected to the system, the user must select the “local printer” option to be able to create
the TCP/IP port. Because of its complexity, this option is not recommended for end-users.
Firewall settings
For printing to network printers or to through print servers, one important consideration applies: by
default the software firewall (either Sygate Security Agent or Symantec Endpoint Protection,
depending on image version) that ships with the OS image on the XPe or WES thin clients is set to
block traffic needed to talk to network printers. In order to successfully use network printers, the
firewall needs to be configured to allow traffic on three ports used for discovery and printing, UDP
port 161 (SNMP), TCP port 9100 (JetDirect) and UDP port 5353 (mDNS). If traffic on any of those
ports is blocked, discovery of and printing to network printers may fail.
In the scenario of a thin client that has been added to a domain, and the users log-in with domain
credentials, the UPD will perform an HTTP and an LDAP query looking for print policies (refer to the
MPA documentation available at
for more information). For these
queries to work, traffic must be allowed on ports TCP 80 (HTTP) and TCP 389 (LDAP).
For environments where the Windows Firewall is used, the only rule that needs to be added to the
default firewall configuration is to allow mDNS traffic (UDP port 5353).
Note:
the printing add-on takes care of making the required changes to the configuration of the
Symantec Endpoint Protection agent or Windows Firewall. If running other firewall solutions, consult
your software documentation.
Printing over an RDP/ICA remote session
In order to print to a local printer from a Microsoft Terminal Services or Citrix Presentation Server
session, the printer must be configured in the thin client first; that is, a print queue must exist in the
“Printers and Faxes” folder such that printing from applications running on the thin client works.
With that pre-requisite satisfied, there are specific considerations for Microsoft Remote Desktop and
Citrix Presentation Server as follow:
Microsoft Terminal Services
When a client connects to a Windows 2003 Server Terminal Services session, if the local printer
auto-creation is enabled (the default setting), the server will attempt to create a print queue for each of
the user’s local printers. When attempting to create a printer, the system tries to find the exact same
driver that is used for this printer in the client’s machine. If that driver is installed on the server as well,
the print queue will be created and made available for the duration of the user’s session. If the exact
same driver is not available in the server, the print queue is not created and an entry is logged in the
system event log notifying the failure.
The recommended approach under Microsoft Terminal Services is to have the
original UPD
(
www.hp.com/go/upd
) installed in the server. To ensure compatibility with the widest array of HP
printers, it is recommended to use the PCL5 version of the UPD on the server. One exception for this
recommendation is if your environment has standardized in postscript printers, in which case it might
be more effective to use the postscript version of the UPD on the server.
Driver mapping
Clients using the
UPD for Thin Clients
driver version 4.7 or earlier need to use driver mapping
because while the driver is based on the
original UPD
, it has a different driver name and won’t be
seen as such by the system. To get around the need of having a multitude of different drivers installed
on the server-side, it is possible to use a smaller set of print drivers and configure mappings that
instruct the system to use alternate drivers for certain given client drivers.