QuickTime, LocalLow and DuplicateFiles

Hi, I've read the posts here about getting QuickTime working and I've managed to get it mostly working, but for some reason I can't get the DuplicateFile table to copy the QuickTime.qtp file into the LocalLow folder for Windows 7 installs.

I've got ActiveSetup running and I can see it's calling the correct components as the HKCU registrys (keys files) are being written. The QTPlayerSession.xml file is being copied to the correct directory. Both files are working with Windows XP using their own seperate components conditioned on VersionNT.

I've noticed something strange which is that I 'sometimes' end up with a HKCU\Software\AppDataLow key being created, even though there is nothing like that in the RegistryTable. I've checked the MSI with Orca in case InstallShield was doing something weird, but the tables look correct in there as well.

I'm not sure if it's relevant, but I'm also using the RemoveFile table to clean up the appropriate files as the DuplicateFile table doesn't seem to overwrite files that already exist. I have tried it with and without this row in the table, so I don't think it's the cause of the problem and the order seems to be working fine for the other DuplicateFiles.

MSI_Pack12, what you've done looks the same to me other than that you've added the file to the folder directly whereas I've used the DuplicateFile table to do the copy. I am using /fua currently but will give /fu a go later.

nheim, I don't seem to have that specific CA, but I would guess that setUserProfileNT would be the InstallShield equivalent?? It's set as setUserProfileNT : VersionNT : 960

Hi Brett,
this CA is part of the QT MSI. It's difficult to guess, where the problem lies.
Please generate a logfile of the installation and load it up to senduit.
With this occasion, you maybe can include your transform too?
Regards, Nick

The reason I don't have that CA is that I've actually created a seperate 'configuration' MSI for QuickTime. We were previously using an MST with Apple's QuickTime MSI, but we had complaints that the repair process was taking too long when the user logged on (we have lots of users that move between multiple computers). I looked at modifying the Feature structure so that the User parts were in a parent feature so the repair was quicker, but I also found information that if you force a repair using /f that Windows Installer will repair the full MSI anyway, rather than the process it uses with an Advertised shortcut.

Sorry, I tried Senduit, but either they're having difficulty or it's one of those many services us poor Aussies don't get access to. However, I've had a look through and I think I can see the cause of the issue, but I'm still not sure why it's doing what it is. A small extract from the log shows properties being set. As you can see, all looks correct as per my Directory table that I posted originally until it gets to setting QUICKTIME3. Although my Directory table says that APPLE_COMPUTER2 (which is set to C:\Users\bgrive01admin\AppData\LocalLow\Apple Computer\) is the Parent directory of QUICKTIME3, QUICKTIME3 gets set to C:\Users\Default\AppData\LocalLow\Apple Computer\QuickTime\.

Any thoughts as to what might be causing this? Thanks again for your help.

are you distributing using some sort of distribution system? Cause this looks alot like the AppData folder the LocalSystem account might use. Is it possible the path gets resolved wrong because of the account that's used to run the installation?

We will be using SCCM to distribute the application, so this was installed using the SYSTEM account to represent an SCCM install. The repair however was run using my user account as would occur with Active Setup. As you can see from the log snippet, most variables are resolving correctly, it only seems to be the QUICKTIME3 property that's having this issue.

It's a very basic MSI package with no Custom Actions at all. I've just done another sanity check and the Directory table lists QUICKTIME3 as having a Directory_Parent of APPLE_COMPUTER2. We can see in the log (I used /log, is there any other switches I should have used instead) that APPLE_COMPUTER2 is being set as C:\Users\bgrive01admin\AppData\LocalLow\Apple Computer\ and is not then reset anywhere further along in the process. Shortly there after QUICKTIME3 is then set as C:\Users\Default\AppData\LocalLow\Apple Computer\QuickTime\ instead of to my account. It is only set the once in the log file.

The other QUICKTIME properties are set using the builtin variables LocalAppDataFolder and AppDataFolder and these are working as expected.

Hi Brett,
once again: Please upload your logfile to a free ftp-service (btw: used senduit yesterday without any problems, but it has its 100MB max filesize).
We need to get a look at th HOLE logfile. Otherwise, its looking for a needle in a haystock...
Regards, Nick

I'm not sure if this is of any help. I decided to clear out all the references to that directory path and recreate. It looks the same, but now when I run the repair USERPROFILE is being set as C:\Users\Default\ and hence all the subfolders are also set as the Default user. I'm installing the MSI with the command line: msiexec /i "C:\Users\bgrive01admin\Desktop\Apple QuickTime Config 1.0 test.msi" ALLUSERS=1 /qb

More testing results. I've created a whole new MSI with just the basic structure of the LocalLow directories, a single file and a HKCU key. If I install it as myself, the file is installed to the correct location as expected. If I install it as SYSTEM and then run a repair using msiexec /fua the the USERPROFILE property is set to C:\Users\Default and the file is not installed.

If I install the MSI as a different Admin account (bgrive01test) and then run the repair in another account (bgrive01admin), the USERPROFILE property is set to C:\Users\bgrive01test. I can see that the repair is working as the file is restored after being deleted, it's just installing to the wrong profile.

Hopefully someone can tell me why the USERPROFILE property is not correctly set to the user's profile and appears to instead remembers the profile of the account that installed the MSI. This is different behaviour to properties such as AppDataFolder.

Hi MSI_Pack,
don't you think 3 times is enough?
This registry key, you mention is only necessary, if you have your quicktime.qtp file in a non-default location.
But this isn't the case here! So it is just plain useless!
Brett's problem is about a behaviour in a new MSI, he has built for this purpose.
Sorry for being rude, but i can't stand this anymore...
Regards, Nick

Thanks so much, it's working now ... I think you've done this packaging thing once or twice yourself haven't you Nick :) . The only changes I made were to the Component table where I set the QTPlayerSession.xmlVer6 Attributes to 4 and added the missing KeyPath values for QTPlayerSession.xmlVer6 and QuickTime.qtpVer6.

I'm not sure if you had something in mind that I should be adding for 64 bit OSs, but all the configurations seem to be working on x64 without any modifications.

Hi Brett,
glad to see it works now.
About the 64bit thing:
AS does not work out of the box on a 64bit system, because all registry settings from a 32bit app go to the x86 branch.
Therefore, you need an extra 64bit component, which creates the AS-registry entries on a 64 bit system.
That would require the following extra entries in your test app:
in the component table:
ActiveSetup64 {GUID-here} INSTALLDIR 260 VersionNT64 Reg64_3
in the feature components table:UserConfig ActiveSetup64
in the Registry table:Reg64_1 2 SOFTWARE\Microsoft\Active Setup\Installed Components\Apple QuickTime Config Apple QuickTime Config 1.0 ActiveSetup64
Reg64_2 2 SOFTWARE\Microsoft\Active Setup\Installed Components\Apple QuickTime Config StubPath msiexec /fua {FDD9CA58-DF6B-40BA-806E-2E4B3072DA62} /qn ActiveSetup64
Reg64_3 2 SOFTWARE\Microsoft\Active Setup\Installed Components\Apple QuickTime Config Version 1,1 ActiveSetup64
That should do the trick.
Regards, Nick

Hmmm, I thought when I was looking into this for something else that you couldn't have 32 and 64 bit components mixed into the same MSI. I must have misunderstood something and will have to go back and revisit.

As this particular install only has files that install to the %programfiles(x86)% area and the user area which is 32 / 64 bit independent, it looks like I can get away without having the 64 bit component. It just puts the AS in HKLM\SOFTWARE\Wow6432Node\Microsoft\Active Setup rather than HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup but it seems to work fine.

Is there any reason that I should mess with something that is now not broken?

Hi Brett,
good question, but you can test it yourself.
The registry entries are nicely installed into the WOW branch, but will just sit there an do nothing.
To get AS going on 64bit systems, the AS-regkeys have to go to HKLM/Software/Microsoft/Active Setup.
And this needs a 64bit component, like i suggested in my previous post.
Quicktime is a pretty good example here, because it is 32bit only, but iTunes, which needs it as a prerequisite, has 32 and 64bit versions.
We do this for all 32bit apps which have AS.
Hope, this clears that a bit.
Regards, Nick

Just to clarify, you're saying that AS entries located in the WOW branch won't run when the user logs on?? Are you refering to x64 OSs in general or just Windows 7?

I've only tested on Win7 x64 myself, but I'm not seeing the behaviour your describing. On my system the AS is installed to the WOW branch as mentioned previously, but the OS does seem to run this on logon as expected. I can see the HKCU entries which are again located in the WOW branch, but the MSI has most definately repaired itself. I can see that the HKCU AS keys, the key registry entries used for the file components and the files themselves have all been recreated (deleted prior to log off / on).

Step 2. Check under %TEMP% there should be 4 msi’s – You can delete AppleSoftwareUpdate.msi as it is not required.

Step 3. I created a .mst for the AppleApplicationSupport.msi and applied our standards. This was installed on aWindows XP SP3 VM and snapped.

Step 4. Installed Quicktime.msi.

Step 5. What we need to do now is apply our preferences.These will manifest themselves in quicktime.qtp file which can be located at [LocalAppDataFolder]Apple Computer\Quicktime.Copy this file to your mst when you have applied you preferences to QuickTime Player and PictureViewer.These should include disabling updates and removing System Tray Icon.

Step 6.I created a separate feature called CG_QTConfig under Setup Design and created a CG_Quicktime.qtp component with a destination of [LocalAppDataFolder]Apple Computer\Quicktime.Here i imported the quicktime.qtp file.Also added HKCU\Software\Apple Computer, Inc.\Quicktime\LocalUserPreferences Name=Auto-Update Date=Disabled. This registry key was set as keypath for the component.

Step 7. Active Setup key added in a new component under newly created feature to ensure replication to all users.

Step 8: The following step copied from - http://www.bdts.com.au/tips-and-resources/48-msi-packaging/74-deploy-quicktime-765.html

Change QT_TRAY_ICON from #2 to #0 - this will disable the tray icon (the blue Q by the clock)Not True but left it so .

Note: the lines above should not have spaces in them, I inserted a space after each ; so it wrapped nicely for the web. You can easily remove the spaces by copying the text into notepad, and replace all "; " with ";"

Optional: I like to change the ProductName field to "QuickTime 7.71.80.42" so users can see which version is being installed / removed.

Step 11. In installed what i had done up to now to see if the System Tray Icon had removed but alas it had not. Some frustrating ‘googleing’ suggested to meto do the following: Create a new component under newly created feature, obtain from your installation up to now and add file com.apple.Quicktime.plist to C:\Documents and Settings\All Users\Aplication Data\Apple Computer\Quicktime.

System Tray Icon still exists.

Step 12. In the QuickTimeInternet feature there is a component called QTPlugin.ocx.In here locate the regkey [HKLM\SOFTWARE\Apple Computer, Inc.\QuickTime\ActiveX] QTTaskRunFlags=[QT_TRAY_ICON].This needs to be changed to a DWORD regkey [HKLM\SOFTWARE\Apple Computer, Inc.\QuickTime\ActiveX] QTTaskRunFlags=2