Skip to content

October 9, 2014

21

Install Application Step fails in Task Sequence

We recently ran into a problem where we were getting failures in our OSD Task Sequences trying to use the Install Applications step using System Center Configuration manager 2012 R2.  When the Task Sequence hits the Install Application step it would fail with the error 0x80004005.  After some troubleshooting were able to isolate the cause of the problem and find a workaround.

In our testing we are deploying Windows 8.1 x64 along with some simple applications such as Adobe Reader and Office 2013.  What we first found was that if we used the WIM file from the DVD/ISO, such as when doing a Build and Capture, the Install Applications step would work successfully.  We then found, if we had more than one Install Applications step in that Task Sequence (such as Adobe Reader and Office 2013 in two separate task sequence steps), the second one would always fail.  We also then found if we used a WIM that was generated by running the Build and Capture sequence, Install Applications would fail the first time.  The theory of this reason is that because our Build and Capture used a single Install Applications step, the record/data of this carried over for new Task Sequences (despite being syspreped and having the SCCM client prepared for capture).  As we continued testing, we found one more scenario that also causes failures. If you have a single Install Application step with multiple apps inside of it, if any of those Applications require a reboot, then Applications that follow the reboot always fail to install with the same error.

When looking for a fix to this problem we found the behavior was slightly different with virtual machines and new faster physical desktops with SSD drives.  If using slower hardware or VMs, we found adding in a restart computer before any Install Application step, could allow this to work successfully in some cases.  However, we found these results to be inconsistent and not always the same on every run of the task sequence.

When looking for a fix, we found the cause of this problem.  Apparently after the SCCM Client initializes, the client isn’t actually ready to Install Applications IF the client has ever installed run the Install Applications step before.  The workaround is, after every reboot, add in a sleep for 180 seconds in the task sequence.  We accomplished this by adding a Run Command Line step after any action that reboots the system and there are still Applications that need to be installed.  The command line is: Powershell.exe -command start-sleep 180.  Where 180 is in seconds (3 minutes), we found anything less than 3 minutes could still fail the step with the same error and anything longer proved was unnecessary (however if you still see the issue simply increase this time).  If you have multiple Applications in a single Install Applications step, that require reboots, it is currently required to break these into multiple steps and add in a step for a 3 minute sleep in between each of them.

We brought this to and worked on with Microsoft support and it has been confirmed as a bug in System Center Configuration Manager 2012 R2.  There is no ETA on a fix.  Hopefully this workaround will help others until a fix is out.

Read more from Microsoft, SCCM, System Center
21 Comments Post a comment
  1. LongtimeUser
    Oct 29 2014

    This is happening for us too. Would appreciate a reference to any Microsoft KB number if/when it is published. Nice,clear article!

    Reply
    • Brent
      Oct 30 2014

      As far as I know, there is currently no KB article for this, if I hear of one being posted I’ll update this post with the link. Hopefully it will be fixed soon…

      Reply
  2. Nov 11 2014

    I have experienced the exactly same issue on both SP1 and R2.

    In my case I had several Install Application steps with several application in each step. I have only set a 8 minutes delay before the first Install Application step and it always work.

    cmd /c ping localhost -n 480 > NUL

    Reply
    • Brent
      Nov 11 2014

      Interesting that a 8 minute delay fixes it permanently, good to know, it must be something in how the client is initializing (longer delay lets it finish differently than my 3 minute delay does). With this issue dating back to SP1 and R2, it is amazing that it is still not fixed as it has been a core problem for quite a while now.

      Reply
  3. Jason
    Feb 1 2016

    I’m deploying Windows 10 and noticed the same situation for me. The pause 180 seems to work, but I still don’t understand why this is the case when my Windows 7 and Windows 8.1 deployment works fine without the pause.

    Did you ever figure out the reason?

    Reply
    • Brent
      Feb 3 2016

      Unfortunately I have never been able to figure out the complete reason. My best guess is that it has something to do with the client state after capturing a WIM/reinstall SCCM client in deployment. When I opened a ticket with MS and all they could tell me is that they had seen this before and recommended we add up to 5 minute delays (I have found that the 180 works fine), no information on a fix. For me, this also occurred in Windows 8.1, but only after I re-captured my WIM at some point. I think something in a later SCCM update brought this problem in. In some of my more advanced images, this can get really annoying because I have to insert the delay after any reboot, some TS have 5 reboots for different application installs; this adds 15 minutes to my image time.

      Reply
  4. Zuheri
    Feb 1 2016

    Can you please guide me through the installation? I’m a newbie on this and i’m required to have Win10 with Office 2016 on a task sequence.
    I’ll appreciate any help i can get.

    Reply
    • Brent
      Feb 3 2016

      Zuheri, that is really outside the scope of this blog, but there a lot of good resources out there for deploy Windows 10 and Office 2016 with SCCM. Here is one example: https://www.systemcenterdudes.com/sccm-2012-office-2016-deployment/. Only thing I would add is that you may need to add the sleep command mentioned in this blog between the “Setup Windows and Configuration Manager” step and the “Install Office” TS step in order to avoid the error mentioned in this blog.

      Reply
  5. Dave van Lare
    Feb 17 2016

    There is another workaround that does not impact deployment time: use packages, not applications.

    Reply
  6. Johan Pol
    Jun 14 2016

    I am facing the same issues and would like to be notified of progress on this one….

    Reply
    • Brent
      Jun 14 2016

      Best I can tell, MS has made no movement to fix this, I still have to maintain the workaround…

      Reply
      • Johan Pol
        Jun 20 2016

        I am goiing to try your workarounf by placing 180seconds delays before the application task actions and will see how that proceed.
        if that solves my issue as well with the Surface Pro 4 i will create case with Microsoft to solve this.
        The more cases for this the sooner a proper solution will be available.

        Reply
        • Brent
          Jun 20 2016

          Sounds good, hope workaround works. That would be great, the more cases we get on this, the more likely MS will fix it.

          Reply
          • Johan Pol
            Jun 29 2016

            Update: i included sleeps which does not complete solve my issue. But when adding additional reboots after the package/applications installations it seems to work fine now.
            I will do some more tests and then will add a case to Microsoft.

  7. Rocky
    Oct 3 2016

    We had the same issue. Followed your advice, worked perfectly.
    Ran this powershell code in task sequence, used sccm progress bar to let people know what was happening.

    param (
    [string] $Title = “Please Wait!!”,
    [Int] $Minutes = “3”)

    function UpdateProgress($uTitle, $uAction, $uStep, $uMaxStep){
    $tsprog.ShowActionProgress($tsenv.value(“_SMSTSOrgName”),$tsenv.value(“_SMSTSPackageName”),$tsenv.value(“_SMSTSCustomProgressDialogMessage”),$uTitle,$tsenv.value(“_SMSTSNextInstructionPointer”),$tsenv.value(“_SMSTSInstructionTableSize”),$uAction,$uStep, $uMaxStep)
    }

    $tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment
    $tsprog = New-Object -COMObject Microsoft.SMS.TSProgressUI
    $Time = $Minutes * 60
    foreach ($Count in (1..($Time))){
    $Action = “Waiting for $($Time) seconds, $($Time – $Count)s left!”
    UpdateProgress $Title $Action $Count $Time
    Start-Sleep -Seconds 1

    }

    Reply
    • Brent
      Oct 3 2016

      Rocky, thanks for the comment and sharing the script for the progress bar, very handy addition.

      Reply
  8. Syparon
    Oct 27 2016

    You made my day thx a lot !!!!

    Reply
  9. Matt
    Dec 11 2016

    I’m having the exact same issue, however we are using packages and not applications. We are using SCCM CB 1602 and deploying to Win10 Enterprise LTSB N 2016. We install about 5 packages post installation of the SCCM client within OSD. Sometimes (not always, sometimes everything installs without issue), one or more of the packages do not install and yet the task sequence log indicates that it installed successfully! This was driving me mad last week. I’ll try a restart and 3 minute pause in-between the installation of each package and provide feedback. Thanks for the tip.

    Reply
  10. Rich
    Mar 8 2017

    Wonder if it has to do with the SMS Client Host service being set to ‘Delayed Start. Be interesting to remove the delayed start and see if you still need to 180 delay.

    Reply
    • Brent
      Mar 29 2017

      I don’t believe that is the cause, as the Task Sequence waits for the Agent to Initialize before proceeding to next step, but it is a good thought to try.

      Reply

Trackbacks & Pingbacks

  1. Re: Install Application Step fails in Task Sequence | What have I done today?

Share your thoughts, post a comment.

(required)
(required)

Note: HTML is allowed. Your email address will never be published.

Subscribe to comments