What is the best practice for setting user service runs under when automating service deployment?

We are trying to automate the deployment of some of the services that we create. We don't want to hard code the user name and password into the application installer. The problem with not hardcoding usernames and logins is that it makes automation of the release problematic.

How would you go about packaging a wind开发者_StackOverflow中文版ows service in an msi such that:

1. The service is installed to run under a particular user name, depending on the environment instance. i.e. in Production it runs under DOMAIN_NAME\ProductionServiceUser, but if we deploy the same service into staging the service runs under DOMAIN_NAME\StagingServiceUser.

2. If you uninstall the service via "Add Remove Programs", the service is removed.

---

To automatically install and uninstall the service you can use the Windows Installer support:

• http://msdn.microsoft.com/en-us/library/windows/desktop/aa371637(v=vs.85).aspx
• http://msdn.microsoft.com/en-us/library/windows/desktop/aa371634(v=VS.85).aspx

Visual Studio setup projects do not support the service tables. So if you are using it, you will need to write install and uninstall custom actions which manage the service. Other setup authoring tools offer direct support for services.

To dynamically set the service account you can use a custom installer property, for example SERVICE_ACCOUNT. During install you can set this property to the account you want. This can be done in multiple ways: custom actions, dialog controls, command line etc.

Services can run under a custom user account only if the log on as a service policy is set for it, even if it's an Administrator account. This policy can be set during install by using ntrights.exe as a custom action.