none
Hosting WCF service in a Windows Service application

    Question

  • I deployed a WCF service hosted in a Windows Service application on Windows 2003 SP1. The service failed to start with the following error message:

    Service cannot be started. System.ServiceModel.AddressAccessDeniedException:

    HTTP could not register URL http://+:2200/myServices/service/. Your process does not have access rights to this namespace (see http://go.microsoft.com/fwlink/?LinkId=70353 for details). ---> System.Net.HttpListenerException: Access is denied
       at System.Net.HttpListener.AddAll()
       at System.Net.HttpListener.Start()
       at System.ServiceModel.Channels.SharedHttpTransportManager.OnOpen()


    As instructed, I went to the link, which provides some oblique instructions on using the httpcfg tool available in the Windows Server 2003 Service Pack 1 Support Tools. I'm working through this still, but I wanted to post this in case anyone else has run into a similar issue with deploying a Windows Service-hosted WCF service.

    FWIW, I had no problem whatsoever running the server at the same URL from a console application. I assume at this juncture that this has to do with the permissions under which the Windows Service is executing.






    Wednesday, November 8, 2006 7:22 PM

Answers

  • The estimable Keith Brown has an article on this precise topic at http://msdn.microsoft.com/msdnmag/issues/06/11/SecurityBriefs/default.aspx?loc=null

    The article describes why you need to configure non-adminstrative permissions for a WCF application that listens on an HTTP channel. The article also includes invaluable code that can be used to easily grant a namespace reservation progrmmatically.

    But that leaves me with one more question. If I implement the service to function using named pipes, why do I need to enable an HTTP channel in the first place?

    For example, here is the server configuration file for my Windows Service-hosted service:

                <service name="MyCompany.MyService">
                    <host>
                        <baseAddresses>
                            <add baseAddress="http://localhost:2200/myCompany/service/"/>
                        </baseAddresses>
                    </host>
                    <endpoint address="net.pipe://localhost/"
                        binding="netNamedPipeBinding"
                        bindingConfiguration="defaultPipe"
                        contract="MyNamespace.MyInterface" />
                    <endpoint address="mex"
                        binding="mexHttpBinding"
                        contract="IMetadataExchange" />
                </service>

    Is the HTTP channel only necessary for metadata exchange? In other words, would this work just as well:

                <service name="MyCompany.MyService">
                    <host>
                        <baseAddresses>
                            <add baseAddress=""/>
                        </baseAddresses>
                    </host>
                    <endpoint address="net.pipe://localhost/"
                        binding="netNamedPipeBinding"
                        bindingConfiguration="defaultPipe"
                        contract="MyNamespace.MyInterface" />
                </service>

    I'll try this out and see if it actually works. But I'd welcome an explanation of the relationship between HTTP channels and named pipes within the context of WCF services.
    Wednesday, November 8, 2006 10:54 PM

