The Dynamics GP support team has seen a recent increase in cases where the drilldown functionality in Microsoft Dynamics GP has stopped working, so we have written the following guide to help customers attempt to troubleshoot the issues before needing to open a support case.
The most common error received with drilldowns is:
"A connection to Microsoft Dynamics GP could not be established. Be sure you are logged on to the appropriate Company and try again."
Note that if you have recently moved the Dynamics GP installation to a new server that is running Microsoft SQL Server and have not updated the server links for the drilldown functionality, you will need to perform the steps in the following article: https://support.microsoft.com/en-us/help/2966672/a-connection-microsoft-dynamics-gp-could-not-be-established-be-sure-yo
Beyond that, typically this comes down to a permissions issue with the protocol handler and GP Code folder that is used with drillback functionality. You will want to give full control of the following folders:
a. GP Code Folder | C:\Program Files (x86)\Microsoft Dynamics\GP2018
b. Right click on the GP 2018 folder and select properties.
c. Add the group "everyone" and give it full control to this folder.
d. Now locate the Microsoft.Dynaimcs.GP.ProtocolHandler.Exe
i. C:\Program Files (x86)\Common Files\Microsoft Shared\Dexterity
ii. Right click on the Dexterity Folder and select properties.
iii. Add the Everyone Group to this and give the group full control.
e. You can now test the drillback functionality again.
2. If that does not work, uninstall Dynamics GP and uninstall Dexterity Shared Components. Then delete the GP code folder. Re-install Dexterity Shared Components and Dynamics GP so that everything is laid down new.
3. If that does not work, if you copy the link from the steps below into a browser window other than IE, such as Chrome, Firefox, etc, does it work then? In some environments, IE Settings can lock down the drill backs or there are group policies in the environment that we are unaware of that cause the drillback to produce the error. Here are the steps for this test:
a. Open SQL Management Studio and log in as an administrator.
b. Start a New Query on the GP database in question.
c. Run this query: select * from Accounts
d. Scroll all the way to the right until you locate the "Account Index For Drillback" column.
e. Copy one of the links from that column.
f. Log into the computer where the drill back error occurs as the user in question.
g. Launch Dynamics GP and log into the company.
h. Paste the link from Step “d.” into a web browser and press Enter.
4. If you right click on IE browser and select to run as administrator and paste the link in from the steps above, does that successfully open the window in GP? 5. If the issue still occurs at this point, test again after disabling UAC (User Access Control) in Windows.
Another common error is:
“A error has occurred trying to process your url.”
We have seen this issue before when a Domain Administrator will log into a terminal server and then logs into GP. An Administrator starting GP causes the WCF net.pipe service to be exposed to other users and as a higher placed user the endpoint overrides the others. Endpoints are how services are discovered in WCF, and without a unique endpoint a valid connection can’t be reached. Net.pipe security disallows crossing the user running process barrier - so when non-domain adminisitrator users attempt to use the drillback functionality, it fails with the error message. This occurs because of the WCF service that was started when the Domain Admin logged into the terminal server and started GP, which raises the authentication level in which non-domain administrators are not able to access. The only option we have to resolve this issue, is to have Domain Administrators log out of the GP session and the drillbacks should begin working for all non-admin users on that terminal server. It is also important to note that with the way drillbacks are designed, you could be running into a limitation where the net.pipe handle is not created for the user – hence, the drilldown does not work for their account. In our tests we have found that on a Terminal Server, multiple net.pipe handles can be created simultaneously which will allow multiple users to be signed into Dynamics GP and use drilldowns at the same time. However, in a non-Terminal Server environment, only one handle will be created. You can confirm this by using the “Handle” tool from Microsoft SysInternals: https://docs.microsoft.com/en-us/sysinternals/downloads/handle
After extracting the tool, you can run the test by executing the following in Command Prompt directly in the folder where the executables reside:
handle64.exe net.pipe -accepteula
handle.exe net.pipe -accepteula
Here is an example showing only one net.pipe handle for Dynamics.exe – which would only allow one user to perform drillbacks:
Here is another example showing multiple net.pipe handles for Dynamics.exe, which will allow two users to perform drillbacks simultaneously:
If all of the steps in this article check out but the issue is still occurring, it would be best to open a support case. Please gather a Process Monitor trace via the following steps and provide it to the support engineer before opening the case:
a. Sign into the affected machine as a Domain Administrator account who is also a member of the local Administrator group on the machine.
b. Download Process Monitor here:
c. Once downloaded double click the Procmon.exe file to start the tracing process. Data collection starts automatically and you will see new records adding into the main form.
d. After you have reproduced the error in Dynamics GP, click File -> Save in Process Monitor and save the log as a .PML file with the default settings.