Default printer on thin clients

By adamsmith ·
I am trying to find a solution to a problem we will be facing very soon with users, terminal servers, and printers. All the printers are network attached laser printers. There are a couple of issues I have to resolve. Here is a deatiled rundown of our 3 different types of workstations:

Typical fat client:
These users have thier own workstation. They log on to a windows domain and have a default printer. All is good!

Generic fat client:
These are "front counter" people. There are 3 different departments which will function this way. Every front counter worksation is signed on with the same generic user account called "sales" which is locked down hard and only allows them to do what is necessary to process sales. The users of these workstations move around very quickly throughout the day but each workstation stays logged in with the "sales" user account all day. If we didnt do it this way we would have hundreds of network logins each hour, and too much time would be taken waiting for profiles to load while customers wait. Each workstation needs to have a default printer defined based on the location.

Remote thin clients:
2 branch stores opperate this way... All the workstations at the remote branches are thin clients. There is a site to site VPN that connects them to a terminal server at the main branch. They all log in through the generic sales account. Their default printer needs to be based on the location of the thin client. I'm not sure how to make that happen...

It may also help to know that each location has a different subnet. For example: 192.168.0.x for the main branch, then 192.168.2.x and 192.168.3.x for the remote branches.

The only proposed solution I can come up with is to use a different username for the generic account in each location. Each location is in a differnt town or city, so instead of using the "sales" user account in every location, I could have front counter users login with cityname as thier username. I could set a default printer for the 2 profiles used at the remote branches.

Anyone here have any suggestions to help me make this work seamlessly?


This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Answers

Collapse -

This might be of help you .....

Configured Printers in a Thin Client

The Add Printer Wizard and Setup user interfaces (UIs) are both supported by logic that reads and writes printer information.

Printer Manufacturer List
A thin client passes the list of printer manufacturers and models to the server so that the server can locate the appropriate printer driver for printer redirection. This list is passed in the form of the ntprint_parsed.txt file for Windows XP or Windows Server 2003 operating system. By default, ntprint_parsed.txt is the file that is copied into the flat release directory during a build and included in a run-time image.
An additional txt file, lhprint_parsed.txt, is provided that contains a list of printer manufacturers and models for use in a Terminal Server session when connecting to a server running the Windows Vista or Windows Server 2008 operating system. If your thin client will support connecting to Windows Vista or Windows Server 2008, you must rename the file lhprint_parsed.txt to ?ntprint_parsed.txt? to be used in place of the list of printers for connecting to a Windows XP or Windows Server 2003 PC. Both .txt files are located in %_WINCEROOT%\PUBLIC\RDP\OAK\FILES.
Additional printer manufacturers and models can be added to the version of ?ntprint_parsed.txt?, and then built into the run-time image (NK.BIN). The printer name in the list must be identical to the printer name of the server so that the correct driver can be loaded onto the server during a redirected print operation.

Installed Printers Registry Key
The registry settings for the installed printers are stored in the HKEY_LOCAL_MACHINE\WBT\Printers\DevConfig\<LPT#> subkey, where <LPT#> indicates any physical port that is available on the Windows Embedded CE powered thin client. Examples of subkey names are LPT1, and LPT2.

Add a New Printer
Do not add new printers through the registry settings. Instead, add new printers by using the Printer Setup Wizard. Depending on the printer added, this wizard adds important binary data to the registry that is used for redirected printing.
When a new printer is added by completing the Printer Setup Wizard, Remote Desktop Protocol (RDP) has additional associated logic for the new printer. Binary data that is associated with the new printer is stored in the named value PrinterCacheData0 in the HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client\Default\AddIns\RDPDR registry key
For additional details about the format of this data, refer to %_WINCEROOT%\Public\Rdp\Oak\Uit\Wbttscmn\Printerhelper.cpp

Named Values in the Registry
The following table shows values for the printer that are created and used internally by the thin client.
These values should never be modified using Registry Editor. They are listed here for reference only.
Indicates a name for the printer. Default is the user-defined friendly name of the printer. This name is optional.
Indicates the model name of the printer. The default is the Windows operating system model name of the printer. This name is required.
Indicates the default printer. This is the printer associated with the port name that is the default value "@" of the HKEY_LOCAL_MACHINE\WBT\Printers\Default subkey.
Default is 1. If this value or key does not exist, no printer is the default printer.
The following table shows the default printer value that is created and used internally by the thin client. This value should never be modified using Registry Editor. It is documented here for reference only. This entry is located in the HKEY_LOCAL_MACHINE\WBT\Printers key.
Indicates the physical port that is associated with the default printer for the thin client. Examples include LPT1: and LPT2:.


Please post back if you have any more problems or questions.
If this info is useful, please mark it helpful. Thanks

Collapse -

Good info

by adamsmith In reply to This might be of help you ...

Looks like good information. Although this is all dealing with redirecting local printers, it got me thinking.

I could just add a "local printer" to each thin client which attaches via a "standard TCP/IP" port with the address of the default printer for that device.

Then make the default printer for that account the "locally attached printer" which redirects to the TS on connection.

I havent had a chance to get my hands on one of the thin clients yet, but they are HP t5135's with the ThinConnect OS. There should be provisions on these for local TCP/IP printer ports.

Any holes in this plan?

Collapse -

Just give it a try..

The HP boxes should be able to handle these types of communication for printers.

Please post back if you have any more problems or questions.
If this info is useful, please mark it helpful. Thanks

Collapse -

OU's and login script by GPO

by Churdoo In reply to Default printer on thin c ...

Remote thin clients
Add an OU to your ADUC sctucture for each remote site. Create a GPO linked to each OU with either a GPO-assigned printer or have the GPO call a site-specific login script which assigns the default printer using the printui.dll. Move the COMPUTER objects into the respective OU's.

POS counter fat clients
You can do the same thing with OU's and GPO's.

The GPMC (Group Policy Management Console) is a free download from MS and a great tool for managing GPO's.

I've written something on this earlier so I'll see if I can dig it up again and repost.

Here's one:

edited: added links

Collapse -

RE: OU's and login script by GPO

by adamsmith In reply to OU's and login script by ...

"Move the COMPUTER objects into the respective OU's"

Will the thin clients actually be "COMPUTER objects?" Seems like the one TS will be the "Computer object" for all of these thin clients...

This will be my first venture into the world of thin client computing, so much of this is new to me... and as I said, I dont have the clients yet to test anything out.

I have the terminal server running and configured with a functioning licensing server. I have activated the necessary nuber of TS licenses. The printers are still boxed up and the thin clients aren't here yet.
The company doesnt want to buy the thin clients until just before "go-live".

I'm going to need to have most of this figured out and ready to go, because there wont a lot of time for experimenting and troubleshooting after I have the necessary equipment.

Related Discussions

Related Forums