Dynamics GP2010 - local workstation can only log in as 'sa'

(0) Share

Report

Posted on by Community Member

My client is on GP2010 and most users access via terminal server. We have done two local installs, and one works without issue and the other can only log in as 'sa'. I created a new user on the work station that can log in as sa and now the new user can log in there, but not in the terminal server. Any ideas? We've compared ODBC's and they are identical. Thanks!

*This post is locked for comments

I have the same question (0)

All responses (4)

Answers (0)

Suggested answer

Bill Campbell 12 on at

Like (0)

Report
Copy link

Link copied!

I think we are missing some of the details that make an answer difficult.

When you say - created new user on the work station - what kind of user? Did you do this in Active Directory? Did you do this on the application Users?

If you created the user in the Application - Users - did you also provide User Access - which tells the system what company they have access to.

If you did the above, did you forget to grant Security to the user for each of the companies that the user has access too.

It also sounds like from the limited comment that you have a permission problem - user can not access files on the terminal server or they can log onto terminal server, but can not run application on the machine. Security / Permissions are a huge part of the problem for all user issues.

If this helps, mark as Answer. But it would be helpful to get more details to assist in more detail.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report
Copy link

Link copied!

Hi - I created a regular user within GP and set them as a power user. I granted them access and set up security and was able to successfully log in as them - but ONLY from the local workstation, NOT from the term server. So I have a local workstation that can log in with SA or with a GP user created from it, and then I have a terminal server that works with the SA user and all other GP users except for the one that was created from the local workstation. I have another local workstation that we installed GP using the exact same files. I don't understand what could be unique about the workstation's environment. Thanks!

Was this reply helpful? Yes No
Ian Grieve 22,784 on at

Like (0)

Report
Copy link

Link copied!

I know you said you checked it, but this does sound like there is a difference in the ODBC setup. The ODBC has to be exactly the same down to any spaces and capitalisation; I had one client have problems where they had the port being specified and separated with a comma, but one client machine had a space after the comma where the rest didn't.

Was this reply helpful? Yes No
Suggested answer

Frank Hamelly | MVP... 46,625 Moderator on at

Like (0)

Report
Copy link

Link copied!

Ian is spot on. The reason behind this is the password algorithm includes the User ID (case sensitive) and the Server name from the ODBC DSN (not case sensitive) in the encryption key. What this means is that if the Server name is changed or if you swap from using a Machine Name to an IP address, the old password will no longer work. It also means that once a password has been created for a specific User ID, the case used for that User ID must remain the same. For example: a password created for JoeBloggs will not work if the User ID is entered as joebloggs. The reason is that if the encryption key is different, then the password sent to the SQL Server will not match regardless of what is entered by the user. So if you swap to a different workstation, make sure that the ODBC DSN Server Name is the same and that the User ID has been entered the same case.

Was this reply helpful? Yes No