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/

Comments

Frank Hiller said…
I'm not sure I follow; are you simple preventing disconnected sessions from being logged off?

We host GP via RemoteApps and have experienced the printer "sticking" issue on multiple implementations. It seems that the default printer is reset to the server’s default printer when a user reconnects after becoming temporarily disconnected, not logged off.

I do not understand how settings a time limit for logoff would alleviate the issue. I also enabled the “Configure keep-alive connection interval” on a hunch, however this was also ineffective.
August 20, 2011 at 2:33 PM
Mariano Gomez said…
@Frank:
Should you have any further questions on TS RemoteApp and/or how any of the features would affect your specific environment, please add a comment to the blog post over at the Remote Desktop Services Team Blog.

I am not aware of your particular environment, and this article merely indicates that this was what worked for my customers and some partners having the same issue. All situations are different.

MG.-
Mariano Gomez
August 20, 2011 at 8:38 PM
Rider said…
Printers are always a sensitive topic for our end users. We decided to use Tricerat's Screwdrivers and after some initial bugginess, it's working well for our 3-node RemoteApp session hosts with GP 2010.

We're having an entirely different problem though- at 8:20am everyday at least 5-8 users in our UK office are logged off, seemingly at random.
September 8, 2011 at 8:35 AM
steve said…
Mariano, sorry to comment on an old post like this, and I do appreciate you highlighting this feature of WS08 and TS, but as @Frank said, lengthening the session termination time delay doesn't actually resolve the issue -- it mitigates it insofar as you can leave your disconnected sessions open forever. If the policy is 18 hrs and a user leaves on day 1, returning the next morning, their printer settings will still be available as you describe. But if they leave for a weekend, we'd need to keep their session open for 48 hrs. If they leave for 2+ days....and so on. We deliver 20 applications to our users via RemoteApp -- GP is the ONLY one that doesn't map the user's local default printer correctly. Really -- the only one. It's a shortcoming in GP. An odd one, but bothersome nonetheless.

I love reading your stuff and will continue to do so, but just want to clarify that the session term delay is a minor mitigating step at best, not a resolution to a real problem.

Thanks for the continued great work!
October 28, 2011 at 7:14 PM
Mariano Gomez said…
Steve,
I appreciate the sincere input and point taken. I should have called it "The Workaround" instead of "The Solution", :-)

Please keep up the readership.

MG.-
Mariano Gomez, MVP
October 28, 2011 at 7:24 PM
Mike said…
I found this post during a recent search for a solution to the same default printer issue that my company has when launching their own applications via RemoteApp. The research and conclusion you reach makes sense, however, like some others who have commented there is something still not quite right. So I continued my research and testing and finally found what I believe is the root cause of the problem.

You were on the right track when said that this behavior is by design, but the behavior you have missed entirely is how log the mapping of the printers at the beginning of a remote session takes. Therein lies the issue. The remote session takes too much time to map all the client's printers and thusly when an application is being launched it doesn't pick the correct printer because RDS has not had a chance to load them all and set the default. The fix I have deployed is to simply delay the launching of the application via a powershell script that I then call on via a batch file and publish as the intended application.

Voila. The app is delayed by whatever value in seconds I specify and I get my default printer everytime.
November 1, 2011 at 1:45 PM
Jim Ponder, IT Dude said…
If using remote desktop connection, you need to make sure to uncheck 'printers' in the local resources area. Every time you connect in, it attempts to set the local printers on the terminal desktop resulting in a lost default printer.
March 2, 2012 at 10:38 AM
Safdar Ali said…
This is great. Can i use this for printing plastic business cards?
December 17, 2012 at 4:18 AM
Mustafa Haidry said…
hir sir my name is mustafa and we also use AX.but i instal AX in new laptop.and also instal thinprint but i am unable to print any report.only AX reports not shown printer otherwise all applications show my default printer...
March 2, 2016 at 11:53 PM
Unknown said…
We know that the printer is a very sensitive topic. I was searching for such types of topic because I got the same sticking problem in my printer. Finally, I got a solution from your blog. But another issue happened with my printer that was sometimes Canon Printer Printing Blank Pages. I do not know why that issue occurred in my Canon printer.
October 15, 2019 at 12:00 AM
Post a Comment

Popular posts from this blog

DBMS: 12 Microsoft Dynamics GP: 0 error when updating to Microsoft Dynamics GP 2013 R2

Image
Hello all! It's been quite a while since I've actually written anything of remote interest to anyone who follows my blog, but at the same time, you will be pleased to know that I've been quite busy in the consulting front, with upgrades, server migrations, complex multi-instance postings involving 10's of thousands of transactions, wrapping up some Field Service Automation projects, and the list goes on and on. This time around I want to bring to the forefront, an issue I encountered updating  from Microsoft Dynamics GP 2013 SP2 to Microsoft Dynamics GP 2013 R2 plus the latest service pack. Background My client requested a server migration to a new environment where they wanted to deploy Dynamics GP 2013 R2 web client (plus the latest service pack) and upgrade their relational database management system to Microsoft SQL Server 2014. This is something I'm absolutely comfortable with (for the most part) given also that my client was sitting at Microsoft Dynamics...
Read more

Do I have to use those "Z-" currency IDs in GP?

Image
I know this seems like a trivia question, but recently I have come across a number of clients who have been using Microsoft Dynamics GP for a number of years and have been told by their former partners that they *must* use the predefined currency IDs created after adding the sample company, with no real explanation to support these claims. Case in point, my new client in Saudi Arabia, has been struggling for years to understand why they were told to prefix all currency IDs with the "Z-". So they went ahead and setup "Z-SR" for the Saudi Real. If you are familiar with Microsoft Dynamics GP and the sample company, Fabrikam, you may have noticed by now that after adding the sample company (which is not a requirement by any means), you will get a number of predefined currencies such as Z-US$ (US Dollars), Z-UK (British Pounds), Z-C$ (Canadian Dollars), Z-AUD (Australian Dollars), and so forth, accompanied by a number of exchange rate tables. If you are not familiar wi...
Read more

Microsoft Dynamics GP Scrolling Windows and Line Sequence Numbers

Image
I thought I would write about something meaningless that no one really thinks about. However, I realized that this is a compelling topic since it makes for some interesting discussion around the ability to insert line items withinin most transaction scrolling windows. Let’s take some time to understand where Line Sequence Numbers come from. A Line Sequence Number is auto generated by Dynamics GP and uses a seed value of 16,384 as a basis for the first line. Each subsequent line in the scrolling window is incremented by this number, so line number 2 would have a Line Sequence Number value of 32,768, line number 3 would have Line Sequence Number Value of 49,152, and so on. Since most GP transaction entry scrolling windows allow inserting rows in between line items, the newly inserted Line Sequence Number value is calculated as an average between the previous and the next line item sequences, i.e., if you were to insert an item in between row 1 and row 2 in the scrolling window -- keep in...
Read more