Quicktime 6.5.2

[rjnagy]

Has anyone here ever created a successful 6.5.2 Quicktime MSI package in a locked down environment. I have been banging my head against the wall so to speak as it seems the package is fine. However in order for it to work properly in an environment where group policy is being pushed it would seem that a administrator has to login and start quicktime for the first time and then after that it seems to work fine for both user and admins. Has anyone come across where a user logs on first and when they try to run a .mov for example I get QuickTimePlayer.exe has generated errors and will be closed by windows. I'm thinking this is because group policy has anyone else come across this and if so please help point me in the right direction.

[sloignon]

Are you trying to deploy the vendor setup? Or have you repackaged the vendor setup into your own msi? I just repackaged Quicktime Pro 7.0.4 in a locked down environment

[rjnagy]

I went to the quicktime website and downloaded the standalone file for 6.5.2. My understanding is that starting with 7.0 Quicktime comes in a MSI whereas prior to that it wasn't a MSI. My problem is, and hopefully you can help with this, that the system partition "C:" is locked down from the users and so is the registry. Average users therefore cannot write to "C:" or the registry.
My current package works fine on a box that hasn't been locked down at all. On a box that is locked down a user can start the program and the player comes up but if they were to try and run a .mov they get "Quicktime player has generated errors and will be closed by windows". It says a log will be generated. Now if an Admin logs on it works fine, and then if a user logs on after an admin it is fine. So my logic says that when you run quicktime the first time "and I don't know if this is with my package setup or quicktime behavior" I believe it is either trying to write something to the registry or write something to the C: drive and if a user is the first person to run quicktime, then quicktime is unable to write that file to the drive or value to the registry. The only thing I had changed in the package was the Folder_SystemFolder_Com which contains the following files: quicktime.qtp, quicktime.cpl, qtplugin.log. I changed the permanent value from yes to no only because I didn't want quicktime.cpl left behind. Did you run into any access problems with users just on first run or are installing it as an admin and then running it once. See we are using Active Directory for distribution therefore a user would more than likely be the person who would run quicktime the first time on any given machine.

[sloignon]

We distribute our installs through SMS. You have the full version of AdminStudio? This was the way I worked it. I went out to the Quicktime website and downloaded the standalone quicktime player. We also got a key to make it a pro version but that does not matter for this example. I have a clean test machine that has access to Installshield repackager. Once the download is complete I move the setup.exe over to my test machine. I launched the repackager and took a baseline snapshot of the machine. I then ran the install on my test machine. In our environment we are not allowed to have desktop shortcuts, quicklaunch shortcuts, etc. So I removed all of them. I entered our key and made any configuration changes needed. I then took a second snapshot. This creates a *.irp (InstallShield Repackager Project). Then on my dev machine, that has the full adminstudio suite, I opened the *.irp and ran the "build". This creates a *.ism. Once the ism is built I open it in Installshiled make any changes I need and build my msi for distribution through SMS. SMS runs with elivated privs. All the files are written to c without issue as well as the registry entries. Make sure the shortcut is not advertised.

[rjnagy]

Yeah see thats wherein the problem lies is that we're using Group Policy to push it out so when a normal joe user starts QT the first time it tries to configure QT and fails. Two more tests I'm going to do today is run Quicktime and let it bomb purposely while regmon and filemon are running to see where access is denied. Secondly as much I do not want to do this I may have to change the Folder_SystemFolder_Com permanent value to yes. The reason why I did not want to do that is when uninstall happens it then leaves the control panel applet behind. Question did you have to change the Install level in or the _IsSetupTypeMin under Behavior and Logic\Property Manager. Mine is set to Typical for _IsSetupTypeMin and Install level has a value of 100.

[sloignon]

Mine is set to Typical for _IsSetupTypeMin and Install level has a value of 100. Let me take a look and see if I can find any tricks.

[turbokitty]

This is well documented on Appdeploy.com. Check the Package Knowledge Database.

[rjnagy]

Kitty had already been to appdeploy.com. What it did not cover there was a locked down environment which is always the case in the places I work whereas alot times the users have no rights to the C: partition or the registry.
However this point is mute now as I have fixed 6.5.2 deployment we had and cleaned up everything in it.

So we are now moving on to 7.0.4 which leads me to a question for Sloignon

Sloignon my question is having deployed 7.0.4 in a locked down environment did you come across any user rights issues in reg or on C: drive as again our users have rights to neither and their profiles are not stored locally.

[turbokitty]

Every environment I've ever worked in has been locked-down. That's actually more common than not.

When you say "no rights to C: or Registry" do you mean they don't even have rights to the HKCU hive or Appdata folder? If not, that's just ridiculous and pointless and I don't envy you.

QT 7 is a much cleaner MSI than 6.x (although still a bit ugly). I found it much easier to package and had no rights issues in a regular locked down environment. The issue came when we tried to deploy it as we deployed with a system account that hated delivering user components.