none
MDT 2012 Beta 2 Windows 7 "Setup.exe - Entry Point Not Found" fastprox.dll

    Question

  • I created a standard task sequence in MDT 2012 Beta 2

    Imported Windows 7 setup files for x86 and defaulted the rest.

    As soon as the task sequence calls setup.exe it throws the following error

     

    The procedure entry point ??0WString2@@QAE@XZ could not be located in the dynamic link library X:\windows\system32\wbem\fastprox.dll.

     

    If you select ok it throws the same error message a second time the once you choose ok on this it starts to install Windows 7 normally.

     

    Any idea what this is and if I can fix it? I also found if you just run setup.exe from command line you get the same messages. So I dont believe it is related to the task sequence.

     

    any help or empathy would be appreciated

    Wednesday, January 25, 2012 8:30 PM

All replies

  • Are you using Windows AIK, or did you install the Windows 8 Dev Preview ADK?

    If you have installed the ADK, this is a known issue.  The only workaround is to use Windows AIK (which can install Windows 7 and 8).

     


    Thanks, -Michael Niehaus Senior Program Manager, Microsoft Deployment Toolkit mniehaus@microsoft.com http://blogs.technet.com/mniehaus
    Wednesday, January 25, 2012 8:43 PM
  • I had a complete MDT 2010 update 1 installed then installed 2012 Beta 2 over it. What ADK am i supposed to install?
    Wednesday, January 25, 2012 8:56 PM
  • Are you saying that I basically need to use the 2010 LiteTouchPE_x86? 
    Wednesday, January 25, 2012 9:08 PM
  • No.  There are two sets of "core" deployment tools that MDT 2012 Beta 2 can use:

    • Windows AIK for Windows 7.  This includes Windows PE 3.
    • Assessment and Deployment Kit (ADK) for Windows 8 Dev Preview.  This includes Windows PE 4.

    If you try to install Windows 7 from Windows PE 4, you will see the popups that you are experiencing.

    So that's why I'm asking if you have the ADK for Windows 8 Dev Preview installed - you should only see this if running Windows PE 4.  So the "fix" (really, workaround) is to uninstall ADK and then install Windows AIK.  After that, MDT 2012 Beta 2 will generate Windows PE 3 images instead of Windows PE 4 images.

     


    Thanks, -Michael Niehaus Senior Program Manager, Microsoft Deployment Toolkit mniehaus@microsoft.com http://blogs.technet.com/mniehaus
    Thursday, January 26, 2012 1:00 AM
  • Ah yeah that was what you were saying. The reason I was trying this was because I wanted the .NET 4 that PE 4 offered.

    I was getting the error with a custom app in PE 4 and "tried" the normal task sequence to see if i had the error.

     

    Ok so that is something that will be addressed before final release?

    Thursday, January 26, 2012 2:11 PM
  • We are still working with the Windows PE team to identify a fix to the problem.  It will definitely be resolved in some manner by the time Windows 8 and ADK reach RTM.


    Thanks, -Michael Niehaus Senior Program Manager, Microsoft Deployment Toolkit mniehaus@microsoft.com http://blogs.technet.com/mniehaus
    Thursday, January 26, 2012 5:43 PM
  • Is this error message a problem or can it be safely ignored?
    Wednesday, March 07, 2012 10:44 PM
  • It's just an annoyance - it doesn't cause any known issues, other than stopping the installation progress until you click OK twice.


    Thanks, -Michael Niehaus Senior Program Manager, Microsoft Deployment Toolkit mniehaus@microsoft.com http://blogs.technet.com/mniehaus

    Wednesday, March 07, 2012 10:48 PM
  • Is there an update on this issue? I'm using MDT 2012 RC1 and ADK.
    • Edited by Louis1962A Thursday, April 05, 2012 10:47 AM
    Thursday, April 05, 2012 10:42 AM
  • The suggested workaround is to not use ADK for deploying Windows 7.

    This will be addressed in future releases of the ADK and MDT.


    Thanks, -Michael Niehaus Senior Program Manager, Microsoft Deployment Toolkit mniehaus@microsoft.com http://blogs.technet.com/mniehaus

    Thursday, April 05, 2012 2:14 PM
  • Since its been a month and MDT 2012 has been released .. is there any update on this issue? 

    Friday, May 04, 2012 2:12 PM
  • As mentioned before, this is an incompatibility between the beta ADK and Window 7 Setup.exe.  This won't be fixed in ADK or in Windows 7 Setup.exe, so in a future MDT release we will stop using Setup.exe to install Windows, which will avoid the issue.

    This issue is also documented in the MDT 2012 release notes.  We still suggest using Windows AIK for Windows 7 deployments, unless you are in a lab environment and are willing to put up with small issues like this.

    Note that if you import your Windows 7 and Windows Server 2008 R2 images into Workbench without the full source files (just import the INSTALL.WIM), then you won't see this popup when using ADK because MDT 2012 will automatically fall back to using ImageX to install the image instead of Setup.exe.  (The change we are making in our next release is to make ImageX the default.)


    Thanks, -Michael Niehaus Senior Program Manager, Microsoft Deployment Toolkit mniehaus@microsoft.com http://blogs.technet.com/mniehaus

    Friday, May 04, 2012 6:20 PM
  • Thanks for the heads up on the workaround .. I will have to give that I try .. very interesting in moving to this version of PE .. so that I can use .Net

    Friday, May 04, 2012 11:01 PM
  • Bob and I were able to find a (Totally unsupported) workaround for this issue today.  He came by my lab and we toyed around with a crazy idea, expecting that it might generate some leads we could follow to find a solution.  Strangely, our first crazy idea just worked without any detected issues.  We simply (manually) replaced the X:\Windows\System32\wbem\Fastprox.dll in our Windows PE v4 with one from a bitness-identical Windows 7 version of PE immediately before running the setup.exe (also manually).  The automation killing fastprox.dll errors did not happen during the setup, where they did with the PE4 version of the DLL in place.  We did not have to unregister the old DLL or register the new one-  We just did a copy /y from where we put it in the MDT share to the X:\Windows\system32\wbem directory of the mounted PE image.  

    In our one and only test, it made it all the way through the setup reboot without any errors.  I theorize (as I have not tested this yet) this DLL replacement could be done on the fly as a command line part of a task sequence, and in that way you could do it only when installing Windows 7, but leave the PE 4 version of the DLL.  No regression testing yet, as this was an end-of-day discovery.   Both Bob and I really want .NET in our PE, so this may become part of our company's production solution if Microsoft doesn't eliminate the problem in a later version of the ADK (we have circumstances that require we run the full Setup install instead of just an ImageX at this time, so being forced into ImageX only would be a very painful transition on our scale)


    Wednesday, May 16, 2012 2:28 AM
  • There are complications, and we are working through them.  While it does make it all the way through setup, it appears that the resulting system does not support short file names.  Bob and I are trying various combinations of replacing different pieces, and seeing if the resulting system is viable.  When we have reached a conclusion, one way or the other, we will post it here
    Thursday, May 24, 2012 7:36 PM
  • Not enabling short file names is one of the changes in the ADK version of Windows PE.  We have added logic into the next version of MDT to re-enable short file names for older (pre-Windows 8) OSes.


    Thanks, -Michael Niehaus Senior Program Manager, Microsoft Deployment Toolkit mniehaus@microsoft.com http://blogs.technet.com/mniehaus

    Saturday, June 02, 2012 2:14 AM
  • winpe 4.0 is out now for rtm and issue still occurs, any work around yet?

    what type of things could be ran into if it don't support short file names?

    Tuesday, August 28, 2012 2:11 PM
  • The "workaround" is "avoidance":  Both MDT 2012 Update 1 and ConfigMgr 2012 SP1 address the issue by no longer using SETUP.EXE to install Windows 7 (or Windows 8), instead leveraging ImageX, DISM, and BCDBOOT to accomplish the same thing.

    In most cases, lack of short name support won't cause any significant issues, but it could confuse some applications.


    Thanks,
    -Michael Niehaus
    Senior Product Marketing Manager, Windows Deployment
    http://blogs.technet.com/mniehaus
    mniehaus@microsoft.com

    Tuesday, August 28, 2012 2:46 PM
  • in our case we are using a pxe env to install windows os on dissimilar hardware. We do not have the money to buy configmrg or mdt. we are using a Linux pxe server and just running winpe with out issues currently. would be nice to add in PowerShell for other options during install. avoidance is not a true workaround.

    what does fastprox.dll do anyways during an install?

    Tuesday, August 28, 2012 4:07 PM
  • MDT is free, and would run quite nicely from Windows PE even if you launched it from a Linux PXE server.

    I think you meant to say that "avoidance is not a true fix", because it is a true workaround :-) 

    The Windows engineering team has recommended using the Windows 8 version of SETUP.EXE to install the Windows 7 image, but that's kind of hard to set up.  It's easier to do what MDT does:

    • ImageX /Apply
    • DISM /Apply-Unattend
    • BCDBOOT

    You can download MDT 2012 Update 1 (which again is free) and look at the LTIApply.wsf script to see exactly how MDT does it.

    The fastprox.dll is part of WMI, but it doesn't really matter what it does - the popups are harmless, just annoying that you have to click OK twice on them.


    Thanks,
    -Michael Niehaus
    Senior Product Marketing Manager, Windows Deployment
    http://blogs.technet.com/mniehaus
    mniehaus@microsoft.com

    Tuesday, August 28, 2012 4:18 PM
  • o ok so ur saying that if I leave the existing dll in there it will have long file name support?
    and just need to use send keys to hit ok twice lol :P.

    I will look into adding It to the win 8 setup cant hurt.

    Tuesday, August 28, 2012 4:20 PM
  • The long file name change is not related to the DLL popup.  By default, when using Windows PE 4.0 to format a disk, it won't enable long file names.


    Thanks,
    -Michael Niehaus
    Senior Product Marketing Manager, Windows Deployment
    http://blogs.technet.com/mniehaus
    mniehaus@microsoft.com

    Tuesday, August 28, 2012 4:36 PM
  • The Windows engineering team has recommended using the Windows 8 version of SETUP.EXE to install the Windows 7 image, but that's kind of hard to set up.

    Michael, how can Windows 8 Setup.exe be used to install Windows 7? When i try a command like...

    > <WinPE4.0>:\Sources\Setup.exe /installfrom:<path_to_7>\Sources\install.wim

    ... I get an error message relating to a required language pack not being available.

    Btw, i just noticed the format command has an /s:enable|disable switch for short file names - enabled by default in Win7/WinPE3.x and disabled by default in Win8/WinPE4.0. However, running 'format C: /q /s:enable' does not help with the WMI error message, of course.

    • Edited by Drewfus Friday, August 31, 2012 8:17 AM
    Friday, August 31, 2012 8:16 AM
  • Both MDT 2012 Update 1 and ConfigMgr 2012 SP1 address the issue by no longer using SETUP.EXE to install Windows 7 (or Windows 8), instead leveraging ImageX, DISM, and BCDBOOT to accomplish the same thing.

    Is there anything that nees to be updated in a task sequence to take advantage of this behavior?  I upgraded a deployment share that was using MDT 2010 Update 1 to MDT 2012 Update 1, installed the ADK, regenerated boot images, and ran into this error trying to deploy Windows 7 with the existing task sequence.  Would I have to create a new task sequence (or somehow update the existing one) after MDT 2012 is installed?

    Thanks,
    Matt


    • Edited by Matt Schultz Monday, September 24, 2012 5:42 PM Revised text to be more accurate
    Monday, September 24, 2012 5:40 PM
  • No, there shouldn't be any need to do this.  The updated LTIApply.wsf script implements this change.  Can you verify that your deployment share has the 6.1.2369.0 or 6.1.2373.0 version of that script?


    Thanks,
    -Michael Niehaus
    Senior Product Marketing Manager, Windows Deployment
    http://blogs.technet.com/mniehaus
    mniehaus@microsoft.com

    Monday, September 24, 2012 6:11 PM
  • Yes, the LTIApply script is version 6.1.2373.0.  I've also tried creating two new task sequences -- one with the plain Win 7 SP1 source files, and one with a captured Win 7 SP1 reference image.  Both still call the Windows 7 setup.exe and throw the "Entry Point not found" error.
    Monday, September 24, 2012 8:37 PM
  • Can you e-mail me the logs (BDD.LOG primarily) at mniehaus@microsoft.com?


    Thanks,
    -Michael Niehaus
    Senior Product Marketing Manager, Windows Deployment
    http://blogs.technet.com/mniehaus
    mniehaus@microsoft.com

    Monday, September 24, 2012 8:47 PM
  • I found references to an MDT 2010 share in BDD.LOG.  Looks like bootstrap.ini had the path to that share instead of the MDT 2012 one.  Corrected that, updated boot images, and now everything is working as expected.  Apologies for the confusion and not checking the log file more closely first!

    Monday, September 24, 2012 9:20 PM
  • I used your work around in our ConfigMgr 2012 SP1 Beta1 test site by mounting both the WinPE 4.0 default boot.wim from the ConfigMgr 2012 SP1 Beta1 site and the default WinPE 3.0 boot.wim from our ConfigMgr 2007 SP2 R3 site (<siteserver>\SMS_<sitecode>\osd\boot\i386\boot.wim) then replaced the fastprox.dll as you described above and no more "setup.exe - Entry Point Not Found" (fastprox.dll) errors during the deployment for both Windows 7 and Windows 8. Obviously this is just a temporary fix since Michael mentioned this will be fixed in the final release of ConfigMgr 2012 SP1.


    • Edited by scarneol Thursday, October 18, 2012 6:14 PM
    Thursday, October 18, 2012 6:10 PM
  • Michael, how can Windows 8 Setup.exe be used to install Windows 7? When i try a command like...

    > <WinPE4.0>:\Sources\Setup.exe /installfrom:<path_to_7>\Sources\install.wim

    ... I get an error message relating to a required language pack not being available.

    This is an interesting question. We're trying to install Windows 7 using the same kind of command, however we receive another error (concerning the availability of licence files, I'm not sure what the exact error message is at this moment). How can we circumvent this error, as I've read that the Windows 8 setup.exe handles the license files differently?

    Does anybody know if some kind of documentation exists concerning the installation of Windows 7 using the Windows 8 setup.exe?

    Edit, the exact message is:

    "Windows cannot find the Microsoft Software Licence Terms. Make sure the installation souces are valid and restart the installation".


    • Edited by marceltje Thursday, November 29, 2012 10:53 AM
    Wednesday, November 28, 2012 12:28 PM
  • I am working with a KACE appliance and I do have the ability to replace the setup.exe with the one from Windows 8 easily. However, I got the same error after replacing the file?
    Wednesday, May 01, 2013 5:05 PM
  • The long file name change is not related to the DLL popup.  By default, when using Windows PE 4.0 to format a disk, it won't enable long file names.


    Thanks,
    -Michael Niehaus
    Senior Product Marketing Manager, Windows Deployment
    http://blogs.technet.com/mniehaus
    mniehaus@microsoft.com

    Hi Michael,

    I am creating custom WINPE 4.0 media to install Windows 7 and we also need shortnames support.  I have compared the registry of WINPE 3.1 and 4.0.

    Would creating the following values on WINPE 4 image allow proper shortnames support?

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem

      NtfsDisable8dot3NameCreation = 2
      NtfsDisableVolsnapHints = 2

    Delete the following value:

      FilterSupportedFeaturesMode = 0

    Thanks,

    Josh



    • Edited by hippman257 Thursday, May 30, 2013 5:28 PM grammer
    Thursday, May 30, 2013 5:25 PM