How do I stop using the SA account with Great Plains

We have a dilemma with our installation of Microsoft Great Plains (Dynamics).  We had a vendor do the entire installation.  The setup is that the client is installed on a Windows Server 2008 Terminal Server and the database is installed on a different Windows 2008 Server running Microsoft SQL Server 2005.  The vendor tells me that any of the Great Plains administrative tasks must be done with the SA login.  For many reasons, I dont think that is a good idea.  I created a SQL login that has full administrative rights over just the GP databases, but that did not work.  Is there any way I can get away from using the SA login to do administrative tasks inside of GP?
LVL 1
biggstrcAsked:
Who is Participating?
 
Jim P.Connect With a Mentor Commented:
DYNSA is the only alternative and the user still pretty much has to have the SysAdmin role assigned.

The only real advantage is that if you use the same SA password against all SQL instances, is that the End user/accounting user doesn't have to have it.
0
 
James GlaubigerCo-FounderCommented:
You say you have created a new account for these tasks in SQL and assigned the user Admin rights on the GP databases.   Have you given this account the "db_owner" permissions as well?   This usually grants the new account the same privledges as the SA for those databases.

Steps I would take.  Create this new account in GP, for the sake of example we will call it "GPSA".  Assign it the Power User role if in GP10, through account security windows etc.  Then go into SQL Management Studio, and also grant this account the "db_owner" role for the GP databases.   Then log back into GP with this new account and test if it can do the tasks you require.

NOTE:  You may also need to assing this user the SYSADMIN role as well.

I would suggest you test this thoroughly and post back results.

0
 
James GlaubigerCo-FounderCommented:
Any update on this issue?
0
Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

 
biggstrcAuthor Commented:
Sorry, not yet.  I was not able to test your solution today, since we had a crisis in another area that took my time.  I expect that I will be able to test your solution later tomorrow afternoon.  I will keep you informed.  Thanks for the help.
0
 
James GlaubigerCo-FounderCommented:
you might also want to try using the DYNSA account.  This account was created when GP was setup, and should be the db_owner of all Dynamics GP databases.   It may have the permissions needed to not use the SA account.

Post back a status of this issue.
0
 
James GlaubigerCo-FounderCommented:
Any update on this issue?
0
 
biggstrcAuthor Commented:
The first solution did not work for us.  Our Great Plains power user is trying to use the DYNSA account.  When he tries it out, I will post the results.
0
 
biggstrcAuthor Commented:
Not a great solution here, but it isn't your fault.  It seems I need to rethink how my server is set up.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.