GP Utilities user permissions

Today’s #TipTuesday post is around GP Utilities and what permissions are required. If you are going through any service pack install or upgrade, you might have a lot of workstations that need to be updated! In our case, we just upgraded our Dynamics GP 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 you do it and what permissions are required.

A typical workstation installation

For a general workstation installation of Dynamics GP, you’re installing the client application(s) including any ISV applications and then you need to run GP Utilities once to synchronize the Account Framework. After that, typically you’ll launch Dynamics GP once and let the “SQL Get” messages run, but once that’s done there is no need to actually log into a company. This means the user installing needs some permission to do this but doesn’t actually need any permission inside of Dynamics GP. Typically most users would log in with ‘sa’ or DYNSA, but that’s not required if you want to lock access to those passwords down a bit.

User Setup & User Access in Dynamics GP

First thing, set up your user(s) as normal in GP, whether you want generically named or specifically named for your situation. 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 your normal GP naming conventions.

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. In fact, 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.