I am working on a Named Printers issue at the moment and thought it would be a good opportunity to put some standard troubleshooting steps on the blog. 

Quick history: I originally developed Named Printers back on version 3.0 when I worked for the selling ISV partner, Sequel Technology, and later sold the module to Great Plains Software for version 5.5 and it became part of the core Dynamics.dic code for 6.0.

Named Printers issues normally come down four classifications:

• Default printer not be selected when logging into a company.
   
• Reports not printing to the expected location or with the expected settings.
   
• Settings on the Assign Named Printers window being lost.
   
• Microsoft Dynamics GP crashing when logging into a company or when printing a report.

Just before we look at the troubleshooting steps, I want to explain a little of how Named Printers works:

• Named Printers is workstation or machine based as the available printers change from system to system. To facilitate this, a Machine ID must be specified when first setting up Named Printers. By default, this would be the Network ID for the machine. It is stored in the ST_MachineID setting in the Dex.ini file.
   
• A System Series Default printer should then be specified. This Printer ID must be of Printer Class: System. This is the application level default printer set when logging into Microsoft Dynamics GP, it overrides the Windows default printer and will be used whenever there is no other printer selection made.  This is the "fall back" printer.
   
• An optional Company Series Default printer can be specified to override the System Series Default printer depending on a specific User ID and/or Company ID being logged in as. This allows for the application level default printer to be customised based on user and/or company and is set during the log in process.
   
• Then the Printer ID for specific Printer Tasks in the various series can be set using any of the available Printer Classes (System, User, Company, User & Company, Any Printer ID and Manual Selection). This will override the application level default printer set at login using the System Series and Company Series Default printers.
   
• If using the Printer Classes: System, User, Company or User & Company, if the Printer ID is left as blank, Named Printers will open a dialog and ask for a Printer ID of that Printer Class to be entered.
   
• If using Any Printer ID, Named Printers will open a dialog requesting a Printer ID be entered. If using Manual Selection, the Printer Setup window will be opened allowing for the printer settings to be selected.
   
• If running on a Terminal Server, you can use Template Users to group together multiple users with the same printer settings. So instead of defining printers for each individual user, you can create a dummy user to be used as a template and set up Named Printers for that "Template" user. Then link all the users to use those settings to the Template User. 
   
• So when selecting a printer for a task, if no Printer ID can be found, and the current user is linked to a Template User, then Named Printers will try again to find a Printer ID, this time using the Template User's user ID. This means that you can still specify settings for an individual user, but if no settings are found Named Printers can fall back to a template.
   
• Named Printers can only control printer destination and settings for reports printed from inside the Microsoft Dynamics GP application using the Report Writer. It has no ability to control printer from external applications such as FRx, Crystal Reports, SQL Reporting Services, or Microsoft Word.

The following Knowledge Base (KB) articles discuss some of these points: 

• How the named printers feature selects a printer in Microsoft Dynamics GP (KB 935790)
   
• Description of how to use named printers to enable printer destination selection and to enable various printer tasks in Microsoft Dynamics GP (KB 936945)

Below are some questions that help define and troubleshoot a Named Printers issue, with an explanation of why each question is important:

1. Are the users on individual workstations or sharing a Terminal Server/Citrix machine or farm of machines? 
   When a Terminal Server/Citrix environment is being used there are two additional considerations added. Firstly, it is likely that settings will be defined on a per user basis (possibly using Template Users), and secondly, there is the issue of workstation printers vs network printers vs local printers.  Workstation printers can change depending on the workstation being used as the remote client. Workstation printers and network printers can also take time to be "available" in a terminal server session. Attempting to change to a printer that is not available or not available "yet" will fail. Printers defined locally on a Terminal Server (for both local and network printers) work best as they are always available. The following article discusses the setup of Named Printers on Terminal Server in more detail:
   
   Using Named Printers with Terminal Server
     
