Microsoft Dynamics GP - More than just Program Files!

In recent days, I have been resting from a long standing project in beautiful Las Vegas, Nevada. Months of traveling every two weeks back and forth have certainly paid off with my customer going live with their newly reimplemented systems. As a Delta regular, working at 35,000 feet during commute time has become more than just a laptop maneuvering exercise and has driven me to explore other obscure features of my beloved Microsoft Dynamics GP, all on my way to the client.

One such thing I decided to explore is, how much of a footprint does a Microsoft Dynamics GP (versions 10 and 2010) installation really have? This curiousity took a different dimension after reading a recent article by fellow blogger Jen Kuntz on Uninstalling Microsoft Dynamics GP 2010 the hardway. In this article, Jen outlines a number of locations, both logical and physical, where she had to search for references to Microsoft Dynamics GP 2010 in order to be able to reinstall the application. She based some of her findings on a previous article I had also written, How to manually uninstall Microsoft Dynamics GP 10.0, but quickly learned that the task at hand won't be that simple.

So, let's get the obvious out of the way: we already know about the %ProgramFiles%\Microsoft Dynamics\GP folder and a the obvious HKLM\SOFTWARE application registry entry, but what about the *rest*? What rest you may ask... It turns out, Microsoft Dynamics GP has its fair share of "things it keeps track of", so here they go:

Folders

1. %ProgramFiles%\Common Files\Microsoft Dynamics GP\{Component GUID}\ - At first glance, this folder stores a copy of all chunk files pertaining to the installation, for both installed and uninstalled features. The existence of this folder would suggest that Microsoft Dynamics GP, and concretely Dynamics GP Utilities uses these chunk files to rebuild the existing dictionaries at their latest service pack.

2. %ProgramFiles%\Common Files\microsoft shared\Dexterity\ - Stores the Dexterity Shared Components, which also include the GPConn.dll COM component and GPConnNet.dll .NET assembly. The latter two DLLs allow external applications to connect to Microsoft Dynamics GP using the credentials of the user currently signed on to the system.

3. %Windir%\Assembly\ - This folder is also known as the Global Assembly Cache (GAC) and there are a number of eConnect and eConnect Serialization assembly references. The GPConnNet.dll assembly also has a reference in the GAC.

4. %Temp%\ - This folder corresponds to the user temporary folder. The temp folder now stores the XML layout of the homepage and all navigation bars. These XML files are created on demand, each time an option is selected. In addition, the temp directory stores any local C-tree file for temp tables used in report processing. See An open operation on table '[TEMP Table]' errors over at Developing for Dynamics GP for more information on C-tree temp tables

5. %AppData%\Microsoft Business Solutions\Microsoft Dynamics GP\ - This folder stores the application's autocomplete information - See AutoComplete Data for GP – it’s not really a Mystery by MVP Leslie Vail.

6. %Windir%\Installer\{Component GUID}\ - This folder stores the installer information used by Microsoft Dynamics GP to change or remove the installation.

Registry Entries

These are only a few locations outside of the actual %ProgramFiles%\Microsoft Dynamics\GP folder where related information can be found. But what about the Windows Registry?

1. HKEY_CLASSES_ROOT\Installer\Products\{Component GUID} 

2. HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\{Component GUID}

3. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Business Solutions\Great Plains\

4. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Folders\

5. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\{Component GUID}

Note: There are a number of other Components that reference the Microsoft Dynamics GP component GUID. These don't necessarily need to be removed from the Registry, but I won't be surprised if a decent Registry cleaning application picks up on them.

6. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{Component GUID}

7. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{Component GUID}_Ex

8. HKEY_USERS\S-1-5-21-3533039690-2615561654-1627596621-1001\Software\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths

Note: The component GUID was located in the url1 and url2 attributes of this key.

If you ever need to uninstall Microsoft Dynamics GP 2010 or 10.0 manually, having the above list of entries may just save your life. If you know of any other obscure folders or Registry entries, please feel free to post a comment to this article and tell me how you came across your finding.

Disclaimer: Modifying the Windows Registry can cause serious damage to your computer or render it unusable, if not done properly. Please consult with a professional before making any changes to your environment.

The above entries may vary due to operating systems configuration or platform. Please take this into account before attempting any changes to your environment.

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/

Read More

Add-In Initialization Error when launching Microsoft Dynamics GP 2010

Lately, many users have reported getting the error depicted below after launching Microsoft Dynamics GP 10 with Service Pack 5 or Microsoft Dynamics GP 2010 with Service Pack 1:




Add-In Initialization Error

The error references the Microsoft.Dynamics.GP.OnlineServices.dll assembly file as the root cause of the problem. This assembly was shipped with Microsoft Dynamics GP 10 SP5 and is a part of the Dynamics Online Services application.

The error typically indicates that the add-in assembly is loaded, however, it most likely indicates that the Dexterity portion of the application, dictionary DO6499.dic, isn't loaded in the path found in the DYNAMICS.SET file -- which should have also generated a dictionary load error prior to receiving the above message -- or isn't loaded at all.

