Hi, I'm wondering if anyone else is having problems with iTunes 12.2 failing to install through SCCM 2012?

I've broken the Application Support, Mobile Device Support, Bonjour and iTunes MSIs into separate Applications. When I install the Application Support MSIs I'm getting a 1603 failure. Running the MSI manually it tells me "A later version of Apple Application Support is already installed on this computer" but there isn't. I need to clean the key out of HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\ before I'm able to install the MSI. Once done, I can install and uninstall without issue using my account or SYSTEM account using the file from CCMCACHE and with the same string AppEnforce.log shows was run. If run through SCCM again (confirmed as running as SYSTEM), the install will fail again, recreating the HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\ key. Seems similar to https://discussions.apple.com/thread/6773753 but their fix of adjusting the version number isn't working as SCCM seems to be setting that key and values itself.

The same process works with iTunes 12.1 and I've replicated this issue on two separate SCCM 2012 systems in different environments, using different SOEs with different OSs (both x64 and x86 of Win7 and Win8.1).

Hoping someone has some suggestions.
Answer Summary:
Cancel
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Answer Chosen by the Author

2
Remove the following launch condition from iTunes.msi, AppleMobileDeviceSupport.msi and AppleApplicationSupport.msi
NOT BNEWERPRODUCTISINSTALLED
Answered 07/28/2015 by: jagadeish
Red Belt

  • Thank you jagadeish. That solved the problem. Any hints as to why the different behaving when run through SCCM?
Please log in to comment

Answers

0
This has nothing to do with SCCM. SCCM is just a deployment mechanism, using the local System account. You could reproduce the "error" using PSExec.

Clearly, Windows Installer sees an installation of the 'Application Support' MSI on the target, or it wouldn't be displaying that error.

Do a search on the target machine's registry for both the ProductCode and its "compressed" version (you can Google 'windows installer compress GUID' and find a script which converts to and from vanilla and compressed codes). You'll find one of them somewhere. In that case - IF you determine that the newer product isn't actually installed - you can use MSIZap, a free MS utility which completely expunges all trace of a product's installation data from the registry. You can then proceed with your deployment.
Answered 07/18/2015 by: VBScab
Red Belt

Please log in to comment
0
Are you testing on a clean machine or clean VM  every time?  This looks like there is a residue of a failed or flawed installation in the registry which is causing your error. The MSIZap solution has merit - I have used this to sort out deployment issues with Java runtimes which are notorious for not updating reliably.
Answered 07/20/2015 by: EdT
Red Belt

Please log in to comment
0
I would have agreed with you about it not being SCCM's fault up until this particular application. I've seen plenty of apps that behave differently between Admin and SYSTEM account; this is the first time I haven't been able to replicate the behaviour with a psexec launched SYSTEM command prompt.

As I mentioned, these are multiple clean VMs that have never had any Apple software installed on them. I've once again checked the registry against the product code and also this time the compressed GUID and received no hits. Having done that, I can use a SYSTEM command prompt to install and uninstall the MSI without issue. I then reverted the VM and tried running the same MSI through SCCM. Once again, it failed to install. If I check the registry, the Product Code now exists with the version number of the MSI I was trying to install. I can delete it and a manual install as SYSTEM will once again complete.

Now, running /lv* I get the following (failure and success respectively)

MSI (s) (24:B0) [00:56:38:504]: Doing action: AppSearch
Action ended 0:56:38: PreventDowngrade. Return value 1.
Action start 0:56:38: AppSearch.
MSI (s) (24:B0) [00:56:38:505]: Note: 1: 2262 2: Signature 3: -2147287038
MSI (s) (24:B0) [00:56:38:507]: Doing action: FindRelatedProducts
Action ended 0:56:38: AppSearch. Return value 1.
Action start 0:56:38: FindRelatedProducts.
MSI (s) (24:B0) [00:56:38:513]: Doing action: LaunchConditions
Action ended 0:56:38: FindRelatedProducts. Return value 1.
Action start 0:56:38: LaunchConditions.
MSI (s) (24:B0) [00:56:38:515]: Product: Apple Application Support (32-bit) -- A later version of Apple Application Support (32-bit) is already installed on this computer.
A later version of Apple Application Support (32-bit) is already installed on this computer.
Action ended 0:56:38: LaunchConditions. Return value 3.
Action ended 0:56:38: INSTALL. Return value 3.


------------------

MSI (s) (D0:80) [01:12:09:469]: Doing action: AppSearch
Action ended 1:12:09: PreventDowngrade. Return value 1.
Action start 1:12:09: AppSearch.
MSI (s) (D0:80) [01:12:09:471]: Note: 1: 2262 2: Signature 3: -2147287038
MSI (s) (D0:80) [01:12:09:471]: Doing action: FindRelatedProducts
Action ended 1:12:09: AppSearch. Return value 1.
Action start 1:12:09: FindRelatedProducts.
MSI (s) (D0:80) [01:12:09:472]: Doing action: LaunchConditions
Action ended 1:12:09: FindRelatedProducts. Return value 1.
Action start 1:12:09: LaunchConditions.
MSI (s) (D0:80) [01:12:09:473]: Doing action: ValidateProductID
Action ended 1:12:09: LaunchConditions. Return value 1.
Action start 1:12:09: ValidateProductID.
MSI (s) (D0:80) [01:12:09:474]: Doing action: CheckAMDServiceRunning


As you can see, in one case it thinks it detects an installed product (even though it isn't there) and in the other it progresses without issue.
Answered 07/21/2015 by: brettski
Purple Belt

Please log in to comment
Answer this question or Comment on this question for clarity