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

    Question

  • 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 formatting
    Thursday, January 17, 2013 6:11 PM

Answers

  • 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 2:50 PM
  • 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
    • Unproposed as answer by Binarymine Thursday, April 04, 2013 8:58 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
    Tuesday, April 02, 2013 10:28 PM
  • 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 2:27 PM

All replies

  • 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 6:39 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
    Thursday, January 17, 2013 7:54 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:37 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:47 PM
  • Facing the same problem ... wish there is a fix for that 
    Monday, January 21, 2013 1:22 PM
  • 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

    Tuesday, January 22, 2013 2:55 AM
  • Have you heard anything back yet? I'm fighting the same problem.

    Wednesday, January 23, 2013 2:07 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 12:26 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
    Monday, February 18, 2013 9:59 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.
    Wednesday, February 20, 2013 12:47 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
    Thursday, February 21, 2013 8:43 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

    Sunday, February 24, 2013 9:41 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, February 25, 2013 2:14 PM
  • 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 5:33 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

    Monday, March 04, 2013 10:19 AM
  • 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 7:04 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:05 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

    Tuesday, March 05, 2013 9:34 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:11 PM Update
    Thursday, March 07, 2013 9:46 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


    • 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 2:50 PM
  • Hello Peter,

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

    Thursday, March 14, 2013 9:41 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: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?

    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.

    Thursday, March 14, 2013 11:35 PM
  • 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.
    Friday, March 15, 2013 1:38 AM
  • 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.
    Wednesday, March 20, 2013 5:55 PM
  • 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
    • Unproposed as answer by Binarymine Thursday, April 04, 2013 8:58 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
    Tuesday, April 02, 2013 10:28 PM
  • 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 2:27 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 7:25 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?

    Wednesday, April 03, 2013 8: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:45 PM edit
    Thursday, April 04, 2013 9:35 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 9:53 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.

    Thursday, April 04, 2013 10:33 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:51 PM Typo
    Friday, April 05, 2013 5:56 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.




    • Edited by fusiongroup Friday, April 05, 2013 10:11 PM
    Friday, April 05, 2013 9:41 PM
  • That does indeed work. Excellent find, thanks to everyone for your feedback and input on this issue

    Thanks

    Friday, April 12, 2013 3:00 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 12:53 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:15 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.



    Friday, April 19, 2013 1:54 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.

    Friday, April 19, 2013 9:24 PM
  • @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.

    Saturday, April 20, 2013 4:07 AM
  • Hi,

    MS has now release CU2 for sccm 2012 which allows importing of 3.1 boot wims :)

    http://support.microsoft.com/KB/2854009

    Cheers,

    Pete

    Monday, June 24, 2013 8:01 AM
  • Thank you Gentlemen! This workaround fixes the issue of not being able to PXE boot my older Dell computers. I also work in a school system and upgrading computers en-masse is simply not an option for us here. So everything works great EXCEPT that it takes WinPE a long time to load (possible 45 minutes) and then it takes another hour before the task sequence password screen shows up. This only occurs on Dell GX260. All others boot up without issue. (745,755) Any ideas on why it's not working on this one model?

    Tuesday, June 25, 2013 6:10 PM
  • I'm guessing that the WIM you're using was imported from a SCCM2012 RTM version and used to work previously?

    You need to see if you can determine what is causing the speed issues. Is it going slow when it pulls the WIM from the network or is it WinPE that's going slow? Try booting off the WIM, then run a task sequence that has a restart computer step that boots into WinPE. This should stage WinPE to the HDD and hopefully fire up a lot quicker.

    If it appears to be network related I'd look at trying different drivers in the boot WIM. If it appears to be WinPE itself that's going slow, I'd download WAIK to get hold of the WinPE 2.0 sources, grab the x86 version, chuck in the SMS binaries, network and any storage drivers (if required) then boot to that to see if it's any faster.

    Wednesday, June 26, 2013 9:01 AM
  • Thank's for the quick response. You are correct. I imported from a SCCM2012 RTM on my virtual server. Can't say it used to work because I started out with SCCM 2012 SP1. Never had RTM running here. I have the boot wim on my flash drive so initially it's the WinPE that going slow. I'll try your suggestion about running a task sequence to restart. I'll also download WAIK w/WinPE 2.0. Do I have to rebuilt from SCCM create task media or can I just retool the flash drive directly?
    Wednesday, June 26, 2013 11:58 AM
  • No probs. Is it going slow when you PXE boot or do you not use that?

    I'm just wondering if it's slow because it's USB 1.1? GX260's are a fair bit older than the 745/755s. I had my GX270 for around 4 years before I upgraded to a 745!

    Have you tried booting off the USBs at the back? Sometimes they're faster than the ports on the front...

    Wednesday, June 26, 2013 11:39 PM
  • Yeah, it's running like molasses from my PXE boot. Never thought about the USB port version. Good point! I'll try it from the back ports to see if it runs any faster. What was your experience with the GX270's. Those are going to be with us for at least another year.
    Thursday, June 27, 2013 3:23 PM
  • Hi,

    Sorry, I had an extended weekend break. Only just back into work-mode.

    I've not had to deal with them so far. We only have four of them left now, three are office based and due to be replaced this month, the last one controls a factory shop floor system and would be a manual process to rebuild so I doubt I'll ever have to be honest.

    Tuesday, July 02, 2013 8:16 AM
  • This is a good post to walk through using 3.1 boot images in your SCCM 2012 SP1 CU2 platform in the supported manner. It worked great for me.

    http://blogs.technet.com/b/brandonlinton/archive/2013/06/21/how-to-create-and-import-a-winpe-3-1-boot-image-for-use-in-configmgr-2012-sp1-cu2.aspx

    Cheers,

    Adam


    Regards Adam

    Wednesday, July 10, 2013 5:12 PM
  • Hey

    Thanks for the response. I'm late replying too - on vacation. So I got it working - sort of. It was the machine not my boot key. So everything comes up ok until the computer tries to receive the policy. Then I get a 0x80070057. A little research reveals that this is a certificate related issue. My question. Is there anyway to import the certificate to the boot key manually?

    Thursday, July 11, 2013 12:42 PM
  • Hi,

    I use certutil to import a SCUP certificate into my Windows Deployment Task Sequences. I'd try inserting the certutil.exe and certadm.dll (Win7 versions) plus your .pfx file into the \sms\bin\i386 folder location (make sure your .pfx file includes all extended properties and also the certificate chain or you'll also have to import the root certificate separately), then adding

    certutil -importPFX X:\sms\bin\i386\<your certificates filename>.pfx

    to the startnet.cmd file.

    I think that should pull in the certificates during the start up of winpe... Again untested.


    • Edited by fusiongroup Thursday, July 11, 2013 2:50 PM grammar
    Thursday, July 11, 2013 2:49 PM