none
Deployment fails after os deployed RRS feed

  • Question

  • We are imaging Lenovo laptops in our school district. There are several different models and they all image perfectly except for one model, the Edge 15. We use the same 64 bit image on all of these. The task sequence starts then after the os is applied the laptop shuts down. Restarted the laptop and pxe booted again to see if the ts would continue. It fails and trying to start windows normally doesn't work either. I looked at the sms log and noticed a red error line stating: Error Task Sequence Manager failed to execute task sequence. Code 0x80004005.

    Accessing these logs are not a problem, understanding what they mean is something else. Anyone that can offer any advice would be deeply appreciated. Thanks in advance for the help.

    /Bob

    Thursday, August 27, 2015 3:51 PM

Answers

  • In the first post above you mention: "Restarted the laptop and pxe booted again to see if the ts would continue"  I don't understand this. Why would you PXE boot again into the machine after applying the image, you should let the machine reboot and continue with Windows OOBE setup. Do not interrupt the process by booting back into PXE, this is the classic definition of "dirty environment"

    Additionally Something is messed up in the logs here. I can see in the bdd.log file that you ran an installation on 8/27/2015 10:39:27 to 8/27/2015 10:55:11 but then the logs stopped, and it appears that it restarted again in mid-task sequence at 8/27/2015 11:25:51

      Console > Image Version: 6.1.7601.18489	LTIApply	8/27/2015 10:55:11 AM	0 (0x0000)
    Property LogPath is now = D:\MININT\SMSOSD\OSDLOGS	LiteTouch	8/27/2015 11:25:38 AM	0 (0x0000)
    

    What happened here?!?!? This is messed up.

    Then, without cleaning the machine, MDT attempted to re-apply the image, and got corrupted:

      Console > ImageX Tool for Windows	LTIApply	8/27/2015 11:26:07 AM	0 (0x0000)
      Console > Copyright (C) Microsoft Corp. All rights reserved.	LTIApply	8/27/2015 11:26:07 AM	0 (0x0000)
      Console > Version: 6.3.9600.17095	LTIApply	8/27/2015 11:26:07 AM	0 (0x0000)
      Console > [   0% ] Applying progress 	LTIApply	8/27/2015 11:26:07 AM	0 (0x0000)
      Console > [   0% ] Applying progress 	LTIApply	8/27/2015 11:26:20 AM	0 (0x0000)
      Console > [   1% ] Applying progress 	LTIApply	8/27/2015 11:26:20 AM	0 (0x0000)
      Console > [ ERROR ] C:\O365Pro\Office\Data\15.0.4719.1002\stream.x86.x-none.dat (Error = 112)	LTIApply	8/27/2015 11:26:20 AM	0 (0x0000)
      Console > Error restoring image.	LTIApply	8/27/2015 11:26:20 AM	0 (0x0000)
      Console > There is not enough space on the disk. 	LTIApply	8/27/2015 11:26:20 AM	0 (0x0000)
    Return code from command = 2	LTIApply	8/27/2015 11:26:20 AM	0 (0x0000)
    FAILURE ( 5624 ): 2: Run ImageX:  /apply "\\board-mmdt.admin.bloomfield.k12.nj.us\DeploymentShare$\Operating Systems\64BIT-7-2015\64BIT-7-2015.wim" 1 C:	LTIApply	8/27/2015 11:26:20 AM	0 (0x0000)
    
    Yup, there is something corrupted in the deployment here.


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Monday, August 31, 2015 4:04 AM
    Moderator
  • Update to this situation. The deployment was fine, being over 700 machines were imaged with it. We found that a setting used in Office 365 was creating the problem. Used a previous image without this setting and the laptop imaged fine. Thank you all for the help
    • Marked as answer by Burntout Tuesday, September 1, 2015 1:37 PM
    Tuesday, September 1, 2015 1:37 PM

All replies

  • Post the logs to OneDrive and share the link. 

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Thursday, August 27, 2015 4:58 PM
    Moderator
  • No problem. Which logs specifically do you want to see?

    If that's a dumb question, I apologize.

    Thursday, August 27, 2015 5:02 PM

  • Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Thursday, August 27, 2015 5:46 PM
    Moderator
  • I would suggest that the logs aren't much help here.

    The problem is that when it PXE boots for the second time, it expects to find a clean environment in order to start the build but it finds a dirty environment. You should only PXE boot once per rebuild - at the very start.

    Without knowing what your Task Sequence is doing I'll give an example - say it applies the OS in PE then reboots back to PE and tries to install .Net, this isn't going to work as it expects to be in Windows 7/8/10 in order to perform this action. The result is the very generic 0x80004005.

    So, what to do is to change the boot order and move the NIC below the HDD and that way when it starts up after applying the OS it will boot to Windows on the hard drive and then the task sequence will continue where it's meant to.

    Try that and let us know how it goes.

    Friday, August 28, 2015 8:56 AM
  • Here is the link Ty. Hope it works

    https://edubloomfieldk12nj-my.sharepoint.com/personal/bcece_bloomfield_k12_nj_us/_layouts/15/start.aspx#/Documents/Forms/All.aspx?RootFolder=%2Fpersonal%2Fbcece%5Fbloomfield%5Fk12%5Fnj%5Fus%2FDocuments%2FMDT&FolderCTID=0x012000C2CD37492739B647A0241846821940E8&View=%7BE8F08189%2DF16B%2D4CA1%2D9F2E%2D50FF1636A16A%7D

    Friday, August 28, 2015 1:28 PM
  • I haven't read the log file. But Code 0x80004005 normally means Access Denied from memory.

    Whatever the next step in the TS is, I would make sure the account used to deploy the task sequence has access to it.

    Thanks
    NN

    0x80004005 doesn't mean anything useful in terms of MDT. The log that was uploaded isn't accessible and as I mentioned earlier I don't believe it will be of any use given that its failing in PE doing an action that should be completed in the full OS.


    Friday, August 28, 2015 1:54 PM
  • The link should be accessible now. It's not an access denied problem. We imaged over 700 computers with this image and there are presently only 3 laptops having this problem. Probably because these are the first of these models that are being done. I don't understand why you say the log files probably won't help. If their useless then why have them? Thanks anyway.
    Friday, August 28, 2015 2:10 PM
  • Sounds like you know what youre doing but I have had something similar due to drivers or packages ive used in the past. To me right now (still not seen log file) it could be a couple of things. Bad network driver or bad storage controller (especially when RAID setup). I would check your drivers, I had a couple models this year that struggled to install the network drivers through the SCCM MDT task sequence which I believe gave the 0x80004005 error code (yes it is an unspecified error, but its common to normally get this code when something is inaccessible, this case might be network related). I had to use the manufacturers own network drivers to solve this.

    Anyway confirming this is working might help you, that's my 2 cents. I hope it helps. Good luck.

    NN

    Friday, August 28, 2015 2:32 PM
  • Thanks for the reply NN. I thought of that two days ago and imported several drivers into MDT. No good. But I'll give it another look. Thanks again.
    Friday, August 28, 2015 2:40 PM
  • I can't access your sharepoint.

    Most important details are logs. If you are unsure how to post logs or where to find them then reference https://keithga.wordpress.com/2014/10/24/video-mdt-2013-log-files-basics-bdd-log-and-smsts-log/

    Friday, August 28, 2015 3:33 PM
    Moderator
  • Sorry for the delay. Haven't used sharepoint, no need to. Try this link to dropbox and see if you can help me out.

    Thanks for the help Ty.

    https://www.dropbox.com/s/igyjxh8tluz55pk/smsts.log?dl=0

    https://www.dropbox.com/s/a1zojvg9dujarry/BDD.LOG?dl=0

    Friday, August 28, 2015 4:32 PM
  • Does Dropbox disallow public sharing?

    Most important details are logs. If you are unsure how to post logs or where to find them then reference https://keithga.wordpress.com/2014/10/24/video-mdt-2013-log-files-basics-bdd-log-and-smsts-log/

    Friday, August 28, 2015 8:19 PM
    Moderator
  • It should. I checked that anyone with the link can access it. If it doesn't I'll have to figure this out some other way. Don't have the time to learn sharepoint right now. Busier than a one armed paper hanger. If no progress I thank you for the help anyway. I'll mark answered to close this post if need be.
    Friday, August 28, 2015 8:29 PM
  • In the first post above you mention: "Restarted the laptop and pxe booted again to see if the ts would continue"  I don't understand this. Why would you PXE boot again into the machine after applying the image, you should let the machine reboot and continue with Windows OOBE setup. Do not interrupt the process by booting back into PXE, this is the classic definition of "dirty environment"

    Additionally Something is messed up in the logs here. I can see in the bdd.log file that you ran an installation on 8/27/2015 10:39:27 to 8/27/2015 10:55:11 but then the logs stopped, and it appears that it restarted again in mid-task sequence at 8/27/2015 11:25:51

      Console > Image Version: 6.1.7601.18489	LTIApply	8/27/2015 10:55:11 AM	0 (0x0000)
    Property LogPath is now = D:\MININT\SMSOSD\OSDLOGS	LiteTouch	8/27/2015 11:25:38 AM	0 (0x0000)
    

    What happened here?!?!? This is messed up.

    Then, without cleaning the machine, MDT attempted to re-apply the image, and got corrupted:

      Console > ImageX Tool for Windows	LTIApply	8/27/2015 11:26:07 AM	0 (0x0000)
      Console > Copyright (C) Microsoft Corp. All rights reserved.	LTIApply	8/27/2015 11:26:07 AM	0 (0x0000)
      Console > Version: 6.3.9600.17095	LTIApply	8/27/2015 11:26:07 AM	0 (0x0000)
      Console > [   0% ] Applying progress 	LTIApply	8/27/2015 11:26:07 AM	0 (0x0000)
      Console > [   0% ] Applying progress 	LTIApply	8/27/2015 11:26:20 AM	0 (0x0000)
      Console > [   1% ] Applying progress 	LTIApply	8/27/2015 11:26:20 AM	0 (0x0000)
      Console > [ ERROR ] C:\O365Pro\Office\Data\15.0.4719.1002\stream.x86.x-none.dat (Error = 112)	LTIApply	8/27/2015 11:26:20 AM	0 (0x0000)
      Console > Error restoring image.	LTIApply	8/27/2015 11:26:20 AM	0 (0x0000)
      Console > There is not enough space on the disk. 	LTIApply	8/27/2015 11:26:20 AM	0 (0x0000)
    Return code from command = 2	LTIApply	8/27/2015 11:26:20 AM	0 (0x0000)
    FAILURE ( 5624 ): 2: Run ImageX:  /apply "\\board-mmdt.admin.bloomfield.k12.nj.us\DeploymentShare$\Operating Systems\64BIT-7-2015\64BIT-7-2015.wim" 1 C:	LTIApply	8/27/2015 11:26:20 AM	0 (0x0000)
    
    Yup, there is something corrupted in the deployment here.


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Monday, August 31, 2015 4:04 AM
    Moderator
  • Update to this situation. The deployment was fine, being over 700 machines were imaged with it. We found that a setting used in Office 365 was creating the problem. Used a previous image without this setting and the laptop imaged fine. Thank you all for the help
    • Marked as answer by Burntout Tuesday, September 1, 2015 1:37 PM
    Tuesday, September 1, 2015 1:37 PM
  • Can you be more specific on how this setting was doing this, and how the previous image differed?

    I may have a similar issue with lenovo hardware, stuck in a loop giving dirty environment messages.

    Thanks!

    Tuesday, June 28, 2016 3:24 PM
  • We had tried to have office 365 install the wrong way. We found the following:

    https://technet.microsoft.com/en-us/library/dn314789.aspx

    We used this method to deploy without a problem.

    Tuesday, June 28, 2016 3:50 PM