none
SCCM 2012 R2 - Error 0x800700C1

    Question

  • Hi All,

    For the past few days I'm experiencing "0x800700C1" errors during the Build & Capture task sequences for an older OS image (Windows 2003 x86) which used to work flawlessly in the past. After detailed investigation of the logs it turns out that the task sequence is failing right after the "Perpare OS" step which is also responsible for implementing the WinPE boot image and the boot sector changes prior the capturing step. The associated error messages within the logs are indicating few times the following:

    "is not a valid Win32 application"

    While this didn't make too much sense initially, digging down the logs a bit further shown that the problem occurs right after the following command is engaged:

    "C:\_SMSTaskSequence\WinPE\SMS\bin\i386\bootsect.exe" /NT60 SYS /MBR

    I tested the command manually and it certainly gives back the same error which makes me think that the included within the x86 boot image bootsect.exe binary is not x86 compatible or there is another problem with it.

    While my SCCM Boot Images are customized with very few boot drivers, there were no other major changes applied to them and furthermore the same issue was experienced also with the unmodified x86 boot image so this whole problem relates back to the Windows 8.1 ADK distribution.

    Anybody else experiencing similar problems ?

    ---------------------------------------------------------------------------------------------------------------------------------------------

    Update:


    In the meantime I made an additional investigation with the bootsect.exe file directly from the Windows 8.1 x86 ISO images (same as the one with WinPE 5.0) and it turns out that this version of the file just can't be used on Windows 2003 x86 OS instances. The same "is not a valid Win32 application" error appears with it.

    I can confirm that there is no problem with bootsect.exe binary from the Windows 8.0 ISO images, so most probably the solution to my original problem will be to replace manually the file within the original WinPE 5.0 image with an older version.

    ---------------------------------------------------------------------------------------------------------------------------------------------

    Update:

    I figured out why the issue is happening even with older WinPE images. The problem resides with SCCM and more specifically with the modifications of the boot images. It doesn't matter whether or not you would be using old or new image. When you upload the boot image to SCCM, it automatically includes the "SMS" folder in it's internal structure which contains the new version of the "bootsect.exe" and also other binaries related to the boot modification processes. During the "Perpare OS" step the SCCM client copies over the referenced boot image and extracts some of the files out of this folder to the ""C:\_SMSTaskSequence\WinPE\" location. Because the provided "bootsect.exe" version is simply incompatible with W2K3 OS, the task just fails despite of the provided older WinPE boot image. So all in all it seems that the problem cannot be resolved without manual intervention at the boot image, but more testing will be required before making any final conclusions. For the time being I would say that SCCM 2012 R2 cannot be considered as fully compatible for managing W2K3 OSD procedures.

    ---------------------------------------------------------------------------------------------------------------------------------------------

    Workaround:

    And so the temporary (maybe even long-term) solution is to replace the bootsect.exe file with an older version then continue with the capture step as per the defined SCCM task sequence. Now the only difficulty was to decide whether to change the boot image directly through DISM or to go for a more comfortable way and implement a global change that would reflect all boot images. Normally I wouldn't go with global changes easily but this time I went for the latter by replacing the the ADK 8.1 based bootsect.exe file at its installation point which in my case is:

    E:\Program Files (x86)\Windows Kits\8.1\Assessment and Deployment Kit\Deployment Tools\x86\BCDBoot\

    The reason why I went this way was to ensure that whenever I'm updating my boot images with new drivers, the "correct" bootsect.exe file would get integrated instead of the latest version. Furthermore whenever there is a requirement to redistribute the images to DP's, the boot images will get updated/reconstructed and therefore the bootsect.exe binary would be reinserted, so the manual modification of the WIM files is not really a solution.

    Of course this global modification method is absolutely unsupported, so if anybody reading this would decide to make similar implementation, he/she will take the responsibility over potential risks and consequences. I haven't tested the older version of the bootsect.exe file with newer OS versions (8.1 / 2012R2) so it is important to note that there is a big potential risk involved with the above described modification as it could break build/capture/deploy tasks for the new OS's. Perhaps I'll give it a test and see how things would work.

    So all in all let's hope that MS would release a fixed version of bootsect.exe with their next ADK release.

    • Edited by asg2ki Monday, October 28, 2013 5:05 PM Workaround
    Sunday, October 27, 2013 12:02 PM

Answers

