Using Named Printers with Terminal Server revisited

This is an update to the original Using Named Printers with Terminal Server post from August 2008.

The original post takes you through the process of using Template Users on Terminal Server so that you only need to setup one user per physical location with user mode printers and then users from that physical location can inherit the Named Printers settings from the Template User. It also mentions the unsupported method of sharing a single Machine ID between servers in a Terminal Server farm ONLY if you are sure that the machines are exactly the same.

I am currently working on a support case which raises new issues which need to be discussed as well as bringing back some previous points to which need to be clarified.

 

The Scenario

The customer has 6 physical locations or sites. At head office, they have a Terminal Server (with Citrix) farm containing 2 load balanced servers. They are using a third party application which stores some settings in the Dex.ini that need to be different based on the site where the current user is located.

To facilitate the Dex.ini settings for the third party application, the customer is using individual Dex.ini files for each user stored in the Home directory.

So far so good. The configuration makes sense and works fine... until you introduce Named Printers.

Note: The customer is running Microsoft Dynamics GP 2010 so they don't have the user level Dex.ini functionality that was introduced in Microsoft Dynamics GP 2013. This GP 2013 feature might help with the settings needed by the third party application. 

 

The Boring Stuff 

Named Printers bases all of its data and settings off one primary value... the Machine ID. The Machine ID is stored as the ST_MachineID setting in the Dex.ini file, it defaults to the Network name of the machine and is tied to the Server itself.

The Machine ID is required because the Dexterity functionality which allows us to capture and use Printer settings stores its data as a binary dump from the printer driver. This is then stored in SQL as a Binary Large Object (BLOB). This BLOB contains the Printer Name and all the selected settings such as printer tray and orientation. Dexterity does not understand or care about the actual content of the BLOB. When Dexterity wants to change default printer or print a report to a specified printer, it just passes the binary data back to the operating system which then handles the printer changes as required.

The problem is that the binary data is stored by the operating system differently for every printer and printer driver. Even updated versions of the same printer driver for the same printer could store that data differently. The length of the name and/or the address of the printer could shift the settings within the binary data.

If you try to use stored binary data from Named Printers with a different version of the driver for that printer, or if the printer has a different name or address, it will probably fail to work. In some cases we have seen Named Printers cause the application itself to crash as described in KB 909739.

This means that if you ever update or change printer drivers, you should recreate the Named Printer's Printer IDs based on those drivers so that they stay binary compatible with the drivers.

And...

It also means that settings created on one machine or server are unlikely to be binary compatible with another machine or server. In other words, the Machine ID should not be shared between servers as it is very unlikely to work and could cause crashing (and did I mentioned it is not supported). I have seen it work but that was with two virtual servers based off the same image so that were as close to identical as you could get.

 

The Problem

So coming back to our support case. The users each had their own Dex.ini file, which contained a Machine ID setting for that user. This meant that each user had to be set up individually within Named Printers. This could be simplified by all users from a specific location sharing the same Machine ID, thus reducing the amount of Named Printers configuration needed. All this works fine until more than one server is added to the farm.

Now the same user level Dex.ini file would get used regardless of which of the servers in the farm the user connected to. So the same Machine ID would be shared between all servers in the farm and, as we now know, that is a problem. For our customer it meant that Named Printers settings created for one server, failed to work on the other server.

In summary, User level Dex.ini files stored in the home folders are not compatible with Named Printers once there is more than one server involved.

Note: Microsoft Dynamics GP 2013 with its user level Dex.ini files, it still has a system level Dex.ini file which would be where the Machine ID is stored, so that works fine.

 

The Solution

The path towards the solution starts with no longer using separate User level Dex.ini files and using a single Dex.ini file on each server. This ensures that each server has its own unique Machine ID and allows Named Printers to work. It is now possible to create 6 Template Users on each machine (so 12 configurations) to have Named Printers working per site.

Note: It does introduce a side effect that users see the User ID of the previous user when they attempt to login. This can be easily resolved using the Dex.ini Configuration window in the Support Debugging Tool to clear the SQLLastUser setting (see Why making the Dex.ini file read only is evil).

But if you remember, our customer has a third party application which needs its Dex.ini settings per site and this is not handled with the above configuration with just 2 Dex.ini files.

To handle this situation we need to have 6 Dex.ini files on each server, one for each of the 6 sites. All 6 on each server use the same Machine ID, so Named Printers still only has 2 Machine IDs, but we can now have settings for the third party application per site. To easily use this configuration this we can create a Published Application for each site and pass the path of that site's Dex.ini file as an additional parameter in the shortcut. Then only provide users access to the Published Application for their location.

While discussing this approach with the customer, we came up with a variant that would be easier to implement from the Named Printers point of view. As we now had 12 Dex.ini files (6 sites by 2 servers) instead of having two Machine IDs and using 6 Template Users and User Mode printers, we could create 12 Machine IDs based on Site and Server (eg. Location1A, Location1B, and so on). This would avoid the need for Template Users and User Mode printers. Each site could have its printers defined as System Mode printers on each server.

So now, each site has its own settings for the third party application, each site has its own Named Printers settings and Named Printer settings are not shared between multiple servers.

