Some of you might know that I was the original developer of Named Printers. I was working with the West Australian partner Sequel Technology at the time. It was created back in version 3.0 as a customisation for a distribution client who wanted to be able to print SOP picking tickets to the warehouse while printing the SOP invoices to the accounting department's printer.
I created the framework of printer tasks in the different series and printer IDs to assign to tasks in my original design. I got into trouble with my business partner for taking too long and "over engineering" the solution because it was a lot more flexible and powerful than was needed for this one client. I was redeemed later when Named Printers won the 1997 Great Plains Technical Innovation Award, helped Sequel Technology achieve President's Club status in 1999, and then was purchased by Great Plains for version 5.50 onwards.
The final bit of code that was added to Named Printers v5.50 before it was handed over to Great Plains was the addition of the template user feature. This was added specifically to make the use of Named Printers in a Terminal Server environment easier, by allowing multiple users who have the same printer settings to be grouped under a single template user.
Template users are usually used to allow a single user to be used to assign the Named Printer settings for all users at a specific location. Using a template user has a number advantages (even if there is only a single user at the location) because it provides a level of independence between the Named Printer settings and the user. If a new user is added, you just need to associate them with the appropriate template user and Named Printers is ready to go. If a user leaves and you remove their User ID from the system, you are not losing their Named Printer settings as they are stored against the template user.
It has always frustrated me when I hear people say that Named Printers can't be used with Terminal Server as it is not true. That said, it is a bit more complex to get it working and there are some issues to be aware of. The aim of this article is to try and help change this incorrect perception.
Below is an updated summary of the steps to getting Named Printers working nicely in a Terminal Server environment with additional notes. To help explain how this works, we will use three locations, Sydney, Melbourne and Perth and two companies, Fabrikam (TWO) and Microsoft (MS).
Create a printer ID of system class for the printer to be used when no other printer is defined. This fallback printer should be somewhere near the system administrator. Example: Create system class printer DEFAULT.
Define the System Series Default Printer task as the system class printer ID created in previous step. This printer will be used when nothing else is defined. This printer should be available to all users at all times. Example: Assign the System Series Default Printer task as System Class and Printer ID DEFAULT. NOTE: The System Series (and Company Series) Default Printers are only used during login to change the application default printer for Microsoft Dynamics GP. You can see this working by looking at File >> Print Setup after login and see that the application printer can be different from the windows default printer.
For each template user, define the Company Series Default Printer task as user class default printer IDs created previously. This printer should be available to all users linked to the template users at all times. Example: Select the template user TEMP_SYD, then assign the Company Series Default Printer task as User Class with the Printer ID DEFAULT_SYD. Change the user to TEMP_MEL and use the lookup button to select Printer ID DEFAULT_MEL. Then change the user to TEMP_PER and select Printer ID DEFAULT_PER. NOTE: Don't get confused about this being a Company Series task. It can be defined as any printer class (company, user, user & company) and is purely to override the printer defined in the System Series.
Optional: You can now specify other separate printer tasks in the other series for the template users or individual users if you want to override the default printers. Example: Select the template user TEMP_SYD, then assign the the SOP Invoice printer task in the sales series as User Class with the Printer ID SOPINV_SYD. Change the user to TEMP_MEL and use the lookup button to select Printer ID SOPINV_MEL. Then change the user to TEMP_PER and select Printer ID SOPINV_PER. NOTE: The Printer class drop down list setting on the Assign Named Printers window is system wide. If you have been setting up User, Company or User & Company class printers and change the value of this drop down list field, Named Printers will remove all the previous settings for this printer task. This is probably the cause of Named Printers "appearing" to lose settings.[Edit] There is now a temporary fix available for this issue for versions 8.00, 9.00 & 10.00 (it is fixed in Microsoft Dynamics GP 2010 onwards), please see the following article:
Using the Support Debugging Tool to create temporary fixes
If you want to use Named Printers to control the destination printer and settings for specific printer tasks but not to control the default application printer, you can change the ST_SetDefault setting in the Dex.ini file to FALSE. This will stop Named Printers from attempting to change the application default printer on login and will leave the printer as defined by the system. Note that this setting change does not disable Named Printers entirely.
If attempting to use remote printers (ie. not local to the terminal server), there might be a delay before the printer is available for use after the terminal server session is established. This might prevent Named Printers from selecting the printer as a default application printer on login. Logging into a desktop or adding a slight delay when logging directly into the application can give the extra time needed to access the remote printer.
If using a Terminal Server farm with multiple terminal server machines, it is possible (but not supported) to use a single ST_MachineID value in the Dex.ini to allow the farm to share a single Machine ID ONLY if you are 110% certain that the machines are configured identically. They must have exactly the same Operating System with exactly the same printers installed with exactly the same printer drivers used. If you have any differences (at the machine code level), when Named Printers attempts to select a printer that is different, it might cause Dynamics GP to crash.
Please read more about setting up Named Printers in a Terminal Server farm environment in the follow up post: Using Named Printers with Terminal Server revisited.
You can also look at the Named Printers section on the General Articles & Links page of this blog as it contains other Named Printers articles worth reading.
Please add your thoughts on this topic as comments.
16-Feb-2009: Added extra comments about ST_SetDefault Dex.ini setting and remote printer delays.
24-Apr-2009: Further updates about template users and the steps for configuring Named Printers.
30-Apr-2009: Added examples to steps.
08-Jun-2009: Added link to Support Debugging Tool temporary fix.
12-Mar-2011: Added note about broken link, and that the issue with losing user printer selections without warning is fixed in Microsoft Dynamics GP 2010.
12-Mar-2011: Added Additional note on sharing ST_MachineID values for a terminal server farm environment.
14-May-2013: Added Link to follow up post: Using Named Printers with Terminal Server revisited.
23-Jul-2013: For more information check out: The Ultimate Guide to Terminal Server Printing - Design and Configuration.
Posting from DynamicAccounting.net
Posting from the Dynamics GP Blogster
The Support Debugging Tool for Microsoft Dynamics GP has the facility to create non-logging triggers
Good stuff Dave although the link here now seem broken?? www.microsoft.com/.../gp_using_named_printers.mspx Can you redirect me?
Just setting up an RDS farm technically they just want to forego named printers so I'll set the ST_SetDefault to false. However, I'm also wondering if in a server farm if it's good practive to also set the MACHINE ID to the same value in the dex.ini for all servers. Will that save me from having to worry about which server a user gets load balanced onto? Thanks.
Looks like that article has been removed or moved. It does not matter as the information on this blog post is more detailed and up-to-date anyway.
Setting ST_SetDefault=FALSE will just prevent a default printer being selected at login, Named Printers is still enabled. To disable Named Printers entirely you need to comment out or remove the ST_MachineID Dex.ini setting.
When you have multiple Terminal Server machines it is best to have separate Machine IDs, UNLESS you are 110% certain that each machine is configured exactly the same with exactly the same OS and exactly the same printers with exact the same printer drivers. In this case you can "share" a Machine ID and only need to set up Named Printers and its template users once for the entire farm.
If there are differences between the machines sharing a Machine ID, you might cause GP to crash when it tries to select a printer and the printer is missing or using a different driver.
Hope this helps
Posting from Mariano Gomez, The Dynamics GP Blogster
PLEASE READ BEFORE POSTING
Please only post comments relating to the topic of this page.
If you wish to ask a technical question, please use the links in the links section (scroll down, on right hand side) to ask on the Newsgroups or Forums. If you ask on the Newsgroups or Forums, others in the community can respond and the answers are available for everyone in the future.