web
You’re offline. This is a read only version of the page.
close
Skip to main content

Announcements

News and Announcements icon
Community site session details

Community site session details

Session Id :
Microsoft Dynamics GP (Archived)

Drillback to GP doesn't work unless GP is started using "Run as administrator"

(0) ShareShare
ReportReport
Posted on by 285

I have a machine in our enviroment where drillback to GP doesn't work unless GP is started using "Run as Administrator". Any ideas how to fix that?

If I don't run GP as administrator, I get the infamous error. "A connection Microsoft Dynamics GP could not be established.  Be sure that you are logged on to the appropriate company and try again."

*This post is locked for comments

I have the same question (0)
  • JoshP Profile Picture
    Microsoft Employee on at

    Hi Japheth,

    Thanks for the details of the issue. I have several questions for you to help with the problem you encountered. Please review the following:

    1. Are you using Management Reporter? If so, what is the full version number?

    2. When you start Management Reporter, do you start it as Administrator?

    3. Which viewer are you using for MR: the Report Viewer (desktop client) or the web viewer?

    4. If using the web viewer to view MR reports, which browser are you using? Also what is the full browser version number?

    5. Start Dynamics GP and the viewer you use for MR reports. Then open the Windows Task Manager and switch to the Details tab. Task Manager has a column called "Elevated" so you can see which processes are running as administrator. To enable the Elevated column, right click on any existing column and click Select columns. Check the one called "Elevated", and click OK. What shows in this column for Dynamics GP and the MR viewer being used?

    6. What is the full Dynamics GP version being used?

    7. Does the same issue occur on other workstations?

    8. Does the same issue occur for other domain users on the same workstation?

    9. If you login to another workstation with your domain account, does the same issue happen?

    Thanks!

  • Tim Wappat Profile Picture
    5,715 on at

    Is the application you are drilling from being ran as administrator?

    If that is the case, there may be a permissions mismatch between the two applications.

    It may also be helpful to do a uninstall-reinstall, just as a blanket reset.

    Tim.

  • Japheth Nolt Profile Picture
    285 on at

    @JoshP  

    This has nothing to do with MR. I'm just taking the drillback link from the GP view, ie. "SELECT TOP 10 [Vendor ID For Drillback], [Vendor Name] FROM Vendors", copying the link, pasting it into IE 11 (or any browser) and executing it.

    None of the browsers I was testing with were elevated. I even tried executing the URL from the Run window (Windows + R), same failure.

    GP version: 18.00.0496

    No. This issue does not occur on other workstations.

    Yes. This issue does occur with another domain user logged into my workstation.

    No, This issue does not occur when I login to another workstation with my account.

    @Tim Wappat

    I did try a GP uninstall/reinstall and it still failed, even before I installed any third party addons.

  • Tim Wappat Profile Picture
    5,715 on at

    Japheth,

    I think my next move would be to see if any errors are getting raised.

    timwappat.info/.../Dynamics-GP-drill-down-logging-to-trace-file-for-diagnosing-problems

    Tim

  • Lucas Miller Profile Picture
    Microsoft Employee on at

    Japheth,

    Is this a Terminal Server environment? I haven't been able to find the details to remind myself, but I want to say I worked with a customer several years ago and we found that when a local/domain administrator logs into a Terminal Server it would disable drillback capability for all other users.  It had to do with that user's DGPP:// endpoint basically invalidating everyone else's on that machine.  I'd be curious if you're running into something similar since you mention having to launch GP as Administrator.

  • Japheth Nolt Profile Picture
    285 on at

    This is not a terminal server environment.

    I enabled logging and below is the exception I'm getting.

    System.ServiceModel.EndpointNotFoundException, System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

    There was no endpoint listening at net.pipe://dgpb/<servername>/<dbname>/ that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.


    Server stack trace:
       at System.ServiceModel.Channels.ConnectionUpgradeHelper.DecodeFramingFault(ClientFramingDecoder decoder, IConnection connection, Uri via, String contentType, TimeoutHelper& timeoutHelper)
       at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.SendPreamble(IConnection connection, ArraySegment`1 preamble, TimeoutHelper& timeoutHelper)
       at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.DuplexConnectionPoolHelper.AcceptPooledConnection(IConnection connection, TimeoutHelper& timeoutHelper)
       at System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection(TimeSpan timeout)
       at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.OnOpen(TimeSpan timeout)
       at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
       at System.ServiceModel.Channels.ServiceChannel.OnOpen(TimeSpan timeout)
       at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
       at System.ServiceModel.Channels.ServiceChannel.CallOpenOnce.System.ServiceModel.Channels.ServiceChannel.ICallOnce.Call(ServiceChannel channel, TimeSpan timeout)
       at System.ServiceModel.Channels.ServiceChannel.CallOnceManager.CallOnce(TimeSpan timeout, CallOnceManager cascade)
       at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
       at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
       at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
    Exception rethrown at [0]:
       at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
       at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
       at Microsoft.Dynamics.GP.ServiceIntegration.ProtocolHandler.DynamicsGPDrillBackService.IDrillBackToGP.CallAction(Uri uri)
       at Microsoft.Dynamics.GP.ServiceIntegration.ProtocolHandler.ProcessDrillBack.ProcessStart(Uri uriParameter)
  • Tim Wappat Profile Picture
    5,715 on at

    Can there be another copy of GP running - do you have any applications that do posting via windows services or similar installed on the machine?

    If you close all GP instances down, does the named pipe get removed - thinking here is that it may not be cleared down due to rogue process and thus getting blocked?

    timwappat.info/.../Protocol-handler-debugging-in-Dynamics-GP-(drill-down)-problems

    I get exhausted for ideas beyond this.

  • Lucas Miller Profile Picture
    Microsoft Employee on at

    Tim is correct.  It can be difficult to troubleshoot drillback issues if it isn't one of the known issues.  There are many environmental factors that could contribute to your problem.

    Since we know that running GP as Administrator resolves the issue it's probably going to be a permissions issue, so you could try capturing the drillback process in Process Monitor to see if any ACCESS DENIED results show up.

    Otherwise you could just change your GP shortcut's properties so it allows runs as Administrator.  Unless you have specific policies against this in your organization this really won't give the user or GP any real permissions that would allow them do something they shouldn't be.

  • Tim Wappat Profile Picture
    5,715 on at

    Indeed - It certainly feels like a permission issue on the named pipe that is created by GP, to which the protocol handler talks.

    The protocol handler is running ok and handling the request which is why the error dialog is produced, the protocol handler just can't talk to GP without admin.

    However why that is occurring is getting too difficult to diagnose without some invasive and involved troubleshooting..

    Tim.

  • Japheth Nolt Profile Picture
    285 on at

    Please don't sweat this one. I'm a GP consultant and .Net developer and this one just had me stumped. I just wanted to pick some other brains to see if you had an easy answer.

    Here's what I think is happening. When GP is run as standard user, it doesn't even create the net.pipe listener. See my screenshot below. This is really odd. Any idea how to log/diagnose that?

    2018_2D00_10_2D00_31-14_5F00_06_5F00_52_2D00_Administrator_5F00_-Windows-PowerShell.png

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Season of Sharing Community Challenge Launch!

Jump in, show your community spirit, and win prizes!

Women in Power Builds Momentum

Expanding mentorship, skilling, and AI innovation

Congratulations to the April Top 10 Community Leaders

These are the community rock stars!

Leaderboard > 🔒一 Microsoft Dynamics GP (Archived)

#1
Shravan Attelli Profile Picture

Shravan Attelli 1

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans