Last week our HR department people had training about the HR module in GP… it was a very formal training of two hours from an external consultant, and as such it wasn’t going very deeply into the subject. But enough to say that he showed our users about some of the hidden gems in the HR module that they weren’t even aware of: the Letter Writing assistant function.
Since I had given them access to the Fabrikam Company in GP for evident privacy purposes, I had also created some training users for the sake of this exercise, not wanting them use their regular GP users.
Having assigned those users regular GP Security role for the HR module (this would likely be HR_MANAGER & HR_GENERALIST), they were supposed to get covered for almost everything… Think so? Not really… In their attempt to create default Security Roles in GP to cover most of the functionality in GP, Microsoft sometimes didn’t checked if all the roles where properly assigned to corresponding tasks, and that those security tasks were also related to actual existing resources in the system…
We all know that by default GP has numerous Security Roles (> 50), Security Tasks (> 450) and Resources (> 9000), resulting in thousands of security combinations in the system, that it is very difficult to test all combination and make sure nothing was missed.
Now what to do when you hit the infamous error message in GP about denied access to resources?
Call your system Administrator of course :-)… but what if you are the system admin? The answer will be to use the Support Debugging Tool (SDT in short). This tool is free for every Dynamics GP customer and you’ll find more details about it on the web (http://aka.ms/sdt). If you don’t have it installed now, you’ll have to contact your Microsoft partner and ask for the latest release for your GP version.
The tool was written and developed by my good friend David Musgrave that works for Microsoft Australia. I’m not going to enter into the history behind the SDT; there is plenty of links on the site.
Where to Start with the SDT?
Once you have the SDT installed into your Dynamics GP client, you’ll get and additional menu entry under your main GP menu >> Tools >> Support Debugging Tools (CTRL-D). From the SDT main menu you can access the user manual by hitting F1 and open the PDF document (assuming the installation was done properly and the PDF was copied into the program folder).
I encourage you to read thru the guide, it is very well written and explains all the aspects of the tool. Don’t be afraid by the length of the document (about 200 pages), the most important information is covered in Chap 2 & 3 in about 40-50 pages. We’re going to focus today on the Security Profiler (Chap. 2, pp 52-59), and see how this tool can help you to identify in about 5 min. what is causing your denial of access in GP.
Warning: the content and usage of the SDT can be dangerous if used inappropriately in Dynamics GP. I always suggest to test this out in a TEST environment or TEST company before your actually apply this to a production system. Over the course of the time, when you become more confident with the tool, you’re going to love it and install it across all your GP clients. This will make your administrator life much easier. Also, most sensitive functions of the SDT are protected by the system password, and assuming that you have set one, it will ask you every time for it before letting you access a critical function.
10 simple steps
That said, let’s start with the Security Profiler and see how we can identify in 10 steps the security issue.
- Start the Security profiler from the SDT ‘Debugger’ menu: Debugger >> Security Profiler
This will open a new form that you can minimize to the bottom of your screen. I suggest creating a shortcut to the security profiler; it’s a tool you’re going to use often.
- Go to the resource that you want to access with the user that is denied of it. In our example we want to access the Applicant form in HR and want to launch the “Write Letters” assistant, in order to use the ‘Prepare an Applicant Letter’ wizard. Click on the menu until you hit the security error message.
- Restore the Security Profiler window and locate the last line…
- Use the Export menu option to save the result of the tracing to an XML file (best place is the shared Data folder on the server, thus you can open that XML file from another GP client with a Power User.
- Either login in the same session with a different user that has access to GP Security and preferably a system admin, or use another client from a different system and has access to the saved XML file.
- Import the XML file previously saved into the Security Profiler and select the line that has the red denial sign in front of the line. With higher privileges, you now get another option to check the security settings.
- When you click on the Security button, the SDT will open a window and show you a tree-like view of the resource that was denied.
- Expand the left side tree labeled “Access Granted” and drill down to the lowest level to get a list of the Security Tasks and Roles assigned to the required resource.
- On the right side you see a list of the users with a small box checked (which means access is granted to all companies, grey would mean only partial company access and blank no access at all).
- Double click on the user name to open the User Security Setup form of GP. Scroll down until you get to the Security Role that was displayed in the Security Information pane on the left side and check the box on that line. Save the changes for that user and ask him/her to log back into GP and try to access the denied resource.
Et Voilà! You just solved your first security mystery in Dynamics GP.
This is only one facet of the multiple functions that the Support Debugging tool can offer. Go thru the user guide and familiarize yourself with the other functions.
Good luck with your daily Dynamics GP administration.