locked
All images suddenly failing? RRS feed

  • Question

  • I've been imaging fine with MDT 2012 with no problem...  I have a 64-bit Win8 image, a 64-bit Win 7 image and a 32-bit image.  The Win 7 images are for three different desktop systems and work fine on each of the them.  We had a need to add a new laptop so I imported it's drivers (into it's own folder), created a new task which was set to use those drivers, did a test deployment which failed because the NIC drivers didn't load.  Found out Dell hadn't included them in the management pack, so added them back into the same folder.  Now I am getting a failure on every deployment on every platform.  

    The first error is the status window at the end of the pre-install:

    During the deployment process, 7 errors and 1 warnings were reported...
    
    LiteTouch deployment failed, Return Code = -2147467259 0x80004005
    LiteTouch deployment failed, Return Code = -2147467259 0x80004005
    Failed to save environment to  (80070057)
    Fatal error is returned in check for reboot request of the action (Restart computer).
    Unspecified error (Error 80004005; Source: Windows)
    An error (0x80004005) is encountered in execution of the task sequence
    Task Sequence Engine failed! Code: 80004005
    Task sequence execution failed with error code 80004005
    Error Task Sequence Manager failed to execute task sequence.  Code 0x80004005


    Unfortunately, I know most of those errors aren't real helpful.  I have the logs being saved to a server using SLShare in the deployment rules, but I can't find anything in particular in the logs that tells me what's going on (and I'm not really sure which log I should be looking at).

    If I restart after the error, it looks like Windows did it's initial image deployment, as it goes into "Starting windows... Updating registry settings...  starting services..." etc.  It pops up an "Unable to find LiteTouch.wsf needed to continue the deployment."  Confirming that starts setting up personalized settings, then gives me a desktop that appears to have my configuration preferences, but none of the app installs run.  

    Other info that might be helpful: Not joining a domain during installation, no custom steps added to tasks, I use gparted to wipe the drives and partitions prior to deploying, not renaming administrator account, using WDS to host boot images from MDT, which the clients use for UEFI IP4 PXE booting.

    Would appreciate any ideas of where to go from here.  

    Oh... I did remove the newly added drivers and completely regenerated the boot images, with no changes in behavior.



    --smthng

    Tuesday, September 24, 2013 4:01 PM

