Wednesday, October 27, 2010

eConnect 2010 Integration Service Won't Start Due To Port 80 Conflict

By Steve Endow

Last week I deployed an eConnect 2010 integration at a client.  We first installed it on the SQL Server for testing, and everything worked fine.

We then deployed it on one of the two load-balanced Citrix servers that the Dynamics GP users utilize, and that went smoothly.  But when we installed and tested it on the second Citrix server,we received the now familiar "there was no endpoint listening at net.pipe" error.  Easy enough to resolve, no problem!

So I open the Services applet, and sure enough, the eConnect 2010 service was not running.  But when I tried to start the service, I received an error that it failed to start.  Hmmm.

I checked the Windows Event Log and found two errors, one of which was helpful.

Input parameters:
Exception type:
Exception message:
HTTP could not register URL http://+:80/Microsoft/Dynamics/GP/eConnect/mex/ because TCP port 80 is being used by another application.

Exception type:
Exception message:
The process cannot access the file because it is being used by another process

So this seemed to be telling me that the eConnect 2010 service was trying to setup a listener on port 80, but something else was already using port 80.  We initially thought that it might be IIS, but after stopping the IIS web site and IIS services, I used the netstat command to confirm that something was still using port 80.

After re-reading the eConnect 2010 documentation and not finding any references to http or port 80, we submitted a support case.  Support responded promptly and offered two workarounds.

We chose the simpler of the two solutions, which was to change a parameter in the eConnect service config file.  To do this, locate the eConnect web services configuration file, which is usually installed at:

C:\Program Files\Microsoft Dynamics\eConnect 11.0\Service\ Microsoft.Dynamics.GP.eConnect.Service.exe.config

Open this file using a text or XML file editor and change the httpGetEnabled parameter to false.

So what in the world does this mean?

Changing the httpGetEnabled parameter to false disables the HTTP publishing of the Web Services Description Language (WSDL) metadata.  Developers should understand what this means--for anyone else, don't worry about it if it doesn't mean anything.

We learned that by default, the eConnect 2010 service publishes its WSDL using both HTTP and named pipes (net.pipe).  The HTTP method can be viewed using Internet Explorer, while the net.pipe method uses the WCF 'metadata exchange' (mex) endpoint, which can be browsed using the WCF metadata tool, svcutil.exe.  And apparently Visual Studio can access the WSDL using either of these methods.

The workaround above, setting httpGetEnabled =false, turns off the HTTP WSDL publishing, thereby eliminating the need for eConnect to use port 80.  The eConnect 2010 service will still provide the net.pipe WSDL in case it is necessary.  I don't yet know if the WSDL is even used for a compiled / deployed eConnect integration, or if is only necessary to setup the service reference in Visual Studio--that will have to be a separate homework assignment.

I suspect that the httpGetEnabled=false option should work just fine for most customers.  In case it isn't a viable option, the second workaround that support provided was to change the port that the eConnect service uses to publish the HTTP WSDL.  That was slightly more involved, and wasn't necessary for us, so we chose not to use that approach.  If anyone is interested in knowing that method, i.e. you have a development server that is already using port 80, let me know and I'll write a separate post on that method.

2/21/11 Update:  Here are the instructions provided by MS Support to change the port number for the HTTP WSDL.

Step 1:  Edit the Microsoft.Dynamics.GP.eConnect.Service.exe.config file located under the following typical location: C:\Program Files\Microsoft Dynamics\eConnect 11.0\Service.exe.   Change the httpGetUrl to have a different port, such as port 83:

< serviceBehaviors >
  < behavior name="eConnectServiceBehavior" >
    < !--Leaves this to true in order to receive Exeption information in eConnect-- >
    < !--This settings turns on Metadata Generation. Metadata allows for consumers to add service references in Visual Studio-- >
    < serviceMetadata httpGetEnabled="true" httpGetUrl="http://localhost:83/Microsoft/Dynamics/GP/eConnect/mex"/  >
  < /behavior >
< /serviceBehaviors >

Step 2:  Use "netsh http add urlacl url=http://+:port_number/ user=DOMAIN\UserName" at a Command Prompt to assign the HTTP namespace to the required user account that the "eConnect 2010 service" runs under.  The below syntax is what I used on my computer to configure it for port 83.   Note the ADOMAIN\GPService account is the Windows account running the "eConnect 2010 service" under Administrative Tools - Services.

netsh http add urlacl url=http://+:83/ user=ADOMAIN\gpservice

Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him on Google+ and Twitter


Lawrence said...

Hi guys,
Thanks for the post! We are experiencing the same issue, yet the workaround listed here is not working in this case. I'd be interested to know what the MS workaround is.


Steve Endow said...

Hi Lawrence,

Glad you found the post useful.

Just to confirm, after disabling httpGetEnabled, did you stop and restart the eConnect 2010 service? That solution should work if the problem was due to the eConnect HTTP WSDL.

If that option did not work, then you may have a slightly different problem with similar symptoms.

I have updated the post with the second option to change the eConnect HTTP port number.

I'd be interested to hear if that solution fixes your issue.



SQL Newbie said...


I am working with Lawrence on this issue. In our environment we are running two citrix server on Windows 2008 R2. The main problem there was a Citrix XML service running on port 80 ( used netstat -o -n -a ) to find the PID of the service listening on the port. Too make a Long story shorter your Second fix worked like a charm. We are able to run our IM with no problem. Thank you so much for your help and posting this information. I owe you one !!

Lawrence said...

Steve, you're the man! I beleive that we restarted that service --but it was changing the port that got us up and going. Thanks again for your post.