D
Darragh Bailey
Currently we're trying to have all our installations work as per-user
installations which is fine if we create them.
But in the case where we're using msi's created by various different
vendors a large proportion of them are not designed to work as
per-user installs or attempt to perform some configuration of the
machine using a custom action that the user simply doesn't have
permissions to do, even if they are installing with elevated
permissions.
Installing per-machine does deal with some of the permissions issues
for actions such as SelfRegModules, SelfUnRegModules, & defered custom
actions but this doesn't really solve the problem as there are many
other custom actions that vendors seem to like to use (InstallScripts,
and various dll's are often encountered) and will result in the
shortcuts appearing in the Allusers profile which isn't very useful
and in cases where other users log on and don't have access to the
application (we set permissions on the application installation folder
to restrict those that can run it.) will try to run the application
and receive an error since they cannot access the install directory.
What we need is the ability to be able to have the msi's installed
where they receive permissions similar to an Administrator (no
problems then with custom actions) but at the same time we want to be
able if possible to redirect the user profile information (registry,
files, windows installer reg keys) to the currently logged on user. My
view is that for normal users, self repair wouldn't work in the future
unless the msi was installed per-machine.
So anyone got any suggestions on how to have the msi's install with
sufficient permissions to allow the various custom actions in vendor's
msi's such ISSelfReg table actions, system configuration by dll's etc,
and at the same time have all the profile information to go to the
logged on user without breaking the self-repair or advertising in the
msi. Definitely having the Vendor's redo their msi's so that they
could be successfully installed per-user by elevated users would be
the nicest option but not always available.
Personally I think that doing a per-machine install via an admin
process and have a script/custom action to redirect the likes of the
shortcuts and user keys to the user profile without breaking* the
self-repair/advertisement features of Windows Installer and then just
repairing via a distribution tool it for each user that logs on
adterwards to install the shortcuts and registry information for that
user would be the best way.
(*) we want the self-repair & advertisement to work so what I want to
know is this possible to do without breaking these? The main issue
with per-users installs are the restricted permissions they run under
and the fact that if your distribution tool uses the
AlwaysInstallElevated=1 for just the duration of the install and then
remove it, self-repair won't work for the users. On the other side if
you do a per-machine install, the self-repair will work for the users
but it will use the allusers profile so that the shortcuts are visible
to any user logging onto that machine.
installations which is fine if we create them.
But in the case where we're using msi's created by various different
vendors a large proportion of them are not designed to work as
per-user installs or attempt to perform some configuration of the
machine using a custom action that the user simply doesn't have
permissions to do, even if they are installing with elevated
permissions.
Installing per-machine does deal with some of the permissions issues
for actions such as SelfRegModules, SelfUnRegModules, & defered custom
actions but this doesn't really solve the problem as there are many
other custom actions that vendors seem to like to use (InstallScripts,
and various dll's are often encountered) and will result in the
shortcuts appearing in the Allusers profile which isn't very useful
and in cases where other users log on and don't have access to the
application (we set permissions on the application installation folder
to restrict those that can run it.) will try to run the application
and receive an error since they cannot access the install directory.
What we need is the ability to be able to have the msi's installed
where they receive permissions similar to an Administrator (no
problems then with custom actions) but at the same time we want to be
able if possible to redirect the user profile information (registry,
files, windows installer reg keys) to the currently logged on user. My
view is that for normal users, self repair wouldn't work in the future
unless the msi was installed per-machine.
So anyone got any suggestions on how to have the msi's install with
sufficient permissions to allow the various custom actions in vendor's
msi's such ISSelfReg table actions, system configuration by dll's etc,
and at the same time have all the profile information to go to the
logged on user without breaking the self-repair or advertising in the
msi. Definitely having the Vendor's redo their msi's so that they
could be successfully installed per-user by elevated users would be
the nicest option but not always available.
Personally I think that doing a per-machine install via an admin
process and have a script/custom action to redirect the likes of the
shortcuts and user keys to the user profile without breaking* the
self-repair/advertisement features of Windows Installer and then just
repairing via a distribution tool it for each user that logs on
adterwards to install the shortcuts and registry information for that
user would be the best way.
(*) we want the self-repair & advertisement to work so what I want to
know is this possible to do without breaking these? The main issue
with per-users installs are the restricted permissions they run under
and the fact that if your distribution tool uses the
AlwaysInstallElevated=1 for just the duration of the install and then
remove it, self-repair won't work for the users. On the other side if
you do a per-machine install, the self-repair will work for the users
but it will use the allusers profile so that the shortcuts are visible
to any user logging onto that machine.