This is a first for me. I have created Windows EXE which edits some configuration items for a Windows Service. It puts some information on the file system, it uses folder shares, and verifies a connection string by connecting to a database. I chose to do this as an EXE because besides doing it as a custom action in the COMMIT of my deployment, I also make it available from the start menu for the user. On my own I managed to figure out to set InstallerClass = False as a property of the custom action.

The problem I am having is that nearly everything it tries to do, including using the folder shares, and connection to the database fail because the context of the EXE is NOT the user who ran the setup, but rather DOMAIN\COMPUTER$ which apparently doesn't have the privileges needed.

Is there some way to get my EXE to run in the context of the user running the installation instead? When you write custom action EXE's how do most of you deal with this limited permission? It would seem most things an installer might do would have these issues.

Thanks!

---

Online Data Processing, Inc. - Spokane, WA

VS 2008 setups do this because it's pretty much the only way to get custom actions to work on UAC systems. If they worked by impersonating the installing user then even if you were an administrator they would run with limited privilege. Running under SYSTEM means they work on Vista. Visual Studio setups are not fully-featured and one opf the things you can't do with th IDE is choose whether you want impersonation or not.

But yes, the SYSTEM account often does not have network privileges are access to shares (which are user based, not system-wide).

So if you run with the acccount of the installing user your setup will not work on UAC systems if what it does requires admin privileges.

This kind of thing is why I usually recommend getting away from custom actions during the install. You have the config program as a separate program - the kind of thing you need in your app is for it to check whether it's configured or not when the user first runs it, and then fire off the configuration program.

If you want to change the impersonation for the custom action, you'd have to use Orca to edit the MSI file, and remove themsidbCustomActionTypeNoImpersonate bit (the bit that adds 2048 to the type).

---

Phil Wilson

VS 2008 setups do this because it's pretty much the only way to get custom actions to work on UAC systems. If they worked by impersonating the installing user then even if you were an administrator they would run with limited privilege. Running under SYSTEM means they work on Vista. Visual Studio setups are not fully-featured and one opf the things you can't do with th IDE is choose whether you want impersonation or not.

But yes, the SYSTEM account often does not have network privileges are access to shares (which are user based, not system-wide).

So if you run with the acccount of the installing user your setup will not work on UAC systems if what it does requires admin privileges.

This kind of thing is why I usually recommend getting away from custom actions during the install. You have the config program as a separate program - the kind of thing you need in your app is for it to check whether it's configured or not when the user first runs it, and then fire off the configuration program.

If you want to change the impersonation for the custom action, you'd have to use Orca to edit the MSI file, and remove themsidbCustomActionTypeNoImpersonate bit (the bit that adds 2048 to the type).

---

Phil Wilson