Recently, I had to deploy .Net Framework 4.5.2 to all systems, as it was a requirement for a software update. I first deployed it through software updates in SCCM 2012. The status showed up as compliant. I thought nothing more of it. I went to deploy the application and it failed on many machines. SCCM was reporting back false data, which is part of my other blog posting. I had verified the powershell script I had written to install the app was working when running it from the software center and/or a command line. I was perplexed. I then kicked off an install after rebooting a machine through a machine policy update from the SCCM console. It stuck on the NDP452-KB2901907-x86-x64-AllOS-ENU.exe execution. I finally found the log file for this located at c:\windows\temp\dd_NDP452-KB2901907-x86-x64-AllOS-ENU_decompression_log.txt. In the log were these last three lines:
[11/4/2015, 14:4:24] Extracting files to: C:\4ace42dcab1cf4386b698f\
[11/4/2015, 14:4:24] Error 0x80004005: Failed to extract all files out of box container #0.
[11/4/2015, 14:4:24] Error 0x80004005: Failed to extract
I then tried another step by checking off the Run installation and uninstall program as 32-bit process on 64-bit clients. This did no good. Since it would successfully execute from a command line and/or manual execution through software center, I decided to add it as package and run it directly from the network share instead of a distribution point. This worked. It is now installing with no problems. When creating the package, there will be no source files. Instead, you will put the network share of where the installation files exist in the Start in field. This should allow you to now install 4.5.2.
[11/4/2015, 14:4:24] Extracting files to: C:\4ace42dcab1cf4386b698f\
[11/4/2015, 14:4:24] Error 0x80004005: Failed to extract all files out of box container #0.
[11/4/2015, 14:4:24] Error 0x80004005: Failed to extract
I then tried another step by checking off the Run installation and uninstall program as 32-bit process on 64-bit clients. This did no good. Since it would successfully execute from a command line and/or manual execution through software center, I decided to add it as package and run it directly from the network share instead of a distribution point. This worked. It is now installing with no problems. When creating the package, there will be no source files. Instead, you will put the network share of where the installation files exist in the Start in field. This should allow you to now install 4.5.2.
But with this solution you're missing the point of having a DP.
ReplyDeleteWhat if you have a remote site connected to the server share that you're directing to using a slow WAN?
Another solution might be to include psexec.exe in the package and then have psexec execute the package locally on the machine instead of through the distribution point.
Delete