You’re offline. This is a read only version of the page.
1,755
I am currently attempting to install Dynamics GP 2010 on the first client in our environment. SQL Server 2008 R2 has already been installed on a separate server. I am installing GP 2010 on Windows Server 2008 R2.
My Question: Is it possible to install Dynamics GP 2010 without using the sa account?
I have read through the following similar post but it did not answer my question:
https://community.dynamics.com/product/gp/f/32/p/31854/54758.aspx
In our environment the sa account is disabled and the dba's do not want to enable it for the GP install.
I have read through the installation documentation for GP 2010 and it says "You must be logged in as a system administrator to complete database and system functions within Microsoft Dynamics GP Utilities". Does this mean you must log in as "sa" or you must log in with a sql account that has system admin permissions?
The installation documentation also states that the sa account must be entered when creating the ODBC. Is this required for all GP client ODBC's or can a different account be used? If a different account can be used, what permissions are required?
I am attempting to complete the install without the sa account. Here are the steps I have taken so far:
1. Logged in as a server administrator I have successfully ran through the GP 2010 install and chose not to install any features (we use HR and Fixed Assets but I will install these features later)
2. I have created a SQL Server account with SQL Server Authentication named "gpinstallacct" for installing GP and have convinced the dba's to give it the systemadmin server role just for the install. We have also given this account access and made it owner for all the system databases.
I can successfully login to SQL Server Management Studio and connect to the default instance with this new account. (GP databases will be installed on this default instance)
3. When I run Dynamics Utilities and try to login with this sql server account I get the error message "This login has failed. Attempt to Login Again or Contact Your System Administrator".
*This post is locked for comments
Frank, I just tried logging in as 'sa' and I was able to add a new user and give the user access to companies. My thinking here was that IT was reluctant to give up the 'sa' password so for most security functions DYNSA would be sufficient. I suppose one thing I could think of would be the creation of a new company.
Just an FYI - DYNSA doesn't have full rights in SQL that 'sa' does. If you have certain processes that require SQL sysadmin rights, such as certain PSTL tools, you can also assign SQL sysadmin rights to any GP user (permanently or temporarily).
You will need 'sa' to add/modify users or to allow access to company and other security tasks. Now there is the DYNSA user account you can use for those same functions. This way if GP uses a shared SQL instance the DYNSA account can be limited to just GP databases.
Sandip,
In SQL 2008 you cannot have a blank 'sa' password, the installation will require it. :-) Not 100% sure about SQL 2005, it's been a while since I installed it.
Greg,
I have seen blank password for sa in production(SQL 2000) environment while working in Bahrain as well as in US too.. in GP (7.5 to 9.0)
I do face lots of issue because of blank password specially in Webservice Installation. But don't know what was logic where consultant not assigned password to sa.
Thanks
Sandip
Hi Victoria,
Thanks for your response and confirming that sometimes you just need the 'sa' account for GP and there is no way around it.
Sometimes it is difficult to get the resources for a separate SQL instance dedicated to GP. This company has a Storage Area Network (SAN) implemented for the sql databases and a fail-over cluster instance implemented for SQL Server. So when planning the architecture it was decided to have one sql instance for all 12 sql databases (only 4 are GP databases). Their disaster recovery policy requires a fail over architecture for sql server and they did not want to implement this for two SQL instances. So after we go live with GP our plan is to disable the 'sa' account and temporarily enable it in the future for applying GP service packs and for whatever else requires 'sa'.
Hi Greg,
I believe that it is possible to create a SQL user with sysadmin rights to accomplish most of what is needed for GP. That said, there may still be times when you absolutely need 'sa'. Some of the PSTL tools are hard coded to require the 'sa' login and some 3rd party products require 'sa' for their SQL objects installation.
In the many years that I have been working with GP, I have not yet run into a situation where I had to do without 'sa'. I know there have been a few posts here from companies that feel they must disable 'sa', but, in my experience, that is not the norm.
Separately from whether you use 'sa' or not, in my opinion, since SQL Server licensing is no longer limited to how many instances you can have, there are very few situations where it doesn't make sense to have a separate SQL instance for GP. And with all the advantages of having a separate instance, that is what I always recommend, also.
I finally got our dba's to enable the sa account and I successfully installed GP 2010.
So it is my understanding that the sa account is required to install Dynamics GP. And the sa account is also required for applying GP service packs. This is very important to know when planning your SQL Server architecture when you have other apps using SQL Server databases and security is a concern. I recommend installing GP on its own separate SQL Server instance.
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,151
Super User 2024 Season 2
#2
Martin Dráb
229,963
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (