Don’t use Administrative Shares in your Dynamics GP Launch File

David Meego - Click for blog homepageI am writing this article after a good friend, who is a Microsoft Dynamics GP administrator, was having some unexplained issues in his test environment.

The issue was originally identified because GP Power ToolsProduct Version Validation feature started reporting a dictionary version mismatch for a couple of Dexterity customization dictionaries. What made it really weird was that it only happened for the test windows’ user and and not for his administrator user account.

This would immediately make you think that it was a windows or SQL permissions issue. However, upon checking all the folder access and SQL permissions it was not possible to identify any differences or access problems.

Once the version mismatch warning from GP Power Tools was dismissed, everything appeared to work correctly in Dynamics GP. Viewing the System Status report from the Capture Screenshots window reported the same dictionary version numbers as the Product Version Validation was seeing. Incorrect for test user, correct for administrator.

Then it was identified that the Additional menus added by triggers in the customization dictionaries were not showing up when logged in as the test user. This sounded related as it was the same dictionaries reporting the version errors that were not registering their triggers, but only for the test user and not for the administrator.

It took a while and was probably staring us in the face all the time, but eventually we noticed that the paths for the two customizations product dictionaries in the Dynamics.set launch file did not match the rest of the paths.

It is very common to have the application dictionaries stored locally and have the custom forms and reports dictionaries located in a shared folder on a server. This looks like the example below:

:C:Program Files (x86)/Microsoft Dynamics/GP/DYNAMICS.DIC
//Server/DynShare/Dictionaries/FORMS.DIC
//Server/DynShare/Dictionaries/REPORTS.DIC

What was noticed was the two dictionaries that were causing the issues had paths that were defined using Administrative Shares (a.k.a. root or hidden shares), see below:

:C:Program Files (x86)/Microsoft Dynamics/GP/PRODXYZ.DIC
//Server/c$/DynShare/Dictionaries/FXYZ.DIC
//Server/c$/DynShare/Dictionaries/RXYZ.DIC

The thing to note about Administrative shares is that they are only available to an Administrator regardless of the permissions at the final folder. Once launch file was corrected and the “C$/” were removed from the paths, the version errors stopped and the missing menus returned for all users.

Interestingly, the FXYZ.DIC and RXYZ.DIC files did not exist as the Modifier and Report Writer had not been used with the PRODXYZ.DIC application dictionary.

The takeaways from this issue were:

  1. Do not to use Administrative Shares.
  2. Also make sure that the folders pointed to in the launch file actually exist and all users of Dynamics GP have access.

It seems that not being able to confirm the existence of a custom forms or report dictionary can cause the application dictionary to misbehave even if access to the application dictionary is available.

Hope you found this interesting.

David

This article was originally posted on http://www.winthropdc.com/blog.

Please post feedback or comments

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.