Build a PowerShell-Enabled Windows PE Key: Part 1


Summary: Sean Kearney explores installing the Windows ADK and validating its presence with Windows PowerShell.

Honorary Scripting Guy, Sean Kearney, here filling in for The Scripting Guy. This week, I’m going to help you out with Windows PE.

   Note   This is a five-part series that includes the following posts:

First, we need to explore “what is Windows PE?”

Windows Preinstallation Environment (Windows PE) is a very light version of Windows that is intended for deployment solutions. A perfect example (and one we’ll delve into next week) is when you need to deploy Nano Server onto a physical server. You need to have some type of operating system to access the hard drive structure to place the media.

You could be booting from a PXE or USB scenario, but at some point, there needs to be an operating system to do the needed work of expanding the WIM file, injecting drivers, applying an unattend file, and applying the boot code. This is the purpose that Windows PE was designed for.

First, I need to obtain the media for Windows PE. It is a part of the Windows Assessment and Deployment Toolkit (ADK), which is a freely downloadable set of tools from Microsoft. These tools provide more than the Windows PE environment, but we’ll be focusing on only that aspect for the purpose of this week—specifically, the most current release for Windows 10.

You’ll need to download the installer from Microsoft: ADKSetUp.exe. This is your application to choose and download the media for the ADK.

If you click Next on the next couple of screens to accept the default parameters, you’ll get to the main screen to choose the features you want.

The following image shows the menu of options for the ADK. For Windows PE, we only need to select Windows Preinstallation Environment and Deployment Tools.

Image of menu

Now to automate all of this…

(What? You thought Scripting Guys were going to spend the entire time clicking away?)

You can run ADKSetup.exe with the following parameters:

adksetup.exe' /features OptionId.DeploymentTools OptionId.WindowsPreinstallationEnvironment /quiet

This automatically downloads the required files and places the installation in the default location.

Now let’s think for a moment…

We’re about to write a Windows PowerShell script that has the task that will be utilizing this software. Shouldn’t we test it first?

The environment we need will be sitting in the following folder:

  C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment

We can build a simple function called Test-WindowsADK by using Test-Path to validate that it’s there. This will give us a simple Boolean True/False for its existence.

Function Test-WindowsADK
{
Test-Path "C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment"
}

But if we get really smart, we’d be testing for this on 32-bit and 64-bit versions of Windows (remember that the path name will change). We can determine this by using Get-CimInstance with Win32_OperatingSystem:

(Get-CimInstance Win32_operatingsystem).OSArchitecture

This will result in “32-bit” or “64-bit” depending on the architecture. We can pad in an extra function to build the correct string for the path name if we’re using a 64-bit architecture:

function Get-ArchitectureString
{
$Arch=(Get-CimInstance win32_operatingsystem).OSArchitecture
if ($Arch='32-Bit')
 {
 Return [string]' (x86)'
 }
}

We can now verify whether the Windows ADK is installed by using this really cool function whether or not we’re running on a 64-bit version of Windows:

Function Test-WindowsADK
{
Test-Path "C:\Program Files$(Get-ArchitectureString)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment"
}

Pop in tomorrow when we start doing the really fun stuff, including customizing the Windows PE environment with everything we might need!

I invite you to follow the Scripting Guys on Twitter and Facebook. If you have any questions, send email to them at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then always remember that with great PowerShell comes great responsibility.

Sean Kearney, Honorary Scripting Guy, Cloud and Datacenter Management MVP 

Comments (4)

  1. Qk says:

    Great post, look forward to the next one!

    One question though, should the IF condition in the example be IF ($Arch -eq ’32-Bit’) rather than if ($Arch=’32-Bit’)?

  2. @qk

    You are absolutely correct. That’s what I get for thinking "Hey! I can type this directly from my Module instead of Copy/Paste" —- then the Commodore 64 Basic creeped and messed it all up 😉

    Sean

  3. sgislain says:

    May be i am wrong, but the if condition are not correct.
    If OS = 32bits then it must return "blank" as program files (x86) exists only on 64 bits.

  4. @seb

    You have it correct. I have to get in to the habit of copying my code over instead of trying to type it directly into Microsoft Word. The test should be

    if ($Arch -eq ’64-Bit’)

    Great job catching that logic flaw!

    Sean

Skip to main content