none
MDT 2013 Hangs at Cleaning Drive and 100% Applying Image RRS feed

  • Question

  • Dealing with a strange issue with MDT 2013. Our task sequences (all of them, doesn't matter if it's 2008 R2, 2012, or 2012 R2) seem to be randomly hanging at the Cleaning Drive or after getting to 100% Applying Image phase - no errors. If I open a command prompt before starting, then run a task sequence, when it gets to that part where it hangs, if I run diskpart it'll immediately continue. Don't have to enter any commands, just have to run diskpart. The logs don't show any errors - for instance, on one where it hung at 100% applying image:

    <![LOG[Return code from command = 0]LOG]!><time="11:04:24.000+000" date="11-11-2013" component="LTIApply" context="" type="1" thread="" file="LTIApply">
    <![LOG[Find the boot drive (if any) [True] [6.1.7601.17514] [False]]LOG]!><time="11:04:24.000+000" date="11-11-2013" component="LTIApply" context="" type="1" thread="" file="LTIApply">

    Nothing after that - as soon as I run diskpart, the deployment will continue. I've tried this on several different Dell PowerEdge systems (M600, 1955, R710) and see the same random behavior. It happens about 50% of the time. I tried adding the latest PERC driver, and also tried disabling the PERC drivers entirely so it would just use in-box drivers with the same result. This was a MDT 2012 U1 installation that was upgraded to MDT 2013. Note that this does not happen when deploying to VMware virtual machines, only physical systems.

    I'm at a loss ...


    Jeff Graves, ORCS Web, Inc.

    Tuesday, November 12, 2013 8:56 PM

Answers

  • We ended up opening a PSS case on this. Looks like it was driver related. Tried several versions until we found one that works.

    Jeff Graves, ORCS Web, Inc.

    Tuesday, November 26, 2013 7:56 PM

All replies

  • Jeff,

    Maybe set the WIPEDISK property to TRUE in your CS.ini, that basically formats the disk prior to applying the image.

    "Specifies whether the disk should be wiped. If WipeDisk is TRUE, the ZTIWipeDisk.wsf script will clean the disk using the Format command. The Format command is not the most "secure" way of wiping the disk.

    Securely wiping the disk should be done so in a manner that follows the U.S. Department of Defense standard 5220.22-M, which states, "To clear magnetic disks, overwrite all locations three times (first time with a character, second time with its complement, and the third time with a random character)."

    When MDT wipes the disk, it uses the Format command with the /P:3 switch, which instructs Format to zero every sector on the volume and to perform the operation three times. There is no way to tell the Format command to use a particular character or a random character."

    -BrianG (http://supportishere.com)

    Wednesday, November 13, 2013 7:56 AM
  • Two things...

    Jeff - There is not much MDT can do if the diskpart.exe command is hung due to some deadlock issue on the VDS Service.  If this is an important issue, I would open up a case with Microsoft with the repro scenario, so they can debug the underlying issue. Lately, I've only seen this on high end servers with RAID Cards.

    Brian - ZTIWipeDisk.wsf is not used in a new computer scenario, it's used in the Replace scenario when a computer is about to be decommissioned.  

    I disagree with the MDT documentation.

    1) the format command in Windows 8 ( and I believe windows 7 ) *will* use random numbers.

      /P:count        Zero every sector on the volume.  After that, the volume
                      will be overwritten "count" times using a different
                      random number each time. ...

    2) However, IMHO DOD it's still overkill. See:  http://security.stackexchange.com/questions/10464/why-is-writing-zeros-or-random-data-over-a-hard-drive-multiple-times-better-th

    If you have *secure* data on a hard disk then you should be using encryption. :^)


    Keith Garner - keithga.wordpress.com

    Thursday, November 14, 2013 4:20 AM
    Moderator
  • We ended up opening a PSS case on this. Looks like it was driver related. Tried several versions until we found one that works.

    Jeff Graves, ORCS Web, Inc.

    Tuesday, November 26, 2013 7:56 PM