6 replies to this topic

[sarbaree]

i want to install a windows service under a particular user account. i can hardcode it in the IDE by entering the details in the advanced settings option of NT services. but i want that the user should be able to enter the domain\username and password and the service shd be logged under that particular name.

this is very urgent. any help would be appreciated.

btw i am using basic MSI project. i have tried to include the dialog "logoninformation" but it is not accepting the credentials.

please help..

[jmcallister80]

Group: Full Members
Posts: 1
Member No.: 13782
Joined: 2007-06-06



I spent quite a bit of time hunting this one down as well. There may be other ways to do it but the basic idea is to create a new dialog which will prompt the user for the login credentials that you want to run the service as. Those credentials will be piped into a PROPERTY, which you then read via an installscript custom action, and add the service using the following calls:

ServiceAddService ( szServiceName, szServiceDisplayName, szServiceDescription, szServicePathFile, bStartService, szStartServiceArgs );

Something like this:

nResult = MsiGetProperty(hMSI, "UserName",szUserName, nSize);
nResult = MsiGetProperty(hMSI, "Password",szPassword, nSize);

ServiceInitParams ();
SERVICE_IS_PARAMS.dwServiceType = SERVICE_WIN32_OWN_PROCESS;
SERVICE_IS_PARAMS.lpServiceStartName = szUserName;
SERVICE_IS_PARAMS.lpPassword = szPassword;

nReturn = ServiceAddService ( szServiceName, szServiceDisplayName, szServiceDescription, szFileName, bStartService, szStartServiceArgs );

[Stefan Krueger]

@jmcallister80: why are you using a custom action to create the service? The ServiceInstall table should support properties in the StarName and Password columns.

[jmcallister80]

I recommended the CA for a couple of reasons:

1. I am not a fan of referencing a property in an obscure place

2. It makes theinstallation source hard to debug when there is a problem and your not familiar with what methods the person used to create the kit

3. It is a more stright forward to read from the kit, meaning less tracing that has to be done to see which property is passed where, and in what dialog sequence.

Granted passing a property to the service control, is a way to do it but it makes for a more complex kit that is hard to debug.

[Stefan Krueger]

I'm sorry, but I completely disagree. The ServiceInstall table is documented, it's not obscure in any way. Using the standard tables makes your package transparent and self-explaining, thus easier to handle for administrators. Custom actions should be limited to situation where Windows Installer doesn't have a way to do things. Replacing Windows Installer' built in capabilities with a custom action is typically a bad idea.

[jmcallister80]

I stand corrected. After doing a bit of research on this your method is more 'standard'. I apologize for my incorrectness.

[Glytzhkof]

This is a very common misunderstanding and it has to do with the overall "uniqueness" of MSI. There are a lot of features in MSI that work very differently from anything most people have experience with, but by using them you typically get a lot of functionality "for free" which would otherwise have to be coded into the custom action.