All replies

  • Why do you use gparted for swiping the disk when the mechanism to diskpart and format is right there in MDT?

    Also why do you have 3 or 4 separate images for your computer models? The power of MDT is just to have 1 image for dozens of models, this can be achieved by targeting drivers of certain models, via Selection Profiles, like it is done here:
    Deploying Windows 7 - Part 25: Managing Drivers – Selection Profiles

    and here:
    Johan Arwidmark - MDT 2010 Lite Touch Driver Management (the site is currently unavailable, but it is a good read)

    Also, check your logs, bdd.log is not the only log. Enable monitoring and count the number of steps where the installation stalls. To find and read more logfiles, read this blog, and open your logfiles with trace32 or trace64.exe:
    Where to find the right MDT 2010 logs

    Basically your error can occur due to bad driver management, but it is also perfectly possible that by formatting your drives with gparted, valuable information (like the C:\MININT folder) gets deleted along the process. To know more, you need to post your logs (preferably zipped)


    If this post is helpful please click "Mark for answer", thanks! Kind regards

    Tuesday, September 24, 2013 6:20 PM
  • I thought it would be kind of rude to just dump all my log files up here and expect everyone else to pick through them, but...  Here they are.

    I use GParted to start again on a system, or when I want to wipe out the factory image that it comes with. My only point of mentioning that was to indicate that there was no old data on the system prior to deployment.  I know MDT can wipe and re-partition, but there are times when it doesn't like to and old partitions can block new installs.  Those are eliminated by wiping the partitions first.

    I've read the driver management article and that's generally what I'm doing.  I have three base images... Win7x64, Win7x86, Win8x64.  I apply drivers based on the device by using different tasks that specify which driver selection profile to use.  There's no added benefit to me doing some database managed driver selection or conditional installs...  I pick what platform I want and tell it if it's one of our three standard laptops or two standard desktops.  It pulls down the appropriate WIM, injects the appropriate drivers for that hardware platform and I'm usually golden.

    I just can't figure out now what's broken from the minor additions of the new laptop.  I've undone everything I can think of and regenerated, I'm just getting no where.



    --smthng

    Tuesday, September 24, 2013 7:00 PM
  • I found something in the smsts.log:

    Reboot to local harddisk
    FALSE, HRESULT=80004005 (e:\nts_sms_fre\sms\client\tasksequence\executionengine\engine.cxx,584)
    Fatal error is returned in check for reboot request of the action (Restart computer). 
    Unspecified error (Error: 80004005; Source: Windows

    An error (0x80004005) is encountered in execution of the task sequence

    On which I found the following thread:
    Restart Computer Task Sequence fails could you please verify, that this is not your issue? Since it sure looks a lot like it
    See more on the same problem:
    Problem injecting drivers to my boot image which leads to this: ConfigMgr 2007: OSD Task Sequence Fails with "Task sequence cannot continue after reboot because TS Manager is not configured to auto-start or GINA is not installed" and this: SCCM OSD - error whene restart to winpe

    concluding:

    Check your WIM file and C:\ drive of the computer you are deploying to for a "boot" folder and check your bootmgr, check if you have a restart computer step added in after deploying your image

    good luck :)


    If this post is helpful please click "Mark for answer", thanks! Kind regards

    Tuesday, September 24, 2013 8:06 PM
  • Hey Rens, I checked through all of those posts and I don't think they really apply.  That issues seems to be specific for SCCM.  Even if not, I know I haven't changed the task sequence for the tasks that were there before I imported the new laptop drivers.  

    Regardless, I went looking through the task sequence, and the closest thing I could find to the ones mentioned above is a "Restart Computer" task during the "Postinstall" phase.  I haven't messed with it and there are no options available for it...  The only options it offers are the generic "Disable this step" and "Continue on error".

    What I see that don't remember seeing before is "Add Windows Recovery (WinRE)".  We don't use WinRE and do not have it available, so I don't know where that came from.  I'll disable it tomorrow and see if that clears it.  If not...  is there anything else I can do in the task list to help narrow this down?  I generally don't mess with the task list if I can help it...  way too many options there for me to track down for the simple deployments we need.


    --smthng

    Tuesday, September 24, 2013 10:09 PM
  • Hi, what else you can do is, create a new standard deployment tasks sequence, point to one of your reference images and see how that deployment goes. Basically it rules out any errors in the task sequence (since it is a new one), if the error still occurs there are two other things that might cause the problem: drivers and your WIM image

    If this post is helpful please click "Mark for answer", thanks! Kind regards

    Wednesday, September 25, 2013 7:06 AM
  • None of that made a difference.  I get the same results on every system with every task sequence.  I created a new task sequence with no modification at all and got the same issue.  Disabling WinRE had no effect either.

    The generic boot works without any issues... can I use that to test the WIM?  I think I remember a web site that showed how to do that, but can't find it now.  

    What are my other options?  Nuke all the drivers and reimport, then rebuild the boot images?


    --smthng

    Wednesday, September 25, 2013 1:21 PM
  • Could you perform a new build task sequence? Which would then rule-out your WIM image..
    And target only the drivers of the hardware you are going to deploy to. In the case of a virtual machine, only VMware / Hyper-V Vdrivers

    Are you testing on a virtual machine by the way?


    If this post is helpful please click "Mark for answer", thanks! Kind regards

    Wednesday, September 25, 2013 1:26 PM
  • I'm not sure what you mean by a "new build task sequence".  I created a new "Standard Client Task Sequence" last time with no changes or additional settings.  Just to be clear, here are the options I have when creating a new task sequence...

    • Sysprep and Capture
    • Standard Client Task Sequence
    • Standard Client Replace Task Sequence
    • Custom Task Sequence
    • Litetouch OEM Task Sequence
    • Standard Server Task Sequence
    • Post OS Installation Task Sequence
    • Deploy to VHD Client Task Sequence
    • Deploy to VHD Server Task Sequence

    I almost always use a Standard Client Task Sequence.  About the only customization I usually do is to add the MAK key and specify which selection profile to use for drivers.

    I'm deploying to physical hardware, but built the source/capture image on VMWare with no drivers added.

    I always select only the drivers for the hardware platform I'm deploying to.


    --smthng

    Wednesday, September 25, 2013 1:36 PM
  • OK, that's the info I need.

    You say you build your 'reference / source' image on VMware with no drivers, when I was asking "Could you perform a new build task sequence? Which would then rule-out your WIM image.." I was referring to that, does this still work? Just to make sure that basically your deployment infrastructure is still working. Because if you can build and capture a new image, you know for sure:

    1. it's not your task sequence

    2. it's not your MDT infrastructure

    So what can it be then, if you target your drivers (only the drivers that are needed, per model) with a selection profile, and you know for sure there are no conflicts with architecture (x86 or x64) and or storage driver conflict's, what remains is your WIM file. But the strange thing is, that you state that this has not been changed and deployment before worked for sometime.

    Check your MDT audit.log to see what has happened over time


    If this post is helpful please click "Mark for answer", thanks! Kind regards

    Wednesday, September 25, 2013 1:44 PM
  • I addressed it a slightly different way...  instead of recapturing, I nuked all the drivers for the new laptop and the WinPE drivers.  Reimported the WinPE drivers the systems all have in common and re-imported only the NIC and drive controller drivers for the new laptop to it's selection profile.  It now installs.  That tells me that the WIM is good and either the new laptop drivers somehow propagated to everything else and one of them is bad, or...  my Unnattend is bad... or both.

    Update - Unnattend is good...  Just reran my standard desktop install on our most common platform and it worked fine.  Now I just need to figure out which of the laptop drivers are "infecting" my others and do a package install afterwards on that platform instead of injecting.


    --smthng

    Wednesday, September 25, 2013 5:33 PM
  • Probably a storage driver :)

    If this post is helpful please click "Mark for answer", thanks! Kind regards

    Wednesday, September 25, 2013 6:14 PM
  • Whoops... This is my unsolved MDT uEFI bug.

    Note your smsts.log file shows:

    Failed to save the current environment block. This is usually caused by a problem with the program. Please check the Microsoft Knowledge Base to determine if this is a known issue or contact Microsoft Support Services for further assistance.
    The parameter is incorrect. (Error: 80070057; Source: Windows)	TSManager	9/24/2013 9:02:59 AM	1260 (0x04EC)
    

    See: http://social.technet.microsoft.com/Forums/en-US/c202ce56-d422-44ea-a3ce-d50b46ba6980/mst-2012-failed-to-inject-drivers-surface-pro-via-pxe-boot

    My recommendation is that if you have any unused Microsoft Support incidents, is to call up Microsoft Support and file a bug. Have them direct you to BoD then ArronCz.

    This bug is beyond the scope of the TechNet forums.


    Keith Garner - keithga.wordpress.com

    • Proposed as answer by Keith GarnerMVP Thursday, September 26, 2013 6:00 AM
    Thursday, September 26, 2013 5:59 AM
  • One possibility... Check your environment and make sure you are using the ADK with MDT 2012 Update 1, not the WAIK. IF you have *upgraded* your environment from the WAIK at any time. Nuke everything, and reinstall everything from scratch.

    Keith Garner - keithga.wordpress.com

    Saturday, September 28, 2013 6:45 AM
  • During the deployment process, 7 errors and 1 warnings were reported...
    
    LiteTouch deployment failed, Return Code = -2147467259 0x80004005
    LiteTouch deployment failed, Return Code = -2147467259 0x80004005
    Failed to save environment to  (80070057)
    Fatal error is returned in check for reboot request of the action (Restart computer).
    Unspecified error (Error 80004005; Source: Windows)
    An error (0x80004005) is encountered in execution of the task sequence
    Task Sequence Engine failed! Code: 80004005
    Task sequence execution failed with error code 80004005
    Error Task Sequence Manager failed to execute task sequence.  Code 0x80004005

    hi, i run into same problem with microsoft deploymet toolkit 2010 and 2013 (upgraded from 2010 to 2013). with both versions i had this problem.
    but reason was not mdt or waik.... it was "just" the harddrive of my dell optiplex 755. after changing physical drive all tasks executed successfully


    • Edited by schtebo Tuesday, November 19, 2013 9:43 AM
    Tuesday, November 19, 2013 9:41 AM
  • Hi,

    I run into this issue and after some troubleshooting I found out that the BIOS HDD settings were "wrong"

    I am using both a HyperV and DELL Optiplex 780 client. the VM was installing just fine with the default task but in the DELL Client it was failing like this:

    http://imgur.com/YsMdZG5

    My error consisted in the BIOS configuration of the HDD in which it should have been RAID Autodetect/ATA instead of RAID Autodetect/AHCI.

    Hope this helps somehow.

    Besmir

    Thursday, January 8, 2015 10:17 AM