While brainstorming about an interesting topic for my next Gilchrist Scott blog post, I got a call about setting up new users.  Seemed very straight- forward at the time. 

Step 1: Log into Dynamics GP, go to Tools ->Setup->System->User and enter an ID and Password.  You can enter a class if your company is using that.

Step 2: Once that part is done, you’d then go to Tools ->Setup->System->User Access and grant them access to each of the companies you want them to be able to get into. 

Step 3: Grant Security so that based on the work that they do, they will only be able to access those areas that have to do with the duties that they perform.

Well, we did this process together, and then tested the users.  Perfect!  We were able to log in as each user and all was working very well.

The part that was not so straight-forward? When they tried to log in as these new users on another machine.  They weren’t able to get these users logged in.  They kept getting the error “Your login failed.  Attempt to login again or contact your system administrator.”  Typically this means that you just entered the password incorrectly.  But while performing the definition of Insanity – “Performing the same steps over and over again, and expecting different results,” we found that we weren’t typing in the wrong password, because when we went back to the original machine that we setup the users on, the same password worked.

Now we needed to figure out what was different about these two machines that would play a role in these strange happenings.  There were several things that could have been contributing to the problem, so we decided to start with the most obvious first.  Any ideas?  Well, I took a look at the ODBC connection.  This is what is used to get Dynamics GP to be able to talk to the database where all your data is stored. 

When I looked at the connection, what I found was that the initial workstation was setup with an IP address (numbers that identify the server) and the other was setup using the server name as it appears on the network.  This was causing the issue for the Id’s and passwords.  The ODBC connections all need to be setup identically or there may be issues such as this.  It happens because the when the password is saved it gets encrypted based on the way the connection is setup, and if you try to access that new user on a workstation where the connection is not setup exactly the same as the workstation that created it, the decryption will not work to extract the password and allow the user in.

As usual with troubleshooting issues that come up, always be sure to look at the obvious first.  Just because something seems simple doesn’t always mean it is. 

Here’s to happy connections!