April 8, 2015 at 8:39 am
Hey all,
Working with a client that has a a Dynamics GP infrastructure and looking for some assistance.
Currently their process for setting up a copy of their production environment is to backup/restore the databases + the logins. In regards to the logins though, they never work after running the supplied scripts. He has to go into the application and reset the passwords anytime a restore occurs. I found this article: http://support.microsoft.com/en-us/kb/878449 which does elude to having to use the tried and true sp_help_revlogin (they call it Capture Logins).
Anyway, I just did a test with him and verified that the password used/created within the application does not correlate to the SQL authentication password. In that we reset user X to password Y and then attempted to connect to the SQL instance with those credentials, unsuccessfully. So my assumption is that this has some relation to how the accounts are encrypted (http://blogs.msdn.com/b/developingfordynamicsgp/archive/2008/10/02/why-does-microsoft-dynamics-gp-encrypt-passwords.aspx) and why post restore the accounts have to be manually reset within the application. Is this working as intended?
With the above said, I question how putting Dynamics GP into an availability group is going to work. If the above is truly necessary and by design, on fail-over won't we have to reset the passwords every time?
Any insight would be most beneficial.
Thanks!
April 8, 2015 at 9:05 am
are you scripting the logins across sql server versions?
That's about the only time it'll fail as the encryption changed between 2008 and 2012
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
April 8, 2015 at 9:10 am
Negative.
Do you administer a GP environment? Do you know if you really have to reset the passwords from within the app post restore?
April 8, 2015 at 9:47 am
no I don't.
Cant see that the passwords have to be reset, there must be something else going on to explain this
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
April 8, 2015 at 10:26 am
Well, according to that article, by design there is some layer of encryption in place. Even though the users connect with their own SQL auth, the password set within the application is not the same password for said user's SQL auth account. My assumption is that this where the issue stems from.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply