none
.NET 4 deployment fails with exit code -2146697211

    Pregunta

  • I'm trying to distribute .NET 4 to Windows 7 x64 clients.  I've setup the package according to Microsofts document here:

    http://msdn.microsoft.com/en-us/library/ee390831.aspx

    The command line I'm using is:

    dotNetFx40_Full_setup.exe /q /norestart

    When my client receives the package it runs for about 10 minutes and then fails.  If I look in advertisement status the error message I get is:  The program failed.  A failure exit code of -2146697211 was returned.

    If I go to the client and look at execmgr.log I see:

    Program exit code -2146697211
    Install failed with exit code failed with exit code 2148270085
    Execution is complete for program "Silent Install".  The exit code is -2146697211, the execution status is FailureNonRetry

    Anybody have this problem before?  Any idea what might be causing it?

    Thanks,
    Jan

    martes, 22 de febrero de 2011 0:24

Respuestas

  • It turned out to be bad source files.  The file size on the distribution point did not match the file size that I originally downloaded from my package source.  I downloaded new source files, created a new package, and pushed it with the same switches and it installed fine.  Just wanted to post so its searchable for future.

    Thanks,
    Jan

    • Marcado como respuesta Janet Schiller jueves, 24 de febrero de 2011 0:44
    jueves, 24 de febrero de 2011 0:44

Todas las respuestas

  • The document you link to gives the command line as: dotNetFx40_Full_x86_x64.exe /q /norestart /ChainingPackage ADMINDEPLOYMENT Is there a reason you left off the /ChainingPackage ADMINDEPLOYMENT ? Could you test that against a pilot collection with one client?
    martes, 22 de febrero de 2011 0:40
    Moderador
  • Hi Eric, thanks for your reply.

    I left it off because the link describes that switch as follows:

    /chainingpackage PackageName

    Specifies the name of the package that is doing the chaining. This information is logged and stored with the SQM data for the .NET Framework installation session. If the package name includes spaces, use double quotation marks as delimiters; for example: /chainingpackage "Chaining Product".

    I don't have a package doing chaining (what the heck is chaining for .net anyway??)

    If I run the command line with the /Q or the /Q /NORESTART switches from a command line (logged-in as an admin) it runs fine on my test boxes.  So I should be able to send the same source with the same command line via SCCM and expect to see the same results I think.

    I will try the /chainingpackage switch tomorrow and post back if it works.

    Thanks,

    Jan

    martes, 22 de febrero de 2011 6:36
  • I don't have a package doing chaining (what the heck is chaining for .net anyway??)

    checkout: http://msdn.microsoft.com/library/ee942965(v=VS.100).aspx#installing_manually this explains installer chaining in the .NetFW context.

    (basically an application installer would chain/spawn the .NetFW installer, then return to the application installer. this is a typical use-case, but for us who have to adhere to "managed/known/desired state" client environments, is usually unacceptable, right?)

    Aaron Stebner's blog http://blogs.msdn.com/b/astebner/, and also Coreworx's blog http://scug.be/blogs/sccm/archive/2010/12/14/net-framework-4-0-silent-deployment-for-software-distribution-or-osd-ts-howto.aspx, have great tips for .NetFW 4.0 silent install.


    tesgroup
    martes, 22 de febrero de 2011 20:32
  • If I run the command line with the /Q or the /Q /NORESTART switches from a command line (logged-in as an admin) it runs fine on my test boxes.  So I should be able to send the same source with the same command line via SCCM and expect to see the same results I think.

    No, not really. logged-in as admin is not the same as what ConfigMgr is doing.
    to get equivalence, you need to use something like psexec -s -i cmd.exe

    this starts the console shell in the LocalSystem context, which is exactly what ConfigMgr does.


    tesgroup
    martes, 22 de febrero de 2011 20:36
  • It turned out to be bad source files.  The file size on the distribution point did not match the file size that I originally downloaded from my package source.  I downloaded new source files, created a new package, and pushed it with the same switches and it installed fine.  Just wanted to post so its searchable for future.

    Thanks,
    Jan

    • Marcado como respuesta Janet Schiller jueves, 24 de febrero de 2011 0:44
    jueves, 24 de febrero de 2011 0:44