WCF Deployment to IIS 6 Results in 403 Permission Error - wcf

Question

I've never deployed a WCF service to IIS 6 before. I've got a service that I'm deploying to IIS 6 by using the default configuration as part of the WCF project. I since simplified the configuration thinking that might have been the issue. Here is the error I'm getting if I browse to the service in a browser:
HTTP Error 403.1 - Forbidden: Execute
access is denied.
My configuration now looks like this:
<system.serviceModel>
<services>
<service name="MyCompany.WebServices.MyService">
<endpoint address="" binding="basicHttpBinding" contract="MyCompany.WebServices.IMyService" />
</service>
</services>
</system.serviceModel>
If I try adding it as a reference in ASP.NET MVC, I get the following:
There was an error downloading
'http://ws.mycompany.com/MyService.svc'.
The request failed with HTTP status
403: Forbidden. Metadata contains a
reference that cannot be resolved:
'http://ws.mycompany.com/MyService.svc'.
The HTTP request was forbidden with
client authentication scheme
'Anonymous'. The remote server
returned an error: (403) Forbidden. If
the service is defined in the current
solution, try building the solution
and adding the service reference
again.
Any ideas what might be going on?
UPDATED:
It appears to be a configuration issue on my IIS 6 box. I'd assume this because I've created a brand new ASP.NET 3.5 WCF Application and deployed it to a new URL at http://ws.unitedoneresources.com/Service1.svc. If I try to call that service, I get the same HTTP Error listed above. The entire service configuration is the following:
<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 brand new ASP.NET 3.5 WCF Application so I haven't modified anything on the project itself.

Answer 1

I wacked the I wacked the website, installed WCF on IIS 6 (using ServiceModelReg.exe /i /x at a command prompt), and redeployed. It worked!
Thanks!

Answer 2

Found this question searching for a solution to the same problem. I had forgotten to changes permissions to 'Scripts and Executables' on the services directory. I was on II7

Answer 3

You don't really give us a lot to go on here - what's missing are the server side configuration bits that show us how you set up security - can you please update your question and show us everything inside the <system.serviceModel> tag on your server side config and on your client calling the server??
Just guessing from the system defaults, using the basicHttpBinding would result in a default security setting of nothing - and it would appear as if your server-side config requires some form of security. It almost seems as if your security settings are out of sync, thus resulting in this error.
Another point is: how did you set up the IIS side? Did you create a virtual directory for your service? Basically, when hosting in IIS, your service URL is determined by server name (plus possibly the port), the virtual directory your *.svc file lives in, and the name and extension of the svc file itself.

Answer 4

We had similar symptoms, but only with PUT and DELETE verbs under IIS 6.0.
By default, the .svc extension within our IIS application was only allowing GET, POST verbs.
Adding the verbs (or allowing all verbs) for the .svc extension for the application fixed the issue.