I have this wierd problem on our Windows Server 2003, XP box running IIS 6.0. I have a WCF service deployed using an application pool identity. I am able to browse the svc file like this on that box,
http://localhost/servicename.svc
But when I do http://machinename/servicename.svc, it asks for credentials.
The website is configured for Anonymous access and Integrated Windows authentication.
I am really not sure what is wrong here, I have another machine that is a failover location for this box, where the same thing works fine with exactly same settings in IIS.
Make sure that the Application Pool identity has Read & Execute access on the files hosted by IIS (in other words, check the files at D:\path\to\site). Whether it's Network Service, a domain account, whatever.. it's going to need R&X permission.
What I'm guessing that's happening is that you're a local Admin on the server, so when you do it locally you're able to use your own local credentials to pull the site. But when you do it remotely, IIS must have access to these files - even if Anonymous access is enabled (otherwise, how can it load the files to serve the page to you?).
If you're still stumped, try using a program like filemon or procmon local on the server while making the request, and see what's getting Access Denied when you get a 401.
Related
I have a service, hosted in a windows service. When I installed the windows service in the local machine, I can get data from the service, but when I installed the windows service in the remote computer (in the server), I don't get data.
I have tried in a internet browser to use the address of the endpoint in the server, and I get response, so I get the page that says how to use svcutil to create the proxy.
Although I get this page, I have tried to disabled the firewall in the server and in the client, but the problem persists, how I expected.
If I get response in the internet browser, wouldn't I get access to the methods of the service?
On server side add trace listener so as to find out what error occures. Do you make use of any certification which service may not possess?
I cannot access my WCF service in IIS 6.0 when running on a VM (Windows 2003 64 bit server).I have a local IIS as well on where I developed the service, and I can access my service fine over there. I built a deployment package and deployed it to the VM, however I just cannot get to it.
Particulars about the WCF service:
1 - Its REST based
2 - Using SSL
If I place a static HTML file in the directory where my service.svc file is, I am able to access that but I cannot access the service.svc file. I am doing all this using IE.
So for instance
Any help would be appreciated it. Thanks.
Couple of things to check:
ASP.NET is installed properly and is registered for IIS (aspnet_regiis -i). Best way is not to use a static file, but an .aspx file to see if the asp.net runtime is running.
Verify you are running a 64-bit binary for the wcf service. If you copied if from a local 32-bit OS, you might need to recompile it for 64-bit.
Did you use https localy also? if not, try to change the configuration of the service to use http (without ssl), check that it works, and then understand what is the required configuration for https.
I am trying to Access mapped network drive from wcf service hosted on IIS7. It says path could not be found. However when I m using visual studio development server, it is able to access it. I have tried impersonation but of no avail. Please let me know what are the settings I have to set in IIS And also on File server if any. Thaks in Advance
http://support.microsoft.com/kb/257174
Drop that mapped drive approach and use UNC path instead.
I know this is an old post, but thought I'd share my solution. Had the same problem; couldn't access a network drive from my WCF running in IIS. I tried a virtual directory providing my network credentials which didn't work.
The solution that worked for me was to create an application pool in IIS for my service to run under. Then I gave the application pool network credentials. Changed my service to run inside this application pool and now the service can access the network share.
So my steps were:
1) Create a new application pool in IIS. Right-click 'Application Pools' in the Connections window. Then 'Add Application Pool...'. Give the new pool a name and choose the framework. I left the other settings as default. 'Ok'.
2) Change the identity of the new application pool. In the Application Pools list, right-click on your new pool and go to 'Advanced Settings'. Under 'Process Mode', open the 'Identity' details. Select 'Custom account:' then provide the network credentials that have access to the network share. Then 'Ok', 'Ok'.
3) Change the pool your service is running in. Select your service application then click 'Basic Settings...' (on the Actions pane). Click 'Select...' in the pop-up. Change the Application Pool to the new pool you created. Then 'Ok', 'Ok'.
Now your service should be able to access the network share using the supplied credentials. You can test using your credentials but I'd recommend using a service account (virtual account with no password reset policy) when you deploy your service.
Hope this helps others!
I'm in the process of deploying a WCF service application. The service works fine if it's running as its own site, but the intention is for the service to run as a virtual directory of the Default web site of the server. When I set the service up in this configuration, I get an odd problem. When the client tries to make a service call, it receives the HTML of the friendly service description, not SOAP. Naturally this generates a service error. The HTML appears to be identical to the service page that you see in a browser with an HTTP Get, but I'm only seeing the first 1024 bytes in the error message, so I may be missing something.
I've checked HttpHandlers and loaded assemblies, and as far as I can tell there's nothing unusual that is being inherited by the virtual directory. The default site has 3 ISAPI Filters installed including Outlook Web Access (yes, this server is running Exchange). I tried installing these filters in my test web site, but it still ran the service without problems. The problem only happens with the service is running as a virtual directory of another virtual directory within the default web site.
The server is Windows Small Bus Server 2003 SP 2 running IIS6.
If you're hosting WCF in IIS you need to set the server up in the 'Application Role' check out the following link does that help:
MSDN: Internet Information Service Hosting Instructions
I have a Web application and a WCF service hosted on the same Windows 2003 development server. They each have their own IIS website node responding to drs.displayscreen.web and drs.displayscreen.service host headers respectively. The hosts file contains entries for both headers pointing back to 127.0.0.1. The web site has a service reference to drs.displayscreen.service.
Both applications work perfectly when their application pool uses the 'Network Service' account.
I need to perform some COM processing under the hood on the service so I want to run the applications under a customised identity. Both sites run on a new application pool.
When I change the application pool identity to use a new windows account created for the purpose, I get the following (inner) exception:
[EndpointNotFoundException: Could not connect to http://drs.displayscreen.service/Handler.svc. TCP error code 10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 192.168.98.2:8080. ]
192.168.98.2:8080 is the address of a DNS server that is no longer in use. It is not referenced anywhere in the solution. It is not referenced by ipconfig at all.
I have made sure that the new account is a member of IIS_WPG and I have run aspnet_regiis -ga . I have also given the account explicit permission to read the hosts file.
Why does the application attempt to use the defunct DNS server to resolve the temporary url (drs.displayscreen.service) instead of the hosts file entry? It has to be a permission of some sort because it does not have this problem when running under the network service account. Help!!
Well, it appears that the answer might involve a bug in the .Net framework. I found a blog posting that clued me in to the fact that the MS .Net implementation of SocketCache.GetSocket might cache invalid sockets and another one that suggests a workaround/hack in the form of an explicit don't-use-proxies configuration setting.
We don't actually use a proxy server in the environment where this problem cropped up but it appears that SocketCache.GetSocket is overridden or behaves differently when the don't-use-proxies setting is in place. Strangely, removing the setting causes the problem to come back so obviously the SocketCache is not repaired when a valid ip/hostname is discovered and successfully used. According to the author of the first post mentioned above, the bug does not exist in Mono. :)