You’re offline. This is a read only version of the page.
100
We're testing GP 2013 currently for the express intent of making sure we can run it on a SQL server with the SA account disabled. In the initial install we were asked to supply the SA user and password for the install. That worked correctly. After the install, we are unable to log in with SA, but can log in with DYNSA. Is this by design with 2013? Does 2013 GP not need the sa account enabled in SQL after installation?
*This post is locked for comments
When GP is initially installed you need to use the SQL 'sa' account when running GP Utilities. Part of this process is the creation of the DYNSA account. Once the DYNSA account is created there really is no longer a need for the 'sa' account as far as GP is concerned. So the bottom line is the 'sa' account is used to create the DYNSA account and once DYNSA exists in SQL GP no longer needs the 'sa' account. The DYNSA account is created with the same rights as 'sa so you will be able to create new GP users and assign roles. The concept is the same as your network domain credentials. You really should not be logging in as Administrator so you create administrator equivalent accounts and login using those credentials.
Well I've answered part of my question with this post:
community.dynamics.com/.../dynamics-gp-security-conundrum.aspx
GP limits the password max length to 15 characters. Our sa password was 17. Shortened the password and are now able to log in with sa.
However, can anyone confirm officially that the sa account is now no longer needed to be enabled on the SQL server after installation and that DYNSA will be able to do all things needed?
Just to be clear, we know that the SQL sa password is correct. We can log in with it in SQL Management Studio and with the GP 12.0 Database Maintenance Utility. I'm not actually sure we have a problem. What I'm hoping is that after the initial install, GP doesn't even need SA to be enabled on SQL at all.
Leslie is saying that GP doesn't need sa anymore. Can this be confirmed in a white paper...or MS article/webpage...etc? I need to be able to show my bosses some "proof".
Thanks again everyone! You've all been very helpful.
Thanks Leslie. You'll have to forgive my ignorance on GP....I'm just the DBA charged with trying to figure out if we need a stand-alone sql server or not :)
To be more clear, our test install was successful. It asked for the sa user/pass before the DYNSA account was even created. Now after the successful install, at the log in screen, we are putting in the username sa and the sa password and getting failures. But when we put in the DYNSA user and password that were created during install it logs in correctly.
We don't actually want to leave the sa account enabled on the SQL server, but, the fact that it is enabled, but GP doesn't seem to be able to log in with it, makes me fear something is wrong with our test installation.
But, when I fire up the GP 12.0 Database Maintenance Utility and log in with sa, it works.
So I'm just needing to know that our login failures when we put in sa as the user (not dynsa) don't mean that our install is messed up.
Just some fyi's about the environment, it's Server 2012 Standard and SQL 2012 Standard.
is there a 2013 version of this tk?
it was most likely was asking for the DYNSA password during the install. You should be able to launch GP using sa. GP 2013 should now be able to run without the dependence on 'sa', even for the PSTL tools and Business Alerts.
Kind regards,
Leslie
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,240
Super User 2024 Season 2
#2
Martin Dráb
230,149
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (