Printing to screen and PDF file causes default printer to change to Acrobat PDF Writer

A user recently reported a strange Microsoft Dynamics GP behavior when trying to print any report in to file in PDF format, while simultaneously sending the report to screen.

The PDF gets created and the report appears on the screen as it would be expected. However, when she attempts to print the report from the screen to printer, the only printer available is Adobe PDF Writer. While having the report on screen, the user checked the default printer, which remained unchanged, nonetheless the report on screen would only print to Adobe PDF Writer, bypassing the default printer.

I suspect what is happening in this case is, when the report is directed to screen and a PDF file simultaneously, the Runtime Engine changes the default printer to the Adobe PDF Writer (Adobe Distiller in some cases) printer in order to write the file in PDF format - after all, Microsoft Dynamics GP does not save files in native PDF format like say, Word or Excel. At the end of writing the file, but before outputing the report to screen, the default printer is not being re-established.

Given the number of printer related posts on the forums lately and the responses by Microsoft staff, it seems this has been identified (along with a few more issues) as part of a list of upcoming fixes - but just in case, I am writing about it today.

Until next post!

MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/

Read More

Default Printer not 'sticking' when running Microsoft Dynamics GP in Terminal Services RemoteApp

A bit of theory...

RemoteApp programs are programs that are accessed remotely through Terminal Services and appear as if they are running on the end user's local computer. Users can run RemoteApp programs side by side with their local programs. A user can minimize, maximize, and resize the program window, and can easily start multiple programs at the same time. If a user is running more than one RemoteApp program on the same terminal server, the RemoteApp programs will share the same Terminal Services session.

The following Microsoft TechNet article explains in more detail:

Terminal Services RemoteApp (TS RemoteApp)

Background

Microsoft Dynamics GP (versions 10.0 and 2010), is currently supported in a Terminal Server RemoteApp environment, but a number of my clients and forum users have reported in numerous occasions that the Default Printer settings are not 'sticking' or simply saving when loging out of the application (which also closes the RemoteApp session) and returning to it.

Print Setup window

The Solution

Puzzled by this, I began doing some digging and found out that the default printer "problem" is actually not a problem, but rather the way RemoteApp decides how the session disconnection will occur. Playing along with the disconnection, there was a new Terminal Server group policy setting that was introduced to control time limits for disconnection and there lies the dirty little secret.

If you are experiencing the issue I described above, please take a look at the following article by the Remote Desktop Services (Terminal Services) Team Blog:

Terminal Services RemoteApp™ Session Termination Logic
http://blogs.msdn.com/b/rds/archive/2007/09/28/terminal-services-remoteapp-session-termination-logic.aspx

The article unveils the steps required to change this behavior and make your Microsoft Dynamics GP printer 'stick'.

Also, if you are using Named Printers with Microsoft Dynamics GP in a Terminal Services RemoteApp environment, take a look at the following articles over at Developing for Dynamics GP:

Using Named Printers with Terminal Server
http://blogs.msdn.com/b/developingfordynamicsgp/archive/2008/08/15/using-named-printers-with-terminal-server.aspx

Named Printers application default printer selections not "sticking"
http://blogs.msdn.com/b/developingfordynamicsgp/archive/2011/06/24/named-printers-application-default-printer-selections-not-quot-sticking-quot.aspx

Troubleshooting Named Printers Issues
http://blogs.msdn.com/b/developingfordynamicsgp/archive/2011/05/26/troubleshooting-named-printers-issues.aspx

Please let me know with your comments if any of the above recommendations by the Remote Desktop Services team worked for you.

Until next post!

MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/

Read More

Troubleshooting printing issues with Microsoft Dynamics GP

Just lately, I have seen a number of inquiries over the various forums on printer support for Microsoft Dynamics GP (usually, versions 10.0 and 2010). If you have been in the channel as an ISV, partner, or customer since the days of the former Great Plains Software, you probably still remember that in the past testing of Microsoft Dynamics GP included exhaustive testing of a number of printers for compatibility.

In fact, leading up to the release of version 10.0, it was not uncommon to see the now infamous Printer Compatibility List, which would outline an extensive list of printers tested for all sort of "maneuvers" including large print jobs, paper handling, character blurriness, and so on. There are still some reminiscent KB articles from back in the days when printers were tested - go grab them now before they disappear!

KB article 870301 - Compatibility of Dynamics With the HP LaserJet 6L or HP LaserJet 6L SE Printer
KB article 865797 - HP OfficeJet 520 Printers
KB article 865796 - HP 6LXI Printers
KB article 865782 - HP Laserjet 5000, 5M and checks
KB article 865399 - Okidata ML 320 printing checks

Starting with version 10.0, Microsoft decided that "enough is enough!", well, not exactly in those terms, but the point being that printer manufacturers had sorted out most of the issues revolving around standards that plagued the 90's and 00's. Printer compatibility was mostly an issue during the transition from impact printers to laser printers -- for those of you out there too young to remember, this is what a dot matrix or impact printer looked like. This one in particular, happens to be an Epson (and yes, I owned one myself!).

Epson dot matrix printer

Another main reason was, they were simply too many printers to be tested! You can find the official word from Microsoft on printer testing with Microsoft Dynamics GP by using the following links:

Printer compatibility for Microsoft Dynamics GP 10.0 - click here
Printer Compatibility for Microsoft Dynamics GP 2010 - click here

Then what are you supposed to do if you suspect a compatibility issue between Microsoft Dynamics GP and a printer in your organization? Here is my list of suggestions/questions you should ask yourself to fight the printing battle:

1. Are you in a Terminal Server environment? Terminal Server environments are notoriously known for printing issues when printer driver versions on workstations do not match the Terminal Server's (or viceversa) during the printer re-direction process. I strongly suggest you consider downloading the Terminal Server Printer Redirection Wizard Tool, which will help you troubleshoot and replace print drivers that were unsuccessfully redirected.

2. Are you using Named Printers? There are a couple known issues with Named Printers "acting up" and not saving certain settings, thus causing erratic behaviors when printing. However, if you are using Named Printers on a Terminal Server environment, my good friend, David Musgrave has written what I consider to be the ultimate guide to Using Named Printers with Terminal Server.

3. Are all the printer driver versions the same on every machine? Different printer driver versions, even for the same printer, can produce unexpected behaviors, for example, if bugs have been fixed in the latest version of the driver. So always ensure you are running the same printer driver version on all workstations - oh, and make sure you obtain the drivers directly from the manufacturer's website, not the one shipped to Microsoft by the manufacturer. Many times, printer drivers are updated by the manufacturer after a version of Windows have been released.

4. Other common troubleshooting guidelines...does the problem happen to all users or one user in particular? You know you will be asked this question if you contact Microsoft Support, so do your homework and save yourself some time. This will allow you to establish whether there's a method to the madness you are experiencing. By asking this question, Microsoft Support will attempt to establish whether there's an issue with that particular user profile in your environment.

5. Does the problem happen with one machine in particular or does it happen across all machines? The objective here is to establish whether the behavior is consistent at the machine level, regardless of the user signed into the machine. If the problem can be replicated regardless of the user, then you can begin to establish a pattern. Working your way through several computers will help establish if there's a bigger issue at play.

For additional information on troubleshooting printing issues:

KB article 959033 - Frequently asked questions about printer issues in Microsoft Dynamics GP 2010, Microsoft Dynamics GP 10.0 or in Microsoft Dynamics GP 9.0

Until next post!

MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.intellpartners.com/

Read More