none
Problem with Windows Deployment via LiteTouch on remote subnet RRS feed

  • Question

  • This is a very odd problem.  It did not happen until I updated everything to the new WinPE for Windows 8.

    I could deploy Win 7 via litetouch all day long on all of our subnets.  When I updated the MDT to the latest version, my remote subnet no longer can image over the network.  It boots to the usb drive and authenticates to the network.  It even pulls up the list of deployment packages that we can select from.  We can choose either our Win 7 or Win 8 deployment and it will act like it's starting, but will get the attached error every time.  

    The same boot disk works fine for both Windows 7 and Windows 8 on the subnet local to the MDT server share.

    I'm pretty baffled as to what happened and what to do about it.  I know that it's attaching and communicating on the network because the litetouch wizard obviously authenticates.  It seems that it's network related, but how and why?  It does this on both older and newer hardware on the remote subnet.

    Any suggestions out there?
    Wednesday, April 23, 2014 2:33 AM

Answers

  • Take a look at the bdd.log file from the client to see if it contains any more information. Best to view from within the CMTrace.exe reader.

    If you still need help, please copy the bdd.log file to a public site like OneDrive and post the public link here.


    Keith Garner - keithga.wordpress.com

    Wednesday, April 23, 2014 5:16 PM
    Moderator
  • It turned out that our SonicWall was throwing a false positive AV block on one of the deployment files.  It flagged it as SSIWG (a trojan).  Once that was disabled, everything started working as it should.  That explains why it started after an update and only happened when going across sites.

    That was truly maddening...

    • Marked as answer by BoomSchtick Friday, May 2, 2014 4:45 AM
    Thursday, May 1, 2014 7:07 PM

All replies

  • Take a look at the bdd.log file from the client to see if it contains any more information. Best to view from within the CMTrace.exe reader.

    If you still need help, please copy the bdd.log file to a public site like OneDrive and post the public link here.


    Keith Garner - keithga.wordpress.com

    Wednesday, April 23, 2014 5:16 PM
    Moderator
  • Here is the bdd.log file:

    http://pastebin.com/KB3k9mnn

    Here is the smsts.log

    pastebin.com/nxLTamhs

    CMTrace did not help me much as I don't really know what I'm looking for.

    Tuesday, April 29, 2014 9:51 PM
  • BTW... it was suggested that I create a new share and recreate the tasks as a troubleshooting step.  I have done that and the issues are still the same.  The logs posted above are from AFTER setting up the new share.
    Wednesday, April 30, 2014 3:14 AM
  • i looked at the bdd.log file, unfortunately the log is incomplete.

    See the last lines in the log file:

    ####### NOTE: If this is one of the last lines in your BDD.log file,
    check C: for the most up to date bdd.log!!!
    ZTIDiskpart processing completed successfully.

    Can you check for the bdd.log file on the local hard disk?

    Thanks!


    Keith Garner - keithga.wordpress.com

    Wednesday, April 30, 2014 3:59 PM
    Moderator
  • Oops...

    Here's the bdd from the c: drive

    http://pastebin.com/STGjv5T9

    Wednesday, April 30, 2014 4:18 PM
  • That's weird, looks like you lost network connectivity?!?!

    D:\>err 0x80070040 # as an HRESULT: Severity: FAILURE (1), Facility: 0x7, Code 0x40 # for hex 0x40 / decimal 64 : ...

    # /* system error */ ERROR_NETNAME_DELETED winerror.h # The specified network name is no longer available.

    Can you open a cmd.exe window using F8 and get to the network server using normal methods?

    dir Z:\

    Ping \\srever

    net use * \\server


    Keith Garner - keithga.wordpress.com

    Wednesday, April 30, 2014 4:23 PM
    Moderator
  • I can ping the server during the whole deployment. No packet loss. 

    Z:\ (mapped network drive) appears during the deployment until the error occurs

    And this happens with more than one model of Dell desktops
    • Edited by handstands Wednesday, April 30, 2014 10:15 PM
    Wednesday, April 30, 2014 10:14 PM
  • I'm not clear on this, are you saying that once the error occurs, you are no longer able to view mapped drives?

    If so, that is a problem, I would verify the drivers being used on these machines (check x:\windows\system32\wpeinit.log), to ensure a consistent network connection.


    Keith Garner - keithga.wordpress.com

    Wednesday, April 30, 2014 11:03 PM
    Moderator
  • It turned out that our SonicWall was throwing a false positive AV block on one of the deployment files.  It flagged it as SSIWG (a trojan).  Once that was disabled, everything started working as it should.  That explains why it started after an update and only happened when going across sites.

    That was truly maddening...

    • Marked as answer by BoomSchtick Friday, May 2, 2014 4:45 AM
    Thursday, May 1, 2014 7:07 PM