The recommended way is to add an URL registration for the service account in question:

netsh http add urlacl url="http://+:9997//Services/HashGenerationService" user="your-domain\service-account"

Derik,

That's interesting.

I do something similar with my current project: We register IWcfService<T> in the container and resolve all implementations during service startup. I also have a deployment script that registers the URL reservation before installing/starting the service. (We deploy our solution with MSDeploy and run that script post-update.)

An option might be to have a shared base address that's reserved and there to run all your services under, like http://+:9997/Services. Service instances would only have to specify the relative part, like /HashGenerator, etc.

As for running services under LocalSystem, I would definitely not want that from an administrative perspective. If I were the admin I would like to lock down services to run under the least privileges possible. We also use NTLM exclusively to connect to SQL Server. Having LocalSystem access databases is, IMHO, scary and (again from an administrative point of view) a smell.

Alex

Derik-- I concur with Alex's point. You want the reservation for the URL space that a given identity can own. While I appreciate the fact that you are using a plugin architecture, this is a case where you need to leak the abstraction a bit in order to keep some semblance of security in your app.

You can also use some of the sample code provided here blogs.msdn.com/.../addressaccessdeniedexception-http-could-not-register-url-http-8080.aspx

and use the HttpNamespaceManager to add your current namespace for the user who is running the servicehost.