SDT – Support Debugging Tool

The All-New-GPPT finally released… in BETA.

It was worth the waiting … on July 7th, David Musgrave finally announced the long waited successor of the Support Debugging Tool (aka #SDT), under the new name GP PowerTools (#GPPT).

Soon as I got the link to the download area, I went to pick up the firt built of the new package and the next day installed it.. and there is when I ran into troubles.. I had previously applied on my GP2015 test bed system upgrades to go from GP2010R2 to GP2013R2, and 2015 RTM, so I was coming from a previous release of SDT that was running fine under GP2013R2, and still had all the references in 2015.. Since I couldn’t survive without the SDT very long, Dave was kind enough to provide me a pre-build for 2015 of the actual SDT, so I could test properly the new GP.

That being said, the new setup of the GPPT comes with a few tricks if you already have an old SDT installed… and you need to be careful the way you apply the update.  I don’t wanna repeat what David already wrote, so for more details about what to care for to install the new #GPPT, go and have a look at today’s blog post about the public BETA setup.

The current BETA release has a time-bomb built-in that will expire the product on August 15th, 2015. By that time David will either have released another BETA with an extended expiration date, or feel confident enough that #GPPT is ready for prime-time release on the commercial level. Yes.. the new #GPPT will no longer be available for free since David doesn’t work anymore for Microsoft and has to work hard to get the bread on the table too :-).. But  the inital launch price should be very affordable at 365$/yr and everyone should get a license to support that super tool that took years of development to reach this level of quality (that’s less than a coffee cup a day !). Just the current BETA release required several hundred hours of work to add in new features and functionality that will make you fall in love again with GP’s administration (in case you just divorced from it 🙂 )..

Here are a few ones just to show you.

  • The Company selection screen. David included some of it’s VBA code that he wrote in the past to allow to enlarge the company selection list from the login screen, because sometimes it was very hard to figure out which company to select when they all started with the same or similar names.. To enable this feature you have to navigate into the GPPT Administrator Settings > Company tab, and in the middle of the screen, check the box called ‘Add extra width to company name drop down list…’
GP widen Login screen

GP widen Login screen

  • Another one I love is the all new Security Log enabler.. in the old #SDT when a user had security issues, you would walk up (or connect) to the end-user and start the security profiler to track what’s causing the issue, then export the log to XML by file or e-mail, re-import it with your POWERUSER role user and load the profiler trace to figure out what’s not working.  The new Security Log allows you to enable all this directly from your workstation on the product level itself. To enable this, you navigate again to the Administrator Settings > General tab, and at the bottom check the box “Enable Security Activity Tracking”.

    Centralized Security tracking log

    Centralized Security tracking log

  • Finally another nugget is the fact that you can now setup a different password for the GPPT administrator and for the System protected area password. This way you can delegate or share some of the powerful functions of GPPT without revealing the system password.

    Image 2015-07-08_134943

    Dedicated GPPT Admin password

Lots of new functions to still discover, so stay tuned as I’m going to report more about my findings on the new #GPPT.

Until next post, have a great time.


Categories: Dynamics GP, GPPT - GP Power Tools, SDT - Support Debugging Tool, System Administration | Leave a comment


For quite a few weeks/months there were uncertainty about the outcome of the SDT (aka Support Debugging Tool) for Dynamics GP. As my good friend David Musgrave had been left in the dust by Microsoft due to the high speed of the all new GP 2015 not being able to wait on the aging SDT, nobody knew would happen in the future.

I was holding my breath hopping that David would be able to #FreeTheCode of the SDT from the #WorldCompany Microsoft, as it was mostly his baby that he raised over the years, though while he was working for Microsoft, but still genetically the creator of the SDT. My guess that Microsoft would loose the tie quite quickly as they had no idea how to decipher the spaghetti code behind that tool (even Edward Snowden was not able to)… and finally a few weeks back David confirmed (just before Convergence 2015) that he got the intellectual property of the code back with some exclusive rights to use.

Then shortly after he started a poll to rebirth the SDT under a new name and was gathering all kinds of suggestions, including my own for the “Dynamics GP Power Tools” which gathered a whooping 45%… So hope was there that we would soon get a brand new tool that would hold on par with the “high speed” GP 2015 and its super-duper Web Client..

Oh Boy ! how foolish was I … Today David announced against all odds that the “Next Generation” of SDT would be called TWMBSSDGPPPSATPLCPAT4MSDGP !  Yes you read that right… be prepared for some tongue twisting. How can someone expect to be able to remember that name ? don’t even think about spelling it out ? Imagine yourself talking to your partner on the phone and asking for the “The Winthrop Microsoft Business Solutions Support Debugging Great Plains Pro Power System Administrator Toolbox Pack Library Control Panel Assistant Tool for Microsoft Dynamics GP”. It’s likely partner will have hung the phone up before you even ended talking…

And that’s why I decided to speak up and use my brand new freshly awarded status as Dynamics GP MVP and my influential position as @GPUG All Star, to encourage everyone that is using the old SDT and frantically waiting on the new offspring to openly boycott David’s product… No one should be fool enough to get talked into using such a product with an un-pronounceable name.

Please spread your voice out on Twitter and the community blogs & forums to stand up against such a stupidity and convince David to get a more reasonnable name. Use hashtags like #FreeDavidsCode, #MSDynGPofApril1st and #MVPBustingSDT.

Until next post,



Categories: All Stars, Dynamics GP, Fun, GPUG, SDT - Support Debugging Tool | Tags: , , | 5 Comments

Using Dynamics GP in a Citrix / TS environment

I often come across discussions in forums and community posts about the problems related to the end-user parameters stored in the DEX.ini file from GP.

Now the problem with shared environments is the reality that all the users are using the program folder to launch the application, thus also the same same settings from the DYNAMICS.SET and the DEX.ini to save the parameters. This can lead to some very confusion situations…. I had users calling in and saying they started a new GP session but only get the icon in the task bar, but actually never get to the login screen.

It took me some investigation back in 2010 or 2011 when this happened the first time, and it was coincidentally at the time when some users started to request a second monitor to increase their productivity :-)…