All replies

  • To my knowledge, the product team is aware of this issue and the recommendation is to use an older version of WinPE for your boot images, specifically WinPE 3.1.

    Technically, the ADK for Win 8.1 and thus WinPE 5.0 does not support XP/Server 2003 so this issue will not be fixed (to my knowledge).


    Jason | http://blog.configmgrftw.com

    • Marked as answer by asg2ki Sunday, October 27, 2013 2:13 PM
    • Unmarked as answer by asg2ki Sunday, October 27, 2013 9:25 PM
    Sunday, October 27, 2013 1:48 PM
  • Thanks for the confirmation Jason

    This certainly answers my question.

    While I can't remember seeing anything within the SCCM release notes around such or similar issues, it's true that I haven't checked the ADK release logs in details beforehand, so this lead to one very uncomfortable situation with no clear documentation especially around the error codes. Hopefully the product team could put some sort of remark in the near future because despite that many environments are trying to move away from XP/Server 2003 OS's (including myself), sometimes it is still a requirement to have it in the background.

    Thanks again.

    ------------------------------------------------------------------------------------------------------------------------------------

    Update:

    Older WinPE image produces the very same error. Further investigation is required.

    • Edited by asg2ki Sunday, October 27, 2013 9:27 PM
    Sunday, October 27, 2013 2:13 PM
  • So I tried with the older image from WAIK (Win 7 based) and for my biggest surprise the same issue had happened.

    • Edited by asg2ki Monday, October 28, 2013 1:33 PM
    Sunday, October 27, 2013 9:25 PM
  • Yuck. Your best bet is to contact CSS at this point then.

    You could try replacing the bootsect.exe in your boot image with an older version, but they may cause other issues.


    Jason | http://blog.configmgrftw.com

    Monday, October 28, 2013 2:31 PM
  • I would have done so if I had support service contract available with MS, but since it is a private lab environment I'm dealing with right now, I'm not eligible to request official support service and therefore I can only wait and see if anybody else would come up with different ideas. In the meantime I'll just keep experimenting on my own, but so far the view for successes is not too positive.


    Anyway thanks for looking into this thread.

    Monday, October 28, 2013 3:05 PM
  • See workaround above.
    • Marked as answer by asg2ki Monday, October 28, 2013 5:05 PM
    Monday, October 28, 2013 5:05 PM
  • Thanks for all this info!  I was able to successfully use this workaround as described above.  My task sequence was for in place hard link migration from Win XP x86 to Win 7 x64 using SCCM 2012 R2.

    After running ScanState.exe and staging the boot image on XP, the sequence would error out with 0x800700C1 due to BootSect.exe, and be unable to apply the new Win 7 WIM.

    Following the instructions above, I replaced BootSect.exe in the ADK 8.1 install source location with the version from ADK 8.0.  Then I used the SCCM console to create two new MDT Boot Images (x86 and x64), published them to the DP, and set my USMT sequences to use them.

    Afterwards, the sequence got past the error and proceeded to upgrade the OS.

    Similarly, you have to build a second USMT5 package from ADK 8.0 in order to do XP to 7 migrations using SCCM 2012 R2.  Because nothing in ADK 8.1 supports XP anymore, including USMT6.

    Thursday, October 31, 2013 9:58 PM
  • Good to know that the workaround worked out well for you.

    And so it seems that there certainly is a need to support XP/2003 within SCCM R2 at least for the purpose of migrations, so I hope MS would make some changes in ADK regarding the bootsect.exe issue sooner or later.

    Thanks for reporting your results. In case you can open a official ticket with MS about that, please do so. If not, then let's hope somebody else with a support contract would initiate the procedure and make a favor to all of us.

    Thursday, October 31, 2013 10:59 PM
  • Thanks asg2ki for all the updates and the workaround.  If anyone else is running into this, I highly recommend opening a support ticket with Microsoft on this.  The more people engage support, the quicker a public fix will be made available.


    Nash Pherson, Senior Systems Consultant
    Now Micro - My Blog Posts
    <-- If this post was helpful, please click "Vote as Helpful".

    Tuesday, November 05, 2013 3:36 PM
  • Thursday, November 14, 2013 3:12 PM
  • Thanks for the clarification and confirmation.
    Thursday, November 14, 2013 3:36 PM
  • I have successfully replaced the bootsect.exe with the one used in the WAIK (dated Nov 2, 2006) but the TS is still failing, I guess because the exe doesn't recognise the /NT60 switch.  Does anyone know how to force the TS to use the /NT52 switch, or should I just use the earlier (non-R2) ADK?
    • Edited by JaysonG Friday, December 06, 2013 2:14 AM
    Friday, December 06, 2013 2:09 AM
  • As an FYI, the USMT x86 version of scanstate.exe (version 6.3.9600.16384) included with the Windows ADK 8.1 also generates the dredded "is not a valid Win32 application" error message (see the thread I just started on this here).  According to the Windows 8.1 ADK (here), scanstate.exe is fully supported on Windows XP so I think there is something a little more going on here with the Windows 8.1 ADK that Microsoft is not telling us.

    Regards,

    JJ

    Friday, December 06, 2013 10:51 PM
  • You can't use the USMT from the 8.1 ADK on Windows XP.  You must use USMT 5 from the 8.0 ADK.  See this post for the walkthrough:

    http://blogs.technet.com/b/configmgrteam/archive/2013/09/12/how-to-migrate-user-data-from-win-xp-to-win-8-1-with-system-center-2012-r2-configmgr.aspx


    Nash Pherson, Senior Systems Consultant
    Now Micro - My Blog Posts
    <-- If this post was helpful, please click "Vote as Helpful".

    Friday, December 06, 2013 11:17 PM
  • Thanks Nash, just saw that. Sure would be nice if Microsoft would update the Windows 8.1 ADK release notes or USMT requirements page (here) with that information.

    Regards,

    JJ

    Friday, December 06, 2013 11:21 PM
  • That link looks like it is to the Windows 8.0 ADK documentation.  But, going to the Windows 8.1 ADK documentation and clicking the USMT link brings you back to the 8.0 docs...

    I'll ping somebody on the documentation team and ask if they are already working on this.


    Nash Pherson, Senior Systems Consultant
    Now Micro - My Blog Posts
    <-- If this post was helpful, please click "Vote as Helpful".

    Friday, December 06, 2013 11:26 PM
  • Yes, but how long before CU1 releases for R2 is the question.

    David Baur

    Monday, January 06, 2014 6:35 PM
  • A very good question.

    I've already had to install KB2905002 to our live enviroment to fix PXE issues that appeared with R2 (and didn't show up in testing).

    The clock is ticking down to April the 8th, and one of the deployment methods we were going to use to upgrade XP clients has been unavailable for two months.
    Thursday, January 16, 2014 12:59 AM
  • Hotfix is now available for Premier customers via CSS.
    • Proposed as answer by NPhersonMVP Thursday, January 23, 2014 2:05 PM
    Thursday, January 23, 2014 9:00 AM
  • Thanks for posting that update!  Hopefully it will be in the soon to be released Cumulative Update...

    Nash


    Nash Pherson, Senior Systems Consultant
    Now Micro - My Blog Posts
    If you've found a bug or want the product worked differently, share your feedback.
    <-- If this post was helpful, please click "Vote as Helpful".

    Thursday, January 23, 2014 2:05 PM
  • Can you share the hotfix number? I'm assuming it's fixing bootsect.exe to support XP...
    Tuesday, January 28, 2014 1:39 PM
  • There is no publicly available hotfix.  You will have to contact Microsoft Support for the private hotfix if you need it right away.

    I'm hoping it will be included in the fixes that come with Cumulative Update 1 sometime soon.


    Nash Pherson, Senior Systems Consultant
    Now Micro - My Blog Posts
    If you've found a bug or want the product worked differently, share your feedback.
    <-- If this post was helpful, please click "Vote as Helpful".

    Tuesday, January 28, 2014 2:37 PM
  • It will be included, there's no need to hope :)
    Wednesday, January 29, 2014 6:48 AM
  • Hot off the presses, there is now a hotfix for CM2012 R2 that addresses this:

    http://support.microsoft.com/kb/2910552/

    Still watching for CU1, but in the mean time this will do nicely.

    I hope that helps,

    Nash


    Nash Pherson, Senior Systems Consultant
    Now Micro - My Blog Posts
    If you've found a bug or want the product worked differently, share your feedback.
    <-- If this post was helpful, please click "Vote as Helpful".

    Monday, February 03, 2014 8:44 PM
  • The hotfix doesn't work for me at a new customer who wants to use SCCM 2012 R2 to migrate away from XP. (I do have an existing customer where I have used the previous version of bootsect.exe as a workaround)  I still get the "Not a valid Win32 application" when the WinPE 5.0 boot image is attempted to be staged (not WinPE3.1 as the hotfix title suggests!).  I'm not sure if the hotfix even applies in this scenario - as it isn't a WinPE 3.1 boot image I am trying to stage, nor should I be doing so if I am refreshing to Win7 or Win8!  So it's back to the workaround for me!

    My Personal Blog: http://madluka.wordpress.com

    Monday, February 17, 2014 3:41 PM
  • I'm facing the same issue when staging the boot image from windows XP. I installed the hotfix and follow the instructions but it didn't solve the issue and I still getting the same error 0x800700c1.

    Thursday, February 20, 2014 12:02 AM
  • as per the Hotfix Instructions, You must use a Windows PE 3.1 boot image. In SCCM 2012 R2 WINPE 5 is used and the hotfix will not work in this case.

    The solution is to install the hotfix and then create a Windows PE 3.1 boot image and import it into the SCCM Server, you can find the steps in the following link :http://technet.microsoft.com/en-us/library/dn387582.aspx

    Thursday, February 20, 2014 7:59 AM
  • After installing the hotfix and then creating the WinPE 3.1 Images as I mentioned above, the task sequence works and the boot images issue is solved :)
    • Edited by Khodr Chams Thursday, February 20, 2014 1:43 PM
    Thursday, February 20, 2014 1:42 PM
  • The idea of having to use an unmanaged (from the ConfigMgr console at least) WinPE 3.1 image to migrate from XP to Win7 or Win8.x using ConfigMgr 2012 R2 is ridiculous.  One disadvantage of this is that you can kiss Goodbye to having one task sequence deployment that can refresh from XP AND build new systems with Bitlocker pre-provisioning - because you have to assign the WinPE3.1 boot image to the TS.

    Replacing the bootsect.exe is the way to go here, however unsupported it may be from what I understand this executable is only ever used to modify the current WinXP install so that a WinPE boot image can be staged and booted from.  Win7/8 does not use BootSect.exe (uses BCDedit - and this file you should NOT replace with an older version.)

    Eagerly awaiting ConfigMgr 2012 R2 CU1!


    My Personal Blog: http://madluka.wordpress.com

    Thursday, February 20, 2014 2:56 PM
  • +1 ...and why we are staying with the unsupported bootsect.exe workaround as we have (1) task sequence that does everything from XP to 7 migration, XP to 8.1 migration, 7 to 8.1 migration, 7 and 8.1 refresh, and bare metal builds of 7, 8.1, and Windows Server 2008 R2, 2012, and 2012 R2.

    Regards,

    JJ

    Thursday, February 20, 2014 3:21 PM
  • Gotta agree that this was not a great way for them to solve this.

    Unfortunately, with WinXP's imminent demise, I don't have a lot of hope that they will put many resources into fixing it well.  That sucks for those still trying to get rid of XP, but I can't say it isn't a justifiable business decision for Microsoft.

    Regarding CU1 for R2... has anybody heard anything?  The rumors were that it would be a couple days behind CU4 for SP1, but now I'm worried they might be skipping it...

    Nash


    Nash Pherson, Senior Systems Consultant
    Now Micro - My Blog Posts
    If you've found a bug or want the product worked differently, share your feedback.
    <-- If this post was helpful, please click "Vote as Helpful".

    Thursday, February 20, 2014 7:51 PM
  • Hi I have been trying to use the workaround. Here is what I did

    - replaced the bootsect.exe  (ver 6.2) in the location

    c:\Program Files (x86)\Windows Kits\8.1\Assessment and Deployment Kit\Deployment Tools\x86\BCDBoot\

    - Tried creating a new boot image

    Everytime i create one , I see the new version being added to the \windows\system32 location in the WINPE image?

    I am using the option, create a new MDT boot image? 

    Is there anything I am missing?

    Regards,

    -h-


    -If Life gives you lemons, make lemonade

    • Proposed as answer by Yan L Thursday, April 10, 2014 5:39 PM
    • Unproposed as answer by Yan L Thursday, April 10, 2014 5:39 PM
    Wednesday, March 05, 2014 3:14 PM
  • After installing the hotfix and then creating the WinPE 3.1 Images as I mentioned above, the task sequence works and the boot images issue is solved :)

    I applied the hotfix in this article, followed the instructions in this article http://technet.microsoft.com/en-us/library/dn387582.aspx and I still get the win32 error for bootsect.exe . Is there something I need to do after the hotfix is installed? The version of the boot image I'm using is 6.1.7601.17514 .

    Update*--------------------

    I updated the client using the MSP package that the hotfix created in SCCM. I deployed that to the client I was testing with and it has so far. . .gotten past that fatal error.

    • Edited by zemerick-sa Wednesday, March 05, 2014 9:02 PM
    Wednesday, March 05, 2014 4:02 PM
  • What Version of winPE are you talking about here?

    The hotfix doesnt work if you use WinPe image 5.0. What I have done so far is used AIK 8.0 to create a boot image and I can confirm it works well so far, it is to do with the version of bootsect.exe as mentioned in the thread above. But the concern that I raised above still remains unanswered.

    Regards,

    -h-


    -If Life gives you lemons, make lemonade

    Thursday, March 06, 2014 4:44 AM
  • Side note here, the ADK for Win 8 created WinPE 4.0 boot images which are technically support in ConfigMgr 2012 R2. Only WinPE 3.1 (Created using the AIK 3.0 [also sometimes called the AIK for Win 7] + the AIK 3.0 Supplement for Win 7 SP1) and WinPE 5.0 (created using the ADK for Win 8.1) boot images are supported in R2.

    Jason | http://blog.configmgrftw.com

    Thursday, March 06, 2014 2:51 PM
  • I have been able to get past the stage 1 of the problem which was to do with bootsect.exe problem, and now have landed into another one, I am using Hyper V (server 2012 R2) to test migration from Windows XP to Windows 7, it goes as far as staging the boot image and it reboots fine, but ends with error message- WinPE Initialization failed with error code - 0x80040154.

    I am using legacy drivers, and I understand this is got to do with the drivers , but considering the fact that I simply dont have any drivers injected in this boot image, also, I dont see there is a mechanism to "enable command prompt support, because any other version of boot image when imported doesnt give you any option to either add drivers, customize or enable command prompt support through GUI.

    Does anyone know if I would need to add additional drivers and how do I get about enabling command prompt support using Dism?

    Regards,

    -h-


    -If Life gives you lemons, make lemonade

    Friday, March 07, 2014 10:35 AM
  • Can anyone please explain how they were able to copy over the older bootsect.exe file to the newer winpe.wim?

    I've mounted the new wim with dism, but I keep getting an access denied error when trying to copy the "older" file over.

    Yes, I have local admin rights...

    Friday, March 07, 2014 9:38 PM
  • Its the trusted installer that is really stopping you. The way out is to take the ownership of the file and then change the permissions to give full control to the owner.

    Once you do that, what you will see is that you have copied over the file successfully, BUT.... I dont know and I have been through this, the file gets replaced automatically---

     


    -If Life gives you lemons, make lemonade

    Saturday, March 08, 2014 7:25 AM
  • Did you deploy the client upgrade as a required install? I just tried that on my client as I was receiving the same error after applying the hotfix and creting the 3.1 winpe package. But when it was installing the client the software center dissappeared and has not reinstalled.
    Friday, March 21, 2014 2:51 PM
  • I think you have to reboot the client after installing client update kb2910552

    Tuesday, April 01, 2014 9:15 PM
  • I have installed CU1 for R2 and like it was stated it does not fix Error 0x800700C1 if using WinPE 5.0 boot images. I was able to use the workarround described above earlier but now I'm back to Error 0x800700C1 even tough I overwrote bootsect.exe in Program Files (x86)\Windows Kits\8.1\Assessment and Deployment Kit\Deployment Tools\x86\BCDBoot\ with version 6.2.9200.16384.

    I opened the modified WinPE 5.0 boot image and noticed that there is 2 bootsect.exe.

    1 in "SMS\bin\i386\bootsect.exe" version 6.2.9200.16384 114KB 2012-07-25

    2 in "windows\system32\bootsect.exe" version 6.3.9600.16384 91.8KB 2013-08-22

    and there lies the problem for me; I can see in the SMSTS.log that it's trying to load the wrong one...

    Executing command line: "C:\_SMSTaskSequence\WinPE\windows\system32\bootsect.exe" /NT60 SYS /MBR

    I still have to investigate why it's not loading the one that worked for me in the past: Executing command line: "C:\_SMSTaskSequence\WinPE\SMS\bin\i386\bootsect.exe" /NT60 SYS /MBR

    I still can't figure out from what source it's getting the 91.8KB file to build the boot image, I did a search against all the local drives. I'm assuming it's coming from the MDT Toolkit.

    Can anyone help me to either: force the TS to run "C:\_SMSTaskSequence\WinPE\SMS\bin\i386\bootsect.exe" /NT60 SYS /MBR or find the source location to the 91.8KB file so I can overwrite it with version 6.2.9200.16384. I know I could use DISM to build the boot image but this file will be overwritten if I make boot image modoficatons through the SCCM console.

    Thank you

    p.s. I'm currently using MDT boot images, maybe I was using standard boot images when it worked to load C:\_SMSTaskSequence\WinPE\SMS\bin\i386\bootsect.exe

    Workarround ----------------------------------------------------------------------------------

    Seems if you are using a standard boot image the workarround in the top post works. If you are using an MDT boot image it's a little more complex but same logic.

    The source file is winpe.wim. In my case it's in the same folder as the customized one "WinPE.<sitecode>000xx.wim". I edited winpe.wim using DISM and injected the version 6.2.9200.18384 of files bootsetct.exe, bcedit.exe and bcdboot. (I was getting bcdedit errors) (you will have to take ownership of the files to overwrite them). I then commited my changes, used SCCM console to Update Distribution Points for my MDT boot image and voila I'm back in business refreshing XP to Win7 using WinPE5.0 MDT boot image.

    p.s. I replaced ZTIUserState.wsf from this blog but haven't tested USMT yet.  http://blogs.technet.com/b/mniehaus/archive/2014/01/09/migrating-from-windows-xp-to-windows-8-1-using-mdt-2013.aspx

    • Edited by Yan L Thursday, April 10, 2014 5:36 PM found workarround
    Thursday, April 10, 2014 1:43 AM
  • I have installed CU1 for R2 and like it was stated it does not fix Error 0x800700C1 if using WinPE 5.0 boot images.

    This statement is exactly true. The hotfix is for WinPE 3.1 images (not WinPE 5.0 images) which is what you should be using for WinXP migrations (God help us all if you are still deploying XP).

    Jason | http://blog.configmgrftw.com

    Thursday, April 10, 2014 1:52 AM
  • @Jason I would like to keep using WinPE 5.0 since I read that it's the version that woks well with bitlocker.

    We have to refresh XP i386 to Windows 7 with bitlocker in the TS! Yes we are behind...

    Any suggestions to get the above working would be appreciated. tks

    Thursday, April 10, 2014 2:04 AM
  • Hi I have been trying to use the workaround. Here is what I did

    - replaced the bootsect.exe  (ver 6.2) in the location

    c:\Program Files (x86)\Windows Kits\8.1\Assessment and Deployment Kit\Deployment Tools\x86\BCDBoot\

    - Tried creating a new boot image

    Everytime i create one , I see the new version being added to the \windows\system32 location in the WINPE image?

    I am using the option, create a new MDT boot image? 

    Is there anything I am missing?

    Regards,

    -h-


    -If Life gives you lemons, make lemonade


    The source is in winpe.wim, see my post. Yan L
    • Edited by Yan L Thursday, April 10, 2014 6:31 PM
    Thursday, April 10, 2014 5:40 PM
  • Did you replace the Bootsect.exe in both the x64 and x86 locations?

    c:\Program Files\Windows Kits\8.1\Assessment and Deployment Kit\Deployment Tools\x86\BCDBoot

    c:\Program Files\Windows Kits\8.1\Assessment and Deployment Kit\Deployment Tools\amd64\BCDBoot

    I replaced the BootSect.exe in both locations, and it appears to be working fine. But then again, I haven't updated to CU1 yet.

    Thursday, April 10, 2014 5:53 PM
  • I did replace in both. I'm only using an x86 MDT boot image. I think it's required to refresh XP x86 machines.

    Your fix did work for a while and does change the bootset.exe file in sms\bin\i386\ of the wim file.  The problem I was facing was the TS was not calling this file anymore it's calling windows\system32\bootsect.exe in the wim file.

    see above for my workarround.

    Thursday, April 10, 2014 6:04 PM
  • @Jason I would like to keep using WinPE 5.0 since I read that it's the version that woks well with bitlocker.

    There are no issues with Bitlocker and WinPE 3.1 (to my knowledge) so not sure what you are referring to here.

    Jason | http://blog.configmgrftw.com

    Thursday, April 10, 2014 9:52 PM
  • I can confirm that: the change of a bootsec file from version 6.3 to version 6.2 (USMT 5.0) with DISM allows the Reboot phase in Task Sequence to work correct. 

    http://techdiving.pro/

    Tuesday, April 15, 2014 8:46 AM
  • It's not needed to manually modify boot images at all. Either http://support.microsoft.com/kb/2910552 or CU1 for R2 will take care of it. WinPE 3.1 boot images can be used then.

    Torsten Meringer | http://www.mssccmfaq.de

    Tuesday, April 15, 2014 8:51 AM