Condividi tramite

Common Support Debugging Tool Myths - Fact or Fiction?

  • Articolo

David Meego - Click for blog homepageI have just returned from Microsoft Dynamics Conference 2011 Atlanta conference, and based on the feedback during the sessions that Mariano and I presented as well as comments from the session evaluations, I thought it would be worth discussing some of the common Support Debugging Tool (SDT) myths.

Here is a list compiled after a quick chat with MVPs Mariano Gomez and Mark Polino:

 

The SDT is hard to install

FICTION: Once you have the archive zip file for your version of Microsoft Dynamics GP, just copy the files into your Microsoft Dynamics GP application folder (need at least the Debugger.cnk and Debugger.pdf) and launch Dynamics GP using Run as Administrator. Copying the Debugger.pdf allows the F1 key to open the User Guide from inside Dynamics GP.

Note: You need to give all users access to the MBS_DEBUGGER_USER Security Role to use the standard mode features. The upcoming build 15 or later builds will offer to apply this security change for you.

 

The SDT is hard to setup

FICTION: No setup is required, however to get the most out of the tool, it is best to use a central location of the Debugger.xml setup file. The Debugger.pdf User Guide manual has a section on Recommended Configuration which gives step by step instructions with screenshots on how to configure the SDT to use a central location.  Just use a folder in the same path you use for OLE attachments for Notes.

 

The SDT can only capture logs

FICTION: The SDT can capture logs either manually or automatically, but that is only a small part of the overall functionality and features of the tool. As the SDT does not need to change Dex.ini settings to capture logs it can capture logs without having to exit the application and come back AND it only captures for the current instance of the application. If you change Dex.ini settings on a Terminal Server it can affect all instances from multiple users.

 

The SDT only needs to be on one machine

FACT & FICTION:  To capture logs or perform most features you can install the SDT on only one machine, BUT to get the most out of the tool including the centralised administration functions you should have the SDT installed on all workstations AND use a central location for the Debugger.xml setup file. 

 

The SDT should be installed on all machines

FACT: To get the most out of the SDT, you should have it installed on all workstations in your system. Features such as differentiating companies using colour coding and changing the window Title will only work if the tool is installed. Also, if you have to exit to install the tool when you have a problem, you might not be able to reproduce the issue once logged back in. Having to tool installed and waiting means it is there when you need it.

 

The SDT should use a shared location for the setup file

FACT: To get the most out of the SDT, you should configure it to use a central location for the Debugger.xml setup file.  This will allow for settings on the tool to be controlled system wide and allow for features like centralised updates to Dex.ini settings to work. See the Recommended Configuration section in the Debugger.pdf User Guide manual for details.

 

The SDT creates tables at the SQL Server level

FICTION: The SDT does store a couple of settings in the System and Company Defaults tables, but it does not create any of its own tables at the SQL Level.  All of its data is stored in the Debugger.xml setup file.

 

The SDT causes performance problems

FICTION: The SDT does not cause any measureable change in performance by being installed. It will just sit passively until you need it. If you have setup the Automatic Debugger Mode to run triggers and/or logging or are using Manual Logging Mode, as expected, there will be a minor overhead caused by the logging or when the triggers run.

Note: There was a performance issue with Automatic Debugger Mode in build 9 of the tool, which was fixed in build 10 in December 2008.

 

The SDT has features that are dangerous

FACT: The SDT does have features which allow data to be manipulated or scripts to be run. However, these are all classified as Advanced Mode features and are only available to be used if the following conditions are met:

  1. Advanced Mode for the Support Debugging Tool is turned on to make the features visible.
  2. Application Level Security to the Advanced Mode feature's windows is granted. You can use the MBS_DEBUGGER_ADMIN Security Role for this.
  3. The System Password is known and entered correctly when opening the window (if a System Password is being used).
  4. The current user is a sysadmin or dbo (for system and company database) at the SQL Server Level.

The "dangerous" Advanced Mode features are very well protected from access by a standard user.

  

The SDT allows standard users to view or edit data

FICTION: A standard user will not have access to any of the Advanced Mode features that allow viewing or editing of data.

 

The SDT allows standard users to write scripts

FICTION: A standard user will not have access to any of the Advanced Mode features that allow writing or executing of scripts.

 

The SDT can only be used by developers

FICTION: The SDT has many features that require no developer skills and are designed for use by users and/or administrators. Amongst the Advanced Mode features there are SQL Execute which requires Transact-SQL skills and Runtime Execute & Automatic Debugger Mode which require Dexterity sanScript skills.

 

The SDT offers nothing for end users

FICTION: The SDT has many features for end users, such as capturing screenshots, sending emails, capturing logs, obtaining resource information, colour coding companies and identifying security issues.

 

The SDT can help administer security

FACT: The SDT has the Resource Information, Security Profiler and Security Information windows to help identify resources and administer security. 

Note: the Security Information window can only be accessed by a user who has access to the windows used for editing security AND that the Security Information window is read-only. You still need to use the standard security windows to make changes to security settings.

 

The SDT can only work with Window and Table security

FICTION: The SDT can work with all dictionary resources which also includes Reports. In Build 15 or later builds, the SDT will also support non-dictionary resources such as Posting Permissions, Document Access, Tools access, Navigation Lists and Smartlists.

 

The SDT is not supported

FICTION: While the SDT is currently not officially supported by Microsoft Dynamics support, it is supported using the Microsoft Dynamics GP Community forum. Post on the forum at https://community.dynamics.com/forums/32.aspx and prefix the subject line with "SDT:".

 

The SDT is not well documented

FICTION: The SDT comes with the comprehensive Debugger.pdf User Guide manual which is approximately 150 pages.  There is also a huge amount of information available on the blogs.  A good starting point is the Support Debugging Tool Portal on this blog. 

 

The SDT is not available for download by Customers

FACT: Currently, the SDT is not available from CustomerSource and so cannot be downloaded by customers.  However, any customer can ask their partner for the tool and use it on their system. We are looking into what is required to get the SDT posted onto CustomerSource.

 

The SDT is only available to Partners

FICTION: While the SDT can only currently be downloaded from PartnerSource, it is available for use by Partners and Customers alike. It was originally only posted onto PartnerSource so that partners would know when their customers had the tool installed.

 

The SDT is free

FACT: Microsoft does not charge for the Support Debugging Tool.

 

The SDT is only available for GP 2010

FICTION: The SDT is available for versions 8.00, 9.00, 10.00 and GP 2010 and will be available for future versions of Dynamics GP.

 

The SDT is Microsoft's most guarded secret 

FICTION: The tool was first shown to the partner channel in May 2008 and build 9 was released onto PartnerSource in September 2008. It has now been shown at five conferences:

You can always find information on the Support Debugging Tool Portal. It is also covered in many blog posts on this blog: Support Debugging Tool Tag and Mariano's Blog: Support Debugging Tool Tag, as well Jivtesh Singh's blog aggregator GPWindow.com.

 

Mark Polino suggested some other myths as well: 

The SDT will make you more attractive to the opposite sex

FACT: Well.... if the person in question is an Administrator of a Dynamics GP system or a user with a problem.

 

The SDT will regrow hair

FICTION: But I am working on it.

 

The SDT was created by advanced aliens, David just stole their technology

FACT or FICTION: You will never know..... maybe I'm an alien....

 

The SDT can be used to show school colours

FACT: If you really want to use the company colour coding feature in that way. 

 

Thank you to all who attended Support Debugging Tool sessions at Convergence and thanks for the great feedback on the evaluations.

Hope this sets everything straight.

David

Comments