If you attended the Microsoft Dynamics GP Technical Conference 2009 in Fargo, North Dakota or Microsoft Dynamics Convergence Atlanta 2010, in Atlanta, Georgia you might have seen a demonstration by Mariano and myself of the Support Debugging Tool for Microsoft Dynamics GP.
One part of the demo was how to solve security privileges errors using the tool. It is a perfect example of how the tool can make administration for a Microsoft Dynamics GP system so much simpler and this is why many partners are now installing the tool on all workstations of all their customer sites.
This post is an update to the How to resolve Security privileges errors post which is part of the Microsoft Dynamics GP Application Level Security Series of posts, and is designed to highlight some of the features added since the original post was written.
The following is a real life scenario showing how the Support Debugging Tool for Microsoft Dynamics GP with the Security Profiler and Security Information features can quickly resolve Security Privileges errors on a live system.
In our scenario, the user is receiving a security error, but the window they were trying to open still opens, however, the window that opened does not include some fields added as a customisation. We are assuming that the Support Debugging Tool is already deployed to all workstations on the system.
On the End User’s Workstation
When the user receives a Security Privileges error (see screenshot below) they can use the Security Profiler to capture the details of the error.
You don’t have security privileges to open this window. Contact your system administrator for assistance.
Use the Tools menu or Ctrl-D keyboard shortcut to open the main window and select Options >> Security Profiler. One the Security Profiler window is open; perform the steps to recreate the security error so that the details can be captured. It is also possible to configure the Security Profiler to open automatically when it receives an error or warning about security settings.
Clicking Export allows the Security Profiler Log to be sent to the System Administrator. The Security Profiler log file can be saved to a shared location on a file server or emailed directly from Dynamics GP.
On the System Administrator’s Workstation
The System Administrator can open the Security Profiler window on their system and import the Security Profiler log sent to them by the user (saved as file or emailed). Now because the System Administrator has privileges to access the security settings, the security button will be active.
Using the right click context menu or selecting the resource and clicking Security, opens the Security Information window for the selected resource and user/company combination.
The left hand pane of the Security Information window screenshot tells us the following information:
- LESSONUSER1 for company Fabrikam does not have access to the window.
- If they did have access the DEFAULT USER Alternate Modified ID would access the original resource.
- To give them access they need to be POWERUSER or have access to the AAA_CUSTOMER_EXTRA Security Task which belongs to the selected AAA CUSTOMER EXTRA Security Role.
The right hand pane of the Security Information window screenshot tells us the following information:
- DYNSA and sa users have access for Fabrikam company when other users do not have access.
Double clicking on the User/Company node (highlighted) on the left hand pane will open the User Security window to allow the necessary changes to be made.
Single clicking on node on the right hand pane will change the user and company selection for the left hand pane so you can see how other users do or don’t have access and why. Expanding the nodes will show which Security Roles and Tasks a user has access too.
Changing the right hand pane view allows many views into the security data to see what the relationships between Users and Security Roles and Security Tasks are. For example: Seeing which users have access to particular Security Tasks and then which Security Roles those tasks belong to.
Within a few clicks the System Administrator can change the Alternate Modified ID to provide access to the correct original window and change also add the correct Security Role for the user. They did not even have to leave their desk to see the error or examine DEXSQL.LOG files to identify the windows causing the problems.
For more information on the Support Debugging Tool, please look at the portal page below: