Installing GP on Terminal Server

(0) Share

Report

Posted on by Jim Lines

Hello,
I'm building out a new terminal server (2008) from scratch and am looking for the "official" instructions on how to do so. I thought I could just install GP and add my AD users to the Users or Remote Desktop Users group. My test users are not able to log into GP and get prompted to run utilities. I'm sure this is a permissions issue. I found several posts on the forum, but am wondering if there is a set of instructions so I can get this set correctly before deploying.

Thanks in advance!

Jim

*This post is locked for comments

I have the same question (0)

All responses (9)

Answers (5)

Verified answer

Redbeard 12,931 on at

Like (0)

Report

Here's a link to a KB article on deploying GP in Terminal Services environments.

support.microsoft.com/.../872242

Was this reply helpful? Yes No
Verified answer

Jim Lines 4 on at

Like (0)

Report

Harrison,

It looks pretty straightforward about the GP install. I'm looking for info specific to what AD permissions the users need. My predecessors have full local admin right to all GP users... (ugh). I'm trying to nail down security.

Thanks,

Jim

Was this reply helpful? Yes No
Verified answer

Derek Albaugh on at

Like (0)

Report

Hello Jim,

We don't really have any specific set of AD permissions a user would need to access Dynamics GP on a terminal server.

On a normal server, we recommend each user having a minimum of Read/Write, if not Full Control, to the following:

--The Dynamics GP directory that the application is installed to.

--The user's own TEMP directory

--Any shared network folders or directories that hold modified forms or modified report dictionary files for Dynamics GP.

You mentioned your test users get prompted to launch Utilities when they attempt to login. If they run Utilities, what does it do? After Utilities runs, and they attempt to login again, does it prompt for Utilities again? If so, make sure the Dex.ini file is not set to Read-Only and the SYNCHRONIZE= line in it, is not set to TRUE, as this can cause the application to continue to prompt to launch Utilities.

Thanks,

Was this reply helpful? Yes No
Verified answer

Jim Lines 4 on at

Like (0)

Report

Derek, Everything seems to be running smoothly. Once I made sure users had Read/Write to the appropriate folders, the error subsided. Thanks for taking the time to answer.

Was this reply helpful? Yes No
Suggested answer

Derek Albaugh on at

Like (0)

Report

Hello Jim,

I'm happy to hear that helped resolve the issue.

Have a great day and thanks again,

Was this reply helpful? Yes No
davidf. on at

Like (0)

Report

Jim,

Terminal Server 2008? not R2? If you can, i definitely recommend going with at least 2008r2. But even then you're building up a server in the final days of 2014 on a version that's not that far away from being eol.

Are your users running GP from the TS Remote Desktop or are you implementing Remote Applications?

What I did - 4 years ago when 2008r2 was still fairly new ;) - was roll out Remote Applications.

1>I created a remote app installer which used a batch file to first map a drive to the share where the OLE Attachments were stored, and then call the GP application specifying where to pick up the dex.ini for each user. Like this:

"C:\Program Files (x86)\Microsoft Dynamics\GP\Dynamics.exe"

"C:\Program Files (x86)\Microsoft Dynamics\GP\Dynamics.set"

"%userprofile%\DynamicsGP\Dex.ini"

2>Have each user log in to the TS desktop which creates their profile. While logged in, go ahead and map drives and set their default printer.

3> Under their User directory, create a folder to hold their individual dex.ini file. In my example above, the folder is called "DynamicsGP".

4> Install the Remote App rdl on the users local machine and they can launch directly into GP like it was a "fat client".

But yeah, you do have to make sure they have r/w permissions on the GP\Data folder and temp directories.

We run all our GP users on the remote app and it really cuts down on support issues.

Was this reply helpful? Yes No
Jim Lines 4 on at

Like (0)

Report

David,

Thanks so much for your detailed reply. Yes, we’re on TS 2008 R2. We have a dedicated systems team that handles our OS versions and I’m not sure of their upgrade plan.

Yes, our users are running GP from RDP and not remote applications. I’d like to simplify and have them use GP as a remote app in the future, but things are going to remain at a status quo right now. The environment was set up before my time and I don’t want to go making any changes. We’ve got a pretty big environment with many customizations and I don’t want to rock the boat as seemingly simple changes have had major impact in the past. I do appreciate the details on how to set up the fat client. That will be super helpful if/when I go down that road.

How does SmartList export to Word/Excel with the Remote App? Right now they export to Excel on the TS which has office installed.

Lastly, have you run into any issues with printer mapping? I was able to install the Windows Print Management tool and export the drivers from my production TS into my server that I am building, but I’m not seeing my printers map properly (Fax, XPS Document Writer, and a Dell Printer map). I’ve installed drivers all over the place, but I think I must be missing something. I’ve got the map printer selected in my RDP connection and the Group Policy on the server is set to allow remote mapping of printers. Any suggestions?

Thanks again David!

Was this reply helpful? Yes No
Verified answer

davidf. on at

Like (0)

Report

Smartlist exports to the Word/Excel on the TS. You can change the settings in Excel & Word to save back to their local drive or a network share by default.

Printer mapping seems to work pretty well, as long as you have the same driver installed locally and on the TS. Networked printers work best, sometimes local USB printers are a pain to get working right for us.

Was this reply helpful? Yes No
Jim Lines 4 on at

Like (0)

Report

Thanks David, good to know!

Was this reply helpful? Yes No