An error occurred while installing system components for Microsoft Dynamics GP 2010 Bootstrapper.

I recently was passing through a local area, and popped in on a client.  They had just received a new workstation and wanted Dynamics GP 2010, Integration Manager and FRx installed on the machine.  

On a good day this should take a few minutes.  Our group stores installation code in a standardized shared folder on the network.  We have standard agreements with IT resources to ensure we have administrative access to domain and machine resources, etc.  In this case, a simple installation proved not to be the case.

Immediately after browsing to the install folder and clicking on setup, I received the typical prerequisite installation dialogue. Dexterity Share components, .Net, etc. So, I clicked ok...

In a couple of seconds, I received the following message:

"An error occurred while installing system components for Microsoft Dynamics 
GP 2010 Bootstrapper.  Setup cannot continue until all system components have been successfully installed."

A quick search of the Interwebz indicated this was a problem with .Net compatibility, which made sense... The machine was brand new, and client IT had installed every patch available for Windows 7 - including several recent patches for .Net. 

Based on my experience I moved to Programs and Features and picked the latest .Net patch, figuring I would peel .Net like an onion until I could install the prerequisites.  When I chose to uninstall the most recent .Net patch, I received an error that I did not have permissions to uninstall the patch.  Intriguing...

So I called client IT and requested they grant our Active Directory account access to this new machine.  A few minutes later Dynamics GP 2010 installed without incident.  The lesson here is security settings can mascaraed as documented installation problems related to product incompatibilities.

Remember your troubleshooting 101.

SmartList Security Setup

If you have some users who can access SmartLists and others who cannot, it is entirely possible the users who can are POWERUSER in GP and the users who cannot are not members of this group.

The POWERSUER user group provides access to any and all features in GP -- technically it is the absence of security controls.  This is a really important distinction if your organization wrestles with SOX Compliance.  In small organizations, it is typical for 2-4 people to have universal access to GP (Ownership, Operations Manager, CFO and Bookkeeper).  In larger organizations there are typically more defined roles for more numerous users, some who act as clerks, others who act as managers and still others who focus primarily on financials -- this is absolutely critical when SOX Compliance is necessary.

There are no default Security Tasks or Roles in Dynamics GP for SmartList Objects.  In order to provide the appropriate security for SmartList Objects to users, these Tasks and Roles must be created and assigned to users.

SmartList Object Security Tasks:   Navigate to Microsoft Dynamics GP > Tools > Setup > System > Security Tasks - Create a New Task ID = _SMARTLIST OBJECTS, Task Name = SmartList Object Permissions, Category = System, Product = SmartList, Type = SmartList Object, Series = SmartList Objects - Click the Mark All button; this will provide access to ALL SmartList Objects that currently exist!  When SmartList Builder is used to create new SmartList Objects, permissions will need to be granted for them, after their creation.  Click the Save button to save this new Security Task.

SmartList System Security Tasks:   Navigate to Microsoft Dynamics GP > Tools > Setup > System > Security Tasks - Create a New Task ID = _SMARTLIST SYSTEM, Task Name = SmartList System Permissions, Category = System, Product = SmartList Builder, Type = SmartList Builder Permissions, Series = SmartList Builder- Click the Mark All button; this will provide access to ALL SmartList Builder Features  Click the Save button to save this new Security Task.

          SmartList Security Role:   Navigate to Microsoft Dynamics GP > Tools > Setup > System > Security Roles - Create a New Role ID = _SMARTLIST ALL ACCESS, Role Name = SmartList Permissions-All Access, Display = System - Check the boxes next to _SMARTLIST OBJECTS and _SMARTLIST SYSTEM; this will provide access to ALL SmartList Builder Features  Click the Save button to save this new Security Role.

  

Assign the Security Role to a User:  Navigate to Microsoft Dynamics GP > Tools > Setup > System > User Security.  Look Up the User, or Type in the User ID.  Select a company - you will only see companies the user has access rights to.  Check the _SMARTLIST ALL ACCESS Security Role - to add the user to the Security Role.  Click the Save button to commit the change.  Users who are logged into GP will need to log out and back in again for changes to propagate.

This security schema will permit access to all SmartList Objects and Features.  If you would like to prevent access to various SmartList Objects, you can create more granular security groups to grant access to only SmartList Objects related to their assigned roles (department).

Dynamics GP Security, Click on Menu Item and Nothing Happens

This blog post summarizes one of the most difficult issues I have wrestled with in my consulting career - it also stumped the experts at Microsoft Tech Support and all of the gurus at my disposal - well almost all.

Symptoms: A user is granted access to a Dynamics GP Window through a Role. The user can see the link to the window in navigation.  When the user clicks on the link in navigation nothing happens.  The window does not open, there is no error produced.  Intermittently the link will disappear from navigation, after it is clicked.

Security in current Dynamics GP releases is structured as follows:

At the bottom tier are the specific window, report, file and posting permissions, which used to be how GP security was administered - it is quite frankly very detailed, very flexible and therefore very cumbersome.

These low level permissions are now collectively assigned to Microsoft created Tasks (task based security groups).  These tasks use a naming convention, and while the naming convention isn't easily decipherable, the Task Names are very instructive (i.e. Set up credit cards, Set up taxes, Set up bank accounts, etc.)

Microsoft has created logical Roles making it much easier to grant and deny access to areas of the software based on the functions a user should perform as part of their job.  Tasks are assigned to these Roles.  The Roles are much more intuitive, having names like AR Clerk, AP Clerk, Accounting Manager, etc.   

First - you have to check thoroughly to ensure the user is actually granted access to the window through a Task assigned to one of the Roles assigned to their User.  Once you have validated the user has access to the window, and you still encounter the behavior described above, try the following:

Create another user and copy permissions from the original user to the new user in the User Security Setup window.  If you have this problem, this step won't help, but it will confirm you have this issue.

So now we're down to "brass-tacks."  You have a user who cannot access a window they have been granted access to, even though they can see the link for the window in navigation.  There is no explanation/error for this problem.

I ran Check Links, disabled customization, granted SQL Administrator access to the affected users - nothing seemed to work.  All these activities did make it clear to me we were dealing with a problem with roots firmly planted in Dynamics GP Security set up.

So, I reached out to several people I consider gurus, and one of them, Brenner Klenzman, said he'd seen something like this before. I was thrilled!  He even had a solution to the problem.  Brenner suggested un-clicking the roles assigned to the user and re-clicking them (not sure those are real words).  So I did just that and tested access again - no improvement!  This fix, while it had worked for Brenner on a previous occasion, did not resolve the problem.

I engaged Microsoft Technical support, and went through several days of creating and submitting log files.  Installed and used the support debugging tool. Still No Luck!  Microsoft Tech Support called "no joy" and credited back my technical support incident.  

Now I was a heart-beat away from emailing the client some exceedingly bad news.  We were going to have to destroy security and recreate it, in a live environment...  I was dusting off a KB article on how to do just that, and putting together a plan of action to implement it.  

When inspiration struck.  Don't ask me why, but I decided to implement Brenner's fix at a lower level.  I opened up the Tasks assigned to the Roles and un-clicked then re-clicked them.  Hallelujah - success!