Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

how to install a service to a user account


6 replies to this topic

sarbaree

sarbaree
  • Full Members
  • 2 posts

Posted 06 June 2007 - 09:37

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.. huh.gif

jmcallister80

jmcallister80
  • Full Members
  • 4 posts

Posted 06 June 2007 - 13:36






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 );



Adventures In Technology - Development and Technology Blog
http://www.adventuresintechnology.net

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 06 June 2007 - 23:24

@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

jmcallister80
  • Full Members
  • 4 posts

Posted 07 June 2007 - 13:31

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.
Adventures In Technology - Development and Technology Blog
http://www.adventuresintechnology.net

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 08 June 2007 - 09:29

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

jmcallister80
  • Full Members
  • 4 posts

Posted 11 June 2007 - 15:57

I stand corrected. After doing a bit of research on this your method is more 'standard'. I apologize for my incorrectness.
Adventures In Technology - Development and Technology Blog
http://www.adventuresintechnology.net

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 12 June 2007 - 06:30

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.
Regards
-Stein Åsmul