WinPE 4.0 boot images not working with CPU's that do not support (NX) bit / Data Execution Prevention

Answered WinPE 4.0 boot images not working with CPU's that do not support (NX) bit / Data Execution Prevention

  • Thursday, January 17, 2013 6:11 PM
     
     

    SYMPTOM DESCRIPTION:


    - Following our organizations migration to SCCM 2012 SP1, and subsequent update of our boot images to the new WinPE 4.0 format any workstations that do not support the (NX) bit generate an error when attempting to boot from the network (See figure-1). workstations that have CPU's supporting the (NX) bit boot fine and seem to be unnaffected by the issue

    Figure 1


    ENVIRONMENT:


    SCCM 2012 SP1 Server – Server 2008 R2

    SQL Server (Hosting SCCM Instance) – Server 2008 R2, SQL 2008 R2 V. 10.50.1600.1

    Single Primary Site, 41 Distribution points, Single Domain

    Clients are all Windows 7 (32-bit)


    RELEVANT CONFIG CHANGES:


    -
    Issue was caused as the result of upgrading our SCCM environment to SP1, and our boot images subsequent upgrade to the new WinPE 4.0 version


    ADDITIONAL INFORMATION:

    - The only client OS we deploy via OSD and SCCM is Windows 7 32-bit

    - According to many forums on the web the error above is the same error that is generated when Windows 8 RTM is attempted installed on workstations that do not support the (NX) bit

    - So far i have been using CoreInfo to assess whether or not processors support the (NX) bit

    If anyone has a workaround to the above problem i would greatly appreciate any help that you can offer

    Thanks



    • Edited by Binarymine Thursday, January 17, 2013 6:12 PM change title
    • Edited by Binarymine Thursday, January 17, 2013 6:12 PM formatting
    •  

