GP user password must be reset on new pc

(0) Share

Report

Posted on by DebN

3,954

We have a customer who has this same issue each time they add a new workstation. When any existing GP user, other than sa, tries to log into GP on a new machine, they get the "login failed" error. So, they log into GP as sa on that machine, reset the user's password (using the same password) and then that use can log onto that PC. Now, if that user tries to log into GP on another machine, they can't until they reset the password on that other machine. What could be the problem? Is this some kind of permissions issue?

*This post is locked for comments

I have the same question (0)

All responses (6)

Answers (1)

Verified answer

Melissa Sandrovich on at

Like (0)

Report

This is usually an issue that your ODBC connections are not setup exactly the same. The server name must be EXACT, as this is part of the encryption that GP uses. The sa user doesn't have this issue, as it is technically a SQL user.

Was this reply helpful? Yes No
Jeff451QL 155 on at

Like (0)

Report

Is the ODBC DSN server name the same on all machines? The sa password is encrypted using the standard SQL server algorithm. So, it will work from multiple workstations. The GP password is encrypted using the DSN server name as part of the key. So different ODBC DSNs will not decrypt the password identically. Possibly one DSN is using the IP address and another the server name.

See below for a full explanation

http://blogs.msdn.com/b/developingfordynamicsgp/archive/2008/10/02/why-does-microsoft-dynamics-gp-encrypt-passwords.aspx

Was this reply helpful? Yes No
Suggested answer

soma 24,410 on at

Like (0)

Report

Check the ODBC connection settings on the all the new PC's and set the IP address of GP server instead of using server name. Sometime the same server name point the different IP address on the each PC. So, always try to set the IP address of GP server in ODBC.

Hope this helps!!!

Was this reply helpful? Yes No
Suggested answer

Bill Campbell 12 on at

Like (0)

Report

In addition to the comment from Soma about the name of the server, I have found that the actual name of the DSN on each machine can make a difference to the connection.

I am certain of this from my experience with FRx that will allways give you error if the DSN names are not identical from machine to machine - so maybe this is similar?

Let me know if this helps.

Was this reply helpful? Yes No
DebN 3,954 on at

Like (0)

Report

Thank you for all the responses! This issue was due to some workstations not having the correct server name in the ODBC connection.

Was this reply helpful? Yes No
Suggested answer

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

Like (0)

Report

Hi Deborah,

The best way to avoid that type of problem is to create a deployment package for your GP client... The Setup of GP has an option for this and it will add the ODBC link creation as part of your Client Setup on every workstation, thus removing the potential of bad configuration for the ODBC setup..

Globally, in our company I've decided to limit the amount of deployed local GP clients to only users that either need a special configuration or are a key / critical player in GP (i.e. production/shipping). All my other users are directed towards a Citrix or TS server applications.. Much easier to maintain when you have to apply Service packs or upgrades. This way 90% of your user base is able to get back to work quickly after the upgrades. And you have less local clients to worry about to do the upgrade.

Hope this helps.

Was this reply helpful? Yes No