GP2010 not holding printer defaults for users from a terminal server

(0) Share

Report

Posted on by Community Member

We have GP2010 installed on a terminal server (Server 2008 R2) using RemoteApps, with around 50 users hitting it from several different sites, and we can not get anyones printer defaults in GP to stay on what they selected.

We are not using a print server, and most of our printers are not installed on the terminal server itself, and no one can keep the default printer settings. If I log on right now to GP and select a printer as my default, regardless of if it is installed on the terminal server or being redirected from my local machine, when I log in tomorrow that default will be changed.

I don't think Named Printers is the solution, as it sounds like it would be a nightmare to admin. Has anyone run into a similar situation and found a solution? Would having a print server fix this issue?

*This post is locked for comments

I have the same question (0)

All responses (18)

Answers (1)

Verified answer

Jonathan Fear on at

Like (0)

Report

You are running into this issue because GP is loading before your printers are being redirected. When launching Microsoft Dynamics GP via RemoteApp often local printers from a workstation are redirected but the default printer from the workstation is not set as the default printer in Microsoft Dynamics GP. When Microsoft Dynamics GP launches it looks for any redirections of printers and if there are none found at that point Microsoft Dynamics GP will take default local printer from the Terminal Server. The workstation’s printers will appear in Microsoft Dynamics GP however the default printer in Microsoft Dynamics GP will not be the workstations default printer. Create a batch file that creates a delay. This delay provides the RemoteApp sufficient time to initialize all redirected printers and to then start the Microsoft Dynamics GP client. You publish the batch file through RemoteApp instead of through the Microsoft Dynamics GP client.

@echo off

PING 1.1.1.1 -n 1 -w 10000 >NUL

Start "FalseTitle" "C:\Program Files (x86)\Microsoft Dynamics\GP2010\Dynamics.exe" "C:\Program Files (x86)\Microsoft Dynamics\GP2010\Dynamics.set"

Note Enter the installation path that is specific to your Microsoft Dynamics GP installation. Also, the "25000" value on the second line represents a 25,000-millisecond (ms) delay.

Was this reply helpful? Yes No
john doel 335 on at

Like (0)

Report

I'm having the same problem and tried as you suggest, Jonathon, but that does not resolve the issue for us. I see the DOS batch file window appear for 10 seconds when running the .bat as a RemoteApp (I had to change the ping address to 1.1.1.0 since 1.1.1.1 was always immediately found thus no delay), but still having the same printer assignment issue. The TS/RD server is Win 2008 R2 and GP 10. There are no printers on the TS/RD server, and I have 5 redirected local printers on the client: CutePDF Writer, Fax, XPS Doc Writer, Send To OneNote 2010 and a Xerox printer (which is client default). When I run the "GPWithDelay" as I've called it RemoteApp that runs the .bat, Xerox is assigned at first, and if I change to anything else, close out of GP, log back into GP via GPWithDelay, the Xerox is assigned again. I also have the GPO "Set time limit for logoff of RemoteApp sessions" toggled to Enabled and Immediately so that sessions running a RemoteApp are immediately logged off when the client closes their RemoteApp application.

Edit ~ I should add that I've tried turning on and off that specific GPO setting, and that's had no effect either way.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Thanks Jonathan, that seems to work, though I am just starting to test it. Is that the only solution to this problem that Microsoft offers? When I present it to the Powers That Be, I would like to be able to definitively say whether or not it is the only one available.

@ Lance: I had the same problem until I changed the wait time to 20 seconds. I put a loop into the batch file with a countdown as well, since without it I doubt many users would patiently wait 20 seconds while nothing happened.

Was this reply helpful? Yes No
Jonathan Fear on at

Like (0)

Report

Yes this is the only answer we have as GP is working correctly the problem is that the redirection of the printers does not happen fast enough.

Was this reply helpful? Yes No
Suggested answer

Paul Sudduth 95 on at

Like (0)

Report

Best practice is to not use redirected printers.

Setup a network printer on the server as default.

Paul Sudduth MCTS - Dynamics

Was this reply helpful? Yes No
Bill Campbell 12 on at

Like (0)

Report

Good afternnoon, we are experiencing almost the exact same issue as discussed above. While I understand the last comment, I can not support that this is the Suggested Answer in the real world.

We have 6 physical locations across the country all that are connected by VPN to Head Office and to our Data Center that houses the Terminal Server and the SQL Server for this client. While I would like to install all the printers that are in use, that would be close to 70 different printers. And it is my understanding that the 'default' printer has to be seen by the user prior to launching the connection to GP.