To fix this error:

1. Run a repair or update on the Microsoft Dynamics GP client under the Windows Control Panel. This will reinstall the Dynamics Online Services application dictionary and the assembly.

NOTE: You will not see this application in a list of selections as it appears to be a "default" application and it will reinstall itself.


However if you not interested in repairing the application and rather completely get rid of the Dynamics Online Services feature, then follow these steps:

1. Under the Microsoft Dynamics\GP folder, locate and delete the DO6499.dic dictionary file.

2. Remove all references of this product from the application launch file, DYNAMICS.SET.

6499
Dynamics Online Services
:C:Program Files/Microsoft Dynamics/GP/DO6499.DIC
:C:Program Files/Microsoft Dynamics/GP/Data/DO6499F.DIC
:C:Program Files/Microsoft Dynamics/GP/Data/DO6499R.DIC

NOTE: Don't forget to decrease the number of products by 1 in the DYNAMICS.SET file. Usually, this is the first entry in the launch file.

3. Locate the AddIns folder and delete the Microsoft.Dynamics.GP.OnlineServices.dll assembly file
4. Also remove the Application.DynamicsOnlineServices.dll from the GP installation folder

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/

Read More

Happy Thanksgiving!

It's this time of the year again... I am personally thankful for your readership and all the feedback I have received from you throughout the year from a good number of you following this blog. Now, go eat some turkey!

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/

Read More

Disabling Multiple Ledgers functionality in Microsoft Dynamics GP 2010...after the fact

Let's face it! Like many things in life, configuration decisions are revisited even after going live (rightfully so!) with your system. What was viewed and considered a requirement a few months aback and worked during User Acceptance Testing turns out to be something the business no longer needs today, due to changes in direction, or changes in business conditions.

Just recently, I came across a request for disabling the new reporting ledgers functionality in Microsoft Dynamics GP 2010. While this implementation was not live, this issue was clearly affecting the consulting teams ability to move forward.

The following script should disable the reporting ledgers function:

-- Created by Mariano Gomez, MVP
-- This code is licensed under the Creative Commons 
-- Attribution-NonCommercial-ShareAlike 2.5 Generic license.

UPDATE GL40000 SET Allow_Reporting_Ledgers = 0, UseLedgersForAcctBalance = 0;
DELETE FROM GL40001;

Once the script is executed, go back to the General Ledger Setup window. You will notice that a BASE ledger is created by default, but also notice that the Allow flag is unchecked.



General Ledger Setup

Click the Ok button to continue.

Now, if you open the GL Transaction Entry screen, you will notice that the Ledger ID field is no longer present.

Transaction Entry

Hope you found this post useful.

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/

Read More

Granting Microsoft Dynamics GP user minimal access at the database level to setup additional users

After the long title of this post, you probably already have the idea of what the article will be about. However, back in April of 2009, I wrote about the POWERUSER role and the Microsoft SQL Server sysadmin server role - see Microsoft Dynamics GP 10 POWERUSER role vs Microsoft SQL Server sysadmin role - and explained the key differences between the two. Among other things, I discussed how a GP user login that's assigned to the sysadmin server role on Microsoft SQL Server becomes able to setup new users in GP.

However, those of you who are database administrators have been quite reluctant to add logins to the sysadmin group, and quite understandably so. After all, logins added to the sysadmin server role can do anything on the database server, and we sure don't want that to happen either.

In response to this, and to the many requests lately on the forums, my friend Robert Cavill, with Emeco Group in Australia, has submitted the following script, which gives a specific user ID in Microsoft Dynamics GP, minimal but sufficient permissions at the Microsoft SQL Server level to create new users. In addition, this script allows Robert's first level support staff with access to Microsoft Dynamics GP, the ability to reset passwords for their user base.

GrantUserRights.sql

--Created by Robert Cavill
--This code is licensed under the Creative Commons 
-- Attribution-NonCommercial-ShareAlike 2.5 Generic license.

DECLARE @sUSERID NVARCHAR(15)
SET @sUSERID = 'LESSONUSER1'

