I work for a company that operates in a locked-down environment. When the users wants to install software they execute a distribution tool. This tool impersonates a user with administrative proviliges. The installations are all per-user. My problem is that the user specific details such as the shortcuts, HKCU etc are all installed under the administrators account. How can I while impersonating an administrator install to the currently logged on users profile? All suggestions and tips are welcome........
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.
Per-User Installs
Started by
nerram
, Dec 18 2003 17:37
10 replies to this topic
Scotsmanscott
-
- Members
- 20 posts
Posted 18 December 2003 - 18:13
What you're doing doesn't make any sense!
If you install a package per-user (ALLUSERS=NULL) for an admin user, you're not supplying the application to the user.
If however, you installed the package per-machine (ALLUSERS=1) as an admin, that would make sense.
Alternatively, use the "AlwaysInstallElevated" policy.
If you install a package per-user (ALLUSERS=NULL) for an admin user, you're not supplying the application to the user.
If however, you installed the package per-machine (ALLUSERS=1) as an admin, that would make sense.
Alternatively, use the "AlwaysInstallElevated" policy.
nerram
-
- Members
- 7 posts
Posted 18 December 2003 - 18:31
The distribution tool works in this manner and I cant avoid this no matter how nonsensical it is. What I want is a way in the MSI to install the per-user information to the currently logged on user and not the user who is actually installing the application. Is this possible?
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 18 December 2003 - 19:42
Then you have to give this user admin rights. Or set the AlwaysInstallElevated policy. or assign the software to the user via group policy.
Stefan Krüger
InstallSite.org twitter facebook
nerram
-
- Members
- 7 posts
Posted 18 December 2003 - 20:00
The distribution tool will always impersonate the same administrative users profile. This distribution tool is installing software on behalf of the user. The users them selves must always operate in a locked down environment. Giving the users admin rights/elevated privileges wont help as the only way they can access the installations is through the distribution tool. Plus the due to security issues the LSA will not grant these premissions. What I am hoping for is that there could be some way to use the Currenly logged on users SID to rigth the HKCU keys to their account rather than the distribution tool account. Also I need to write the shortcuts to the currently logged on users profile and not the distribution tools account.
Glytzhkof
-
- Moderators
- 1,447 posts
Posted 19 December 2003 - 00:56
It really sounds like you need to use the MSI features to run with elevated rights if you want this to work smoothly. This would involve assigning the MSI to the user using active directory (as Stefan already wrote).
An alternative to this is to install the software per-machine, but with user specific data. This is what we are doing. We set key paths for user specific component to a HKCU registry key. What happens in this scenario is that when any user who didn't install the application invokes the advertised shortcut for our application windows installer will kick in to "repair" the missing HKCU settings. This will cause the install to run again in self-repair mode and install user specific data. You should condition custom actions that require admin rights with the property "AdminUser" to ensure that self-repair mode works without error messages. If your user will have elevated priviledges during self-repair you can use the "Priviledged" property instead of "AdminUser".
An alternative to this is to install the software per-machine, but with user specific data. This is what we are doing. We set key paths for user specific component to a HKCU registry key. What happens in this scenario is that when any user who didn't install the application invokes the advertised shortcut for our application windows installer will kick in to "repair" the missing HKCU settings. This will cause the install to run again in self-repair mode and install user specific data. You should condition custom actions that require admin rights with the property "AdminUser" to ensure that self-repair mode works without error messages. If your user will have elevated priviledges during self-repair you can use the "Priviledged" property instead of "AdminUser".
Regards
-Stein Åsmul
-Stein Åsmul
nerram
-
- Members
- 7 posts
Posted 19 December 2003 - 10:00
This company operates in a multi-user environment. Only the user who installs the software should see the shortcuts. So putting shortcuts in the allusers profile wont work.
Scotsmanscott
-
- Members
- 20 posts
Posted 19 December 2003 - 11:19
In that case, you'll need a custom solution... Maybe rebuilding the Start Menu at logon based on group memberships (login script or something)?
But then you'll still have the issue of file associations and other advertising information.
Also, users could still potentially run the applications directly from the application folder.
I'd say your fancy inhouse tool should flip the "AlwaysInstallElevated" keys on and off at installation time (using your admin account). The only drawback is that your tool might crash, and leave the policy enabled.
But then you'll still have the issue of file associations and other advertising information.
Also, users could still potentially run the applications directly from the application folder.
I'd say your fancy inhouse tool should flip the "AlwaysInstallElevated" keys on and off at installation time (using your admin account). The only drawback is that your tool might crash, and leave the policy enabled.
nerram
-
- Members
- 7 posts
Posted 19 December 2003 - 12:08
"The only drawback is that your tool might crash, and leave the policy enabled."
This is the major issue. By the way I need never describe this tool as a "fancy inhouse tool" but more so as a piece of crap.
This is the major issue. By the way I need never describe this tool as a "fancy inhouse tool" but more so as a piece of crap.
Glytzhkof
-
- Moderators
- 1,447 posts
Posted 19 December 2003 - 19:00
In my humble opinion, this discussion shows that you should really make your setup run with elevated rights and assign it to the user through active directory. Only that way you will be able to make it a truly user-specific setup without giving the user admin rights.
I would read up on windows installer, elevated rights and active directory deployment if I were you.
I would read up on windows installer, elevated rights and active directory deployment if I were you.
Regards
-Stein Åsmul
-Stein Åsmul
felix
-
- Members
- 5 posts
Posted 16 February 2004 - 13:25
Believe I'm working on a similiar problem but approaching it from a different angle.
Personnally I feel that the per-user attack on the problem doesn't really solve the problem. We're (narrem and myself) having to use NetInstall so if anyone is really familiar with how it handles the various situations I'm going to discribe please let us know if we've understood it correctly.
Firstly installs can be assigned on a Machine or User basis. Additionally Travelling User Support is for roaming profiles. It allows for each installation to be split between user and machine parts, in fact as I understand it, it really forces this option.
For the sake of clarity I'm going to identify when I'm talking about assigning the installation to be run specific machines for specific users I'll refer to it as assigning. For installing as the machine or user split I'll refer to them as machine/user part. NetInstall is confusing because it refers to Per-Machine and Per-User installs for the assigning of software to machines/users.
If you install an msi using the default command to perform it as the machine part this will be installed with a local admin account using ALLUSERS=1 (Windows Installer per-machine).
If you install an msi using the command to install it as the user part it will be installed with the user account process using ALLUSERS="" (Windows Installer per-user). You also get granted elevated privileges through the use of AlwaysInstallElevated=1 for the duration of the installation and then it is removed.
Assumptions based on current understanding of NetInstall
User1 installs an application on Machine1 using NetInstall.
User1 moves to Machine2. NetInstall will only install the machine part on Machine2 because it recognises that the user already has the user part install due to installing the same installation on Machine1.
Case 1: we work with the msi's until they can be installed as the user part (i.e. ALLUSERS=""). User1 goes to Machine2 but NetInstall will not reinstall the msi because it thinks that the user part is already installed and there is no machine part even though files for under Program Files are in the msi. Additionally requires some rather severe modification of vendor msi's to get around their requirements. Also self repair will not function once the AlwaysInstallElevated key is removed.
Case 2: We install the msi's as the machine part (i.e. ALLUSERS=1) which handles the problem of installing vendor msi's and self-repair will work file. but now all profile files will go to the allusers profile along with the shortcuts. Additionally the shortcuts will be visible even to users that won't be able to use the applications (we will be setting permissions on the installation directories to prevent users not in the correct group from accessing the installation directory of this application)
Now to whats required.
1) To perform installations so that the shortcuts are only visible to the users installing.
2) To be able to install various Vendor MSI's (most require Administrative privilegs to be able to run various custom actions that the vendor requires for their application to install correctly.)
3) Carry out the installs in such a method so that the roaming profiles support available with NetInstall will function.
My Suggestion: 2 step solution
step 1:
We install the msi's as the machine part of the installation but use "Set Property" custom actions to change the default directory paths for all directories under the Allusers profile to point to the current user profile (installing user profile). In this case they will go to the local system account of NetInstall.
step 2:
We reinstall/repair the msi's as the user part of the installation. Again this use's the "Set Property" custom actions described above. Normally this would be a Windows Installer per-user installation due to ALLUSERS="" being set by NetInstall, however Windows Install will override this to 1 since the msi is already installed per-machine. This should mean that now the shortcuts are added to the user's profile (in this case the current user will be the logged on user instead of the local system account as was previously.)
Concerns/Questions to be answered:
While I'm investigating this and I'm hopeful that there should be no negative impact to advertising/self-repair, I would appreciate any experiences by anyone else as to whether changing the creation location of the shortcuts/user files whether this will cause any problems with Windows Installer. Or any other views as to what this is thought of as a solution to deal with the problem without causing too much work.
Personnally I feel that the per-user attack on the problem doesn't really solve the problem. We're (narrem and myself) having to use NetInstall so if anyone is really familiar with how it handles the various situations I'm going to discribe please let us know if we've understood it correctly.
Firstly installs can be assigned on a Machine or User basis. Additionally Travelling User Support is for roaming profiles. It allows for each installation to be split between user and machine parts, in fact as I understand it, it really forces this option.
For the sake of clarity I'm going to identify when I'm talking about assigning the installation to be run specific machines for specific users I'll refer to it as assigning. For installing as the machine or user split I'll refer to them as machine/user part. NetInstall is confusing because it refers to Per-Machine and Per-User installs for the assigning of software to machines/users.
If you install an msi using the default command to perform it as the machine part this will be installed with a local admin account using ALLUSERS=1 (Windows Installer per-machine).
If you install an msi using the command to install it as the user part it will be installed with the user account process using ALLUSERS="" (Windows Installer per-user). You also get granted elevated privileges through the use of AlwaysInstallElevated=1 for the duration of the installation and then it is removed.
Assumptions based on current understanding of NetInstall
User1 installs an application on Machine1 using NetInstall.
User1 moves to Machine2. NetInstall will only install the machine part on Machine2 because it recognises that the user already has the user part install due to installing the same installation on Machine1.
Case 1: we work with the msi's until they can be installed as the user part (i.e. ALLUSERS=""). User1 goes to Machine2 but NetInstall will not reinstall the msi because it thinks that the user part is already installed and there is no machine part even though files for under Program Files are in the msi. Additionally requires some rather severe modification of vendor msi's to get around their requirements. Also self repair will not function once the AlwaysInstallElevated key is removed.
Case 2: We install the msi's as the machine part (i.e. ALLUSERS=1) which handles the problem of installing vendor msi's and self-repair will work file. but now all profile files will go to the allusers profile along with the shortcuts. Additionally the shortcuts will be visible even to users that won't be able to use the applications (we will be setting permissions on the installation directories to prevent users not in the correct group from accessing the installation directory of this application)
Now to whats required.
1) To perform installations so that the shortcuts are only visible to the users installing.
2) To be able to install various Vendor MSI's (most require Administrative privilegs to be able to run various custom actions that the vendor requires for their application to install correctly.)
3) Carry out the installs in such a method so that the roaming profiles support available with NetInstall will function.
My Suggestion: 2 step solution
step 1:
We install the msi's as the machine part of the installation but use "Set Property" custom actions to change the default directory paths for all directories under the Allusers profile to point to the current user profile (installing user profile). In this case they will go to the local system account of NetInstall.
step 2:
We reinstall/repair the msi's as the user part of the installation. Again this use's the "Set Property" custom actions described above. Normally this would be a Windows Installer per-user installation due to ALLUSERS="" being set by NetInstall, however Windows Install will override this to 1 since the msi is already installed per-machine. This should mean that now the shortcuts are added to the user's profile (in this case the current user will be the logged on user instead of the local system account as was previously.)
Concerns/Questions to be answered:
While I'm investigating this and I'm hopeful that there should be no negative impact to advertising/self-repair, I would appreciate any experiences by anyone else as to whether changing the creation location of the shortcuts/user files whether this will cause any problems with Windows Installer. Or any other views as to what this is thought of as a solution to deal with the problem without causing too much work.