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

Cannot insert the value NULL into column 'CONTACT' error when clicking on Items List in Navigation Pane

Image
Moving on from my previous article on a similar subject - see Cannot insert the value NULL into column 'BASEUOFM' error when clicking on Items List in Navigation Pane , I recently came across this error,  Cannot insert the value NULL into column 'CONTACT' when clicking on the All Purchasing Transactions list under the Purchasing Navigation Pane option, after performing an upgrade from Microsoft Dynamics GP 9.0 to Microsoft Dynamics GP 2010 R2. All Purchasing Transactions list error - Purchasing Navigation List The name of the global temp table - in this case, tempdb.dbo.##2093338- varies in almost all cases, but the end result of the error is the same. The issue has been identified running Microsoft Dynamics GP 2010 RTM, SP1 or SP2. Upon further review, the issue is due to bad data in the Vendor ID (VENDORID) column in the Purchasing Receipt History table (POP30300). In summary, if you have a purchasing receipt with a blank vendor ID or a vendor ID that doe
Read more

How to uninstall Microsoft Dynamics GP 10.0 if you cannot uninstall it by using the "Add or Remove Programs" feature

INTRODUCTION This article describes how to uninstall an existing Microsoft Dynamics GP v10 system if you cannot uninstall it by using the Add or Remove Programs feature (or Programs and Features in Windows Vista) in Control Panel. It is recommended that you verify that you cannot uninstall by using Add or Remove Programs first. MORE INFORMATION First, verify that you cannot uninstall Microsoft Dynamics GP by using Add or Remove Programs (or Programs and Features) To verify that you cannot uninstall Microsoft Dynamics GP by using Add or Remove Programs (or Programs and Features in Windows Vista), follow these steps. For Windows XP or Windows Server 2003: 1. Click Start, click Run, type control appwiz.cpl in the Open box, and then press ENTER. 2. Click to select Microsoft Dynamics GP 10.0 product from the application list, and then click Remove. For Windows Vista: 1. Click Start, type Programs and Features in the Search box, and then press ENTER. 2. Click to select the product to be un
Read more