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/

Advertisements

7 Responses to Default Printer not ‘sticking’ when running Microsoft Dynamics GP in Terminal Services RemoteApp

  1. Frank Hiller says:

    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.

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

  3. Rider says:

    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.

  4. steve says:

    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!

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

  6. Mike says:

    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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: