Today's #TipTuesday post is about GP Utilities and what permissions are required. For those going through any service pack install or upgrade, there might be a lot of workstations that need to be updated! In our case, we just upgraded the Dynamics GP environment and wanted all hands on deck to help with installs, including some IT team members who didn't have any GP access. Here's how to do it and what permissions are required.
A typical workstation installation
For a general workstation installation of Dynamics GP, install the client application(s) including any ISV applications and then run GP Utilities once to synchronize the Account Framework. After that, I'll typically launch Dynamics GP once and let the "SQL Get" messages run, but once that's done there is no need to log into a company. This means the user installing needs some permission to do this but doesn't need any permission inside Dynamics GP. Typically most users would log in with 'sa' or DYNSA, but that's not required if there is a desire to lock access to those passwords down a bit.
User Setup & User Access in Dynamics GP
First thing, set up the installer user(s) as normal in GP, whether that is a generically named user or a specifically named user. In my example on my local laptop, I am creating a user called "GPinstaller" but it could easily be a named user "Steve", "Bob" etc. per the normal GP naming conventions the organization uses.
Next, do nothing else in GP! Seriously, the user using GP utilities doesn't need access to any companies as they are not logging into GP except to let those "SQL get" messages run. Access to companies here and security within those companies has no bearing on using GP Utilities.
Default SQL access
By default, without doing anything else other than creating a user as per the above screenshot, this user will be granted access to the DYNAMICS (or named system database if not using DYNAMICS) and specifically the database role of DYNGRP. No server role is needed nor granted by default.
THAT permission is sufficient to synchronize the account framework, based on my limited testing. Within GP Utilities, that user would be able to log in, and perform that default task, and have very little other permission. The only thing visible is Upgrade Forms and Reports Dictionaries, with this base permission. That makes sense as every other task in GP Utilities would require some SQL permission to create or modify objects in company databases.
That's it. There are cases where users who install workstation software really shouldn't also have access to get into GP with that same login. Sharing the default or typical 'sa' or DYNSA logins also isn't wise because of what their permissions allow. Most "best practices" want to grant the least permissions possible for a given task and in this specific case, this works.
