Share
ReportHello:
We're on GP 2013 R2 (12.00.1920). Today, we changed our "sa" password. We do so, about every sixty days.
None of our ODBC connections were based on the "sa" user ID.
So, the very first time that I tried to login as "sa" on each of our three production Terminal Server boxes, I received a message saying that the password that I entered was incorrect.
The second time that I tried on each box, the "sa" password worked perfectly.
Again, the "Dynamics GP 2013" ODBC connection were not configured with "sa". They were originally created, by the app, when it was first installed.
So, for at least two boxes, "SYSTEM" was the User ID field for the "Dynamics GP 2013" ODBC connection.
On the other box, the User ID field contained a read-only login that we use for reporting purposes when extracting data from SQL into Excel. I think that I was doing some testing in Microsoft Query a few weeks ago on that box and had "accidentally" changed the credentials for the "Dynamics GP 2013" ODBC connection in the "Data Sources" window of Microsoft Query, not realizing that I was changing the credentials for GP 2013 R2 also.
Since I was having the issue on all three production Terminal Servers where I was told by GP that my "sa" credentials were wrong on the first attempt and the second time was told that they were correct, I decided to update the "Dynamics GP 2013" ODBC connection on all three boxes with the new "sa" credentials. I did this, in hopes of this issue not happening again, when we change the "sa" password again sixty days from now.
Here are my concerns and my questions. When we change the "sa" password sixty days from now, will no one be able to access or use GP, until I go on to each of the three boxes and update the "Dynamics GP 2013" ODBC connection to reflect the new "sa" password?
If so, what is the best way to prevent the "stifling" of users from accessing and using the app?
Thanks!
John
*This post is locked for comments
All responses (
Answers (
65,271
