none
.NET 4.5.1 Install only works when running on a UI session

    Question

  • I have created an application package for .NET 4.5.1 offline installer with the following installation command:

    NDP451-KB2858728-x86-x64-AllOS-ENU.exe /q /norestart /ChainingPackage "ADMINDEPLOYMENT"

    When SCCM attempts to install this application after a machine policy refresh the install fails with the following errors:

    [12/13/2013, 8:51:47] Directory 'C:\e5bb6b6b88f53e9031f3ffa7a961\' has been selected for file extraction
    [12/13/2013, 8:51:47] Extracting files to: C:\e5bb6b6b88f53e9031f3ffa7a961\
    [12/13/2013, 8:51:47] Error 0x80004005: Failed to extract all files out of box container #0.
    [12/13/2013, 8:51:47] Error 0x80004005: Failed to extract
    [12/13/2013, 8:51:47] Exiting with result code: 0x80004005

    Manually going to the machine and running the installation via the Software Center results in the application installing correctly and reporting back to SCCM as a success. 

    I've tried going the route of the web installer but it fails because it can't get past the corporate proxy and I'd prefer the offline installer anyways.  The web installer does manage to extract itself via SCCM though.  I have already tried redownloading the installer but it didn't make a difference.

    Any advice?

    Thanks in advance.

    Friday, December 13, 2013 3:11 PM

Answers