As it turned out at that time, Dynamics GP was used on the Citrix XenApp server by the vast majority of our users (around 120) and there was a single DEX.ini file for all the users, which means that every time a user launched the application remotely, it was showing the last user ID that logged in previously and also put the main GP windows at the screen coordinates where it was closed the last time. This was not too bad as long as everyone had pretty much the same configuration for the hardware (screen and printer), but soon as people started using 2 or more monitors, and moved the main GP window off the monitor #1, then the next user would run into troubles if he/she didn’t had the same setup.

That’s when I came across a blog post from my good friend David Musgrave  (at that time) from Microsoft Australia, who wrote something about the side-effects of shared DEX.ini files and how to avoid collisions in shared environments.

His article inspired me to find a smart way to make sure when a user would start GP the first time from the Citrix server that he would get a clean pristine DEX.ini file that become he/her own and contains only the settings from their sessions. No more hidden windows and lengthy DEX.ini files that would grow out by endless printer queue entries.

So I created a small batch file that would check the presence of an existing DEX.ini file in the owner’s home profile under the system hidden AppData folder. The content of the batch file looks like this :

 @echo off
rem This file is used to launch Dynamics GP
rem from within CITRIX MF without parameters
rem echo Press any key to start the GP apps
rem pause
rem Modified version to TEST SP3 1:07 PM 7/13/2012
cd “C:\Program Files (x86)\Microsoft Dynamics\GP11SP3”
if exist %HOMEDRIVE%%HOMEPATH%\AppData\Local\Dex.ini Goto StartGP
copy C:\Users\Default\AppData\Local\Dex.ini %HOMEDRIVE%%HOMEPATH%\AppData\Local\Dex.ini
start Dynamics.exe Dynamics.set %HOMEDRIVE%%HOMEPATH%\AppData\Local\Dex.ini
cd \

Save the file as a .cmd in the Program Folder location of your GP application on the Citrix server. Make sure you have fresh and pristing DEX.ini file copy in the Default user home path (see location above).  You can take the current DEX.ini file from your GP Data folder and remove any references to the ‘remembered’ printers and clear out the last user in the file :


It’s important to set the 2nd value to FALSE, otherwise GP will try to auto-login the user and this would fail since there is no user-id.

Lets assume you named your file GP_Roaming.cmd, then your new launch file command line would look like this :

“C:\Program Files (x86)\Microsoft Dynamics\GP\GP_roaming.cmd”

There is no need anymore for a parameter provided in the published application for Citrix, since everything is already passed in the .cmd file itself.

One last tip when you apply a new service pack or a year-end update to your GP. When updating your client on the Citrix or TS server, only the DEX.ini that’s sitting in the GP Data folder gets updated… none of the distributed config files from the users home profile…Remember to delete them all before given the updated GP apps free again for the users (the nice thing with published apps is that you can quickly enable/disable them).

If you don’t want to delete the files, use a VBS script or Powershell to loop through all the DEX.ini’s and make the changes.. I wouldn’t necessarily recommend this way of doing it, since during a service pack upgrade, there are quite a few changes applied to the file.

Test the new launch file with a few users and do adjustments if required. This procedure has worked pretty well for our company since about 3-4 years now and has successfully been ported to a newly built Windows 2012 Remote Desktop Application Server.

Until next post…

Update on 2015-08-21:

There is relief to all the users that have setup GP in a Citrix or TS environment. Since GP2013 was released, you don’t need anymore to have a separate DEX.ini for each user. Read on the Blog post from my friend Mariano Gomez, Dynamics GP MVP :

To me when upgrading to GP 2015 it was a real relief to not have to deal anymore with outdated DEX.ini settings every time you do apply an upgrade / service pack to your share GP client (as only the main DEX.ini got updated by the GP Utilities process). Running the GP client with wrong release information from the DEX.ini file can be very stressful as you get all kinds of strange messages and don’t necessarily think of the user’s DEX.ini (though I haven’t tested yet the user’s DEX.ini scenario after an update).

Until next post…

Update on 2016-01-25:

After we upgraded last year the GP2010R2 to GP2013R2 (not going to 2015 was a decision based on the fact that some important features from BP were missing on the Web Client PTE), I realized that the user shared DEX.ini feature was finally not so good and in some cases not useful at all. For that reason I went back to the individual DEX.ini file for each users on the TS. This way I have a much better control over the settings. I’ll post in a future blog entry, some tips on how to quickly get rid of all the DEX.ini files after an upgrade, rather then having to painfully delete them one-by-one.
Until next post…

Categories: Citrix - TS, Dynamics GP, SDT - Support Debugging Tool, System Administration | Tags: , , | 4 Comments

Use the Support Debugging Tool to tackle GP security issues

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?

Dynamics GP Security Denial Message

Dynamics GP Security Denial Message

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 ( 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.

  1. 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.
  2. 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.
  3. Restore the Security Profiler window and locate the last line…

    Security Profiler window (regular user)

    Security Profiler window (regular user)

  4. 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.
  5. 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.
  6. 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.

    Security Profiler window (Power User or SA)

    Security Profiler window (Power User or SA)

  7. 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.

    SDT Security Tree View

    SDT Security Tree View

  8. 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.
  9. 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).
  10. 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.

Categories: Dynamics GP, SDT - Support Debugging Tool, System Administration | Tags: , , | Leave a comment

Blog at