Hosting

patterns & practices Developer Center

  • How do I configure a least-privileged account to host my service?
  • When should I host my service in IIS?
  • When should I host my service in a Windows service?
  • When should I self-host my service?

How do I configure a least-privileged account to host my service?

Perform the following steps to create a least-privileged account for your service:

  1. Create a Windows account.

  2. Run the following aspnet_regiis.exe command to assign the relevant ASP.NET permissions to the account:

    aspnet_regiis.exe -ga machineName\userName 
    
  3. If your application needs to run in ASP.NET compatibility mode, use the Local Security Policy tool to grant the Windows account the Deny logon locally user right. This reduces the privileges of the account and prevents anyone from logging onto Windows locally with this account. Otherwise, skip this step.

  4. Use the least-privileged account to run your WCF service:

    • If your service is hosted in IIS 6.0, use IIS Manager to create an application pool running as an account identity. Use IIS Manager to assign your WCF service to that application pool.
    • If your service is hosted in a Windows service, configure the Windows service to run using the account identity. The WCF service will run under the security context of the Windows service.

Additional Resources

When should I host my service in IIS?

Use IIS to host your WCF service, unless you need to use a transport that IIS does not support. IIS provides a large number of features for efficient service management and scalability. By using IIS as your WCF service host, you can take full advantage of IIS features such as process recycling, idle shutdown, process health monitoring, and message-based activation.

IIS 5.0 and 6.0 only support bindings over HTTP, so if you need to use TCP, MSMQ, or named pipes, you should host in a Windows service instead.

IIS 7.0 supports all the commonly used transport protocols such as HTTP, TCP, MSMQ, and named pipes.

Additional Resources

  • For more information, see Hosting.

When should I host my service in a Windows service?

You should use a Windows service when you have to support transports such as TCP, MSMQ, and named pipes and you do not yet have IIS 7.0. Windows services offer advantages over self-hosting in that they give the benefit of automatic startup; service lifetime is controlled by the operating system; it is easier to run under a least-privileged account; and the Windows service host will restart your service if it fails. Windows services can be managed in the Service Control Manager in the Microsoft Management Console (MMC).

The drawback of using a Windows service compared to IIS is that Windows services have limited features to support availability, manageability, and deployment, so you will have to write custom code to support these features. For instance, you will need to add an installer to your service so that it can be installed on the system.

Additional Resources

  • For more information, see Hosting.

When should I self-host my service?

Self-hosting should only be used for development and demonstration purposes because it is not suitable for a production scenario. Similar to using a Windows service, self-hosting can be used with any transport and therefore provides binding flexibility beyond the capabilities of IIS 5.0 or IIS 6.0. Self-hosting is also the easiest hosting mechanism to get up and running, furthering its usefulness in a development environment. The drawback of self-hosting compared to a Windows service is that service lifetime is controlled by the self-hosted application rather than by the operating system, which makes it more difficult to run under a least-privileged account, and there is no automatic recovery in the case of failure.

Additional Resources

  • For more information, see Hosting.