All replies

  • What log is the above snippet from? The framework installation log file?

    Are you running this using a package or an application?

    Anything useful in the event log?


    Jason | http://blog.configmgrftw.com

    Friday, December 13, 2013 6:30 PM
  • That is from c:\windows\temp\dd_NDP451-KB2858728-x86-x64-AllOS-ENU_decompression_log.txt

    The event log has absolutely no information in application or system regarding this installation.

    Friday, December 13, 2013 6:34 PM
  • What about AV?

    Jason | http://blog.configmgrftw.com

    Friday, December 13, 2013 6:42 PM
  • MS Security Essentials is installed and running.
    Friday, December 13, 2013 8:08 PM
  • MS Security Essentials is installed and running.

    I disabled real-time protection, re-ran the installation and the issue persists.
    Monday, December 16, 2013 1:12 PM
  • Hi,

    Since, .NET 4.5.1 (KB2858725, KB2881468) is already live on Windows Update, you can maybe use these Microsoft provided bundles rather than trying to create a custom deployment?

    Thanks,


    Vivek Mishra - MSFT


    Tuesday, December 17, 2013 2:04 AM
  • So, coincidentally, I'm running into the exact same behavior described above at my current customer. No resolution though although this seems to me an issue with the 4.5.1 installer.

    Jason | http://blog.configmgrftw.com

    Tuesday, December 17, 2013 5:09 PM
  • I'm experiencing this same problem, and I've been wrestling with it for some time.  I'm trying to deploy .Net 4.5.1 via SCCM 2012 R2 and an OSD Task Sequence, and I see the same results as described in the original post.

    I'm to the point that I'm going to open a case with Microsoft, as deploying this software is essential to a successful implementation of OSD (it's a requirement for so many of our applications).  Without it, I can't install my applications via a task sequence...

    In my task sequence, I have implemented a pause before and after the installation of the framework so I can troubleshoot.  

    When the task sequence executes, the .net install is just a 15-30 seconds.  It then produces the log C:\Windows\Temp\dd_NDP3451-KB2858728-x86-x64-ALLOS-ENU_decompression_log.txt.

    [1/7/2014, 10:28:0] === Logging started: 2014/01/07 10:28:00 ===
    [1/7/2014, 10:28:0] Executable: C:\WINDOWS\ccmcache\1\NDP451-KB2858728-x86-x64-AllOS-ENU.exe v4.5.50938.18408
    [1/7/2014, 10:28:0] --- logging level: standard ---
    [1/7/2014, 10:28:0] Successfully bound to the ClusApi.dll
    [1/7/2014, 10:28:0] Error 0x80070424: Failed to open the current cluster
    [1/7/2014, 10:28:0] Cluster drive map: ''
    [1/7/2014, 10:28:0] Considering drive: 'A:\'...
    [1/7/2014, 10:28:1] Drive 'A:\' is rejected because of the unknown or unsuitable drive type
    [1/7/2014, 10:28:1] Considering drive: 'C:\'...
    [1/7/2014, 10:28:1] Considering drive: 'D:\'...
    [1/7/2014, 10:28:1] Drive 'D:\' is rejected because of the unknown or unsuitable drive type
    [1/7/2014, 10:28:1] Considering drive: 'Q:\'...
    [1/7/2014, 10:28:1] Drive 'Q:\' is rejected because of the unknown or unsuitable drive type
    [1/7/2014, 10:28:1] Drive 'C:\' has been selected as the largest fixed drive
    [1/7/2014, 10:28:1] Directory 'C:\d7a66bf1a9fd49b4c82794360e371a9e\' has been selected for file extraction
    [1/7/2014, 10:28:1] Extracting files to: C:\d7a66bf1a9fd49b4c82794360e371a9e\
    [1/7/2014, 10:28:1] Error 0x80004005: Failed to extract all files out of box container #0.
    [1/7/2014, 10:28:1] Error 0x80004005: Failed to extract
    [1/7/2014, 10:28:1] Exiting with result code: 0x80004005
    [1/7/2014, 10:28:1] === Logging stopped: 2014/01/07 10:28:01 ===

    At this point, I have my task sequence paused and a command prompt open.  If I run my batch file, the installer launches and works fine, but I can't do this for every build as it needs to be automated.

    The batch file is:

    :Init
      @Echo Off
        If Not Exist C:\Logs md C:\Logs  
        If Not Exist C:\Logs\OSD md C:\Logs\OSD
        If Not Exist C:\Logs\OSD\Software md C:\Logs\OSD\Software
    
    :Main
      "%~dp0NDP451-KB2858728-x86-x64-AllOS-ENU.exe" /q /norestart /log "C:\Logs\OSD\Software\dotNet451.log" /ChainingPackage ADMINDEPLOYMENT
    
    :End
      Exit %errorlevel%

    Tuesday, January 07, 2014 4:16 PM
  • A case with Microsoft is probably the best course at this point.

    Jason | http://blog.configmgrftw.com

    Tuesday, January 07, 2014 5:15 PM
  • Thanks for the response.

    I managed to finally get this working.  Instead of deploying with the SCCM Application model, I went back to the pre-2012 methodology and used a Package.  Same script and the install worked fine.

    Hopefully that will help someone else with this problem.  I'd love to use the Application model, but I'll take it, as long as its working! 

    Tuesday, January 07, 2014 5:38 PM
  • I have the same issue too.  I hope someone at MS gets it fixed.  The installer works fine on win7, but win8 throws the failed extraction error.  I ended up pre-extracting it (1GB+) and using that as a giant SCCM app.  The command for the extracted setup.exe requires a couple more arguments: setup.exe  /norestart /x86 /x64 /redist /q.  It probably would have been better to go the package route though.
    Friday, January 10, 2014 3:26 PM
  • lge,

    I'm assuming that you're deploying it using the application model with SCCM?  If so, try deploying it using a package.  I know it isn't as full featured as using the application model, but until the installer is fixed (I'm sure it won't get fixed in this version), it's at least a way to do a quicker install.  

    I, too, looked at pre-extracting the installer.  But the 1+GB package that the 70MB file extracted to pushed me to use the package method.

    I've had 100% success with it this method.

    Friday, January 10, 2014 3:29 PM
  • I was having the same issue described in this thread.  To get around the failure installing .NET 4.5.1 as an application in my OSD TS, I converted it to a package and that fixed the issue.  However, I also wanted to push the application to all my existing clients.  Wanting to utilize features only available with the Application model (i.e. icons and categories in App Catalog, app detection, etc.) I started to look at why it didn't work as an application. 

    The result....it works if you select to run the installation and uninstall program as 32bit process on 64bit clients (all clients in our company are 64bit).

    There is no issue with the installer as suggested above.  Go ahead and give this a shot! 


    • Edited by Jay.Tung Friday, January 10, 2014 5:43 PM typo
    • Proposed as answer by Jay.Tung Friday, January 10, 2014 5:44 PM
    Friday, January 10, 2014 5:42 PM
  • Hey Guys,

    same problem here, just testing it as package. Maybe running it as 32-bit process is working, but is this really the solution? .net Framework is an installer for 32-bit and 64-bit. Running it as 32-bit will install the wrong version, or am i wrong?

    Daniel

    Monday, January 20, 2014 2:15 PM
  • Installing it as a batch file is a temporary workaround.

    NDP451-KB2858728-x86-x64-AllOS-ENU.exe /q /norestart /ChainingPackage ADMINDEPLOYMENT /log c:\dotnet451install.log

    Tuesday, January 21, 2014 3:02 PM
  • Batch File? Do you mean that you created a batch file that is in turn called via the Application?

    Jason | http://blog.configmgrftw.com

    Tuesday, January 21, 2014 3:41 PM
  • I used a package for this, works fine. Running a batch or autoIt script as a deployment type will also work. But remember to give the return codes of the installation back to sccm from the batch or autoIt Script.

    for a Batch:
    exit /b %errorlevel%

    This returns the return code of the last executed file.

    • Proposed as answer by d4rkcell Monday, February 09, 2015 6:01 PM
    • Unproposed as answer by d4rkcell Monday, February 09, 2015 6:01 PM
    • Proposed as answer by d4rkcell Monday, February 09, 2015 6:01 PM
    Tuesday, January 21, 2014 3:46 PM
  • Jep. I've created a package which contains the *.exe and a single batch file. The batch file runs the *exe. Furthermore I've generated a softrware metering rule to detect the software. Unfortunately it's the only way I know to get the software installed.

    BTW: I knew that you are going to kill me :)

    Tuesday, January 21, 2014 3:47 PM
  • @Daniel: Just put the *exe in a package and it worked?
    Tuesday, January 21, 2014 3:49 PM
  • Did you create a package or an application?

    If you use a package, you do not have to use a batch. It's working without a batch file. Only when I use the new SCCM 2012 Application model, i have the problem.

    Daniel

    Tuesday, January 21, 2014 3:50 PM
  • Yes, here's the command line for the program:

    NDP451-KB2858728.x86-x64-AllOS-ENU.exe /q /norestart

    Tested this two times in the OSD Task Sequence and works fine.

    Tuesday, January 21, 2014 3:53 PM
  • Are there any updates to this error? I'm currently in the same situation...

    Deploying the .NET Framework 4.5.1 via package is working fine, but i need the application as dependency on other applications which i can't do with a packge..

    • Edited by eXpress48 Monday, February 17, 2014 2:38 PM
    Monday, February 17, 2014 2:34 PM
  • Do as Jay.Tung suggests and enable the option to run the installer as a 32bit program on 64bit systems. The .NET 4.5.1 installer is obviously getting confused about the Task Sequence Environment and it's 32bit status in a 64bit environment. I tried encapsulating the installer within a batch file that calls the Native command processor to do the install but it still failed with 16389. Jay.Tung's suggestion, however odd, does result in the Application (not package) being installed during OSD.

    My Personal Blog: http://madluka.wordpress.com

    Wednesday, February 19, 2014 11:02 AM
  • Huh, i obviously missed Jay.Tungs's post. Enabling "Run installation and uninstall program as 32-bit process on 64-bit clients." worked like a charm.

    Now i'm able to install .Net Framework 4.5.1 during an osd task sequence.

    • Edited by eXpress48 Wednesday, February 19, 2014 2:13 PM
    • Proposed as answer by NPhersonMVP Friday, April 04, 2014 1:18 PM
    Wednesday, February 19, 2014 2:12 PM
  • Just need to bring this topic back up...

    As i mentioned Enabling "Run installation and uninstall..." on the deployment type of my .NET Framework 4.5.1 Application solved the problem on the Task Sequence of my Windows 7 64-bit Clients.

    However we also got some Windows 7 32-bit Clients in our company, which i also want to deploy with .NET Framework 4.5.1.

    Here the Task Sequence fails at exactly the same point:

    [6/24/2014, 13:44:42] === Logging started: 2014/06/24 13:44:42 ===
    [6/24/2014, 13:44:42] Executable: C:\WINDOWS\ccmcache\1\NDP451-KB2858728-x86-x64-AllOS-ENU.exe v4.5.50938.18408
    [6/24/2014, 13:44:42] --- logging level: standard ---
    [6/24/2014, 13:44:42] Successfully bound to the ClusApi.dll
    [6/24/2014, 13:44:42] Error 0x80070424: Failed to open the current cluster
    [6/24/2014, 13:44:42] Cluster drive map: ''
    [6/24/2014, 13:44:42] Considering drive: 'C:\'...
    [6/24/2014, 13:44:42] Drive 'C:\' has been selected as the largest fixed drive
    [6/24/2014, 13:44:42] Directory 'C:\a896aaa45d652e576b\' has been selected for file extraction
    [6/24/2014, 13:44:42] Extracting files to: C:\a896aaa45d652e576b\
    [6/24/2014, 13:44:42] Error 0x80004005: Failed to extract all files out of box container #0.
    [6/24/2014, 13:44:42] Error 0x80004005: Failed to extract
    [6/24/2014, 13:44:42] Exiting with result code: 0x80004005
    [6/24/2014, 13:44:42] === Logging stopped: 2014/06/24 13:44:42 ===

    Any idea?


    • Edited by eXpress48 Tuesday, June 24, 2014 11:57 AM
    Tuesday, June 24, 2014 11:56 AM
  • There's no solution to this to my knowledge. I've resorted to using a package for this very issue.

    Curious if anyone has tried .Net Framework 4.5.2?


    Jason | http://blog.configmgrftw.com

    Tuesday, June 24, 2014 3:46 PM
  • Oliver wrote up that he saw a similar issue which required 'run as 32-bit' workaround:

    http://ardamis.com/2014/05/24/microsoft-net-framework-4-5-2-installation-fails-during-sccm-osd-task-sequence/

    Try wrapping your installer in a batch file in addition to the 'run as 32-bit'.  Not sure why this seems to help, but it works as an Application for me on both x86 and x64 OS architectures.

     

    Nash Pherson, Senior Systems Consultant
    Now Micro - My Blog Posts
    If you found a bug or want the product to work differently, share your feedback.
    <-- If this post was helpful, please click the up arrow or propose as answer.



    Tuesday, June 24, 2014 4:00 PM
  • Yep, so the same. Now someone just needs to open a CSS case as it probably won't get fixed without someone doing so.

    Jason | http://blog.configmgrftw.com

    Tuesday, June 24, 2014 4:18 PM
  • Try wrapping your installer in a batch file in addition to the 'run as 32-bit'.  Not sure why this seems to help, but it works as an Application for me on both x86 and x64 OS architectures.

    I tried that, but it didn't helped. I created a batch file which is executing the .NET Installer:

    "%~dp0NDP451-KB2858728-x86-x64-AllOS-ENU.exe" /q /norestart /ChainingPackage "ADMINDEPLOYMENT"

    But the Task Sequence fails at the same point with the same message.


    • Edited by eXpress48 Wednesday, June 25, 2014 8:51 AM
    Wednesday, June 25, 2014 8:41 AM
  • We're currently experience the same situation here. We will open a case. I will inform about any news on that.


    Wednesday, June 25, 2014 8:52 AM
  • Running as a 32-bit process on 64-bit clients fixed this for us as well.
    Wednesday, July 16, 2014 4:58 PM
  • I've run into this exact error historically, and currently, both in the ConfigMgr 2012 Application Model, and deploying the .NET Framework 4.5.1 (and now 4.5.2) via PowerShell Remoting (WS-Management / WinRM).

    At my most recent customer, I thought that checking the "Run as 32-bit process" checkbox, in the Deployment Type, fixed the problem. The deployment ran successfully on a variety of computers, but we ran across one computer that still experienced the issue.

    The fallback option, in this case, is to use the Package/Program model, instead of the ConfigMgr 2012 Application Model.

    Cheers,
    Trevor Sullivan
    Microsoft MVP: PowerShell


    If this post was helpful, please click the little "Vote as Helpful" button :)

    Trevor Sullivan
    Trevor Sullivan's Tech Room
    Twitter Profile

    Thursday, July 24, 2014 5:31 PM
  • I find a solution for this issue.

    Extract the .Net framework 4.5.1 setup file manually by using /x option and set that directory as the DT start directory.

    Program:'Setup.exe /q /norestart /SkipMSUInstall /chainingpackage NETFX45WURTM /x86 /x64 /redist'

    It works fine for me.

    Monday, August 04, 2014 4:15 AM
  • This works fine on my system as well. But the extracted .NET setup is around 1.1 GB which will be transfered every time from the distribution point to the client.
    Tuesday, August 05, 2014 9:29 AM
  • You can just use the content downloaded by WSUS or SUP and extracted source file is about 450MB.
    • Edited by Nodium Wednesday, August 06, 2014 6:10 AM
    Tuesday, August 05, 2014 10:09 AM
  • Just use the 68 MB installer and a batch file.  For your Deployment Type's program, check the box that says "Run installation and uninstall program as 32-bit process on 64-bit clients" and it will work with what the vendor gives you.

      

    I hope that helps,

     

    Nash


    Nash Pherson, Senior Systems Consultant
    Now Micro - My Blog Posts
    If you found a bug or want the product to work differently, share your feedback.
    <-- If this post was helpful, please click the up arrow or propose as answer.

    Tuesday, August 05, 2014 1:32 PM
  • @ NPherson, with a batch file and "Run installation and uninstall program as 32..." the deployment during Task Sequence runs perfectly fine on a Windows 7 x64 Task Sequence. However if i use the application in a Task Sequence which is installing Windows 7 x86, the Deployment will fail with the posted extraction error.

    Wednesday, August 06, 2014 6:08 AM
  • I just tested successfully with 4.5.2 last night on W7 x86 and W8.1 x86.  I'll try again with a clean WIM (without any updates or other previous .NET).

     


    Nash Pherson, Senior Systems Consultant
    Now Micro - My Blog Posts
    If you found a bug or want the product to work differently, share your feedback.
    <-- If this post was helpful, please click the up arrow or propose as answer.

    Wednesday, August 06, 2014 12:57 PM
  • I ran into this issue too and wanted to share my findings.

    I had my application for .NET setup to install for System which constantly failed to install with the same error although it would install if I ran it manually from Software Centre.

    CMTrace shows that the application was installing in system context however when run from Software Centre it runs as User Context.

    I've changed my app to Install for User and all is working now.

    Thursday, September 25, 2014 10:44 AM
  • I wanted to post this so other users can leverage the info. Here are the results with SCCM 2012 and .NET 4.5.2. I believe the issues stem from the compressed EXE needing to extract within a User Interface of some sort

    Using the 70Mb Compressed Installer with these switches works fine with Package Model 32bit or 64bit

    1. path_to_setup.exe /norestart /passive /log c:/windows/logs/blah.log
    2. /passive worked from a wrapper script/batch and /q often didn't
    3. This works for Application Model as well on 64bit PC's If you check off the “Run installation and uninstall program as 32-bit process on 64-bit clients.” checkmark box
    4. this works for Application Model on 32bit PC’s as well IF:
      1. You run “Only when the user is logged in” – Again related to running in a UI, also means the reboot countdown SCCM thing will be displayed to the user
      2. The user runs from Software Center – Again related to running in a UI
      3. This will not work if no user is logged in, this will not run from the software catalog

    If you extract the package it worked out to be 450Mb for Windows 7 by removing Windows server, Window 8 patches/files. Run this command on the extracted files (directly or in a wrapper script):

    1. path_to_setup.exe /norestart /q /x86 /x64 /redist /log c:/windows/logs/blah.log
    2. This works everywhere - package, application, 32bit/64bit, software center, software catalog, when a user is logged on or off the PC, etc but it does add some network traffic and bamdwidth.

    If someone manages to make the Application Model with a 32bit PC work for the 70Mb compressed installer please let me know.


    Tuesday, October 07, 2014 7:04 PM
  • Hello community,

    I know the last post is 3 months ago, but maybe I can help somebody with that information. OSD deployment with NET Framework 4.5.2 over SCCM 2012 R2 is working. Here are my steps:

    1. Step from MSDN.Microsoft.com
    (http://msdn.microsoft.com/en-us/library/ee390831(v=vs.110).aspx#creating_a_package)

    Same like in the link above, how to make an SCCM Package:

    In the Configuration Manager console, choose Software Library..
    In the Software Library workspace, expand Application Management, and then choose Packages.
    On the Home tab, in the Create group, choose Create Package.
    On the Package page of the Create Package and Program Wizard, enter the following information:
    Name: .NET Framework 4.5
    Manufacturer: Microsoft
    Language. English (US)
    Choose This package contains source files, and then choose Browse to select the local or network folder that contains the .NET Framework installation files. When you have selected the folder, choose OK, and then choose Next.
    On the Program Type page of the wizard, choose Standard Program, and then choose Next.
    On the Program page of the Create Package and Program Wizard, enter the following information:
    Name: .NET Framework 4.5
    Command line: dotNetFx45_Full_x86_x64.exe /q /norestart /ChainingPackage ADMINDEPLOYMENT (command-line options are described in the table after these steps)
    Run: Choose Hidden.
    Program can run: Choose the option that specifies that the program can run regardless of whether a user is logged on.
    On the Requirements page, choose Next to accept the default values, and then complete the wizard.

    Second step:
    In your Task Sequence in SCCM add an step "Install Package", but put this step AFTER "Setup Windows and Configuration". Then it is working without problems.

    Tested it with SCCM 2012 R2 and NET Framework 4.5.2

    Tuesday, January 06, 2015 11:20 AM
  • I used a package for this, works fine. Running a batch or autoIt script as a deployment type will also work. But remember to give the return codes of the installation back to sccm from the batch or autoIt Script.

    for a Batch:
    exit /b %errorlevel%

    This returns the return code of the last executed file.

    This worked for me with 4.5.2. Application using a batch file.
    Monday, February 09, 2015 6:02 PM
  • Could anyone share the Batch script for deploying .NET 4.5.2 via the Application Model? I still have the Problem, that on a Task Sequence with Windows 7 x86, the Installation Fails with the extraction error in the .NET Log.

    Installation via Task Sequence on Windows 7 x64 / Windows 8.1 x64 is working fine. I tried to move the Setup call in a Install.bat and run this via the deployment type, but with no success. Again, Win7 x64 is working fine, Win7 x86 not!

    The "Run as 32-bit process" is enabled on my deployment type!

    Thanks!


    Best regards, Simon





    Thursday, February 26, 2015 1:12 PM
  • I'm having the same problem here.

    Everything works great, except in Windows 7 x86.

    I've even extracted it myself (NDP451-KB2858728-x86-x64-AllOS-ENU.exe /extract), same issue.

    It also occurs with 4.5.2.


    Alexander S.

    Monday, March 16, 2015 8:28 PM
  • The extract will fail when in a task sequence. The workaround of running as x86 works for x64 systems. For x86 systems, it will need to be extracted before the task sequence starts.  I've written up a blog post on how to do this here (The same steps apply to both 4.5.1 and 4.5.2):

    http://www.nowmicro.com/deploying-net-framework-4-5-2-configmgr-application/

    I hope that helps,

    Nash


    Nash Pherson, Senior Systems Consultant
    Now Micro - My Blog Posts
    If you found a bug or want the product to work differently, share your feedback.
    <-- If this post was helpful, please click the up arrow or propose as answer.

    • Proposed as answer by TCZ30 Wednesday, May 06, 2015 7:25 PM
    Monday, March 30, 2015 1:24 PM