One of the major changes in Windows Vista security is that most people are no longer going to be running with Administrator privileges by default like they were doing on earlier platforms. This impacts your ability to run HTTP web services because listening at a particular HTTP address is a restricted operation. By default, every HTTP path is reserved for use by the system administrator. Your services will fail to start with an AddressAccessDeniedException if you aren’t running the service from an elevated account. Windows 2003 includes a tool called httpcfg.exe that lets the owner of an HTTP namespace delegate that ownership to another user. On Windows Vista, httpcfg.exe is no longer included and instead there’s a new command set available through netsh.exe.
I’m going to walk through delegating part of the HTTP namespace to get a web service working that wants to listen at http://localhost:8000/. Since I’m not running as the Administrator when debugging in Visual Studio, the service fails to start when I run it.
HTTP could not register URL http://+:8000/. Your process does not have access rights to
this namespace (see http://go.microsoft.com/fwlink/?LinkId=70353 for details).
The plus sign in the URL just means that there’s a wildcard being applied to the hostname. I’ll have another article that talks about wildcards in more detail. To fix this problem, I first need to start a command prompt using “Run as administrator” so that I have elevated privileges. Then, I can use netsh.exe to give some of the Administrator’s HTTP namespace to my user account. You can look at the existing HTTP namespace delegations by using “netsh http show urlacl”. There should be several namespaces set up by default, including the default one that WCF uses for temporary addresses as an example.
Reserved URL : http://+:80/Temporary_Listen_Addresses/
Now, I’m going to use “netsh http add urlacl url=http://+:8000/ user=MYMACHINE\UserName” to assign some of the HTTP namespace to my user account. You can get the syntax for all of these commands by running “netsh http” without any arguments. Note that I’ve matched the URL in this command to the URL that appeared in the error message. The wildcarding is important for getting the right reservation and you’ll continue to be denied access if your reservation covers less than your service’s attempted registration. Going back to Visual Studio, my service now starts up and runs as expected.
For more details on netsh options, see the article on namespace reservation permissions.
Next time: TransportWithMessageCredential Over TCP