The problem is solved.

 

Hope you find this information useful.

David

23-Jul-2013: For more information check out: The Ultimate Guide to Terminal Server Printing - Design and Configuration.

Comments

• Anonymous
  May 19, 2013
  Posting from Mark Polino at DynamicAccounting.net mpolino.com/.../using-named-printers-with-terminal-server-revisited-developing-for-dynamics-gp-site-home-msdn-blogs

• Anonymous
  May 20, 2013
  Hello David, What great timing - I just started working with a client who needs to have Named Printers setup on their Terminal servers.  They are not load balancing servers - they just have 3 TS that users will log into.  We plan on having all network printers setup identically on each server. I've run into a snag.  They have a printer used for printing AP & Payroll checks that is secured with locked paper trays and security codes when printing.  If I setup the first printer property and put the security code in the settings it saves that setting in the properties when I open the next. For example: I need 3 Named Printer ID's 1 - Printing admin reports, tray 1 - password 1111 2 - Printing accounts payable checks, tray 3, password 3333 3 - Printing payroll checks, tray 4, password 4444 I can setup specific trays without any problem but after setting up the first printer ID I can see the security code from the last setup.  If I change it on the next, then that code is there when I go to the next printer ID setup I may not be an admin for the printer & this may be he reason but I'm not so sure.  I'll contact their IT dept. to see if that's the issue.  It's a Lanier SP 5200DN PCL 5e.  Can you think of anything else? I could really use your help. Thanks, Sheila Jefferson-Ross

• Anonymous
  May 20, 2013
  Hi Sheila It sounds like the password information is stored against the printer driver itself and not in the settings captured by Named Printers. So the solution to an issue like this is to add the same printer driver twice more with different names. You can then set up the default tray and security codes for the 3 different windows printers.  Then use Named Printers to just select the printers and leave the selection of tray and password to the printer driver itself. Instead of 3 Printer IDs pointing to one printer driver with different settings, use 3 Printer IDs pointing to 3 printer drivers (for the one physical printer). David

• Anonymous
  May 20, 2013
  Thanks David. I think that was where I was going next.  I was just hoping that the security code would have saved with the printer driver since we don't want other users to have access to this  printer on the server.  I guess we might be able to have those printers display in certain user profiles.  I'll check with IT tomorrow. I appreciate your quick response. Hope all is well 'down under'! Sheila

• Anonymous
  July 10, 2013
  Wouldn't making the machine ID on both servers the same reduce this even more? Works for me

• Anonymous
  July 10, 2013
  Hi Arthur Making the Machine ID on more than one machine the same is not supported. It will only work if the machines and exactly the same at the binary level. If the binary data stored in the SQL blob is not compatible with the driver build installed on a machine, Named Printers will fail to work and in some cases cause the application to crash. If it is working for you, you are lucky. Make sure you remember to update both machines at the same time and recreate the Named Printer settings if you ever update a printer driver. David

• Anonymous
  July 17, 2013
  Hi David, Just some info, they are a clone of each other running in citrix environment with a Universal Print driver  so that might be what makes it work....I only realised this was the case to be honest months later as I had cloned them and not changed the dex.ini. Arthur

• Anonymous
  July 21, 2013
  Hi David, I'm having a problem printing 2 copies with named printers in a MSTSC environment - actually I can reproduce the problem on my local installation of GP as well so I don't think it has anything to do with the terminal server.   I setup a copy of an HP LaserJet printer driver on the machine, and set the copied driver to print 2 copies.  When I print from any app on the server or my computer, or prints 2 copies every time by default.  But for some reason in Dynamics GP it only prints 1 copy on that named printer unless you manually change it.   Is this by design or a bug?  Am I doing something wrong?  I'm setting the # of copies on the print driver itself, not Dynamics GP.  

• Anonymous
  July 21, 2013
  Hello Are you running on GP 2013. If so you might be having the issue described in the post below: blogs.msdn.com/.../microsoft-dynamics-gp-2013-printer-selection-named-printers-page-orientation-and-the-system-print-dialog.aspx Other than that, number of copies has always been temperamental. Some drivers work and others don't. David

• Anonymous
  June 12, 2014
  Hi David, To follow up the last post on the number of copies, since we move our Citrix/MSTSC server that runs GP on Windows server 2008 (it was window server 2003), I now have the same problem of copies that only prints 1 copy. When I return in the properties of the printer from Named Printers, the number of copies is resetted to 1. All our printers are using HP Laserjet 5 driver. We are running GP2010 R2. Do you have more information on the drivers that has the number of copies to work or not? If our HP Laserjet 5 driver does not work we would like to know which driver we should used. Thanks Eric

• Anonymous
  June 25, 2014
  Hi David, We have the same problems with the setup of copies in named printers. We are running GP2010 on Citrix servers, all our printer are using generic HP5 driver. This problem occurs only since we migrated GP on Windows Server 2008, there was no problem on our Windows Server 2003 servers. Can you help us with that? Do you know if we should use another generic printer driver?

• Anonymous
  July 01, 2014
  Hi Eric Ages ago, I found that the HP Universal Driver worked with number of copies, but was much slower to print. I have not looked at the issue for many years. David