Today, I’ve been working with my build team to get setup packages built for our current project. I have to admit, I’ve never really had to deal with installers before. I’ve either worked on small packages where I could use a click-once deployment or I’ve been working on really big projects with a dedicated build team. I’d hand off my code by checking it into source control. My current project is a bit different because I’m doing the architecture, leading the day-to-day development, and doing all of the hiring/firing bits too AKA management.
Anyway… One issue we had today was this:
An exception occurred during the Install phase.
System.ComponentModel.Win32Exception: No mapping between account names and security IDs was done
The issue is that the serviceProcessInstaller1 (default name) is using a user account during the install.
Oops.
Here is a quick overview of Service Accounts from the Microsoft site:
Each service executes in the security context of a user account. The user name and password of an account are specified by the CreateService function at the time the service is installed. The user name and password can be changed by using the ChangeServiceConfig function. You can use the QueryServiceConfig function to get the user name (but not the password) associated with a service object. The service control manager (SCM) automatically loads the user profile.
When starting a service, the SCM logs on to the account associated with the service. If the log on is successful, the system produces an access token and attaches it to the new service process. This token identifies the service process in all subsequent interactions with securable objects (objects that have a security descriptor associated with them). For example, if the service tries to open a handle to a pipe, the system compares the service’s access token to the pipe’s security descriptor before granting access.
The SCM does not maintain the passwords of service user accounts. If a password is expired, the logon fails and the service fails to start. The system administrator who assigns accounts to services can create accounts with passwords that never expire. The administrator can also manage accounts with passwords that expire by using a service configuration program to periodically change the passwords.
If a service needs to recognize another service before sharing its information, the second service can either use the same account as the first service, or it can run in an account belonging to an alias that is recognized by the first service. Services that need to run in a distributed manner across the network should run in domain-wide accounts.
So?
You need to set the user account to fit your needs. You can do it through code as discussed above or you can do it inside the ProjectInstaller.cs [Design] screen in Visual Studio.
Open the design view, then click once on “serviceProcessInstaller1”. Next right-click and select properties.

There are 4 options for which account you want to use.

User (default)
Since the this is the default and the existing setup doesn’t work, this might not be the best option for you.
Why is this a problem? This account selection loads the service as the current user which may or may not be what you want. When you are running/installing the service on your dev machine everything installs as admin, because that’s the context you are running in. Which is fine. But when you try to install the service via an install package on a different computer your runtime security context might be different.
LocalService
From Microsoft
The LocalService account is a predefined local account used by the service control manager. This account is not recognized by the security subsystem, so you cannot specify its name in a call to the LookupAccountName function. It has minimum privileges on the local computer and presents anonymous credentials on the network.
NetworkService
From Microsoft
The NetworkService account is a predefined local account used by the service control manager. This account is not recognized by the security subsystem, so you cannot specify its name in a call to the LookupAccountName function. It has minimum privileges on the local computer and acts as the computer on the network.
LocalSystem
From Microsoft
The LocalSystem account is a predefined local account used by the service control manager. This account is not recognized by the security subsystem, so you cannot specify its name in a call to the LookupAccountName function. It has extensive privileges on the local computer, and acts as the computer on the network. Its token includes the NT AUTHORITY\SYSTEM and BUILTIN\Administrators SIDs; these accounts have access to most system objects. The name of the account in all locales is .\LocalSystem. The name, LocalSystem or ComputerName\LocalSystem can also be used. This account does not have a password. If you specify the LocalSystem account in a call to the CreateService or ChangeServiceConfig function, any password information you provide is ignored.
For my project: we’re moving data between servers with WCF, running an MSMQ service, and reading/writing files from the local file system. We picked “LocalSystem” for our account.

Problem solved.
References:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms686005(v=VS.85).aspx