Share via

Using Named Printers with Terminal Server

  • Article

David MeegoSome 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). 

  1. 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.
     

  2. 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.
     

  3. 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.
      

  4. 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.

  5. 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.

  6. 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.

  7. 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

  8. 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.  

 

 

Additional Notes

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. 

David

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.

Comments

  • Anonymous
    August 17, 2008
    Posting from DynamicAccounting.net http://msdynamicsgp.blogspot.com/2008/08/dynamics-gp-named-printers-on-terminal.html

    • Anonymous
      December 10, 2018
      David. When setting up templates on a single terminal server I'm running into an issue which appears to indicate that I can't have multiple users print to the same task using different printers. When attempting to assign I get an error "Changing the printer class will remove the existing settings for this printer task for the current Machine ID. Do you want to continue". Am I missing something or is this not possible?

  • Anonymous
    August 17, 2008
    Posting from the Dynamics GP Blogster http://dynamicsgpblogster.blogspot.com/2008/08/all-about-named-printers-on-terminal.html

  • Anonymous
    June 07, 2009
    The Support Debugging Tool for Microsoft Dynamics GP has the facility to create non-logging triggers

  • Anonymous
    March 11, 2011
    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.

  • Anonymous
    March 11, 2011
    Hi Todd 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 David

  • Anonymous
    August 17, 2011
    Posting from Mariano Gomez, The Dynamics GP Blogster dynamicsgpblogster.blogspot.com/.../default-printer-not-sticking-when.html

  • Anonymous
    April 07, 2014
    Hi David, How can we assign specific tray of named printer for reports.

  • Anonymous
    April 07, 2014
    Hi Sunil When you select the printer, click on Properties and set the alignment and tray settings as well. David

  • Anonymous
    August 25, 2014
    Hi David, Thanks for the reply. How can I add custom reports or those Standard GP Reports which are not listed under Named Printers?

  • Anonymous
    August 28, 2014
    Hi Sunil Have a look at my example: blogs.msdn.com/.../adding-named-printers-control-to-reports-using-vba.aspx Also look at NamePrnt.doc in the Microsoft Dynamics GP SDK (Software Development Kit). Thanks David

  • Anonymous
    August 30, 2014
    Hi David, Thanks for the reply. Through your example I am able to add my custom window or Standard GP Window in Named Printer. But my scenario is bit different I have customized Print Payables Checks window by adding few buttons. On click of one button i set to print User-Defined Check 1 and on click of other button I set to Print User-Defined Check 2 and so on. Is it possible I can assign Tray1 to User-Defined Check 1 and Tray2 to User-Defined Check 2? In a nutshell I want to assign specific tray to specific reports printed from a window.

  • Anonymous
    August 31, 2014
    Hi Sunil It all depends on whose code issues the run report command. If it is your code running the report, you can add printer clause to the run report command. If it is not your code, then you must trigger before and after the run report command is issued to change the default printer to the desired printer and back. You can add as many Printer Tasks to the list as you need, so one for each format is not an issue. You just need to adjust your code to use the correct printer task for each report. Named Printers stores the destination printer AND its settings (including Tray number and orientation). David

  • Anonymous
    December 10, 2018
    David. When setting up templates on a single terminal server I'm running into an issue which appears to indicate that I can't have multiple users print to the same task using different printers. When attempting to assign I get an error "Changing the printer class will remove the existing settings for this printer task for the current Machine ID. Do you want to continue". Am I missing something or is this not possible?

    • Anonymous
      December 10, 2018
      Hi JayThis just means you must have already set up some printer settings in a different printer mode. If you want to have printers that change on a user basis then you need to change the mode to user. This will delete any previous settings and then you need to define the printer ID to use for each user (or at least for the template user they have been assigned).If you have a user which has not been assigned by direct assignment or by template user assignment, they will be asked to enter a User Class Printer ID at print time.DavidDavid