Windows Network Drivers -A WinPE, NDIS and OS Version Graphical Overview

1. The machine boots into a pre-boot imaging Operating System (in this case WinPE4)
2. An imaging tool launches. This locates a remote image file (in this case Sysprep'd Win7 64-bit image) and extracts its contents to the local harddisk
3. Drivers are injected into the dormant Operating System now on the local harddisk
4. Configuration files are injected into the dormant Operating System now on the local harddisk
5. The machine is rebooted into the dormant Operating System, so it can awaken, configure, and become live

Hopefully there is nothing too contentious in all this. As we're here to talk about drivers, I've specifically highlighted a couple of red areas in the 5-point deployment graphic as they require special consideration from a driver point of view),

1. 32-bit NIC driver library for WinPE4
   When deploying a 64-bit operating system, the conceptual ideal is to deploy it with the 64-bit flavour of it's Windows PreInstallation Environment (WinPE) for maximum flexibility. So, why do we here appear to be complicating matters by using 32-bit WinPE?

   Well, 64-bit WinPE has a problem. Microsoft have for years resisted including within WinPE the Windows-On-Windows (WoW) technology that permits downlevel application architectures to run. This is a pain, as most of the useful tools which we'd like to include inside WinPE are compiled  primarily for 32-bit Windows and often do not have 64-bit variants. For this reason (and because in-house apps are still easier to write in 32-bit) most of us end up deploying our machines with the 32-bit flavours of WinPE.

   Whilst this might seem strange, using a 32-bit environment to deploy a 64-bit OS, it's not all bad. Most of the drivers we'd normally install to get a machine fully up and running are not required in WinPE -this environment is designed to be lightweight and the primary task we set it is to pull an image file from a remote network location and dump it to disk. Typically, it's therefore only the NIC drivers (and occasionally mass storage) that we deem critical to include at this stage.

   From the point of view of introducing new models to WinPE, one important consideration is time it takes to confirm a successful import. The process of adding drivers to WinPE, recompiling, and then testing can take over an hour. Every driver chosen in error at this point therefore costs, so anything which reduces that failure rate is welcomed with open arms.
    

2.  64-bit Driver Library for Windows 7
   This is for the driver injection process that forms the heart of most Hardware Independent Imaging (HII) implementations.  HII traditionally uses a combination of sysprep'd images and targeted driver copies to make images more portable. The end result is that we can deploy a single image to multitude of models with full confidence that all the correct drivers automagically installed.

   In order for the driver injection process to work however, a library of drivers needs to be compiled in advance so that the process can correctly target and pull as required. Step 3 in the deployment process injects these drivers to provide this functionality.

   For new models, the process of testing each and every driver can take days, as each driver test requires a full image deployment. Many vendors provide per-model or per-series driver packs which can massively accelerate this process.

In most instances, populating the above libraries can be a simple case of downloading the drivers for the target OS and importing it. NIC drivers however can be slightly thorny as the are often filed using an unfamiliar standards version numbers rather than using something human-readable like the OS name. This leaves many of us guessing as to which is the correct driver to import into our library. The end result all too often for that many admins is that they have to test every driver variant to discover exactly which driver works in each environment. 

Getting The Right Driver for your WinPE Version

So, how do we do this smarter? First I think it will be instructive to see the 'problem' in action. Let's consider the scenario where we have a new model to put in our fold, and that has a new Intel NIC, say the Intel i218-LM adapter. Let's also assume we're still in the scenario depicted in the deployment graphic where we are using 32-bit WinPE4 to deliver our Windows 7 64-bit OS.

Now, the first environment we need to get working for this is the WinPE4 environment (without a function NIC adapter in WinPE, we don't be able to pull the disk image down to the local machine in the imaging process).

A quick visit to the Intel website gives us these options for the i218-LM NIC,

So which do we choose for our WinPE environment? At this point we are left to Google to see which one applies to our environment. The wikipedia entries for the Windows PreInstallation Environment are a good reference, and if we merge that with the Windows Version numbers we get a most useful table,

So, here we see that WinPE4 it turns out to be built on the same core that's used to build Windows 8 and Windows Server 2012. So in this case, we are deploying Windows 7 using the core of Windows 8. That isn't as dumb as it sounds -the Windows 8 core is a better choice for us as it has by default an awful lot more driver support out-of-the-box

For extra piece of mind, we can be doubly sure of the WinPE version by typing the ver command in a command-shell once WinPE is loaded,

Which is in exact agreement with the table. 

So, here we've identified that WinPE 4 requires Windows 8 (or Windows 2012 server) drivers. So, let's now download these and see what we get.

The Network Driver Interface Specification (NDIS)

Once you unpack those Intel I218-LM drivers, this is the folder structure you see,

What these cards illustrate (apart from the fact that we're all waiting for Windows 2016 Server!) is how the Microsoft Operating Systems and their WinPE counterparts are all inter-related under the NDIS framework. The sea of blue shows the extent of the NDIS version boundary, the green labels show the base OS version number, and the 'underpants' labels help illustrate how the WinPE releases relate to the OS release. With these cards, I find that I'm never confused by obscured driver downloads (or WinPE environments that don't explicitly tell you what version they are).

For Windows 8 and beyond, we see that the relationships between OS, WinPE and NDIS versions become very simple; a result perhaps of the technology nomenclature in use here now being fairly mature.  Going back to Windows 7 we see an extra layer of complexity appearing with two WinPE versions existing. If we go further back to Windows XP, to the time when WinPE in particular was just finding its feet, we see a very different story.

The Quick-Reference Cards For Legacy Operating Systems

For those supporting legacy environments, I also have some cards that cover these older releases. These too tell interesting stories. For example, with Windows Vista we see clearly how it alone pioneered NDIS 6.0, creating some confusion for driver authors as they tried to fathom whether they were installing on Windows Vista RTM or Windows Server 2008 (they shared the same OS build number yet implemented different NDIS versions!!).

The Windows XP/ Server 2003 Server card is also fascinating as it captures that time when WinPE first emerged. With each service pack, we see in the card below that WinPE blossomed, finding popularity on it's path to becoming the highly versatile imaging environment we know today.