Month: January 2018

Over the last couple of weeks we have been on a bit of an upgrade splurge with clients; a number of them are doing test upgrades to Microsoft Dynamics GP 2018 from a variety of versions. One client is upgrading from Microsoft Dynamics GP 2016 RTM to 2018 RTM; according to the Upgrading Microsoft Dynamics GP hot topic, Microsoft Dynamics GP 2016 can be upgraded from version 16.00.0439 or later; however, when Analytical Accounting is installed, this is not correct.

To upgrade the client, we upgraded them to the last hotfix for Microsoft Dynamics GP 2016 (KB4056559 which is version 16.00.0641) and then to 2018; however, GP Utilities for 2018 errored saying that it could not upgrade Analytical Accounting from that version. Fortunately, we did not have to go back to a backup and redo the upgrade, as, while AA in installed, this particular client does not use the module.

I used the scripts to remove the tables and other database objects and was then able to run the 2018 GP Utilities to do the database upgrade without further issue.

I have previously upgraded a test system from 2016 to 2018 without issue; this was from KB3194397 (version 16.00.0558). We do have a small number of other clients with AA installed, so we now know what version of GP 2016 to upgrade them from to avoid this issue.

Back in February 2017, I posted about a Microsoft Knowledge Base article on removing Analytical Accounting (AA) from Microsoft Dynamics GP. At the time, the KB article was unavailable, but the download links still worked (if you knew what they are).

I was contacted by someone recently asking if I had a copy of the scripts as the download links no longer work (the KB article itself is available).

This was unusual timing as I had just been onsite with a client where we encountered issues upgrading their system from 2016 RTM to 2018 RTM. In that case, the solution was to remove AA from the system as they had the module used, but never implemented it.

To remove AA, I dipped into my script library for the AA removal scripts from KB915903. After being alerted at the scripts were no longer available, I thought it might be useful to others to post them here.

The scripts are available from the following links:

1. KB915903_AA_Remove_AACompete_DYNAMICS_10 – this script needs to be run against the system database (typically called DYNAMICS).
2. KB915903_10 – this script should be run against all of the company databases.
3. KB915903_DYNAMICS_Remove_DB_Upgrade_10 – this script is run against the system database.

Belinda Allen has recently done a blog post with download links for all of the What’s New documents from Great Plains 6 through to Microsoft Dynamics GP 2018.

It’s fair easier to find the What’s New document you want from Belinda’s page than it is searching through Partner/Customer Source.

In recent times we have taken over a few clients from other partners and one common theme we are running into is poor security practices. For a lot of these new clients, we find that a lot of people know the sa password, the vast majority know the System Password and all users have the POWERUSER* role assigned.

All of these are bad:

1. sa is the SQL Server system administrator account and should only be used for the initial implementation of Dynamics GP, when Dynamics GP is moved between servers, or when configuring some ISV products.

   When Dynamics GP is implemented, an account called DYNSA is created; this is the Dynamics System Administrator account which is intended for use by the people/team administering Microsoft Dynamics GP.

   However, most of the admin is actually creating or maintaining users and this can be done with any user account, once it has been configured with the relevant permissions.

2. The System Password should only be known to those people who have a need to know it. It protects access to some windows in the system which can cause problems if used incorrectly.
3. POWERUSER* is a role which gives access to all windows in Microsoft Dynamics GP; combined with users knowing the System Password can be a recipe for disaster. New security roles should be created and assigned to users which give them access to the windows they need.

Even when users have security roles rather than POWERUSER*, I still recommend clients review the access rights to ensure that people have access they need; this is true for all users. I recommend everyone review their security every year or two to ensure that the changing needs of the business are being met.

We do a fair bit of work for clients assisting them in reviewing the security, but not everyone has a partner they can work with on this type of project. And not everyone has the budget for a full-scale security review with their partner.

One other option, to involving your partner, is to pick up a copy of the Microsoft Dynamics GP Security and Audit Field Manual: Dynamics GP 2016 book by MVP Mark Polino and Andy Snook. This book is for the 2016 version of Dynamics GP, but still fully applies to Microsoft Dynamics GP 2018 (as well as earlier versions).