Dynamics GP California Partner Notes: how not to use SA account in Great Plains administration

Aug 14
07:51

2009

Andrew Karasev

Andrew Karasev

  • Share this article on Facebook
  • Share this article on Twitter
  • Share this article on Linkedin

If you have Microsoft Dynamics GP (formerly this ERP, MRP and Accounting application was known as Great Plains Software Dynamics GP and eEnterprise) implemented in your organization and your internal IT security is very tight, you may have this question: is it possible for GP administrator not to use MS SQL Server System Administrator account (sa).

mediaimage

This is very big concern,Dynamics GP California Partner Notes: how not to use SA account in Great Plains administration  Articles especially when the same SQL Server 2008, 2005, or 2000 is hosting multiple DB Applications: Dynamics GP, Payroll Processing Database, Microsoft CRM, and others.  If this is your case, you do not want Dynamics GP administrator to be able to simply open New Query in SQL Server Management Studio and Select all the run select statement against your employees salaries codes.  In this small publication we would like to offer you simple solution and highlights:

                                                                                     

1.       DYNSA account in Great Plains.  This account is what you need - it is Dynamics System Administrator, as Great Plains Software designed Dynamics for Microsoft SQL Server platform back in 1990th.  Many of the readers at this point will probably go away with the decision to use this idea and be happy, however for the rest of us - we would like you to come through checkup and troubleshooting procedures and understand the architecture

 

2.       DYNSA in SQL Server Upgrades Transformations.  If you deploy Great Plains long time, then you should know that you organization in its history potentially might came through the following upgrade: MS SQL Server 6.5 to 7.0, then from MS SQL Server 7.0 to 2000, then from MS SQL Server 2000 to 2005, and then from MS SQL Server 2005 to 2008.  We recommend you to check is DYNSA login is still member of the following Server Roles: dbcreator, public, securityadmin

 

3.       DYNSA in Test or New Companies Creation and Restore from Backup.  When your MS SQL Server Management Studio 2005 or MS SQL Server Enterprise Manager 2000 are set to use sa account, and if you are using these tools to backup and restore Databases, then when you restore the DB, database owner account will be changed to sa automatically.  In the day-to-day rush and stress of modern IT director life or in Dynamics GP internal support under the pressure, you may not realize immediately the problem of kicking DYNSA user out of the scenes - your Dynamics GP system and its databases will continue function as expected, but from this moment you will have to use SA as Dynamics GP administrator user.  In order to resurrect DYNSA you will need to first run SP_HELPDB to understand who is current owner of the DYNAMICS and companies DBSm and then you will need to reset ownership to DYNSA by running this statement: sp_changedbowner 'DYNSA'

 

4.       Last tip.  In Microsoft SQL Server 2005, DYNSA is not required to be in the DB users list, as it is DBO or Database Owner.  However for older MS SQL Server Versions: 2000, 7.0 and 6.5 this restriction might not be forced.  So, if you are getting error message in running sp_changedbowner 'DYNSA' script, please, open DB in SQL Management Studio, expand the DB  -> Security -> Users and delete DYNSA from the users list if it is there.  Then rerun sp_changedbowner 'DYNSA'

 

5.       At this point you should be able to use DYNSA account in the same capacity as SA

 

6.       If you have concerns or comments, please feel free to call us: 1-866-528-0577, help@albaspectrum.com