WCF Deployment for IIS 6 Results in 403 Resolution Error

Question

I have never deployed a WCF service for IIS 6. I have a service that I deploy to IIS 6 using the default configuration as part of a WCF project. I have so simplified the configuration, which could be a problem. Here is the error I get if I go to the service in the browser:

HTTP Error 403.1 - Forbidden: Access denied.

Now my configuration is as follows:

<system.serviceModel> <services> <service name="MyCompany.WebServices.MyService"> <endpoint address="" binding="basicHttpBinding" contract="MyCompany.WebServices.IMyService" /> </service> </services> </system.serviceModel> 

If I try to add it as a reference in ASP.NET MVC, I get the following:

An error occurred while loading ' http://ws.mycompany.com/MyService.svc '. Request failed with HTTP status 403: Forbidden. The metadata contains the link cannot be resolved: ' http://ws.mycompany.com/MyService.svc '. An HTTP request was denied by the 'Anonymous' client authentication scheme. Remote Server Error: (403) Forbidden. If the service is defined in the current solution, try building the solution and adding a service link again.

Any ideas what could happen?

UPDATED:

This seems to be a configuration problem in my IIS 6 box. I would suggest this because I created a completely new ASP.NET 3.5 WCF application and deployed it to the new URL at http://ws.unitedoneresources.com/Service1.svc If I try to call this service, I get the same HTTP error as above. The entire service configuration is as follows:

  <system.serviceModel> <services> <service name="WcfService1.Service1" behaviorConfiguration="WcfService1.Service1Behavior"> <!-- Service Endpoints --> <endpoint address="" binding="wsHttpBinding" contract="WcfService1.IService1"> <!-- Upon deployment, the following identity element should be removed or replaced to reflect the identity under which the deployed service runs. If removed, WCF will infer an appropriate identity automatically. --> <identity> <dns value="localhost"/> </identity> </endpoint> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/> </service> </services> <behaviors> <serviceBehaviors> <behavior name="WcfService1.Service1Behavior"> <!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment --> <serviceMetadata httpGetEnabled="true"/> <!-- To receive exception details in faults for debugging purposes, set the value below to true. Set to false before deployment to avoid disclosing exception information --> <serviceDebug includeExceptionDetailInFaults="false"/> </behavior> </serviceBehaviors> </behaviors> </system.serviceModel> 

Again, this is a completely new ASP.NET 3.5 WCF application, so I have not changed anything in the project itself.

Answer 1

I removed the wacked website, installed WCF in IIS 6 (using ServiceModelReg.exe / i / x on the command line) and redistributed. It worked!

Thanks!

Answer 2

Found this question, looking for a solution to the same problem. I forgot to change the permissions to "Scripts and executables" in the services directory. I was on II7

Answer 3

You really do not give us much to continue here - that there are not enough server-side configuration bits that show us how you configure security - can you please update your question and show us everything inside the <system.serviceModel> in your server configuration and on your client calling the server

Just guessing the system defaults, using basicHttpBinding will set the default security parameter to default — and it will look as if your server-side configuration required some protection. It seems your security settings are out of sync, which leads to this error.

Another point: how did you create the IIS side? Have you created a virtual directory for your service? Basically, when placed on IIS, your service URL is determined by the server name (plus, possibly, the port), the virtual directory in which your * .svc file is located, as well as the name and extension of the svc file itself.

Answer 4

We had similar symptoms, but only with the verbs PUT and DELETE in IIS 6.0.

By default, the .svc extension in our IIS application only allows GET, POST verbs.

Adding verbs (or resolving all verbs) for the .svc extension for the application fixed the problem.