All Users / Per User installs
I need to package Apple QuickTime 7.6.4 but am having some problems with the LocalAppDataFolder and ALLUSERS properties. In order to set some of the QuickTime preferences, you need to add a quicktime.qtp file to the LocalAppDataFolder\Apple Computer\QuickTime folder for each user.
I've setup an MST with the quicktime.qtp file in its own component. This component installs to the appropriate folder when run manually to test.
Obviously, the point of this is to create a deployable install, in our case using SCCM, which runs the install using the SYSTEM account.
As this file needs to exist for each user, I've setup an Active Setup configuration to the MSI that will run a repair on the MSI once for each user on logon. As quicktime.qtp is missing from their profile, the repair adds the file, again as expected.
The problem occurs when the user logging on is a local admin. In this case, the computer considers the install to be for all users, can see the file exists for the original installed account (SYSTEM) and therefore the repair fails to add the necessary file to the users profile. This occurs for both ALLUSERS=1 and ALLUSERS=2.
Using ALLUSERS=0 means that it only installs per user, so when I try to run a repair on the install, Windows Installer complains that the program isn't installed (because it's not for this user).
This is particularly frustrating as the setting is turning off the Auto Update feature which wouldn't work for regular users anyway, so we end up stopping users from doing something they couldn't anyway and still having all Admin's PCs do it automatically.
Is there a way around this other than creating a VBScript custom action that copies the file, rather than using the Windows Installer directly??
I've setup an MST with the quicktime.qtp file in its own component. This component installs to the appropriate folder when run manually to test.
Obviously, the point of this is to create a deployable install, in our case using SCCM, which runs the install using the SYSTEM account.
As this file needs to exist for each user, I've setup an Active Setup configuration to the MSI that will run a repair on the MSI once for each user on logon. As quicktime.qtp is missing from their profile, the repair adds the file, again as expected.
The problem occurs when the user logging on is a local admin. In this case, the computer considers the install to be for all users, can see the file exists for the original installed account (SYSTEM) and therefore the repair fails to add the necessary file to the users profile. This occurs for both ALLUSERS=1 and ALLUSERS=2.
Using ALLUSERS=0 means that it only installs per user, so when I try to run a repair on the install, Windows Installer complains that the program isn't installed (because it's not for this user).
This is particularly frustrating as the setting is turning off the Auto Update feature which wouldn't work for regular users anyway, so we end up stopping users from doing something they couldn't anyway and still having all Admin's PCs do it automatically.
Is there a way around this other than creating a VBScript custom action that copies the file, rather than using the Windows Installer directly??
0 Comments
[ + ] Show comments
Answers (16)
Please log in to answer
Posted by:
AutomateIT
14 years ago
I created a wise Script that the MST installs and also sets the active setup to be configured. All the script does is install the qtp file. I have not tested as local admin though.
Posted by:
brettski
14 years ago
Right you are dreyer ... but it still behaves the same way.
Sounds like you're using the same concept as I was thinking AutomateIT. You would have thought there would be some built in way to get Windows Installer to install user specific parts in each users profile, but I guess not.
Sounds like you're using the same concept as I was thinking AutomateIT. You would have thought there would be some built in way to get Windows Installer to install user specific parts in each users profile, but I guess not.
Posted by:
anonymous_9363
14 years ago
some way <snip> to install user-specific parts in each user's profileYou mean, as in installing to All Users, i.e. per-machine? :)
Posted by:
brettski
14 years ago
Nope, I don't mean per machine. Per machine will, or at least is in this case is, installing user specific parts (LocalAppDataFolder) into the LocalAppDataFolder\... of the user that installed the application (SYSTEM in this case), rather than the LocalAppDataFolder\... of the logged in user running the repair when the logged in user is an Admin on the PC.
When the logged in user is NOT an admin, and a repair is run on the install, the 'missing' files are installed to that user's LocalAppDataFolder\... as would be expected.
When the logged in user is NOT an admin, and a repair is run on the install, the 'missing' files are installed to that user's LocalAppDataFolder\... as would be expected.
Posted by:
AngelD
14 years ago
When the logged in user is NOT an admin, and a repair is run on the install, the 'missing' files are installed to that user's LocalAppDataFolder\... as would be expected.
Sounds like the common mistake from a beginner.
Set the keypath for the component to a HKCU registry entry instead of the file in the users profile.
Posted by:
PackageExpert
14 years ago
ORIGINAL: AngelD
Sounds like the common mistake from a beginner.
Set the keypath for the component to a HKCU registry entry instead of the file in the users profile.
yeap and when the admin user launches the shortcut, the corresponding files will be added during a self-repair. I don't see the necessity of Active Setup if your package has a advertised entry.
Posted by:
brettski
14 years ago
Ahhh, thank you very much, that's done the trick.
This does seem like a work around hack for a problem with Windows Installer. I can understand that certain special folders (desktop and start menu come to mind) that are shared between the %ALLUSERSPROFILE% and %USERSPROFILE% can be installed per machine, but surely Windows Installer should be smart enough to know that LocalAppDataFolder isn't shared and therefore look for the file in the running users profile.
Oh well, unless someone else knows a good reason why it behaves this way, I'll consider it a 'feature'.
Oh, and why it needs to be an Active Setup is that if the user launches a streamed file through the web, it's not launched via an Advertised shortcut.
This does seem like a work around hack for a problem with Windows Installer. I can understand that certain special folders (desktop and start menu come to mind) that are shared between the %ALLUSERSPROFILE% and %USERSPROFILE% can be installed per machine, but surely Windows Installer should be smart enough to know that LocalAppDataFolder isn't shared and therefore look for the file in the running users profile.
Oh well, unless someone else knows a good reason why it behaves this way, I'll consider it a 'feature'.
Oh, and why it needs to be an Active Setup is that if the user launches a streamed file through the web, it's not launched via an Advertised shortcut.
Posted by:
PackageExpert
14 years ago
ORIGINAL: brettski
This does seem like a work around hack for a problem with Windows Installer. I can understand that certain special folders (desktop and start menu come to mind) that are shared between the %ALLUSERSPROFILE% and %USERSPROFILE% can be installed per machine, but surely Windows Installer should be smart enough to know that LocalAppDataFolder isn't shared and therefore look for the file in the running users profile.
Quote from MSDN,
Files, .ini files, or shortcuts in per-user only directories are installed into a particular user's profile. Even if the user sets the ALLUSERS property for a per-machine installations, files, .ini files, or shortcuts in per-user only directories are not copied in to the "All Users" profile and are not available to other users. The per-user only directories do not vary with the ALLUSERS property. The following is a list of the per-user only directories:
AppDataFolder
FavoritesFolder
NetHoodFolder
PersonalFolder
PrintHoodFolder
RecentFolder
SendToFolder
MyPicturesFolder
LocalAppDataFolder
Therefore as AngelD mentioned, we create a random HKCU for that component if it doesn't exist so that it get's copied during a self heal or AS.
Posted by:
brettski
14 years ago
hmmm, so from what that's saying, LocalAppDataFolder ignores the ALLUSERS property and always install per-user. Why then do we need to add the HKCU registry key path? For example, in QuickTime, there is a file being installed to [LocalAppDataFolder]Apple Computer\QuickTime.
For a standard user, a repair will correctly determine that QuickTime.qtp is missing and add the file to that folder.
For an admin user, a repair will NOT add the file to that folder.
If LocalAppDataFolder is always consider to be per-user as MSDN states, then the repair should be looking at the logged on user's profile, seeing that the file is not there an adding it, the same as it does for the non-admin user. I'm obviously missing something here [&:]
For a standard user, a repair will correctly determine that QuickTime.qtp is missing and add the file to that folder.
For an admin user, a repair will NOT add the file to that folder.
If LocalAppDataFolder is always consider to be per-user as MSDN states, then the repair should be looking at the logged on user's profile, seeing that the file is not there an adding it, the same as it does for the non-admin user. I'm obviously missing something here [&:]
Posted by:
PackageExpert
14 years ago
ORIGINAL: brettski
Why then do we need to add the HKCU registry key path?
so that any user wanting to use the application, gets the user profile files and HKCU settings when the self repair mechanism takes place....
hmmm, so from what that's saying, LocalAppDataFolder ignores the ALLUSERS property and always install per-user.
Yes
If LocalAppDataFolder is always consider to be per-user as MSDN states, then the repair should be looking at the logged on user's profile, seeing that the file is not there an adding it, the same as it does for the non-admin user.
What switches you implement for your AS? Perhaps try Msiexec /fpu <ProductCode>
Posted by:
brettski
14 years ago
OK, I've re-created my MST to what I had before adding the HKCU with key path set. What I now have is a component with a single file and its destination is set for [LocalAppDataFolder]Apple Computer\QuickTime. This file is set as a key path and the shortcut is Advertised. I'm installing the MSI /MST using SYSTEM to replicate what happens with SCCM.
Once it's installed, using my Admin account, I look at %userprofile%\Local Settings\Application Data\Apple Computer\QuickTime\ and QuickTime.qtp is missing as expected as it's been installed as SYSTEM, not my account. When run the shortcut, Quicktime does it's usual setup stuff (not self repair) which includes adding a default QuickTime.qtp file in if it does not exist. I can tell that this is not my file though as AutoUpdate has not be disabled.
If I log off and back on so that Active Setup runs (msiexec /fd {Product Code}), repair will run, but the file will not be either created if it doesn't exist or replace if it does. Using the HKCU method does result in the file to be replaced as part of the Active Setup repair.
Now, if I log on with a Non-Admin account (having removed the Active Setup registry entry) and try running QuickTime, it will perform a Windows Installer self repair and AutoUpdates will be disabled.
As you can see, there is a difference in behaviour based on if the logged on user is an Admin or Standard User.
Going back to what MSDN stated, LocalAppDataFolder should always behave per-user. Therefore, if %userprofile%\Local Settings\Application Data\Apple Computer\QuickTime\QuickTime.qtp is missing when QuickTime runs, Windows Installer SHOULD perform a self repair as it does for a Non-Admin user.
Once it's installed, using my Admin account, I look at %userprofile%\Local Settings\Application Data\Apple Computer\QuickTime\ and QuickTime.qtp is missing as expected as it's been installed as SYSTEM, not my account. When run the shortcut, Quicktime does it's usual setup stuff (not self repair) which includes adding a default QuickTime.qtp file in if it does not exist. I can tell that this is not my file though as AutoUpdate has not be disabled.
If I log off and back on so that Active Setup runs (msiexec /fd {Product Code}), repair will run, but the file will not be either created if it doesn't exist or replace if it does. Using the HKCU method does result in the file to be replaced as part of the Active Setup repair.
Now, if I log on with a Non-Admin account (having removed the Active Setup registry entry) and try running QuickTime, it will perform a Windows Installer self repair and AutoUpdates will be disabled.
As you can see, there is a difference in behaviour based on if the logged on user is an Admin or Standard User.
Going back to what MSDN stated, LocalAppDataFolder should always behave per-user. Therefore, if %userprofile%\Local Settings\Application Data\Apple Computer\QuickTime\QuickTime.qtp is missing when QuickTime runs, Windows Installer SHOULD perform a self repair as it does for a Non-Admin user.
Posted by:
AngelD
14 years ago
ORIGINAL: brettski
Going back to what MSDN stated, LocalAppDataFolder should always behave per-user. Therefore, if %userprofile%\Local Settings\Application Data\Apple Computer\QuickTime\QuickTime.qtp is missing when QuickTime runs, Windows Installer SHOULD perform a self repair as it does for a Non-Admin user.
No!
Check out post #20 for an explanation in the below thread
http://www.appdeploy.com/messageboards/fb.asp?m=53108
Posted by:
brettski
14 years ago
Thanks for pointing me to that AngelD, your explaination of how it works was very informative. What you've described there is pretty much what I'd suspected was happening based on what I was seeing happen in my testing.
I still kind of feel that Windows Installer should be 'smart' enough to know that keypath for component X is using a per user property, therefore the keypath metadata also should reflect a per-user value - maybe either recorded in the HKCU or just recording the equivalent variable rather than direct path. But, clearly it does not do this, so using the HKCU registry for the keypath is a suitable solution which I shall use from now on.
Thanks again all, not just for the solution, but also for the help understanding the process better.
Brett
I still kind of feel that Windows Installer should be 'smart' enough to know that keypath for component X is using a per user property, therefore the keypath metadata also should reflect a per-user value - maybe either recorded in the HKCU or just recording the equivalent variable rather than direct path. But, clearly it does not do this, so using the HKCU registry for the keypath is a suitable solution which I shall use from now on.
Thanks again all, not just for the solution, but also for the help understanding the process better.
Brett
Posted by:
AngelD
14 years ago
ORIGINAL: brettski
Windows Installer should be 'smart' enough
Well, no :)
The keypath metadata do not have a value of "%userprofile%\Local Settings\Application Data\Apple Computer\QuickTime\QuickTime.qtp" but the full "resolved" path to the user's profile ("C:\Documents and Settings\<username>\Local Settings\Application Data\Apple Computer\QuickTime\QuickTime.qtp").
And as broken component means missing file which isn't the case when an admin-user triggers the resiliency check as that account is able to verify that the file exists in the "other" user's profile not repair will be triggered.
Posted by:
nheim
14 years ago
Hi Brett,
See: http://itninja.com/question/how-do-you-roll-out-new-machines?7774
All the key things in this thread are still true for the actual version of QT. Especially, the use of the DuplicateFile Action for this kind of stuff.
@Harjinder: Advertised shortcuts are not a good thing in package which is part of the "Default programs" collection of windows. If one disables QT from the default programs, the SC's are being deleted. And recreated as "normal" SC's when it is enabled again.
Regards, Nick
See: http://itninja.com/question/how-do-you-roll-out-new-machines?7774
All the key things in this thread are still true for the actual version of QT. Especially, the use of the DuplicateFile Action for this kind of stuff.
@Harjinder: Advertised shortcuts are not a good thing in package which is part of the "Default programs" collection of windows. If one disables QT from the default programs, the SC's are being deleted. And recreated as "normal" SC's when it is enabled again.
Regards, Nick
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.