What we have are a number of users that have local printers attached and then a few common printers that all users should have access to and there are published on the Terminal Server. All others come to Terminal Server as redirected printers.

In reviewing the notes above I followed the suggestion and build a delay into the Launch file of 22 Seconds using the "Sleep" command in the batch file. This created the pause (22 seconds is a long time when you are watching) and "most of the time" the redirects get attached and if you have your local printer selected as your default it seems to hold - for some time.

After some time and others user attach to the system the user often find that their local printers are no longer their default printer for GP. While looking at the users local printers we do not see a change to the users selected default printer, only in GP the change has occured.

Is there any reason why multiple users launching the same Dynamics.set and effecting the same Dex.iini would be of concern? I am trying to figure out if the Dex.ini being changed by the 77 users might be the cause of the printer changes.

Looking to the community for assistance, thanks so much in advance.

Was this reply helpful? Yes No
Fabian Perez-Parada 55 on at

Like (0)

Report

Hi Bill,

There is a way to do this, but it requires separate dex.ini files for each user. The dex.ini files are being written over every time a new user logs in, pulling their default printer as the "new" default printer. If you put a dex.ini file in each users profile, we create a Dynamics GP folder, and place the dex.ini there. Then use the following shortcut to launch GP. The %USERNAME% keyword will go to each user's folder and launch using that dex.ini

"C:\Program Files (x86)\Microsoft Dynamics\GP2010\Dynamics.exe" Dynamics.set c:\users\%USERNAME%\DynamicsGP\dex.ini

Note this path is set for Windows 2008 x64.

Also be aware that when you do an upgrade, you will need to copy down the new updated dex to each users' profiles. As you can see the more terminal servers, the more work is required to maintain this.

This is not supported by Microsoft as far as I know, although there is documentation on how to use separate dex.ini files for other reasons, so the framework is there.

Fabian

Was this reply helpful? Yes No
Suggested answer

Beat Bucher GP Gee... 28,058 Moderator on at

Like (0)

Report

Reply to everyone in this thread,

As Fabian suggested it, this is the best way to do it in a shared environment, and although we use XenApp Citrix and not TS, it's pretty much the same behavior. I put it even a step further in my batch and test the presence of the Dex.INI file in the users roaming profile, and if it doesn't exist, then it copies a default one from the GP folder. This way when there is a version upgrade, I can just delete all the 'private' Dex.INI files and the batch file wil take the latest version. With this solution you avoid also to end up with a Dex.INI file that contains hundreds of printer definitions...

Was this reply helpful? Yes No
Paul Sudduth 95 on at

Like (0)

Report

In my humble opinion, redirected printing is not well suited for professional grade users. They are far to easy to disrupt.

Additionally, differences in drivers (from PC to Server) give a variety of unwanted results when printing reports.

Keep in mind also that Microsoft Dynamics can have different printer settings for different functions.

(I have assisted many user who have just printed something that they will not be able to reprint, only to find out that they sent it to the wrong printer because they forgot to check the destination of they Print Setup in the window before they printed.)

For worry free printing, I suggest spending what it takes to get a network printer and connect to it throught the TCP/IP port on the terminal server.

The amount of time you will save and the relief from the frustration is well worth the extra $100.00.

Paul Sudduth MCTS - Dynamics (psudduth@helpdesktupelo.com)

P.S. ~ Feel free to set up a ticket at www.helpdesktupelo.com if you want some in depth help.

Was this reply helpful? Yes No
Bill Campbell 12 on at

Like (0)

Report

Paul, I can agree with your comments up to the point of 'a network printer in the TCP/IP port'

Maybe I dont fully understand something, but, we have 6 physical locations across the country from which these users are connecting, upwards of 50 users have 'personal' printers, all users are currently connecting via Remote Application and all of them are running on full Desktop PC stations.

Fabian Perez-Parada, I think I am going to have to attempt this solution as it fits with the research that I have done and the testing that I have done. I stumbled across the Dex.ini when I was doing the update and I deleted it from the system and let the first user recreate it - that was my user id - I connect to GP via Remote Desktop and have all the network printers attached to my user ID. When the next user connected I noticed the change in the Dex.ini and that is when I started to consider this as a probable solution.

Béat Bucher , you have expanded upon this solution and I would like to ask how you got the batch process to evaluate for the presence of the dex.ini file in the individual user folders?

If you can share that information it would be much apprciated.

Thanks again to all that have provided feedback on this matter, I believe that we are now closer to getting this solution to work the way it should in this environment.

Bill Campbell

billc@misltd.ca

Was this reply helpful? Yes No