All Replies

  • Thursday, January 17, 2013 6:39 PM
     
     
    This is probably best something to report to Microsoft support/CSS and work with them on.

    Jason | http://blog.configmgrftw.com

  • Thursday, January 17, 2013 7:54 PM
     
     

    Thanks for the suggestion Jason. I have submitted the support request with Microsoft, i will post feedback on this article as i recieve it. In the meantime if anyone experiences and finds a resolution to this issue i would appreciate any input or suggestions that you could possibly offer.

    Thanks


    • Edited by Binarymine Thursday, January 17, 2013 7:55 PM Reply edit
    •  
  • Friday, January 18, 2013 2:37 PM
     
     
    Thanks for posting back details once you have them, there is at least one other person who posted the same problem.

    Nick Moseley | http://t3chn1ck.wordpress.com

  • Friday, January 18, 2013 2:47 PM
     
     

    Do you have a link to the post, i know the microsoft support agent will be asking for any furhter details and evidence of the issue so if i can direct him to the link that would be great. Also, there is a post on windows-noob that another user has started regarding this issue:

    http://www.windows-noob.com/forums/index.php?/topic/7264-creating-a-new-win7-boot-wim-for-sccm-2012-sp1/?p=27582

    Thanks

  • Friday, January 18, 2013 2:49 PM
     
     
  • Monday, January 21, 2013 1:22 PM
     
     
    Facing the same problem ... wish there is a fix for that 
  • Tuesday, January 22, 2013 2:55 AM
     
     
    Call support and tell Microsoft that this is a business issue for you. Simply commiserating in the forum is pretty useless.

    Jason | http://blog.configmgrftw.com

  • Wednesday, January 23, 2013 2:07 PM
     
     

    Have you heard anything back yet? I'm fighting the same problem.

  • Monday, February 18, 2013 12:26 PM
     
     
    If anyone gets a reply to this problem, please let everyone know, as we are experiencing the same problem, have a case open with MS, but no movement on the issue.  Thanks.
  • Monday, February 18, 2013 9:59 PM
     
     

    Hi everyone, I ran into the same issue,

    NX Support is a requirement for Windows 8 and WinPE 4.0 and thus also SCCM 2012 SP1 OSD. I have some really old PCs (Circa 2004 and older) that don’t support NX which just hang during boot of PE 4.0. I had a quick look and found that NX was first introduced by Intel circa Q3 (October 2004) in the Prescott range of CPU. Google “NX support for Intel Prescott” to get more details or look at the list of Intel releases on Wikipedia. I did find some people suggesting that systems released shortly after this date may actually have NX support but it might not be enabled so you might want to try checking the BIOS for NX / XD support. Also take a look at running the SysInternals Core Info tool http://technet.microsoft.com/en-gb/sysinternals/cc835722.aspx  to identify NX capability of your systems and then have a look at the below response that I got from Microsoft Premier Support when I raised this issue with them for completeness. In a nutshell it looks like some of us are stuck between a rock and a hard place J we need SCCM 2012 SP1 to deploy new technology (Windows 8) to new systems in a properly supported manner, (Without using MDT 2012 u1) but we then can’t use SCCM 2012 SP1 to properly deploy old technology such as WinXP to old systems in a supported manner. I am planning to play with a work around that I have heard about which involves opening up the 2012 SP1 boot.wim with DISM, ripping the SMS content from it and putting it into a PE 3.1 WIM for import into 2012 SP1. I’ll be doing this in my lab of course, and it will be just for fun J as I will never let it near my production environment because even if it were to work it would be totally unsupported by MS, goodness knows what might happen under the hood in SCCM. I’ll post back here if I find anything cool though :-)

    Definitive confirmation from Microsoft Premier Support regarding PE 4.0 and NX support that confirmed my fears:

    "ConfigMgr 2012 SP1 uses WinPE 4.0, which utilizes a Windows 8 kernel. Because of this, the WinPE 4.0 will not be able to support older hardware which does not support PAE / NX / SSE2 in the BIOS as it is a requirement in Windows 8. I have also attached some links below that go into further details about the requirements and what is supported:

    PAE/NX/SSE2 Support Requirement Guide for Windows 8

    http://msdn.microsoft.com/en-us/library/windows/hardware/hh975398.aspx

    What is PAE, NX, and SSE2 and why does my PC need to support them to runWindows 8?

    http://windows.microsoft.com/en-IN/windows-8/what-is-pae-nx-sse2"

    My last question to MS “Why is the above message regarding NX support and WinPE4.0 / SCCM 2012 SP1 not simply copied and pasted into the Configuration Manager 2012 TechNet documentation to help people like me who are planning a big 2007 to 2012 migration...?”

    …… Remains unanswered J

    Cheers

    Adam


    Regards Adam

    • Proposed As Answer by adflet999 Monday, February 18, 2013 9:59 PM
    • Unproposed As Answer by Binarymine Thursday, February 21, 2013 8:43 PM
    •  
  • Wednesday, February 20, 2013 12:47 PM
     
     
    Our SCCM Manager had to upgrade to SP1 to resolve other issue we were having with the system.  Now SCCM works better than ever with SP1 installed, but we lost the ability to image our Windows XP and Windows 7 machines because of the WinPE 4.0 update.  It's too bad they don't have a compatibility mode option within SCCM so you can re-enable WinPE 3 support for legacy hardware.  We don't plan on upgrading to Windows 8 in our school district, since we don't have any touch screen devices to take advantage of it.
  • Thursday, February 21, 2013 8:43 PM
     
     

    I very much appreciate the response, this is essentially what my support agent told me as well...complete bull if you ask me...this change should have been adequately documented in migration material prior to SP1 being released. If so I may have revaluated our needs to migrate so soon. We were early adopters due to many of the positive feature enhancements that SP1 brings to the table. I am a little disappointed in the number of bugs we have encountered so soon...this is one of 3 that has caused us headaches so far and 1 of 2 that remains outstanding.

    Please keep us posted on how you make out regarding ripping the SMS content in your attempts to hack a 3.1 image.

    Also, please take no offence, but I don't see this preliminary hack, and as yet untested and unproven workaround as a valid reason to propose your own reply as an answer. Once you have posted your findings and I can confirm them as working I will be happy to mark this as the answer.

    Until then you really only reiterated what I had initially suspected and posted as the problem


    • Edited by Binarymine Thursday, February 21, 2013 8:44 PM grammar change
    •  
  • Sunday, February 24, 2013 9:41 PM
     
     

    My last question to MS “Why is the above message regarding NX support and WinPE4.0 / SCCM 2012 SP1 not simply copied and pasted into the Configuration Manager 2012 TechNet documentation to help people like me who are planning a big 2007 to 2012 migration...?”

    Because there are endless permutations and caveats that simply cannot be included in the documentation. Basically, not everything is or can be documented.  This one specifically might have been overlooked or more likely put into the doesn't impact very many folks category. The fact that anyone has systems running in production from almost ten years ago is surprising and scary to me.

    Jason | http://blog.configmgrftw.com

  • Monday, February 25, 2013 2:14 PM
     
     

    The fact that anyone has systems running in production from almost ten years ago is surprising and scary to me.

    Jason | http://blog.configmgrftw.com

    Jason...not trying to be disrespectful here, but it would seem by this statement that you have never worked in K-12 education.  Myself included, three of the users in this thread appear to hail from various school districts.  Now, I could be way off base here, and I know that state to state things are different, but I know that the budgetary concerns here leave us very little room to keep all our workstation hardware up to date.

    As stated above, we are also experiencing the same issue...waiting to hear back from Microsoft and others who have reported this as well.

  • Monday, March 04, 2013 4:40 AM
     
     
  • Monday, March 04, 2013 5:33 AM
     
     
    Russ -- I think the issue at this point is not so much identifying what won't work...those of us with this problem already know what isn't working...it is more a matter of finding a method/solution that will actually support some of these older systems.  At this point, I believe everyone is waiting to see what Microsoft support has to say on the matter, and what they propose as a solution...hopefully they won't just say that we're SOL.
  • Monday, March 04, 2013 10:19 AM
     
     

    In my post above I provided the feedback that I got from Microsoft premier support. The impression that they gave me in their response to my premier ticket was that this is simply unsupportable. Thinking about the options here, SCCM 2012 SP1 uses PE4.0, I can’t see it being practical to change that without causing issues with deploying Windows 8 etc. The only thing that I can think they could do here would be to allow SCCM 2012 SP1 to use both PE 3.1 and 4.0 boot images but I would think that would be quite a significant update which they are unlikely to do for a small group of people and I doubt is even possible anyway. I have just resigned myself to using a WDS server to deploy OS images to the affected systems and then to deploy the 2012 client to the systems after deployment via GPO / client push and then to manage them, inventory them, etc… using SCCM 2012 SP1 once they are deployed and active as clients. It is only the OSD that doesn't work on these systems after all. It’s not great but I really don't see any realistic options other than to work around it like that until these old systems can be retired and replaced with new.


    Regards Adam

  • Tuesday, March 05, 2013 7:04 PM
     
     

    Adam,

    I am in the same boat, I put my eggs int the SCCM 2012 SP1 basket and now I have about 400 computers that I can nolonger support.  I am going to leave the old wds server in place. 

    Tom

  • Tuesday, March 05, 2013 9:05 PM
     
     

    We have the same problem.  We have multiple sites, so we are hoping to upgrade the 160 computers at the main campus so we can upgrade it to SP1.  The other sites will have to remain without SP1 until we can replace the computers there.\

    Duane

  • Tuesday, March 05, 2013 9:34 PM
     
     

    Hi Tom, Russ has provided a great link above which I used in my environment to establish the extent of the issue. Sadly I found that have about 5k (circa 9%) of my systems that are impacted by this. I have to be in a position to deploy Windows 8 properly so I must upgrade to 2012 SP1 to be supported. Saying that I deployed W8 with SCCM 2007 last September in my lab by creating the image manually with DISM from PE4.0 and then deploying it via 07 PE 3.1 ;-) but of course that's not properly supported so it doesn't go into my production environment.  In my initial post I pointed out that this issue extends back to the Intel Prescott time in Q4 2004 when they first introduced NX support. In reality I have found several systems that we bought well into 05 that also have the same issue. 3 year rolling refresh is good for some but not realistic for a lot of us. I still haven't had the time to test the boot image idea from my first post but as I said before even if it works in my lab I wont be using it in production. I will post back here if I figure it out though. I came to the conclusion that OSD is only one bit of SCCM 2012 SP1, I would rather continue the roll out and deploy my old XP image to those archaic bits of hardware using WDS than miss out on 2012 altogether. 


    Regards Adam

  • Thursday, March 07, 2013 9:46 PM
     
     

    Adam,

    I found info on Technet about manually creating a boot image for sccm 2007.  I was thinking of reverse engineer the 2012 boot image and find the required sccm 2012 files and stuff them in a windows 7 wim.  Well not that simple but you get were I am going.  Any imput is appreciated. 


    • Edited by tommypotatoes Saturday, March 09, 2013 4:07 PM Update
    • Edited by tommypotatoes Saturday, March 09, 2013 4:07 PM Update
    • Edited by tommypotatoes Saturday, March 09, 2013 4:11 PM Update
    •  
  • Thursday, March 14, 2013 2:50 PM
     
     Answered

    Hi Adam,

    I’m please to say I have managed to get a work around for this issue. We have approx 9000 machines in our environment which cannot boot from winPE4.0. 

    Unfortunately, at the moment, you are restricted to USB/CD bootable media but its better than nothing.

    These are the steps I followed.

    1. Build an SCCM 2012 RTM server (Site code TST) and copying off the boot.TST0001.wim from D:\Program Files\Microsoft Configuration Manager\OSD\boot\i386
    2. Create a bootable USB using the Task Sequence wizard in you SCCM 2012 SP1 installation
    3. Copy the boot.wim, off the newley created USB (D:\sources\boot.wim) and mount the image using DISM. This should be winPE4.0
    4. Browse the mounted image and copy the (d:\sms\bin\i386) to a local drive for later use.
    5. Mount the boot.TST0001.wim, which is winPE3.0, and copy the above directory (which should contain all the SMS SP1 OSD functions) into the same location on the mounted wim. Click yes to overwrite all files.
    6. Un-Mount and commit the boot.TST0001.wim, rename it to boot.wim and copy to the USB key in place of the WinPE 4.0/Overwriting this

    You will now be able to boot an old machine, using winPE3.0, and connect to a SCCM SP1 server and build machines.

    Thanks,

    Pete


    • Edited by Peter J Ellis Thursday, March 14, 2013 2:51 PM
    • Proposed As Answer by dr_heathcliff Thursday, March 14, 2013 9:40 PM
    • Marked As Answer by Binarymine Thursday, April 04, 2013 8:58 PM
    •  
  • Thursday, March 14, 2013 9:41 PM
     
     

    Hello Peter,

    This methodology has worked for me too!    Thanks for the heads up!  

  • Thursday, March 14, 2013 11:25 PM
     
     

    I have some questions regarding this process...I'm not at my desk, so I cannot test this at the present time...but when using the boot media, how does it present you with a list of TS's to run?  Meaning, does it give you a list of ALL TS's, or just those which are deployed/available to the workstation?

    As a side thought...What about a TS with a different boot image associated with it? Will it  try to download the other boot image and prestage it on a restart in order to run the TS selected from the boot media?

  • Thursday, March 14, 2013 11:35 PM
     
     

    I have some questions regarding this process...I'm not at my desk, so I cannot test this at the present time...but when using the boot media, how does it present you with a list of TS's to run?  Meaning, does it give you a list of ALL TS's, or just those which are deployed/available to the workstation?

    As a side thought...What about a TS with a different boot image associated with it? Will it  try to download the other boot image and prestage it on a restart in order to run the TS selected from the boot media?

    In the SCCM world, the client (media/PXE/software center) will only ever see the deployments that are targeted to it.

    As for Peter's suggestion of manually putting the SCCM OSD binaries to a 3.0 PE, the solution will work. Now, as you have already alluded to, there is a potential problem if the selected task sequence is associated with a boot image that is different from the one the CD/DVD. If the TS engine detects such a condition, it will download the boot WIM that is associated with the task sequence and reboot from that boot WIM.

    The obvious solution would be to make sure that the boot WIM package that you use to create your boot CD/DVD is the same as the ones that are associated with your task sequences.

  • Friday, March 15, 2013 1:38 AM
     
     
    In the SCCM world, the client (media/PXE/software center) will only ever see the deployments that are targeted to it.

    So then theoretically, if there is a Required TS deployed to a client, using the boot media (in this case the WinPE 3.0 WIM with the WinPE4.0 binaries) to enter into WinPE should kick off the TS which is deployed to that particular client/workstation.

    As for Peter's suggestion of manually putting the SCCM OSD binaries to a 3.0 PE, the solution will work. Now, as you havealready alluded to, there is a potential problem if the selected task sequence is associated with a boot image that is different from the one the CD/DVD. If the TS engine detects such a condition, it will download the boot WIM that is associated with the task sequence and reboot from that boot WIM.

    The obvious solution would be to make sure that the boot WIM package that you use to create your boot CD/DVD is the same as the ones that are associated with your task sequences.

    Right...this would really only be in very unique instances where a user might have customized a boot image for one reason or another.
  • Wednesday, March 20, 2013 5:55 PM
     
     

    Hi Adam,

    I’m please to say I have managed to get a work around for this issue. We have approx 9000 machines in our environment which cannot boot from winPE4.0. 

    Unfortunately, at the moment, you are restricted to USB/CD bootable media but its better than nothing.

    These are the steps I followed.

    1. Build an SCCM 2012 RTM server (Site code TST) and copying off the boot.TST0001.wim from D:\Program Files\Microsoft Configuration Manager\OSD\boot\i386
    2. Create a bootable USB using the Task Sequence wizard in you SCCM 2012 SP1 installation
    3. Copy the boot.wim, off the newley created USB (D:\sources\boot.wim) and mount the image using DISM. This should be winPE4.0
    4. Browse the mounted image and copy the (d:\sms\bin\i386) to a local drive for later use.
    5. Mount the boot.TST0001.wim, which is winPE3.0, and copy the above directory (which should contain all the SMS SP1 OSD functions) into the same location on the mounted wim. Click yes to overwrite all files.
    6. Un-Mount and commit the boot.TST0001.wim, rename it to boot.wim and copy to the USB key in place of the WinPE 4.0/Overwriting this

    You will now be able to boot an old machine, using winPE3.0, and connect to a SCCM SP1 server and build machines.

    Thanks,

    Pete


    This worked for myself as well (at least so far!)...note that you might need to add the drivers for your USB stick to your WinPE image, otherwise you may get an error stating that it cannot read the task sequence disk.
  • Tuesday, April 02, 2013 10:28 PM
     
     Answered

    Hi,

    I'm PXE booting WinPE 3.0 from my SCCM 2012 SP1 server.

    Here's what I did:

    1. Set up a Hyper-V VM with Win2K8 R2
     2. Installed temp domain/dns (contoso.com)
     3. Ran SCCM 2012 RTM setup and downloaded required files
     4. Copied Distribution Point PKI Client Certificate to the new server
     5. Copied SQL 2008 R2 + SQL 2008 R2 SP2 to new server
     6. Completely removed domain
     7. Changed IP address of VM to an isolated one (192.168.254.254/255.255.255.255)
     8. Changed name of server to match production SCCM 2012 SP1 server
     9. Setup new domain with same name as production domain
     10. Installed SQL 2008 R2 using SQL_Latin1_General_CP1_CI_AS collation
     11. Installed SQL 2008 R2 SP2
     12. Added SCCM 2012 Pre-requisites
     13. Installed SCCM 2012 RTM in Evaluation mode pointing to previously downloaded updates.
     14. Re-used my production site code and site name

    Then in SCCM 2012 RTM Console:
     15. Imported certificate into distribution point component
     16. Customised the boot image (Added Scripting, HTA, drivers & Enabled F8 etc.)
     17. Distributed the boot image to the PXE distribution point
     18. Updated the distribution point
     19. Powered off and mounted the VM's VHD on the hosting server
     20. Copied C:\Program Files\Microsoft Configuration Manager\OSD\boot\i386\boot.XXX000A.wim to the SCCM 2012 SP1 server C:\Workaround.XXX000A.wim

    In SCCM 2012 SP1
     21. Made a copy of the the WinPE4.0 boot.wim (C:\Program Files\Microsoft Configuration Manager\OSD\boot\i386\boot.wim) to (C:\Program Files\Microsoft Configuration Manager\OSD\boot\i386\Workaround.wim)
     22. Added a new boot image, pointing to the new Workaround.wim
     23. Used the distribute content wizard to distribute the WinPE4.0 boot image to the distribution point (copying to package share too), noting the Package ID XXX000A
     24. Updated distribution points
     25. Mounted "C:\Program Files\Microsoft Configuration Manager\OSD\boot\i386\boot.wim" to C:\PE4\mount using dism
     26. Mounted C:\Workaround.XXX000A.wim to C:\PE3\mount using dism
     27. Copied C:\PE4\mount\sms\boot\i386\ to C:\PE3\mount\sms\boot\i386\ overwriting the destination
     28. Dismounted the C:\PE3\mount folder commtting the changes, dismounted c:\PE4\mount
     29. In Windows Explorer - Right clicked C:\Workaround.XXX000A.wim and copied the file to clipboard
     30. In Windows Explorer browse to C:\Program Files\Microsoft Configuration Manager\OSD\boot\i386\
     31. Updated WinPE4.0 boot image on distribution point
     32. Switch back to Windows Explorer, the wizard will still be in progress and a temporary {GUID}.wim file will be visible
     33. The instant it disappears, paste the C:\Workaround.XXX000A.wim to overwrite the freshly created PE4 image with the PE3.0 one (if you do this quick enough the PE3.0 version will be distributed to the SCCMContentLib\FileLib folders)
     34. Associated the task sequences that require PE3 with the Workaround boot image
     35. PXE booted Virtual PC VM with the task sequence targeted to it and kicked off an image deployment

    Cheers,

    James.

     




    • Proposed As Answer by fusiongroup Tuesday, April 02, 2013 10:28 PM
    • Edited by fusiongroup Tuesday, April 02, 2013 10:28 PM
    • Edited by fusiongroup Tuesday, April 02, 2013 10:29 PM
    • Edited by fusiongroup Wednesday, April 03, 2013 9:22 AM typos
    • Edited by fusiongroup Wednesday, April 03, 2013 9:22 AM
    • Edited by fusiongroup Wednesday, April 03, 2013 9:22 AM typos
    • Unproposed As Answer by Binarymine Thursday, April 04, 2013 8:58 PM
    • Edited by fusiongroup Friday, April 05, 2013 9:38 PM New solution allows for PE3 image to be staged to the HDD
    • Edited by fusiongroup Friday, April 05, 2013 9:38 PM
    • Edited by fusiongroup Friday, April 05, 2013 9:42 PM
    • Proposed As Answer by fusiongroup Friday, April 05, 2013 9:42 PM
    • Edited by fusiongroup Friday, April 05, 2013 10:00 PM Partial rewrite
    • Marked As Answer by Binarymine Friday, April 12, 2013 2:59 PM
    •  
  • Wednesday, April 03, 2013 2:27 PM
     
     Answered

    My workaround:

    Site Code for SCCM 2012 RTM: VHD

    Site Code for SCCM 2012 SP1: STS

    1. From you  SCCM 2012 RTM : Copy your boot.VHD00003.wim (winPE3.0 x86) to \\SAN\Share\PE3
    2. From you  SCCM 2012 SP1: Copy your boot.STS00092.wim (winPE4.0 x86) to \\SAN\Share\PE4
    3. Mount your STS00092.wim to C:\IMG_4 using DISM
    4. Browse the mounted image and copy all files and folders from C:\IMG_4\sms\bin\i386\ to C:\temp\PE4_Binaries
    5. Un-mount C:\IMG_4 using DISM (discard flag)
    6. Mount your VHD00003.wim to C:\IMG_3 using DISM
    7. Browse the mounted image and copy all files and folders from C:\temp\PE4_Binaries  C:\IMG_3\sms\bin\i386\ (replace all)
    8. Un-mount C:\IMG_3 using DISM (commit flag)
    9. Rename your modified image boot.VHD00003.wim to boot.wim
    10. On your PXE server, browse in D:\RemoteInstall\SMSImages\STS00092\ and copy your boot.wim image renamed at point 9. (your boot image 3.0 with binaries from PE4)

    Client will take this image at boot.  So, you are in PE 3.0

    I tested in your test and prod environment successfully.

    • Marked As Answer by Binarymine Thursday, April 04, 2013 8:58 PM
    •  
  • Wednesday, April 03, 2013 7:25 PM
     
     

    I want to thank everyone for your contributions to this roadblock.  Never thought I would be happy about imaging a 10 year old pentium 4 computer. I used Manu BE's solution, nice and simple.

    Tom


    • Edited by tommypotatoes Wednesday, April 03, 2013 7:28 PM update
    •  
  • Wednesday, April 03, 2013 8:35 PM
     
     

    I'm not so sure it's 100% there just yet as I found another stumbling block this afternoon.

    I have refresh/upgrade task sequences that are launched from within Windows and use USMT to upload docs to the state migration point. After this they download the boot image to the hard drive. Even though it downloads and stages the correct workaround .wim, it still crashes with the same error... Very odd.

    I'd be interested to hear if you see this behaviour too?

  • Thursday, April 04, 2013 9:35 PM
     
     

    Sorry I didn't respond sooner, been studying for and writing cert exams :P, finally got around to confirming these fixes.

    @Peter J & Manu


    You have both provided valid solutions that are relatively simple to implement I have tested both and confirmed them to be working, I have opted to go with Peter J's solution as this is less intrusive in terms of meddling with the PXE distribution points. We have 42 PXE distribution points in our environment, and I don't really feel that copying the hacked image to the DP's manually would be the best route for us, especially since if I want to make any offline changes to the boot.wim I will have to do a manual update again.


    A quick note on both methods is that they wipe out any custom NIC drivers or background customizations loaded on to the boot.wim via SCCM. Manually mounting the hacked boot.wim with DISM and injecting the drivers via "/Add-Driver /Recursive" switches and replacing the background image via a file copy fixed both issues.


    I ended up creating a bootable ISO out of the files on the modified USB stick. I am distributing this ISO via a software package to our distribution points. Our techs then access and burn the ISO to CD / DVD or stage it onto a flash drive via YUMI.

    Thanks once again for all of your hard work on finding a solution to this problem



    • Edited by Binarymine Thursday, April 04, 2013 9:37 PM edit
    • Edited by Binarymine Thursday, April 04, 2013 9:45 PM edit
    •  
  • Thursday, April 04, 2013 9:53 PM
     
     

    @Fusion

    Your solution is essentially a more complicated version of Manu's, for the sake of anyone who finds this thread I have marked Manu and Peter J as the answers to point to only the most pertinent and efficient information.

    However you raise an interesting concern regarding the state migration point. I have disabled the ability to migrate to a State Migration via UDI as although we utilize USMT4 as part of our deployments we utilize the Hard Link functionality for migrating data. I have not confirmed whether a UDI deploy via refresh with a hard link migration exhibits the same behavior as you have noted above. I will run through a deployment and let you know.

    Thanks

  • Thursday, April 04, 2013 10:33 PM
     
     

    Binarymine,

    I have a single central DP so had to recreate the PE3 boot images from scratch as I had no working PE3 boot image. I created this as a knowledgebase article for our internal network and was going to blog about it, posting the link in here... but I've not bothered signing up for a blogging site since MS shut Live Spaces so it was just quicker to copy and paste it instead. Hopefully it will help out people in the same situation.

    I'd be very interested to hear how your deployment goes. I've no idea why the image will run from the network but not the HDD. I guess it's something else to plug away at. I've also PXE booted to WinPE2 from some images I found on a backup of our old 2007 VM. I might integrate the PE4 binaries to that and see what happens.

    Thanks,

    James.

  • Friday, April 05, 2013 5:56 PM
     
     

    I've done some further testing and have confirmed why the problem is occurring.

    When the image is downloaded, it's actually downloaded from the SCCM content library, rather than from the WDS server.

    This means it's pulled from the \SCCMContentLib\FileLib\ subfolders and because the boot image has only been successfully distributed when it was a WinPE4 boot image, the copy that resides here is still of the original PE4 version.

    I've tried generating these replacement files on the RTM server I built and transferring them over but get a signature check fail error... I'm gonna look into how to get around this next stumbling block and if I find a solution I'll post it back in this thread. I'm not holding out for a solution though as the signatures are there to make sure that the content hasn't been tampered with.



    • Edited by fusiongroup Friday, April 05, 2013 7:50 PM Formatting
    • Edited by fusiongroup Friday, April 05, 2013 7:51 PM Typo
    •  
  • Friday, April 05, 2013 9:41 PM
     
     

    Nailed it!

    I've updated the solution so it will allow the task sequence to download and stage the WinPE3.0 boot image to the HDD.

    Something else you might be interested in. I deleted the package folder (C:\SMSPKGC$\XXX000A) and the WDS image (C:\RemoteInstall\SMSImage\XXX000A) and it re-distributed the PE3 image automatically. This should replicate to all the secondary DPs automatically too.

    So now I have a fully functioning PE3 boot image plus the two original Win8 ones... Might add the x64 PE3 one on Monday, not that I'll use it, just for completeness :)

    Thanks,

    James.




  • Friday, April 12, 2013 3:00 PM
     
     

    That does indeed work. Excellent find, thanks to everyone for your feedback and input on this issue

    Thanks

  • Friday, April 19, 2013 12:53 PM
     
     

    This response worked great for me.  Further, I was able to use dism with the /add-drive switch to inject the drivers I need into the WIM file.

    Does anyone know how to enable command-line support within the WIM file?  I understand how to do so within SCCM, but that's obviously not an option in this case.  I can't find a property or setting within the WIM file that enables this.  We need command-line support in order to grab the smsts.log when the task sequence fails.

  • Friday, April 19, 2013 1:15 PM
     
     
    Why don't you just have a group step in your TS for handling errors?  Then it will automatically grab your log files, copy them out to a file share, and you don't have to worry about doing it manually or enabling command line support.
  • Friday, April 19, 2013 1:54 PM
     
     

    @scubapimp

    In the files that you copied in step 27, there's a TsBootShell.ini file which contains an option, EnableDebugShell, which can be set to true or false.

    I've not tested it, but I'm guessing it's that.



    • Edited by fusiongroup Friday, April 19, 2013 1:55 PM
    • Edited by fusiongroup Friday, April 19, 2013 1:57 PM
    •  
  • Friday, April 19, 2013 9:24 PM
     
     

    @_h4xor_

    I'm unfamiliar with that method - can you please elaborate or link to an example?

    @fusiongroup

    You are right!  I verified EnableDebugShell controls command line support.  Thanks man.

  • Saturday, April 20, 2013 4:07 AM
     
     

    @Scubapimp: We use something similar to the following in our production environment:

    http://schadda.blogspot.com/2012/01/sccm-2012-how-to-catch-errors-in-task.html 

    There might be a typo in the steps, but that article will get you on the right track.