2 replies to this topic

[Taco Bell]

I don't want to touch an MSI-based product with a ten foot pole, but I'm being asked too look into this.  Plus, if I did go that route, then I would use IS Developer 8, so here I am with some questions.

1. One of the tauted benefits of a Windows Installer-based setup is that it can run with elevated level of priveleges, thereby removing the Administrator requirement.  That's all well & good and the main reason it's being considered, but what about external programs that I call during installation.  Do they in turn pick up these same evelated priveleges?  Even if that external program is an old InstallScript-based InstallShield setup?  I know a Run As under Windows would do it right, but what about MSI?

2. Does Developer 8 have a built-in method for changing file/directory permissions?  And if so, does that only apply to your setup's data files/directories, existing files/directories, or both?  I'm asking because I need to do expose write priveleges to Power Users for Windows lmhosts file.  In lieu of Windows XP, I also need to give Full Control to Users for our old product's installation directory.

Let me know on both please, despite my bias/opinions, and thanks in advance.

[Stefan Krueger]

1. You can optinally run a custom action (which could be an exe) with such elevated privileges. I'm not sure how good this will work with another InstallShield setup, because it's setup.exe in turn launches another process...

Note that in order to get elevated privileges, the Administrator must either allow this (for all MSI based setups) in a policy, or he must advertise or assign the package to that machine or user (e.g. using Active Directory). If he does neither, your setup will not receive elevated privileges (else this would open a big security hole)

2. There are built in ways to specify permissions of files you install. In order to change permissions on existing files you would have to call a custom action (I think there's a command line tool to do such things)

[Taco Bell]

Thanks for the reply Stefan.  I always appreciate your experienced insight.  I also figured the elevated privileges to be a security risk, but hadn't seen anyone mention how actually came into play.  Thanks again.