WinPE 4.0 boot images not working with CPU's that do not support NX/PAE/SSE2

Now that SP1 is out for ConfigMgr 2012, some folks have reported issues after upgrading to ConfigMgr 2012 SP1 due to the fact that it automatically upgrades your WinPE 3.1 (which leverages Windows 7 as the core OS) to WinPE 4.0 which leverages Windows 8 as the core OS.  The reason for this is many processors do not support the three features which Windows 8 requires a processor to support – namely NX, PAE, and SSE2.

On MSDN, we have a document which outlines the support required for Windows 8 here.

This will help you understand the requirements, but does not help if you need to determine if your clients will have an issue when you attempt to utilize OSD after upgrading to SP1 to image your PCs with any OS.

Fear not, for I have created a PowerShell script which leverages the SysInternals tool named “Coreinfo” which is downloadable from https://technet.microsoft.com/en-us/sysinternals/cc835722.aspx.  A huge thanks goes out to PFE Norman Drews for his assistance each time I got stuck in my adventures in PowerShelling!!

Here are the steps to implement my “Pre-Flight” check for reporting on the WinPE 4.0 compatibility in your entire environment.

*NOTE* As a pre-requisite you will need to install WMF 2.0 (https://support.microsoft.com/kb/968929) on your Windows XP SP3 clients so they will know how to execute PowerShell scripts.

1. Download Coreinfo.exe from https://technet.microsoft.com/en-us/sysinternals/cc835722.aspx and my Coreinfo.ps1 script from https://sdrv.ms/YcNNqc.  Drop both of these files into your package source directory for your new application.

2. Create a new ConfigMgr 2012 package using the source directory of the coreinfo.exe and coreinfo.ps1.  The command line will be “powershell.exe –ExecutionPolicy bypass –File .\coreinfo.ps1”.    You will most likely want to create a package for it versus an application since we aren’t actually installing an application.  If you prefer to use an application, you could use the Coreinfo.exe file for the detection method.

3. Place the downloaded Coreinfo.exe in the package source directory.

4. Create a deployment for your new package to run for whether or not a user is logged in. 

When the script executes on the clients, the script will create a new WMI class called “Win_8_Compat” and along with three properties – NX, PAE, and SSE2 which will equal  “0” if the feature is not supported by the processor, and a “1” if the specific feature is supported.  If all three features are a “1” for a client, you should be able to use WinPE 4 in your OS deployment task sequence on the specific client.  If any features are a “0”, you should determine if the PC even supports Windows 8, and if so, there is more than likely a BIOS firmware upgrade available from the PC manufacturer for it to enable Windows 8 support.

Note: Run the script once on the client you are running the ConfigMgr admin console on in order for the new WMI class to show up as an available class. It will be named “Win_8_Compat” in the next step.

5. Add a new hardware inventory class in your client settings by going to Client Settings->Hardware Inventory

6. Click Set Classes->Add->Connect->Connect

7. The properties are stored in root\cimv2.  Enable the three new properties in the new inventory class which will be named “Win_8_Compat”.   Select it and click “OK”.

8. Expand “Win_8_Compat” and the three new properties to add are NX, PAE, and SSE2

Add this new class to your hardware inventory classes and now you can build yourself a report to proactively determine if your clients are going to have issues with Windows PE 4.0.

For example:

SELECT
  v_GS_SYSTEM.Name0
  ,v_GS_Computer_System.Manufacturer0
  ,v_GS_Computer_System.Model0
  ,v_GS_PC_BIOS.Description0
  ,v_GS_Win_8_Compat.NX0
  ,v_GS_Win_8_Compat.PAE0
  ,v_GS_Win_8_Compat.SSE20
FROM
  v_GS_SYSTEM
  INNER JOIN v_GS_Win_8_Compat
    ON v_GS_SYSTEM.ResourceID = v_GS_Win_8_Compat.ResourceID
  INNER JOIN v_GS_Computer_System
    ON v_GS_SYSTEM.ResourceID = v_GS_Computer_System.ResourceID
  INNER JOIN v_GS_PC_BIOS
    ON v_GS_SYSTEM.ResourceID = v_GS_PC_BIOS.ResourceID
WHERE
  v_GS_Win_8_Compat.NX0 != N'1'
  OR v_GS_Win_8_Compat.PAE0 != N'1'
  OR v_GS_Win_8_Compat.SSE20 != N'1'

Build a new report in SQL Report Builder and you get something like this:

 

Now, you’re probably wondering what you can do about the clients which are not supported by WinPE4.  The first thing to look at is, does this specific model support running Windows 8?  If so, check with your specific hardware vendor for a BIOS update to bring it up to current, and it will likely pass the check after doing so.

If it’s just far too old of hardware to support Windows 8 / Windows PE 4, another option is to replace the PC with a PC that does. 

If none of these options are not ideal for your scenario, there is one workaround which you can use to buy you some time until you CAN replace these older PCs.  It requires using USB/CD bootable media but should work for the one-off machines which aren’t supported by WinPE 4.  It’s also not an officially supported workaround, but could be used as a last resort if you’re finding yourself having to support the dinosaurs for a bit longer.

1.  Build yourself a temporary ConfigMgr 2012 RTM version server.  For this example, I will give my RTM install a site code of “ABC”.  If you have not yet upgraded to SP1, you can skip this step.
2.  Copy the boot.ABC0001.wim file from your ConfigMgr 2012 RTM %ProgramFiles%\Microsoft Configuration Manager\OSD\boot\i386 to a safe place.  If you haven’t yet upgraded to SP1, you will not be able to proceed with step 3 until you do.
3.  Create a Task Sequence Bootable USB Media (https://technet.microsoft.com/en-us/library/bb632725.aspx) using your ConfigMgr 2012 SP1 installation.
4.  Copy the WinPE 4 boot.wim from newly created USB (x:\sources\boot.wim) and mount it using DISM.exe (https://technet.microsoft.com/en-us/library/dd744382(v=WS.10).aspx). 
5.  Copy the x:\sms\bin\i386 directory from the WinPE 4 mounted wim to a safe place for use in the next step.
6.  Mount the WinPE 3.x boot.ABC0001.wim copied off during step 2, and copy the i386 directory from step 5 into the same location within the WinPE 3.x mounted wim, overwriting the existing files.
7.  /Unmount-Wim and /Commit-Wim the boot.ABC0001.wim file.
8.  Rename the boot.ABC0001.wim file to boot.wim and copy it to the USB key replacing the WinPE 4.0 boot.wim.

You should be able to use this USB key to boot your older hardware and connect to your ConfigMgr SP1 server for OSD purposes.  You will need to make sure that the boot.wim you use to create your boot media is the same boot.wim that is associated with the task sequence you deploy to these old dinosaurs to prevent them from downloading the fully SP1 based WinPE 4 boot.wim which they cannot successfully boot from.  Check out this thread https://social.technet.microsoft.com/Forums/en-US/configmanagerosd/thread/8faa337b-a648-49b4-8431-49c022b96e04/ for more tweaks related to this workaround.

Enjoy!

Comments

• Anonymous
  January 01, 2003
  Frank - A separate test lab is fine

• Anonymous
  January 01, 2003
  I have not heard that, i'm not sure how that would be the case since there would need to be a thin version of Windows to image PCs.  I suppose the name of it could change but i'm not thinking anyone could image PCs very easily without PE.

• Anonymous
  January 01, 2003
  Worked great.  I hate that it had to be that 'difficult'.  Would it be bad to post some generic boot.wim files for people to download for this issue?

• Anonymous
  January 01, 2003
  Hang in there all, we should have something more elegant in the works to help with this challenge!

• Anonymous
  March 04, 2013
  Excellent this is just what I was looking for! Thank you very much

• Anonymous
  March 04, 2013
  VERY nice - many thanks!

• Anonymous
  April 05, 2013
  Nice workaround, but what didn't Microsoft take this option under consideration from the beginning? I have tons of customers who have stone-age technologies and hardware, and Microsoft cannot just close an eye and say "we don't support them", even if Microsoft should say so, it is not written anywhere unless to run into the problem and search and find a reply in a blog like this. I like the workaround, but I do not like the way Microsoft works here. Thank you

• Anonymous
  April 13, 2013
  Gotta get rid of the old hardware at some point ... I think Microsoft has been more than lenient with developing operating systems that are backwards compatible. They've done a phenomenal job of ensuring that Windows runs on as many systems as realistically possible, while still pushing more and more functionality into the OS.

• Anonymous
  May 22, 2013
  Hi, does the RTM Site Needs to be part of the existing ? or can it also be a Server in a seperate Test LAb ?

• Anonymous
  May 22, 2013
  Thanks Russ. Will check this.

• Anonymous
  July 17, 2013
  I keep hearing from vendors that Microsoft is no longer making PE and the last  final version is 4.0. Is this true?