I was running into a problem with the installation of Microsoft .NET Framework 4.5.2 during an SCCM 2012 SP1 build and capture Task Sequence, both in Windows 7 and Windows 8.1.
I was using the application model and executing the offline installer executable with the command line “NDP452-KB2901907-x86-x64-AllOS-ENU.exe /q /norestart” through a VBScript wrapper script.
When the application failed, the error in smsts.log read, in part:
Execution status received: 4 (Application failed to install ) Installation failed. ... Install application action failed: 'Microsoft .NET Framework 4.5.2'. Error Code 0x80004005 ... Install Static Applications failed, hr=0x80004005 Process completed with exit code 2147500037 !--------------------------------------------------------------------------------------------! Failed to run the action: Microsoft .NET Framework 4.5.2. Unspecified error (Error: 80004005; Source: Windows)
According to the MSDN page .NET Framework Deployment Guide for Administrators, log files are written to “%temp%\Microsoft .NET Framework 4.5*.txt” and “%temp%\Microsoft .NET Framework 4.5*.html”, but neither of these logs existed on my Windows 7 and Windows 8.1 systems after the installation failed.
However, a log file at C:\Windows\Temp\dd_NDP452-KB2901907-x86-x64-AllOS-ENU_decompression_log.txt caught my eye. The contents of this decompression log read:
[5/22/2014, 16:42:35] === Logging started: 2014/05/22 16:42:35 === [5/22/2014, 16:42:35] Executable: C:\Windows\ccmcache\1\NDP452-KB2901907-x86-x64-AllOS-ENU.exe v4.5.51209.34209 [5/22/2014, 16:42:35] --- logging level: standard --- [5/22/2014, 16:42:35] Successfully bound to the ClusApi.dll [5/22/2014, 16:42:35] Error 0x80070424: Failed to open the current cluster [5/22/2014, 16:42:35] Cluster drive map: '' [5/22/2014, 16:42:35] Considering drive: 'A:\'... [5/22/2014, 16:42:36] Drive 'A:\' is rejected because of the unknown or unsuitable drive type [5/22/2014, 16:42:36] Considering drive: 'C:\'... [5/22/2014, 16:42:36] Considering drive: 'D:\'... [5/22/2014, 16:42:36] Drive 'D:\' is rejected because of the unknown or unsuitable drive type [5/22/2014, 16:42:36] Drive 'C:\' has been selected as the largest fixed drive [5/22/2014, 16:42:36] Directory 'C:\26169df5670339bdf66775485ff857\' has been selected for file extraction [5/22/2014, 16:42:36] Extracting files to: C:\26169df5670339bdf66775485ff857\ [5/22/2014, 16:42:36] Error 0x80004005: Failed to extract all files out of box container #0. [5/22/2014, 16:42:36] Error 0x80004005: Failed to extract [5/22/2014, 16:42:36] Exiting with result code: 0x80004005 [5/22/2014, 16:42:36] === Logging stopped: 2014/05/22 16:42:36 ===
If I ran my installation wrapper script from the ccmcache subdirectory while logged on as the local administrator account, the .NET Framework 4.5.2 installation ran successfully.
I Googled the rather generic error messages from the decompression log a little bit and didn’t find anything helpful, although I did find some recommendations to extract the file using 7-Zip and then run the setup.exe, which I did not want to do, and to use the traditional package/program method, which I considered. On the day that I was going to give up on the application model and just create a package, I did a little more Googling on installing .NET Framework 4.5 through a task sequence in SCCM and found a thread on the Technet forums that describes the problem exactly and gives a working solution:
.NET 4.5.1 Install only works when running on a UI session
http://social.technet.microsoft.com/Forums/en-US/4808233e-1410-4305-a8d1-0e88f3a6fdc8/net-451-install-only-works-when-running-on-a-ui-session?forum=configmanagerapps
The resolution described in the thread is to edit the properties of the Deployment Type to enabled “Run installation and uninstall program as 32-bit process on 64-bit clients.” (This setting is found on the Programs tab.)
For the Detection Rule, I chose to use a registry setting must exist:
HKLM\SOFTWARE\Classes\Installer\Products\6414876250E69FF3395387C6C7F05BEB\ProductName = Microsoft .NET Framework 4.5.2
Good luck.
P.S. I expect, but will have to validate, that this method of running the installer as a 32-bit process might help with other applications that fail to install during a task sequence but run successfully via Software Center or Application Catalog when a user is logged on.
