All Users / Per User installs

All Users / Per User installs

Click here to associate this thread with a Package KB article.

Logged in as: Guest

Users viewing this topic: none

Printable Version

All Forums >> [AppDeploy Forums] >> Package Development >> All Users / Per User installs

Page: [1]

Message

<< Older Topic Newer Topic >>

All Users / Per User installs - 11/17/2009 9:07:15 PM

brettski

Posts: 58
Score: 0
Joined: 3/15/2006
From: Adelaide, Australia
Status: offline

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??

Post #: 1

RE: All Users / Per User installs - 11/18/2009 5:38:22 AM

dreyer

Posts: 46
Score: 5
Joined: 11/30/2005
From: Stavanger, Norway
Status: offline

ALLUSERS=0 is not a valid option. ALLUSERS="" is correct.

(in reply to brettski)

Post #: 2

RE: All Users / Per User installs - 11/18/2009 8:14:59 AM

AutomateIT

Posts: 17
Score: 0
Joined: 6/25/2009
Status: offline

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.

(in reply to dreyer)

Post #: 3

RE: All Users / Per User installs - 11/18/2009 7:11:45 PM

brettski

Posts: 58
Score: 0
Joined: 3/15/2006
From: Adelaide, Australia
Status: offline

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.

(in reply to AutomateIT)

Post #: 4

RE: All Users / Per User installs - 11/19/2009 3:24:04 AM

VBScab

Posts: 6634
Score: 192
Joined: 9/5/2006
From: London, UK
Status: online

quote:

some way <snip> to install user-specific parts in each user's profile

You mean, as in installing to All Users, i.e. per-machine? :)

_____________________________

- Don't know why 'x' happened? Want to know why 'y' happened? ProcMon will tell you.
- Try using http://www.google.com before posting.
- I answer questions only via forums. PMs and personal emails will be ignored.

(in reply to brettski)

Post #: 5

RE: All Users / Per User installs - 11/19/2009 5:55:45 PM

brettski

Posts: 58
Score: 0
Joined: 3/15/2006
From: Adelaide, Australia
Status: offline

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.

(in reply to VBScab)

Post #: 6

RE: All Users / Per User installs - 11/19/2009 6:42:54 PM

AngelD

Posts: 2937
Score: 102
Joined: 6/9/2004
From: Sweden
Status: offline

quote:

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.

(in reply to brettski)

Post #: 7

RE: All Users / Per User installs - 11/19/2009 8:09:04 PM

PackageExpert

Posts: 122
Score: 3
Joined: 5/20/2008
From: Malaysia
Status: offline

quote:

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.

(in reply to AngelD)

Post #: 8

RE: All Users / Per User installs - 11/19/2009 11:39:14 PM

brettski

Posts: 58
Score: 0
Joined: 3/15/2006
From: Adelaide, Australia
Status: offline

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.

(in reply to PackageExpert)

Post #: 9

RE: All Users / Per User installs - 11/19/2009 11:57:53 PM

PackageExpert

Posts: 122
Score: 3
Joined: 5/20/2008
From: Malaysia
Status: offline

quote:

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.

(in reply to brettski)

Post #: 10

RE: All Users / Per User installs - 11/20/2009 12:14:56 AM

brettski

Posts: 58
Score: 0
Joined: 3/15/2006
From: Adelaide, Australia
Status: offline

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

(in reply to PackageExpert)

Post #: 11

RE: All Users / Per User installs - 11/20/2009 1:18:59 AM

PackageExpert

Posts: 122
Score: 3
Joined: 5/20/2008
From: Malaysia
Status: offline

quote:

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....

quote:

hmmm, so from what that's saying, LocalAppDataFolder ignores the ALLUSERS property and always install per-user.

Yes

quote:

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>

< Message edited by PackageExpert -- 11/20/2009 1:19:41 AM >

(in reply to brettski)

Post #: 12

RE: All Users / Per User installs - 11/20/2009 2:10:16 AM

brettski

Posts: 58
Score: 0
Joined: 3/15/2006
From: Adelaide, Australia
Status: offline

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.

(in reply to PackageExpert)

Post #: 13

RE: All Users / Per User installs - 11/20/2009 4:14:39 AM

AngelD

Posts: 2937
Score: 102
Joined: 6/9/2004
From: Sweden
Status: offline

quote:

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

(in reply to brettski)

Post #: 14

RE: All Users / Per User installs - 11/22/2009 7:35:03 PM

brettski

Posts: 58
Score: 0
Joined: 3/15/2006
From: Adelaide, Australia
Status: offline

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

(in reply to AngelD)

Post #: 15

RE: All Users / Per User installs - 11/23/2009 4:50:19 AM

AngelD

Posts: 2937
Score: 102
Joined: 6/9/2004
From: Sweden
Status: offline

quote:

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.

(in reply to brettski)

Post #: 16

RE: All Users / Per User installs - 11/23/2009 5:42:36 AM

nheim

Posts: 1180
Score: 55
Joined: 4/5/2004
From: Switzerland
Status: offline

Hi Brett,
See: http://www.appdeploy.com/messageboards/tm.asp?m=27774
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

(in reply to AngelD)

Post #: 17