All replies

  • The estimable Keith Brown has an article on this precise topic at http://msdn.microsoft.com/msdnmag/issues/06/11/SecurityBriefs/default.aspx?loc=null

    The article describes why you need to configure non-adminstrative permissions for a WCF application that listens on an HTTP channel. The article also includes invaluable code that can be used to easily grant a namespace reservation progrmmatically.

    But that leaves me with one more question. If I implement the service to function using named pipes, why do I need to enable an HTTP channel in the first place?

    For example, here is the server configuration file for my Windows Service-hosted service:

                <service name="MyCompany.MyService">
                    <host>
                        <baseAddresses>
                            <add baseAddress="http://localhost:2200/myCompany/service/"/>
                        </baseAddresses>
                    </host>
                    <endpoint address="net.pipe://localhost/"
                        binding="netNamedPipeBinding"
                        bindingConfiguration="defaultPipe"
                        contract="MyNamespace.MyInterface" />
                    <endpoint address="mex"
                        binding="mexHttpBinding"
                        contract="IMetadataExchange" />
                </service>

    Is the HTTP channel only necessary for metadata exchange? In other words, would this work just as well:

                <service name="MyCompany.MyService">
                    <host>
                        <baseAddresses>
                            <add baseAddress=""/>
                        </baseAddresses>
                    </host>
                    <endpoint address="net.pipe://localhost/"
                        binding="netNamedPipeBinding"
                        bindingConfiguration="defaultPipe"
                        contract="MyNamespace.MyInterface" />
                </service>

    I'll try this out and see if it actually works. But I'd welcome an explanation of the relationship between HTTP channels and named pipes within the context of WCF services.
    Wednesday, November 8, 2006 10:54 PM
  • Peter,

          Resurrecting this old thread again.. I faced the same problem. Did you mange to find out any other configuration using which you could setup a listener which doesnt need any special rights???

     

    Tuesday, August 14, 2007 10:52 PM
  • Suraj,

     

    can you post your endpoint config and also see what this command spits out?

      httpcfg query urlacl

     

    Friday, August 17, 2007 6:33 AM
  • Did anybody any solve this problem?

     

    I've got this too.

     

    I'm trying to host a WCF service as a Windows Service, and I'm using the example code from Learning WCF (Ch. 4).

     

    I hosted one service and everything was fine. I tried to add another service which exposed to endpoints, and I got the error.

    App Config:

    Code Snippet

    <service name="Messaging.OpenMessagingService" behaviorConfiguration="serviceBehavior" >

    <endpoint address="OpenMessagingService" contract="Messaging.IOpenMessagingService" binding="netTcpBinding" />

    <endpoint address="OpenMessagingServiceHttp" contract="Messaging.IOpenMessagingService" binding="basicHttpBinding" />

    <endpoint address="mex" contract="IMetadataExchange" binding="mexTcpBinding" />

    <host>

    <baseAddresses>

    <add baseAddress="net.tcp://localhost:9200"/>

    <add baseAddress="http://localhost:8080"/>

    </< FONT>baseAddresses>

    </< FONT>host>

    </< FONT>service>

     

     

    Error (from the eventlog):

    Code Snippet

    Service cannot be started. System.ServiceModel.AddressAccessDeniedException: HTTP could not register URL http://+:8080/. Your process does not have access rights to this namespace (see http://go.microsoft.com/fwlink/?LinkId=70353 for details). ---> System.Net.HttpListenerException: Access is denied

    at System.Net.HttpListener.AddAll()

    at System.Net.HttpListener.Start()

    at System.ServiceModel.Channels.SharedHttpTransportManager.OnOpen()

    --- End of inner exception stack trace ---

    at System.ServiceModel.Channels.SharedHttpTransportManager.OnOpen()

    at System.ServiceModel.Channels.TransportManager.Open(TransportChannelListener channelListener)

    at System.ServiceModel.Channels.TransportManagerContainer.Open(SelectTransportManagersCallback selectTransportManagerCallback)

    at System.ServiceModel.Channels.TransportChannelListener.OnOpen(TimeSpan timeout)

    at System.ServiceModel.Channels.HttpChannelListener.OnOpen(TimeSpan timeout)

    at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)

    ...

     

     

    Any help will be greatly appreciated!

    Thanks,

    Assaf.

    Thursday, July 24, 2008 9:55 AM

  • Hi guys,

    I am facing the same problem.
    Anyone has solved this issue?

    Any help would be really appreciated.

    Thanks!
    Mauricio.-
    Thursday, April 23, 2009 9:08 PM
  • Hey guys, have you tried using the HttpNamespaceManager ?

    Regards,
    John
    Thursday, April 23, 2009 9:45 PM
  • I faced the same issue which was resolved by setting the access privilege of the service or the app invoking the service.
    (e.g: run that as admin)
    Unblocking the fire wall port would also resolve this which is less preferred due to security issues.
    thanks
    Tuesday, June 23, 2009 6:17 AM
  • The article Peter links to in his post has a lot of good information about how to handle this situation.  On W2K3, you can use either the httpcfg.exe tool or the httpapi.dll to get the namespace reservation.  The API is useful for distribution with a custom action in an MSI.  On Vista/W2K8, you can use "netsh http add urlacl".  To answer Peter's question, named pipes do not require an HTTP channel.

    Wednesday, June 24, 2009 9:44 PM
    Moderator
  • Hello Peter,

     

     

    The problem you are facing with is :

    The service account doesn't have the permissions to run on the port that you have specified.

     

    There are 3 ways to solve this issue.

    1-) Close the firewall.  (Not recommended).

    2-) Give the admin rights to the service account. (also not recommended).

    3-) Give access rights to the service account to run on specific port. (that is also what i use).

    you can use the command below;

    netsh http add urlacl url=http://+:2200/ user=DOMAIN\USERNAME

     

    I hope it will solve your issue.

     

    Kind regards,

     

    • Proposed as answer by bedwar2 Friday, October 28, 2011 8:33 PM
    Friday, August 26, 2011 8:34 AM
  • I was able to duplicate this (unwittingly) and was not able to solve it with netsh, because the service turned out to be running under a different authentication.  

    In my case, the "Local System" account I specified in Visual Studio (in the ServiceProcessInstaller's Account property (in my case, serviceProcessInstaller1.Account)) was not being acknowledged by my Windows Service after installation (I installed with InstallUtil.exe).  

    Setting the auth once manually (Computer->Manage->Services And Applications->Services->[MyServiceName]->Properties->Log On and selecting "Local System Account") cured this problem immediately.  

    No amount of setting or resetting in VS and reinstallation of the service seemed to fix this, and the variety of non-specific error messages led to a number of wrong turns.  Only setting the Log On manually (through the Services gui, as above) resolved the problem.  

    Tuesday, October 25, 2011 4:56 PM
  • Hi,

    Tip from KodeMoeDee worked properly on my WCF service running as Windows Service. Now... it works!

    Thank you so much

    Friday, November 11, 2011 10:00 AM
  • I have done the configuration at least 20-30 times in the past on services with no problem, but I got this error on my newest WCF service hosted in a Windows Service upon startup as well. I messed up on just 1 step: On the ProcessInstaller object that is part of the Windows Service I accidentally set Account to LocalService instead of the correct option of LocalSystem. They are so close in spelling I overlooked it so many times, and of course with the LocalService account, it will not have the proper rights to start the service.

    Still one of my favorite 'quick notes' link on setting up and configuring the Windows Service:

    Walkthrough: Creating a Windows Service Application in the Component Designer:
    http://msdn.microsoft.com/en-us/library/zt39148a.aspx


    Thank you,
    • Edited by atconway Tuesday, January 17, 2012 4:37 PM
    Tuesday, January 17, 2012 4:36 PM
  • This one worked for me after granting the access to port number for the service account i was able to get the windows service working. Thanks Berk
    Tuesday, September 25, 2018 11:41 PM