This is a reposting of an article I originally wrote on my Developing for Dynamics GP blog.
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 template user for each location or group of similar users. Remember that individual settings for a user are used before the template so you can have a user with both individual settings and also template user settings.Example: Create users TEMP_SYD, TEMP_MEL, TEMP_PER.
NOTE: You do not need to grant access to any companies for a template user. Once other users are associated with a template user it can be selected for a company even though it does not have access.
- Using Named Printer Advanced Options window, assign the individual users to the appropriate template users.Example: Associated users from each location to the appropriate template user of TEMP_SYD, TEMP_MEL, TEMP_PER.
- Create printer IDs for each location as User Class printers. This includes the default printer for each location as well as any specific printers for individual printer tasks.Example: Create default user class printers for each location, DEFAULT_SYD, DEFAULT_MEL, DEFAULT_PER. Create user class printers for printer tasks that do not change based on company, SOPINV_SYD, SOPINV_MEL, SOPINV_PER. Create user & company class printers for printer tasks that do change based on company, CHQ_SYD_TWO, CHQ_SYD_MS, CHQ_MEL_TWO, CHQ_MEL_MS, CHQ_PER_TWO, CHQ_PER_MS.
NOTE: Only use printers which are always visible to the terminal server, workstation printers will not work well and could cause instability if they are not there or have different drivers when Named Printers tries to use them.
- 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.
- As a continuation from the previous step: Once you have define a task as User, Company or User & Company, you must define a Printer ID for each of the users, companies or user & company combinations.Example: Select the template user TEMP_SYD and company as Fabrikam, then assign the the Cheque printer tasks in the purchasing series as User & Company Class with the Printer ID CHQ_SYD_TWO. Change the company to Microsoft and use the lookup button to select Printer ID CHQ_SYD_MS. Repeat for user TEMP_MEL and Printer IDs CHQ_MEL_TWO and CHQ_MEL_MS and then for user TEMP_PER and Printer IDs CHQ_PER_TWO and CHQ_PER_MS. NOTE: You can have the printer class as User, Company, or User & Company and have no Printer ID defined. However unless Named Printers can find a Printer ID from the associated template user’s settings, it will ask for a Printer ID interactively using a system dialog when you print.
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 Application Article 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.
This article was originally posted on the Developing for Dynamics GP Blog and has been reposted on http://www.winthropdc.com/blog.