Tag Archives: System

I was working on a client’s system the other day and discovered that no-one knew the dynsa password. Bearing in mind my minor crusade to get clients to stop giving the SQL sa password to the GP administrator, instead giving them the dynsa password, I needed to reset the password.

In theory this should be possible from the User Security window (Microsoft Dynamics GP menu >> Tools >> Setup >> System >> User). However. after changing the password I was unable to log into Microsoft Dynamics GP with the dynsa user.

In the end the solution is to remove the password using the SQL Server Management Studio. Next time dynsa logs in the following message will be displayed and force the password to be changed;

Actually, that’s not the question at all; as a general rule of thum, the sa user should not be used by anyone within Microsoft Dynamics GP. The sa user is the SQL System Administrator user whereas Dynamics GP has it’s own System Administrator user; dynsa.

So, what is the difference between these two system admins? Well, to start with, sa is the SQL Server database administator and, as such, has access too all databases, including non-Dynamics databases, on the SQL Server instance. Instead dynsa should be used as it is the GP database administrator and only has access to the GP databases.

While sa is needed for initial system instllation and configuration, and for some third party add-on administration, it should not be used for day-to-day administration of Dynamics GP. As dynsa is a database owner it can be used for most security and maintenance tasks within GP and, like sa, is granted the Poweruser role automatically.

I have to admit, this is more “do as I say, than as I do” because we have been slightly lax in getting this message out to clients. This is something I fully intend to put right this year as I travel around client sites doing upgrades to Microsoft Dynamics GP 2010; in some cases this may lead to entertaining discussions with various Heads of Finance or Directors of Finance or Resources. However, I think in all cases the clinching argument is that using dynsa instead of sa minimises the possibility of tampering with non-GP databases should the password be accidentally leaked.