2. Does each workstation or Terminal Server have its own unique Machine ID?
   It is possible to have the same ST_MachineID Dex.ini setting on more than one machine.  This could be due to a copied Dex.ini file or an intentional change. The idea is to allow multiple machines to share the same settings. This is not a supported environment and will only work if every machine using the same Machine ID is absolutely identical. They must be the same version, build, service pack, hotfix, windows update of the operating system and they must have exactly the same printers set up using exactly the same version, build etc. of printer driver. The reason for being so pedantic about being exactly the same will be explained in the next point.
     
3. Has the printer driver been updated manually or automatically (Windows Update) recently?
   Named Printers settings are stored in binary and are only valid for the printer driver build they were created on. Attempting to use binary data stored in printer settings with an unmatched printer driver can have unpredictable results, including failure to change printer, use of incorrect settings and in the worst case scenario, causing Microsoft Dynamics GP to crash. To fix this, refresh the printer settings; from the Setup Named Printers, select each Printer ID and click on the lookup for the printer and reselect the printer settings and save the Printer ID.
    
4. Are you using Named Printers to select an application default printer?
   The default situation would be to use Named Printers to select the application default printer using the System Series and Company Series Default printers. Now, if the printer is failing to change after login, it could be due the printer not being available (see point 1) or because the printer driver has changed (see point 3). If Microsoft Dynamics GP is crashing just after the company selection, it is possible that Named Printers is causing this (as per point 3). The KB article below explains how to temporarily disable the setting of the default printer, so you can log in and fix the printer settings:
    
   Error message when you try to start Microsoft Dynamics GP on a computer on which named printers are enabled: "Application must close" (KB 909739)
    
5. Is that application default printer the same regardless of which user and company is logged in?
   This is just trying to understand whether the System Series Default printer is being used alone, or if the Company Series Default printer is also being used. Named Printers will actually try to change printer twice if both System Series and Company Series Default printers are being used.
    
6. What other Printer Tasks in which series are you specifying printers for?
   To help understand how the site is using Named Printers, we need to know what Printer Tasks have been defined and if they are working.
    
7. Are the settings on the Assign Named Printers window being "lost"?
   The setting of Printer Class on the Assign Named Printers window is a workstation wide setting. Changing the Printer Class setting will remove any Printer IDs assigned to that Printer Task on the workstation. Where this becomes an issue is on a Terminal Server install where they are using User Class printers. If a Printer ID for a specific user has not been defined, Named Printers will open a dialog to ask for one. If you are logged in as that user and change Printer Task to None, it will erase the settings for all users. Or if you change the task, just to force the lookup window to open, that will also erase settings.... in this case use the lookup button instead.
   
   In Microsoft Dynamics GP 2010, we added a warning to prevent accidental removal of settings caused by changing the Printer Class drop down list. The article below explains how you use the Support Debugging Tool to apply a similar temporary "fix" to prior versions:
     
   Using the Support Debugging Tool to create temporary fixes (Note: This issue is fixed in Dynamics GP 2010 onwards).
    
8. If the settings are not lost, then we can turn on Named Printers logging to see what is happening.
   Edit the Dex.ini file to add ST_Debug=LOG into the [General] section and check the ST_Debug*.log files generated. This show whenever Named Printers attempts to change a printer and if it believes it was successful. Note: Please ignore the "Message #22404 missing" message that can appear in the log, the message missing is a bug (PR 62974), but it is just telling you that the user logged out and Named Printers performed some cleanup tasks. The following KB article covers logging:
    
   How to create a log file that you can use to troubleshoot Microsoft Dynamics GP when the program does not use the printer that you specified in the Named Printers Options dialog box (KB 850068)
    
9. Not all settings on all drivers work with Named Printers.
   Not every setting that is available on a printer driver works with Named Printers. Some settings are just not saved in the printer settings stored by Named Printers and some settings that are saved don't get applied when Named Printers requests the change. Using a different driver (Windows vs Manufacturer) or a different build can sometimes resolve this.

That's all I can think of at this stage. I hope this information is helpful.

David