SET NOCOUNT ON;
SELECT 'EXEC master..sp_addsrvrolemember @loginame = ''' + @sUSERID + ''', @rolename = N''securityadmin'';'

SELECT
'USE [DYNAMICS];
GO
IF NOT EXISTS (SELECT * FROM sys.database_principals WHERE name = ' + QUOTENAME(@sUSERID, CHAR(39)) + ') 
  CREATE USER '+ QUOTENAME(@sUSERID) + ' FOR LOGIN ' + QUOTENAME( @sUSERID ) + '; 
EXEC sp_addrolemember N''db_accessadmin'', ' + QUOTENAME(@sUSERID, CHAR(39)) + ';
EXEC sp_addrolemember N''db_securityadmin'',' + QUOTENAME(@sUSERID, CHAR(39)) + ';
EXEC sp_addrolemember N''DYNGRP'', ' + QUOTENAME(@sUSERID, CHAR(39)) + ';
GO'

SELECT 
'USE [' + RTRIM(INTERID ) + '];
IF NOT EXISTS (SELECT * FROM sys.database_principals WHERE name = ' + QUOTENAME(@sUSERID, CHAR(39)) + ') 
  CREATE USER '+ QUOTENAME(@sUSERID) + ' FOR LOGIN ' + QUOTENAME( @sUSERID ) + '; 
EXEC sp_addrolemember N''db_accessadmin'', ' + QUOTENAME(@sUSERID, CHAR(39)) + ';
EXEC sp_addrolemember N''db_securityadmin'',' + QUOTENAME(@sUSERID, CHAR(39)) + ';
EXEC sp_addrolemember N''DYNGRP'', ' + QUOTENAME(@sUSERID, CHAR(39)) + ';
GO'
FROM DYNAMICS..SY01500

When this script is executed against the DYNAMICS database for a specified Microsoft Dynamics GP user (@sUSERID variable), the result is another script granting the correct access to all the Microsoft Dynamics GP company databases.

Result

EXEC master..sp_addsrvrolemember @loginame = 'LESSONUSER1', @rolename = N'securityadmin';

USE [DYNAMICS];
GO
IF NOT EXISTS (SELECT * FROM sys.database_principals WHERE name = 'LESSONUSER1') 
  CREATE USER [LESSONUSER1] FOR LOGIN [LESSONUSER1]; 
EXEC sp_addrolemember N'db_accessadmin', 'LESSONUSER1';
EXEC sp_addrolemember N'db_securityadmin

USE [TWO];
IF NOT EXISTS (SELECT * FROM sys.database_principals WHERE name = 'LESSONUSER1') 
  CREATE USER [LESSONUSER1] FOR LOGIN [LESSONUSER1]; 
EXEC sp_addrolemember N'db_accessadmin', 'LESSONUSER1';
EXEC sp_addrolemember N'db_securityadmin','LESSON

Upon running the result script, the new database permissions will enable the Save button on the User Maintenance window, and allow users to be assigned to companies in the User Access window.

Here are a few additional tips:

1. With this approach, the Microsoft Dynamics GP user is not a member of the sysadmin fixed server role.
2. The user ID must already exist in Microsoft Dynamics GP with access to at least one company so they can log on.
3. If, after executing this script, you attempt to delete the user ID from GP, it will fail.

In the following post, I will publish the script that will reverse the outcome to allow deletion of the user ID from Microsoft Dynamics GP.

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/

Read More

And speaking about Conferences...

It turns out, this is the time of the year when I start looking forward to next years events I would like to attend... as a speaker! It's my honor and priviledge to introduce two of the events I will be speaking at:

Microsoft Dynamics GP Technical Conference 2011 will be held in Fargo, North Dakota, USA on the 1st - 3rd March 2011.

Microsoft Dynamics Convergence 2011 Atlanta will be held in Atlanta, Georgia, USA on the 10th - 13th April 2011.

You will also be pleased to know that I will be presenting with my dear friend, Microsoft's David Musgrave, who has been cleared for both presentations. So, please, please, please help us with session ideas for the conference by emailing your suggestions.

Also, please feel free to post comments on this article AND also submit your thoughts to the Convergence NA 2011 Call for Topics site before it closes on the 20-Nov-2010. Kevin Machayya from the Microsoft Dynamics Partner Community Blog explains more in his post: Help Identify the Hot Topics for Convergence 2011.

If you are excited about Microsoft Dynamics GP development or would like to learn more about the Support Debugging Tool, or if you have ideas for new topics you would like us to cover, please don't hesitate to contact us.

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/

Read More

Dex - Why do memory tables seem to be slower in Dexterity 11.0?

As more of you begin to migrate your Dexterity 8.0 and Dexterity 9.0 customizations to be compatible with Microsoft Dynamics GP versions 10.0 and 2010, you may have noticed some performance decrease in your applications if using memory tables.

The reason for this decrease in performance? There was a change to how memory tables were implemented since Dexterity 10.0.

Originally, memory tables used the Ctree data structure but were created in memory. However, they needed large contigious blocks of memory and as more developers used them and data stored in them grew, Runtime Engine crashes were more noticeable when memory tables failed due to running out of usuable memory.

See KB article 898993 - You receive an "Open operation on table mytable has used a bad file name" error message when you try to access a memory table in a program that you create by using Great Plains Dexterity.

The change was to implement memory tables as local Ctree tables in the user's temp folder. Each session/instance of the Runtime Engine will create a temporary (TNT****) folder and in that folder you will see the *.dat and *.idx files for the respective memory tables.

This means that performance of memory tables will have dropped as the file system and hard drives are now involved. But application stability has been restored.

Thanks to Microsoft's David Musgrave for the detailed explanation.

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/

Read More