Sign in
 
HomeLibraryWikiLearnGalleryDownloadsSupportForumsBlogs
Resources for IT Professionals >
> 
> 
> 
MDT2010 error in Refresh Scenario!

已答复 MDT2010 error in Refresh Scenario!

  • Thursday, November 12, 2009 12:18 PM
     
     
    Sign In to Vote
    0
    Hi,

    I'm trying to test "Refresh Scenario" with MDT 2010 for the first time, i call LiteTouch.vbs and it runs successfully through capturing user state and then applying Windows PE, it restarts and boots to windows PE when it suddenly stops with the following error in the command prompot (before i see any progress bar, i can just see the custom background i made for my windows PE):



    A winpeshl.ini file is present, but no commands were successfully launched. This could be caused by incorrect formatting or an invalid executable name. Please consult the documentation for more information.

    X:\windows\system32>




    Any help would be appreciated.

    Regards,
    Basel
     

All Replies

  • Friday, November 13, 2009 9:12 AM
     
     
    Sign In to Vote
    0
    That's odd.  Can you look at the X:\Windows\system32\wpeinit.log to see what happened there?

    How much memory is in the machine?  512MB is the minimum.

    -Michael Niehaus
     Senior Software Development Engineer
     mniehaus@microsoft.com
     
  • Friday, November 13, 2009 10:29 AM
     
     
    Sign In to Vote
    0
    Hi Michael,

    I have no access currently to my testing environment to check the wpeinit.log file, i'll do that later and come back to you with my findings. But, the memory allocated for my client machine is 1G (it successfully runs through verify tasks in my Task Sequence). I'm using hyper-v environment, my MDT server is a virtual machine as well.

    One thing i noticed might be useful, when i tried to connect to the deploymentshare$\scripts folder to run the LiteTouch.vbs script using MDT server's Host name it failed, but when i replaced host name by MDT server's IP address it worked, is it -by any means- related?
     
  • Friday, November 13, 2009 1:57 PM
     
     
    Sign In to Vote
    0

    it appears your name resolution is not working, and you are going to need that to have lite touch connect to your deployment share. Check your netbios and dns name resolution, and make sure the windows firewall on the machine that is storing the files has file and print sharing allowed.

     
  • Friday, November 13, 2009 4:20 PM
     
     
    Sign In to Vote
    0
    But Jonathan, I can successfully connect to the share using Host name, what failed -like i explained in the above post- is the execution of the script when i connected to the share using Host name, the execution of the script worked however when i connected to the share using IP address. I agree it might be a name resolution issue but something starts after the script initiates not before.

    Windows firewall is off, and all possible sharing options are "On" on my "windows server 2008" MDT server. I'll check DNS further though.
     
  • Sunday, November 15, 2009 1:55 PM
     
     
    Sign In to Vote
    0
    Hi Again, sorry for being late i was at a customer site.

    Jonathan, I checked my name resolution process and it's working just fine, but i was able to connect to the share normally after using the FQDN of the MDT server afterwhich the LiteTouch.vbs ran successfully, captured user state, applied Windows PE and restarted, then i was hit with the same error above in Windows PE.

    Michael, i tried searching for wpeinit.log in system32 and other directories but in vain, it seems it is not created yet. All logs in C:\MINNT seem to have information for what happened only before the restart, and all is well.

    Any ideas?
     
  • Sunday, November 15, 2009 2:46 PM
     
     
    Sign In to Vote
    0
    An update:


    I tried to open winpeshl.ini to check what's inside, i found only 2 lines:

    [LaunchApps]
    %SYSTEMROOT%\system32\bddrun.exe,/bootstrap

    Then i executaed the above command (bddrun.exe ..) manually, the following was returned:

    This version of X:\windows\system32\BDDRUN.exe is not compatible with the version of Windows you're running. Check your computer's system information to see whether you need a x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher.

    I'm using hyper-v, the client architecture is x64, OS on client is x64 and windows PE is also x64. How could not the bddrun.exe version be compatible?!
     
  • Sunday, November 15, 2009 8:31 PM
    Moderator
     
     
    Sign In to Vote
    0
    The wrong version could have been copied during creation of the litetouch_x64.iso image.
    Verify that the version in the x:\windows\system32 directory is the correct version.
    x64 - bddrun.exe 131,480 bytes
    x86 - bddrun.exe 128,424 bytes

    If you have problems, ensure that you have no other custom version of bddrun.exe copied from other directories, and rebuild.
     
  • Monday, November 16, 2009 9:08 PM
     
     
    Sign In to Vote
    0
    Hi Keith,

    I have just checked, bddrun.exe is x64 (131,280 bytes) as well.
     
  • Monday, November 16, 2009 9:11 PM
     
     
    Sign In to Vote
    0
    Try a total regenration of your images. I would be interested to see what happens.
     
  • Monday, December 14, 2009 6:34 PM
     
     
    Sign In to Vote
    0
    Hi,

    I'm having same problem and have tried regenerating the ISO Images.   Do you have any suggestions?

    I noticed that when images are created I get failure by DISM to add some components.

    Deployment Image Servicing and Management tool

    Version: 6.1.7600.16385

     

    Image Version: 6.1.7600.16385

     

    Processing 1 of 1 - Adding package WinPE-HTA-Package~31bf3856ad364e35~amd64~~6.1.7600.16385

     

    Error: 0x800f081e

     

    The specified package is not applicable to this image.

     

    The DISM log file can be found at C:\Windows\Logs\DISM\dism.log

     

    Exit code = -2146498530

     

    DISM /Add-Package failed for component C:\Program Files\Windows AIK\Tools\PETools\amd64\WinPE_FPs\winpe-hta.cab, rc = -2146498530.

    Added component winpe-hta

     

    Deployment Image Servicing and Management tool

    Version: 6.1.7600.16385

     

    Image Version: 6.1.7600.16385

     

    Processing 1 of 1 - Adding package WinPE-Scripting-Package~31bf3856ad364e35~amd64~~6.1.7600.16385

     

    Error: 0x800f081e

     

    The specified package is not applicable to this image.

     

    The DISM log file can be found at C:\Windows\Logs\DISM\dism.log

     

    Exit code = -2146498530

     

    DISM /Add-Package failed for component C:\Program Files\Windows AIK\Tools\PETools\amd64\WinPE_FPs\winpe-scripting.cab, rc = -2146498530.

    Added component winpe-scripting

     

    Deployment Image Servicing and Management tool

    Version: 6.1.7600.16385

     

    Image Version: 6.1.7600.16385

     

    Processing 1 of 1 - Adding package WinPE-WMI-Package~31bf3856ad364e35~amd64~~6.1.7600.16385

     

    Error: 0x800f081e

     

    The specified package is not applicable to this image.

     

    The DISM log file can be found at C:\Windows\Logs\DISM\dism.log

     

    Exit code = -2146498530

     

    DISM /Add-Package failed for component C:\Program Files\Windows AIK\Tools\PETools\amd64\WinPE_FPs\winpe-wmi.cab, rc = -2146498530.

    Added component winpe-wmi

     

    Deployment Image Servicing and Management tool

    Version: 6.1.7600.16385

     

    Image Version: 6.1.7600.16385

     

    Processing 1 of 1 - Adding package WinPE-MDAC-Package~31bf3856ad364e35~amd64~~6.1.7600.16385

     

    Error: 0x800f081e

     

    The specified package is not applicable to this image.

     

    The DISM log file can be found at C:\Windows\Logs\DISM\dism.log

     

    Exit code = -2146498530

     

    DISM /Add-Package failed for component C:\Program Files\Windows AIK\Tools\PETools\amd64\WinPE_FPs\winpe-mdac.cab, rc = -2146498530.

    Added component winpe-mdac



    Thanks,
     
  • Monday, December 14, 2009 7:13 PM
    Moderator
     
     
    Sign In to Vote
    0

    Try just deleting the boot images from the BOOT folder on the deployment share and then create new ones by updating the deployment share. 

    Tim Mintner Principal Consultant Xtreme Consulting Group http://deployment.xtremeconsulting.com
     
  • Tuesday, December 15, 2009 2:53 PM
     
     
    Sign In to Vote
    0
    Just tried again and still giving errors above.  Any other suggestions?

    It mounts the same WIM image when creating boot disks that has x86\x64 Windows 7 Enterprise install in it if that matters.  I'm at a loss as to what the issue could be.

    Thanks for the help,
     
  • Tuesday, December 15, 2009 5:24 PM
    Moderator
     
     
    Sign In to Vote
    0
    Can you try this? http://blogs.technet.com/askcore/archive/2009/11/19/mdt-2010-incorrect-wimgapi-dll-version-causing-wim-mounting-issues.aspx
    Tim Mintner Principal Consultant Xtreme Consulting Group http://deployment.xtremeconsulting.com
     
  • Tuesday, December 15, 2009 6:25 PM
     
     
    Sign In to Vote
    0
    I tried this and both files are version listed on site above (6.1.7600.16385).  Also checked a Windows XP machine I have Deployment Toolkit 2010 installed on and version is correct there too. 

    When updating images still showing that packages don't apply The specified package is not applicable to this image. for x64.

    Thanks,
     
  • Tuesday, December 15, 2009 6:37 PM
    Moderator
     
     
    Sign In to Vote
    0
    The errors about the packages aren't critical errors and are expected.  Is the boot image generated now?
    Tim Mintner Principal Consultant Xtreme Consulting Group http://deployment.xtremeconsulting.com
     
  • Tuesday, December 15, 2009 6:49 PM
     
     
    Sign In to Vote
    0
    Yep boot image was generated before but when I try to boot off x64 boot wim or ISO I get this message still.  The x86 boot image and ISO works fine for deploying Windows installations.

    A winpeshl.ini file is present, but no commands were successfully launched. This could be caused by incorrect formatting or an invalid executable name. Please consult the documentation for more information.

    X:\windows\system32>

    If I run BDDRun.exe I get

    This version of X:\windows\system32\BDDRUN.exe is not compatible with the version of Windows you're running. Check your computer's system information to see whether you need a x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher.

    Thanks,
     
  • Tuesday, December 15, 2009 7:51 PM
    Moderator
     
     
    Sign In to Vote
    0
    Thanks Jimmy.

    Can you try changing the Windows PE selection profile to All Drivers and then do an update on your boot images?
    Tim Mintner Principal Consultant Xtreme Consulting Group http://deployment.xtremeconsulting.com
     
  • Tuesday, December 15, 2009 8:38 PM
     
     
    Sign In to Vote
    0
    Yep gave that a try and also tried unchecking ADO on x64 tab and rebuliding images with no luck.  Any other ideas?

    Do you know of some versions of Windows 7 Enterprise don't have the x64 bit boot.wim or if the problem is with it.  I was playing around and imported the DVD we have and it only brought in a boot.wim for x86 into WDS console with both Operating Systems x86 and x64 showing up.

    winpeshl.log info:

    Info      Windows PE Shell beginning execution
    Info      Beginning PNP initialization.
    Info      Winpeshl.ini detected.
    Warning   Failed to launch X:\windows\System32\bddrun.exe [X:\windows\System32\bddrun.exe /bootstrap] [0x800700d8]
    Info      Succeeded launching X:\windows\system32\cmd.exe [X:\windows\system32\cmd.exe /k "echo A winpeshl.ini file is present, but no commands were successfully launched.  This could be caused by incorrect formatting or an invalid executable name.  Please consult the documentation for more information.
    "]
    Info      PNP initialization succeeded.
    Info      PNP Initialization thread terminating.

    Thanks,
     
  • Tuesday, December 15, 2009 10:30 PM
    Moderator
     
     
    Sign In to Vote
    0
    Sounds like your source files may not contain everything.  Do you have another Windows 7 DVD that you can import?
    Tim Mintner Principal Consultant Xtreme Consulting Group http://deployment.xtremeconsulting.com
     
  • Tuesday, December 15, 2009 10:31 PM
    Moderator
     
     
    Sign In to Vote
    0
    Just to make sure as well.  You mentioned importing into WDS.  You have imported the DVD as an operating system in the Deployment Workbench correct?
    Tim Mintner Principal Consultant Xtreme Consulting Group http://deployment.xtremeconsulting.com
     
  • Tuesday, December 15, 2009 11:16 PM
     
     
    Sign In to Vote
    0
    Yep I imported into both when testing.  I just tried importing Windows 7 Ultimate DVD and it showed two options (x86 and x64) and one boot image.  Is that what is suppose to happen with Windows 7 media when importing into WDS?

    Thanks again,
     
  • Wednesday, December 16, 2009 12:06 AM
     
     Answered
    Sign In to Vote
    0
    I just removed Windows 7 Enterprise from Operating Systems in Workbench and then updated deployment share again.  It looks like everything worked normal this time, workbench used WAIK Winpe.wim under C:\Program Files\Windows AIK\Tools\PETools instead of Windows 7 Enteprise source boot.wim. 

    Should the workbench use the WAIK Winpe.wim for each architecture versus Windows 7 or Server 2008 R2 boot.wim file?  Is there a way to tell Workbench where to select boot.wim when updating deployment share?  I can't seem to find any documentation on this.

    Thanks,
     
  • Wednesday, December 16, 2009 5:07 PM
    Moderator
     
     
    Sign In to Vote
    0
    It will try to use the boot.wim from Windows 7 if it can find it.  Otherwise it will use the one from the Windows AIK.  Unfortunately there isn't a way to choose but it shouldn't matter.  Not quite sure why it didn't work with the Windows 7 image for you.
    Tim Mintner Principal Consultant Xtreme Consulting Group http://deployment.xtremeconsulting.com