If you spend a lot of time creating ConfigMgr 2012 R2 OSD Task Sequences, you probably have a method for inserting the steps and groups that you like to use in every TS you create.  Maybe you open a reference TS up and copy and paste steps into a new TS that you are creating.  Maybe you export and import your favorite task sequences or just right-click on one and copy it in the console.  Wouldn’t it be great if you could just create a template of your favorite task sequences and be able to pick them when running through the Create MDT Task Sequence wizard?  Yeah – I was thinking the same thing one day and decided to see if I could do it.

A ConfigMgr Task Sequence is stored in XML.  If you use the Get-CMTaskSequence PowerShell cmdlet, you will notice one of the properties is Sequence.  This is what gets displayed (and updated) when you use the Task Sequence editor.  So, all you need to do is the following:

1. Build a TS the way you like it
2. Export the TS XML
3. Modify it slightly
4. Copy it into the MDT directory
5. Test it by using the Create MDT Task Sequence wizard

For step #1, depending on the steps that you add in the task sequence, you might need to clean them up a bit.  For example, if you have a reference package in a step, you might disable the step if you plan on using the template in another ConfigMgr site.  Do the same for anything that is unique or you do not want shared.  In these cases, there might be minor edits that need to be made to the task sequence after running through the Create MDT Task Sequence wizard.  The benefit is the time saving and all of the groups and steps are in the correct order in the task sequence.

For step #2, export the (XML) contents of Sequence property.  If you just dump that value, the XML will be unformatted and if you are like me, that will drive you crazy.  With a little help from PowerShell (and my good friend Kaido @ Coretech for the proper syntax), we can dump this to a file all nicely formatted.  In my previous post, ConfigMgr 2012 OSD: Automatically Open SMSTS log, I included a template that could be used.  I will use this as my example.  The name of the task sequence that I created as a reference is called Standard OS Deployment MDT-DEBUG.  I want to export the XML to a file called Client Task Sequence – DEBUG.xml.  I accomplished this by using the following:

	$TS = Get-CMTaskSequence -Name 'Standard OS Deployment MDT-DEBUG'
	[XML]$XML = $TS.Sequence
	$XML.Save('e:\1E Demo\Client Task Sequence - DEBUG.xml')

For step #3, there are just a few things that need to be done in order to make it usable with the Create MDT Task Sequence wizard.  Add the following to the beginning of the XML:

<?xml version="1.0"?>
<SmsTaskSequencePackage xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <BootImageID>CEN00006</BootImageID>
  <Category />
  <DependentProgram />
  <Description />
  <Duration>360</Duration>
  <Name>Client Task Sequence - DEBUG</Name>
  <ProgramFlags>152084496</ProgramFlags>
  <SequenceData>

Be sure to give it the proper name as you want it to show up in the Create MDT Task Sequence wizard drop down box (mine is named Client Task Sequence – DEBUG), and update any other settings you require.  The Boot Image ID will get updated by the one that is selected/created in the wizard, so no need to worry about that field.  The next thing is to add the following to the end of the XML:

  </SequenceData>
  <SourceDate>2014-09-16T16:00:00</SourceDate>
  <SupportedOperatingSystems />
  <IconSize>0</IconSize>
</SmsTaskSequencePackage>

I usually modify the SourceDate as a way of versioning my templates.  (Modifying this manually shows what needs to be done, however, this whole process could be automated using PowerShell.)

For step #4, save the file and copy it into the SCCM directory where the Microsoft Deployment Toolkit is installed (i.e. C:\Program Files\Microsoft Deployment Toolkit\SCCM).

For step #5, create a new task sequence using the Create MDT Task Sequence wizard and you should see your newly created template:

Test it out to make sure it works and then share it with your coworkers, friends, local user group, etc.!

Originally posted on http://miketerrill.net/

Last month I had the honor of speaking at my first ever IT/Dev Connections in sunny Las Vegas.  I had the pleasure of presenting on Building the Ultimate Operating System Task Sequence with my coworker and good friend Troy Martin.  As promised, we have completed publishing a series of blogs on all the topics in our session.  We managed to pack a bunch into the session and you can find each of the blogs listed below:

Including Pre-Flight Checks in Your Ultimate Task Sequence

ConfigMgr 2012: Always including certain files in your Boot Images

ConfigMgr 2012 OSD: Automatically Open SMSTS log

ConfigMgr 2012 R2 OSD: Create Your Own TS Templates

I am already looking forward to next year.  It was a great conference with lots of familiar faces and reminded me of the early MMS days.

Originally posted on http://miketerrill.net/

Recently, I was curious to see if I could get 1E PXE Everywhere (included with 1E Nomad) to boot a MDT Lite Touch boot image.  Since PXE Everywhere integrates with System Center Configuration Manager, it automatically creates the necessary BCD files based on the ConfigMgr boot images.  So that left me with using the command line utility bcdedit to generate the BCD file that I needed for the MDT Boot Image.  Not that there is anything wrong with bcdedit, it just requires a bit of typing out long commands.  It returns a GUID when the OSLOADER is create that then needs to be used in some of the follow up commands.  This is where I thought it would be nice to have a simple PowerShell cmdlet to do it for me – the only problem is one does not currently exist.  So after a bit of playing around with the syntax, I came up with the following function below.  It still calls bcdedit, but because of the way PowerShell uses certain characters, it is necessary to use various escape techniques.

This is a quick script to get the job done, so there is not any type of error handling or logging.  Also, I follow the PXE Everywhere naming convention of boot.xxxxx.bcd, so feel free to modify the script to your needs or preferences.

#Create-BCD
#Author: Mike Terrill
#Version 1.0

#Disclaimer:
#Your use of these example scripts or cmdlets is at your sole risk. This information is provided “as-is”, without any warranty, whether express or implied, of accuracy,
#completeness, fitness for a particular purpose, title or non-infringement. I shall not be liable for any damages you may sustain by using these examples, whether direct,
#indirect, special, incidental or consequential.

#Usages:
#Create-BCD Name Platform TFTPBlockSize
#Example:
#Create-BCD LiteTouchPE x64 8192
#Will create a BCD file called boot.LiteTouchPE_x64.bcd with a TFTPBlockSize of 8192

function Create-BCD {
    [CmdletBinding()]
    param (
    [Parameter(Mandatory=$true,ValueFromPipeline=$true)][string]$Name,
    [Parameter(Mandatory=$true,ValueFromPipeline=$true)][string]$Platform,
    [Parameter(Mandatory=$true,ValueFromPipeline=$true)][int]$TFTPBlockSize
    )

    $ImageName = $Name + "_" + $Platform
    $BCDFileName = "boot.$ImageName.bcd"
    bcdedit /createstore $BCDFileName
    bcdedit /store $BCDFileName /create "{bootmgr}"
    bcdedit /store $BCDFileName /set --%{bootmgr} description "Boot Manager"
    bcdedit /store $BCDFileName /set --%{bootmgr} fontpath \Boot\Fonts
    bcdedit /store $BCDFileName /create --%{ramdiskoptions} /d "Windows PE"
    bcdedit /store $BCDFileName /set --%{ramdiskoptions} ramdisksdidevice boot
    bcdedit /store $BCDFileName /set --%{ramdiskoptions} ramdisksdipath \boot.sdi
    #Grab the output that contains the GUID
    $x = bcdedit /store $BCDFileName /create /d "$ImageName" /application OSLOADER
    $GUID = $x|%{$_.split(' ')[2]}
    bcdedit /store $BCDFileName /default $GUID
    cmd /c "bcdedit /store $BCDFileName /set {default} device ramdisk=[boot]\Images\$ImageName\boot.$ImageName.wim,{ramdiskoptions}"
    cmd /c "bcdedit /store $BCDFileName /set {default} osdevice ramdisk=[boot]\Images\$ImageName\boot.$ImageName.wim,{ramdiskoptions}"
    bcdedit /store $BCDFileName /set --%{default} systemroot \WINDOWS
    bcdedit /store $BCDFileName /set --%{default} winpe Yes
    bcdedit /store $BCDFileName /set --%{default} detecthal Yes
    cmd /c "bcdedit /store $BCDFileName /set {ramdiskoptions} ramdisktftpblocksize $TFTPBlockSize"
    }

Using the example inputs will generate the following output (bcdedit /store boot.LiteTouchPE_x64.bcd /enum all):

Windows Boot Manager
--------------------
identifier              {bootmgr}
description             Boot Manager
fontpath                \Boot\Fonts
default                 {default}

Windows Boot Loader
-------------------
identifier              {default}
device                  ramdisk=[boot]\Images\LiteTouchPE_x64\boot.LiteTouchPE_x64.wim,{ramdiskoptions}
description             LiteTouchPE_x64
osdevice                ramdisk=[boot]\Images\LiteTouchPE_x64\boot.LiteTouchPE_x64.wim,{ramdiskoptions}
systemroot              \WINDOWS
detecthal               Yes
winpe                   Yes

Setup Ramdisk Options
---------------------
identifier              {ramdiskoptions}
description             Windows PE
ramdisksdidevice        boot
ramdisksdipath          \boot.sdi
ramdisktftpblocksize    8192

And if you were wondering if I got 1E PXE Everywhere to boot a MDT LiteTouch boot image – the answer is absolutely!

Originally posted on http://miketerrill.net/

I am really honored to have been a speaker at the first ever Midwest Management Summit (aka the new MMS), that took place November 10th – 12th in Minnesota.  This event was the who’s who of systems management and did not disappoint.  There were over 100 sessions delivered in three days by 50+ experts (which included 32 Microsoft MVPs).  This is one conference and training event that you will not want to miss next year.

I also got the opportunity to present again with my co-worker and good friend Troy Martin.  Troy and I presented the following two sessions:

Hacking the Task Sequence

We will go behind the scenes of the CM OSD Task Sequence engine to look at all of the Task Sequence variables.  Mike and Troy will show you:

• Tips and tricks on how to pause, interact and resume a Task Sequence when developing your own custom steps.
• How to overcome certain limitations like read only variables.
• How to tweak your Boot Images so that they always contain the tools and utilities that are needed for ultimate success.
• How the task sequence works “under the hood” and some cool tips for manipulating it.

MMS – Hacking the Task Sequence.pptx

PXE Booting in the Real World

This session will focus on how PXE works and what it takes to get it working in the real world using System Center 2012 R2 Configuration Manager.  In addition to the native PXE boot capabilities in CM, this session will also cover the benefits and capabilities of PXE Everywhere from 1E.

Having difficulty performing zero touch because of 3rd party disk encryption?  Come learn the possibilities that open up when using PXE in your environment. Learn about PXE and what it takes to get up and running.

MMS – PXE Booting in the Real World.pptx

I also got to present for the first time with my co-worker Shawn Cardamon.  For those of you that have not met him, he is full of energy and constantly cracking jokes.  It was a fun presentation and we announced our upcoming 1E Solution Accelerator called 1E Enforcement that we will be releasing for free in the near future.

Advanced Application Management

System Center 2012 Configuration Manager application policies are evaluated prior to content being transferred, so that it can be determined if it the software is actually needed in the first place. Applications make use of the re-evaluation cycle which is enabled by default for all required deployments. This can cause potential issues if a rigid software distribution process is not followed. Come join us in this session as we take a deep look inside Applications and demonstrate some of the pros and cons. Also learn how to do selective Application enforcement and only those Applications that always need to be installed. Learn about Applications and application enforcement.

MMS – Advanced Application Management.pptx

Since 1E was a MMS Platinum Sponsor, we also gave a session on all the cool things that we do at 1E and how we help our customers save money.  For that session, I was joined by Troy, Shawn and also Liam Morrison.

World Class Solutions for Real World Problems

At 1E, our sole mission is to reduce the costs of running IT for our customers and provide avenues to true business value.

Many demands are being placed on IT today to deliver products and services which keep up with the consumerization of IT, provide stronger automation, and at the same time lower overall cost to the business. This session will cover what we see as the true circle of influence systems management has on an organization and how these things may be achieved. For example:

• Are you currently facing a software audit or need to reduce costs on software licenses?  AppClarity can help by identifying software installation and usage. It can even remove unused installations to prevent further license purchases or audit exposures.
• Are your users asking about BYOD? Are you constantly providing laptops for contractors and consultants?  With MyWorkNow you can provide a secure virtual corporate Windows desktop at a fraction of the price to any Mac or PC.
• Are your users looking for an easy way to request and install software?  Has it been challenging to manage and assure the right applications are being installed for your users during an OS deployment? Shopping is the App Store for the Enterprise that puts users and IT in control, each being able to focus on more strategic efforts.
• Stuck managing a large SCCM infrastructure? Do you have multiple locations to manage with SCCM?  Regardless of size, with Nomad you can eliminate the need for 95%+ of servers from SCCM architectures and still be able to perform all of the functions of SCCM like SWD, OSD and SUM.

Come and learn about 1E’s world class solutions and how they address real world problems.

MMS – World Class Solutions for Real World Problems.pptx

This conference was a great way to end the year and I am already looking forward to the next one!

Originally posted on http://miketerrill.net/

Windows Image sizes continue to get bigger and bigger.  I recently recreated my WIMs that I use for testing and applied all important updates through March of 2015 before taking the capture (using MDT of course).  For Windows 7 (both 32-bit and 64-bit), I started with the latest available Windows 7 Enterprise with SP1 ISOs.  For Windows 8 (both 32-bit and 64-bit), I started with the latest available Windows 8.1 Enterprise with Update (released in December 2014).

Prior to the capture, I ran the Disk Cleanup utility to remove any unnecessary files and reduce the size of the final captures.  Below is the end result with a comparison of the original ISO sizes.

Dell recently released the Dell Command | Configure utility (previously known as the Dell Client Configuration Toolkit – CCTK) that allows IT Pros to configure and manage Dell Enterprise client systems.  The latest release (version 3.1 at the time of this blog) includes support for Windows 10 and WinPE 10.  The Command | Configure utility can be used to enable and standardize BIOS settings automatically across the enterprise, yielding a consistent, standard environment.  Now that Windows 10 is here, organizations are going to want to configure UEFI as the default so that they can leverage features like Secure Boot and Device Guard.

Like the CCTK, there is a GUI component and a command line component that can be installed.  For this post, I am going to show you how to create a basic Package that can be used as part of an OSD Task Sequence under WinPE.

The first thing you need to do is download from here (or search on Dell Command Configure) and install it on a Dell system that is already running Windows 7/8/8.1/10.

Next create a directory on your ConfigMgr Package repository share where you store the source files for your ConfigMgr Packages (for example \\ContentSource\Packages\Dell\Command-Configure-WinPE\3.1.0.250).

Locate the install directory and copy the X86 and X86_64 sub folders to the Package share.  On an x64 system, the default location is C:\Program Files (x86)\Dell\Command Configure.

Create a file in the root of the Package directory called cctk.cmd.  Use the following for the contents of the file:

@ECHO OFF

set cmdline=%*

ECHO == Seting BIOS Settings ==

REM Determine Arch
IF "%PROCESSOR_ARCHITECTURE%" == "AMD64" GOTO :X64
GOTO X86

:X64
SET CCTKPath="x86_64"
GOTO RunCCTK

:X86
SET CCTKPath="x86"
GOTO RunCCTK

:RunCCTK
ECHO --Running command %CCTKPath%\cctk.exe %CMDLINE%
%CCTKPath%\cctk.exe %CMDLINE%

EXIT /B %errorlevel%

Next, create another file in the root of the Package directory called HAPIInstall.cmd.  Use the following for the contents of the file:

@echo off
REM Determine Arch
IF "%PROCESSOR_ARCHITECTURE%" == "AMD64" GOTO :X64
GOTO X86

:X64
x86_64\hapi\hapint.exe -i -k C-C-T-K -p "hapint.exe"
GOTO END

:X86
x86\hapi\hapint.exe -i -k C-C-T-K -p "hapint.exe"
GOTO END

:END

Both of these files handle the logic to install either x86 or x64 based on the currently detected platform.  The final Package source directory should look like the following:

Create a Package in ConfigMgr like you normally would and distribute to the Distribution Points.  A Program is not required, so that can be skipped.

In an upcoming post, I will show how this can be used in an OSD Task Sequence.

Originally posted on http://miketerrill.net

If you are starting to deploy Windows 10 (or are currently deploying Windows 8/8.1), then now is the time to make the switch to UEFI.  A system needs to be configured for UEFI (without Compatibility Support Module being enabled) in order to take advantage of Secure Boot (and other Windows 10 security features like Device Guard).  Secure Boot prevents loading of drivers and OS loaders that are not signed with a certified digital signature, thus preventing malware and root kits that alter the boot process.

The first version of Windows that support Secure Boot was Windows 8 and Windows Server 2012.  If you were one of the many companies that either skipped Windows 8/8.1 or only deployed it in limited quantities, then chances are you deployed your systems for legacy BIOS mode.  This means that you Windows 7 systems have MBR partitioned disks and in order to make the switch to UEFI, these systems need to be re-partitioned.  This is one of the limitations of using the Windows 10 In-place upgrade method, as it does not support changing the disk partitioning structure.  The quickest approach to getting to Windows 10 is the In-place upgrade path and it might make sense to do this on the systems that qualify.  For the ones that don’t (including brand new systems), then you definitely want to start configuring them for UEFI and Secure Boot now!

In my previous post, How to create a Dell Command-Configure Package in ConfigMgr, I showed how you could set up the Dell Command-Configure Package in order to use it in OSD Task Sequences.  Now, I am going to show you an example on how it can be used in WinPE via PXE boot (of course, I use 1E PXE Everywhere 3.0 which is part of Nomad 6.0) to enforce these standards.  This will not only increase standardization in your environment, but also prevent costly mistakes made by manual processes.

The first thing we need to do is create a custom Task Sequence.  For this example, I am going to give it the name of BIOS-UEFI Configuration for Windows 10.

NOTE: This Task Sequence example will only work on systems that already have a formatted disk.  We will cover handling bare disks at another time.

Once created, edit the Task Sequence.  For those of you using Nomad, create the Set Nomad as Download Program (new in Nomad 6.0) and Install and Configure Nomad in Windows PE as the first two steps.  Otherwise, add an Apply Operating System Image step called Dummy Step to trick CM and put a Task Sequence variable condition on the step so that the TS variable NEVERTRUE equals TRUE.

This is very important for two reasons – 1. it will make CM set this as an OSD TS so that we can boot into WinPE and run it, 2. the condition will always evaluate to false and allow the step to be skipped (cause we really do not want to apply an OS image yet).

Next, add a Group called Dell BIOS-UEFI Configuration and put a WMI condition on the group with the following query:

Select * From Win32_ComputerSystem WHERE Manufacturer LIKE "%DELL%"

This way it will make it will only apply to Dell systems if you use other OEMs in your environment and it will make it easier to copy and paste into other Task Sequences.

Each of the following steps in this group will be Run Command Line steps that reference the Package Dell Command-Configure-WinPE 3.1.0.250.  I have split out each of the steps in order to make the solution modular.  In other words, not all settings may apply to all Dell models and conditions can be set on the individual steps accordingly.  So, be sure to test against all models that you support.  Another reason for splitting out the steps is that you will get output from each of the commands.  I have included steps that will attempt to get the current setting prior to the step that actually sets the value.  Some of the output can be read from the status messages that are sent back to ConfigMgr, while others will only be reflected in the smsts.log.  For the steps that get the current values, I have made those ‘continue on error’ in order to prevent the Task Sequence from failing from non-zero return values.  Getting the Secure Boot value is one that returns a non-zero exit code (along with the text “The option ‘secureboot’ is not enabled”, if it is not enabled) and will cause the Task Sequence to fail at that point.  In other words, we do not care if it fails reading a value, but we do care if it fails setting a value.

Also, these settings are ones that I would set, so please research each one using the Dell Command-Configure documentation and set the values that work for your environment.

Here is a list of the settings:
NOTE: each of the commands use a double dash, which is hard to see from the screen shots.

Name: Install Dell HAPI Drivers
Command line: HAPIInstall.cmd

Name: Current Active Boot List
Command line: cctk.cmd bootorder --activebootlist

Name: Enable UEFI
Command line: cctk.cmd bootorder --activebootlist=uefi

Name: Current Legacy ROM Setting
Command line: cctk.cmd --legacyorom

Name: Disable Legacy ROMs
Command line: cctk.cmd --legacyorom=disable

Name: Current Secure Boot Setting
Command line: cctk.cmd --secureboot

Name: Enable Secure Boot
Command line: cctk.cmd --secureboot=enable

Name: Current Wake On Lan Setting
Command line: cctk.cmd --wakeonlan

Name: Enable Wake On Lan
Command line: cctk.cmd --wakeonlan=enable

Name: Current UEFI PXE Setting
Command line: cctk.cmd --uefinwstack

Name: Enable UEFI Network Stack
Command line: cctk.cmd --uefinwstack=enable

Name: Current SATA-RAID Setting
Command line: cctk.cmd --embsataraid

Name: Set SATA Operation - AHCI
Command line: cctk.cmd --embsataraid=ahci

Name: Set PXE Boot on next boot
Command line: cctk.cmd --forcepxeonnextboot=enable

Outside of the Dell BIOS-UEFI Configuration Group, I put a Run Command Line step called Pause with the condition that the Task Sequence variable PAUSE equals TRUE.  This is useful for testing and/or troubleshooting as it will launch a command line and prevent the Task Sequence from finishing.  Simply put the PAUSE variable on either the collection targeted or a device that is being tested.

The last step is a Set Task Sequence Variable step called Restart WinPE.  This sets the Task Sequence variable SMSTSPostAction to the value wpeutil reboot.  This allows the Task Sequence to finish cleanly.

Hopefully you have found this information useful and it gets you well on your way for standardizing your environment’s BIOS-UEFI settings. By making the change to UEFI, it will allow you to take full advantage of the security features in Windows 10.  Now when you boot into WinPE and run the OSD Task Sequence wizard, it will detect that the system is running UEFI (_SMSTSBootUEFI = TRUE) and the disk will be partitioned and formatted accordingly.

You can also download an export of the Task Sequence here: BIOS-UEFI Configuration for Windows 10.zip

Originally posted on http://miketerrill.net/

Now that Windows 10 has been released, you are probably starting to take a closer look at the new OS and the related security benefits that it has to offer.  Secure Boot is a supported security feature in Windows 10 that secures the boot process by only allowing the loading of drivers and boot loaders that are signed with a trusted signature.  The first versions of Windows to support Secure Boot were Windows 8 and Windows Server 2012.  Secure Boot requires computer systems to be running UEFI 2.3.1 (or later).  Legacy ROMs or compatibility support modules (CSM) must be disabled in order to enable Secure Boot.

In this blog, I will show you how to extend the Configuration Manager hardware inventory so that you can report on the state of Secure Boot in your environment.  This will not only tell you which systems have Secure Boot enabled or disabled, but it will also help you detect systems that are not currently running UEFI (the ones running in BIOS mode).  Identifying these systems will be helpful when determining the deployment method that you will select when moving to Windows 10.  If it is a requirement of your security team that all systems running Windows 10 must also be running Secure Boot, it will give you an idea on how much effort will be involved during the deployment process.

Now, for the systems that are running in BIOS mode, it will not show which ones are UEFI capable.  However, most enterprise class systems purchased in the last three years are UEFI capable.  In a later post, I will show how you can use OEM specific tools that will help you determine which systems are UEFI capable.  If the desire is to ‘take the hit’ and change all of the BIOS systems to UEFI as part of the Windows 10 deployment, then this will require the disks to be completely re-partitioned so that it can boot UEFI.  This is a destructive process, meaning that anything on the disk will be lost and any data that needs to be retained needs to be backed up to another location (like a network share, State Migration Point, external storage, or even a peer system – like Nomad Peer Backup Assistance).  Note that it is not necessary to convert to UEFI in order to upgrade to Windows 10.  Windows 10 supports systems that are currently running in BIOS mode, but you cannot take advantage of the security features in Windows 10 – like Secure Boot, Device Guard and Credential Guard.

The inventory extension is actually pretty simple and it will not add that much additional data to the hardware inventory scan.  Since I am keying off of a registry key, this extension uses the registry property provider and requires an addition to the configuration.mof file.  This file can be found in the .\inboxes\clifiles.src\hinv directory where Configuration Manager is installed on the Primary Site Server.  Add in the following section (also provided below in a file called UEFI_SECUREBOOT_CONFIGURATION.mof) at the end of file in between the // Added extensions start and // Added extensions end lines:

// ==================================================================
// START SECTION
// Custom UEFI Secure Boot Settings
// ==================================================================

#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("SecureBootState", NOFAIL)
[DYNPROPS]
Class SecureBootState
{
	[key] string KeyName;
	Uint32 UEFISecureBootEnabled;
};

[DYNPROPS]
Instance of SecureBootState
{
	KeyName="Secure Boot Settings";
	[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\SecureBoot\\State|UEFISecureBootEnabled"),Dynamic,Provider("RegPropProv")] UEFISecureBootEnabled;
};

// ==================================================================
// Custom UEFI Secure Boot Settings
// END SECTION
// ==================================================================

Next, save the following text to a file called UEFI_SECUREBOOT_SMS_DEF.mof (or download the file below):

// ==================================================================
// START SECTION
// Custom UEFI Secure Boot Settings
// ==================================================================

#pragma namespace ("\\\\.\\root\\cimv2\\SMS")
#pragma deleteclass("SecureBootState", NOFAIL)
[SMS_Report(TRUE),
SMS_Group_Name("Secure Boot State"),
SMS_Class_ID("UEFI|SecureBootState|1.0")]
Class SecureBootState: SMS_Class_Template
{
[SMS_Report(TRUE),key] string KeyName;
[SMS_Report(TRUE)] Uint32 UEFISecureBootEnabled;
};

// ==================================================================
// Custom UEFI Secure Boot Settings
// END SECTION
// ==================================================================

I typically make a backup of each file on the Primary Site Server in a folder called Custom MOF Extensions so that they can be backed up as part of a DR plan and so other team members know what custom inventory extensions were done.

Following this, navigate to the Default Client Settings in the Configuration Manager Console and select the Hardware Inventory section.  Once open, click on the Set Classes … button:

On the Hardware Inventory Classes screen, click the Import button and browse to the location where the UEFI_SECUREBOOT_SMS_DEF.mof file was saved earlier and leave the default selected (Import both hardware inventory classes and hardware inventory class settings) when prompted:

You should now see the new class listed and it will be enabled.  If you would rather inventory this class on a specific collection of systems (like workstations), then un-select it from in the following screen.

Once systems start processing the new inventory extension, you will see a new Hardware Inventory category in Resource Explorer called Secure Boot State.  If a system is running in UEFI mode, it will have a 1 in the column UEFI Secure Boot enabled for systems that have Secure Boot enabled:

For systems that do not have Secure Boot enabled but are running in UEFI mode, the value will be 0, and for those systems not running in UEFI (i.e. ones running in BIOS mode), the value will be null.

Files:

UEFI_SECUREBOOT_CONFIGURATION.mof

UEFI_SECUREBOOT_SMS_DEF.mof

Originally posted on http://miketerrill.net

Dell recently released the Dell Command | Configure utility (previously known as the Dell Client Configuration Toolkit – CCTK) that allows IT Pros to configure and manage Dell Enterprise client systems.  The latest release (version 3.1 at the time of this blog) includes support for Windows 10 and WinPE 10.  The Command | Configure utility can be used to enable and standardize BIOS settings automatically across the enterprise, yielding a consistent, standard environment.  Now that Windows 10 is here, organizations are going to want to configure UEFI as the default so that they can leverage features like Secure Boot and Device Guard.

Like the CCTK, there is a GUI component and a command line component that can be installed.  For this post, I am going to show you how to create a basic Package that can be used as part of an OSD Task Sequence under WinPE.

The first thing you need to do is download from here (or search on Dell Command Configure) and install it on a Dell system that is already running Windows 7/8/8.1/10.

Next create a directory on your ConfigMgr Package repository share where you store the source files for your ConfigMgr Packages (for example \\ContentSource\Packages\Dell\Command-Configure-WinPE\3.1.0.250).

Locate the install directory and copy the X86 and X86_64 sub folders to the Package share.  On an x64 system, the default location is C:\Program Files (x86)\Dell\Command Configure.

Create a file in the root of the Package directory called cctk.cmd.  Use the following for the contents of the file:

@ECHO OFF

set cmdline=%*

ECHO == Seting BIOS Settings ==

REM Determine Arch
IF "%PROCESSOR_ARCHITECTURE%" == "AMD64" GOTO :X64
GOTO X86

:X64
SET CCTKPath="x86_64"
GOTO RunCCTK

:X86
SET CCTKPath="x86"
GOTO RunCCTK

:RunCCTK
ECHO --Running command %CCTKPath%\cctk.exe %CMDLINE%
%CCTKPath%\cctk.exe %CMDLINE%

EXIT /B %errorlevel%

Next, create another file in the root of the Package directory called HAPIInstall.cmd.  Use the following for the contents of the file:

@echo off
REM Determine Arch
IF "%PROCESSOR_ARCHITECTURE%" == "AMD64" GOTO :X64
GOTO X86

:X64
x86_64\hapi\hapint.exe -i -k C-C-T-K -p "hapint.exe"
GOTO END

:X86
x86\hapi\hapint.exe -i -k C-C-T-K -p "hapint.exe"
GOTO END

:END

Both of these files handle the logic to install either x86 or x64 based on the currently detected platform.  The final Package source directory should look like the following:

Create a Package in ConfigMgr like you normally would and distribute to the Distribution Points.  A Program is not required, so that can be skipped.

In an upcoming post, I will show how this can be used in an OSD Task Sequence.

Originally posted on http://miketerrill.net

If you are starting to deploy Windows 10 (or are currently deploying Windows 8/8.1), then now is the time to make the switch to UEFI.  A system needs to be configured for UEFI (without Compatibility Support Module being enabled) in order to take advantage of Secure Boot (and other Windows 10 security features like Device Guard).  Secure Boot prevents loading of drivers and OS loaders that are not signed with a certified digital signature, thus preventing malware and root kits that alter the boot process.

The first version of Windows that support Secure Boot was Windows 8 and Windows Server 2012.  If you were one of the many companies that either skipped Windows 8/8.1 or only deployed it in limited quantities, then chances are you deployed your systems for legacy BIOS mode.  This means that your Windows 7 systems have MBR partitioned disks and in order to make the switch to UEFI, these systems need to be re-partitioned.  This is one of the limitations of using the Windows 10 In-place upgrade method, as it does not support changing the disk partitioning structure.  The quickest approach to getting to Windows 10 is the In-place upgrade path and it might make sense to do this on the systems that qualify.  For the ones that don’t (including brand new systems), then you definitely want to start configuring them for UEFI and Secure Boot now!

In my previous post, How to create a Dell Command-Configure Package in ConfigMgr, I showed how you could set up the Dell Command-Configure Package in order to use it in OSD Task Sequences.  Now, I am going to show you an example on how it can be used in WinPE via PXE boot (of course, I use 1E PXE Everywhere 3.0 which is part of Nomad 6.0) to enforce these standards.  This will not only increase standardization in your environment, but also prevent costly mistakes made by manual processes.

The first thing we need to do is create a custom Task Sequence.  For this example, I am going to give it the name of BIOS-UEFI Configuration for Windows 10.

NOTE: This Task Sequence example will only work on systems that already have a formatted disk.  We will cover handling bare disks at another time.

Once created, edit the Task Sequence.  For those of you using Nomad, create the Set Nomad as Download Program (new in Nomad 6.0) and Install and Configure Nomad in Windows PE as the first two steps.  Otherwise, add an Apply Operating System Image step called Dummy Step to trick CM and put a Task Sequence variable condition on the step so that the TS variable NEVERTRUE equals TRUE.

This is very important for two reasons – 1. it will make CM set this as an OSD TS so that we can boot into WinPE and run it, 2. the condition will always evaluate to false and allow the step to be skipped (cause we really do not want to apply an OS image yet).

Next, add a Group called Dell BIOS-UEFI Configuration and put a WMI condition on the group with the following query:

Select * From Win32_ComputerSystem WHERE Manufacturer LIKE "%DELL%"

This way it will only apply to Dell systems if you use other OEMs in your environment and it will make it easier to copy and paste into other Task Sequences.

Each of the following steps in this group will be Run Command Line steps that reference the Package Dell Command-Configure-WinPE 3.1.0.250.  I have split out each of the steps in order to make the solution modular.  In other words, not all settings may apply to all Dell models and conditions can be set on the individual steps accordingly.  So, be sure to test against all models that you support.  Another reason for splitting out the steps is that you will get output from each of the commands.  I have included steps that will attempt to get the current setting prior to the step that actually sets the value.  Some of the output can be read from the status messages that are sent back to ConfigMgr, while others will only be reflected in the smsts.log.  For the steps that get the current values, I have made those ‘continue on error’ in order to prevent the Task Sequence from failing from non-zero return values.  Getting the Secure Boot value is one that returns a non-zero exit code (along with the text “The option ‘secureboot’ is not enabled”, if it is not enabled) and will cause the Task Sequence to fail at that point.  In other words, we do not care if it fails reading a value, but we do care if it fails setting a value.

Also, these settings are ones that I would set, so please research each one using the Dell Command-Configure documentation and set the values that work for your environment.

Here is a list of the settings:
NOTE: each of the commands use a double dash, which is hard to see from the screen shots.

Name: Install Dell HAPI Drivers
Command line: HAPIInstall.cmd

Name: Current Active Boot List
Command line: cctk.cmd bootorder --activebootlist

Name: Enable UEFI
Command line: cctk.cmd bootorder --activebootlist=uefi

Name: Current Legacy ROM Setting
Command line: cctk.cmd --legacyorom

Name: Disable Legacy ROMs
Command line: cctk.cmd --legacyorom=disable

Name: Current Secure Boot Setting
Command line: cctk.cmd --secureboot

Name: Enable Secure Boot
Command line: cctk.cmd --secureboot=enable

Name: Current Wake On Lan Setting
Command line: cctk.cmd --wakeonlan

Name: Enable Wake On Lan
Command line: cctk.cmd --wakeonlan=enable

Name: Current UEFI PXE Setting
Command line: cctk.cmd --uefinwstack

Name: Enable UEFI Network Stack
Command line: cctk.cmd --uefinwstack=enable

Name: Current SATA-RAID Setting
Command line: cctk.cmd --embsataraid

Name: Set SATA Operation - AHCI
Command line: cctk.cmd --embsataraid=ahci

Name: Set PXE Boot on next boot
Command line: cctk.cmd --forcepxeonnextboot=enable

Outside of the Dell BIOS-UEFI Configuration Group, I put a Run Command Line step called Pause with the condition that the Task Sequence variable PAUSE equals TRUE.  This is useful for testing and/or troubleshooting as it will launch a command line and prevent the Task Sequence from finishing.  Simply put the PAUSE variable on either the collection targeted or a device that is being tested.

The last step is a Set Task Sequence Variable step called Restart WinPE.  This sets the Task Sequence variable SMSTSPostAction to the value wpeutil reboot.  This allows the Task Sequence to finish cleanly.

Hopefully you have found this information useful and it gets you well on your way for standardizing your environment’s BIOS-UEFI settings. By making the change to UEFI, it will allow you to take full advantage of the security features in Windows 10.  Now when you boot into WinPE and run the OSD Task Sequence wizard, it will detect that the system is running UEFI (_SMSTSBootUEFI = TRUE) and the disk will be partitioned and formatted accordingly.

You can also download an export of the Task Sequence (updated for CM 1511) here: Dell BIOS-UEFI Configuration for Windows 10 x64.zip

Originally posted on https://miketerrill.net/

HP has a utility that is similar to the Dell’s Command | Configure utility (see How to create a Dell Command-Configure Package in ConfigMgr) called the HP BIOS Configuration Utility that allows for reading and setting BIOS/UEFI values on HP systems. The latest release (version 4.0.13.1 at the time of this blog post) can be found on the HP Client Management Solutions page in the Download Library. The HP BIOS Configuration Utility can be used to enable and standardize BIOS/UEFI settings automatically across the enterprise, yielding a consistent, standard environment. Now that Windows 10 is here, organizations are going to want to configure UEFI as the default so that they can leverage features like Secure Boot, Device Guard and Credential Guard.

The HP BIOS Configuration Utility is only command line (in other words, there is not a GUI component like Dell’s Command | Configure utility). However, the HP BIOS Configuration Utility can output an answer file that can then be used to apply to other systems. For this post, I am going to show you how to create a basic ConfigMgr Package that can be used as part of an OSD Task Sequence

The first thing you need to do is download it from the HP Client Management Solutions page (or search on HP BIOS Configuration Utility) and install it on a HP system.

Next, create a directory on your ConfigMgr Package repository share where you store the source files for your ConfigMgr Packages (for example \\ContentSource\Packages\HP\BIOS Configuration Utility-WinPE\4.0.13.1).

Locate the install directory and copy the contents of the installation directory (minus the link to the User’s Guide) to the Package share. On a x64 system, the default install location is C:\Program Files (x86)\Hewlett-Packard\BIOS Configuration Utility.

Create a file in the root of the Package directory called BCU.cmd. Use the following for the contents of the file:

@ECHO OFF

set cmdline=%*

ECHO == Seting BIOS Settings ==

REM Determine Arch
IF "%PROCESSOR_ARCHITECTURE%" == "AMD64" GOTO :X64
GOTO X86

:X64
SET BCU="BiosConfigUtility64.exe"
GOTO RunBCU

:X86
SET BCU="BiosConfigUtility.exe"
GOTO RunBCU

:RunBCU
ECHO --Running command %BCU% %CMDLINE%
%BCU% %CMDLINE%

EXIT /B %errorlevel%

This file handles the logic to run the correct exe based on the currently detected platform. The final Package source directory should look like the following:

Create a Package in ConfigMgr like you normally would and distribute it to the Distribution Points. A Program is not required, so that can be skipped.

In a future post, I will show how this can be used in an OSD Task Sequence.

Originally posted on http://miketerrill.net

At the Midwest Management Summit today in the 7 AM OSD Birds of a Feather session, there was a lot of discussion around troubleshooting PXE booting issues. A reference was made to a session that Troy Martin and I gave at the 2014 Midwest Management Summit called PXE Booting in the Real World. Troy put together some nice SQL queries that help with the troubleshooting process:

/* Get list of devices and their Last PXE boot for (a) required deployments */
SELECT * FROM [CM_PS1].[dbo].[LastPXEAdvertisement] order by MAC_Addresses
 
/* Get item key for unknown records */
select * [CM_PS1].[dbo].[UnknownSystem_DISC]
 
/* Is device known and a valid client on the site */
Use CM_PS1
exec NBS_LookupPXEDevice N'45A74041-2F02-4A5E-B413-CD35DDE47123',N'1E:1E:1E:1E:1E:B1'
exec NBS_LookupPXEDevice N'2DCFD0F8-9134-44A3-84BB-0BFC114ADD87',N'1E:1E:1E:1E:1E:B2'
 
/* Get list of deployments for device */
Use CM_PS1
exec NBS_GetPXEBootAction N'16777278',N'2046820352',N'45A74041-2F02-4A5E-B413-CD35DDE47123',N'1E:1E:1E:1E:1E:B1',N'CM12PS1.contoso.com'
exec NBS_GetPXEBootAction N'16777279',N'2046820353',N'2DCFD0F8-9134-44A3-84BB-0BFC114ADD87',N'1E:1E:1E:1E:1E:B2',N'CM12PS1.contoso.com'

Here is a link to the slide deck that contains more information and a bunch of useful references.

Originally posted on https://miketerrill.net/

The history of AZSMUG:

We have been planning this meeting for a long time and I really wanted to make this a special meeting. I got the idea to start the user group from a session that I attended at the Microsoft Management Summit in 2006. A Microsoft MVP by the name of Ed Aldrich gave a session on starting a local user group and I followed up with him afterwards for help on get things started (ironically Ed is now my coworker at 1E – although neither of us worked at 1E when we first met).

I also went through several Microsoft employees trying to find someone (a Microsoft blue badge employee) that would sponsor us so that we could host the meetings at the Microsoft office (back then it was at Central and Thomas). After striking out multiple times, I came across a Microsoft person by the name of Harold Wong (many of you probably know him from the TechNet Events). At the time, Harold was traveling as much, if not more than I was, but he always made time for us  when we wanted to have a meeting (even during his personal time, as most of our meetings were in the evenings). So a huge thanks to Harold for helping out all of these years! (BTW – he still travels a lot)

Our very first meeting was on September 21st, 2006. I think we had about 12 people attend the very first meeting – ironically many of those people still attend the user group today, so another thanks to all of you for sticking with us throughout the years!

Now, I know it would have been epic to have the 10-year meeting on the same exact day this year, but due to logistics October 7th turned out to be the ideal day. I personally am super excited for this meeting and hope to see as many of you there as possible.

So what is a Taste of MMS? The AZSMUG 10-year Anniversary Meeting IS a Taste of MMS. MMS, the Midwest Management Summit, is a systems management conference that provides top quality real-world sessions in a relaxed, setting. There is plenty of time for questions or even talking to speakers and peers.

So what makes this 10-year Anniversary Meeting a Taste of MMS? Every single speaker (Kent Agerlund, Brian Mason, Peter Daalmans, Greg Ramsey, Michael Niehaus and myself) has presented multiple sessions at the previous MMS conferences, which makes this meeting a ‘taste’ of what you get by attending the next MMS.

Registration is filling up fast, so be sure to book your ticket soon.
10 Years of AZSMUG
6 Speakers
4 Microsoft MVPs
1 Day (Friday, October 7th 2016, Tempe, AZ Microsoft Office)
https://www.eventbrite.com/e/azsmug-10-year-anniversary-meeting-tickets-27330799156

Thanks,
Mike Terrill
AZ Systems Management User Group

Originally posted on https://miketerrill.net/

I have seen a few blog posts lately that talk about splitting large WIM files in order to get them to fit on a USB flash drive that is formatted as Fat32. I am not exactly sure why you would want to do that when you don’t have to, as it sounds like extra work to me (but hey, if you like extra work then be my guest).

In my previous post, USB Flash Drives, UEFI and large WIMs, I showed how you can create multiple partitions on certain USB Flash Drives that were either already set as a fixed disk or could have the removable bit flipped using a special utility. Having multiple partitions is useful when you need to boot a UEFI system off the USB Flash Drive and install an operating system. UEFI needs a Fat32 formatted partition in order to boot. The problem with Fat32 is that it has a maximum file size limit of 4GB. Custom images (WIMs) can easily exceed 4GB in size (even the install.wim for Windows Server 2016 is larger than 4GB), which prevents them from being copied to a Fat32 formatted partition. In order to over come this, you would need either need to split the WIM or install it from a file share (provided you have network connectivity) or from another NTFS formatted partition/drive.

Starting in the Windows 10 Insider Preview build 14965, Diskpart now allows you to create multiple partitions on ANY USB Flash Drive – even ones that have the removable bit set.

The following two USB Flash Drives were ones that I could not flip the removable bit nor get multiple partitions on them previously (note that they both still show as Removable):

SanDisk Ultra:

Lexar:

In order to copy files to the second partition, you will need to use the Windows 10 Insider Preview build 14965 (or later). Windows 10 1607 cannot read the second partition (yet), which means that current Windows setup (Server 2016 or Windows 10) might have an issue reading it (in other words I haven’t fully tested that part yet).  Now time to experiment more with this and the new WinPE found in the Windows ADK Insider Preview…

Originally posted on https://miketerrill.net/

Back in December, Microsoft published a blog (Windows 10 Creators Update advances security and best-in-class modern IT tools) where they mentioned a conversion tool for making the conversion to UEFI:

“In-place UEFI conversion

We’ve heard from our customers that they want to take advantage of new Windows 10 security investments like Device Guard on their existing modern hardware, but many of these new features require UEFI-enabled devices. For those customers who have already provisioned modern Windows PCs that support UEFI but installed Windows 7 using legacy BIOS, converting a device to UEFI required an IT manager to repartition the disc and reconfigure the firmware. This meant they would need to physically touch each device in their enterprise. With the Creators Update, we will introduce a simple conversion tool that automates this previously manual work. This conversion tool can be integrated with management tools such as System Center Configuration Manager (ConfigMgr)* as part of the Windows 7 to Windows 10 in-place upgrade process.”

I disagree with their statement that you need to physically touch each device in the enterprise in order to make the conversion to UEFI, as I have engineered the process that we have been using at 1E in our Windows 10 Now solution since last year. However, in order to do the conversion and to be supported (which the 1E Windows 10 Now Solution is 100% supported) you need to completely format and partition the in order to change it from MBR to GPT. This presents other challenges, such as backing up and restoring user data and re-installing applications. There are other unsupported solutions out there (like GPTGen) that I know other vendors use that enable you to switch the disk layout from MBR to GPT without formatting and partitioning the disk, but I would steer clear of these solutions (and vendors) in order to continue to be supported by Microsoft.

In the Microsoft blog, they only made a mention of the ‘simple conversion tool’ and did not provide any details about it (like when to expect it, how to use it, etc.). Well, there was a nice little surprise that showed up in build 15007 of the Windows 10 Enterprise Insider Preview called MBR2GPT.EXE

This looks like the conversion utility that the blog post mentioned. Other than the MBR2GPT help, there is not much information about the utility and what versions of Windows 10 that will be supported. With this tool, more machines will qualify for an in-place upgrade (like machines that are currently running BIOS). There are still some in-place upgrade limitations out there, like 3rd party disk encryption (unless the vendor now supports in-place upgrade) or changing between architectures or base OS languages, that will still require a wipe-and-load approach (see Johan’s post Windows 10 Upgrade Limitations for a few others).

The other thing that needs to be done when using MBR2GPT is to set the correct vendor specific BIOS settings changes so that the system will boot UEFI after converting the disk layout. The order of the settings does matter and settings can vary among models from the same vendor. I have previously blogged about (Automating Dell BIOS-UEFI Standards for Windows 10) how to do this for Dell (they have the most consistent BIOS settings out of everyone). We also have a BIOS to UEFI tool that only comes with Nomad that abstracts all of the vendor settings that I have blogged about (Getting Started with 1E BIOS to UEFI) that has a slick UI in the form of a Task Sequence step.

(Yea, I know, I have heard from many of you that 1E should offer this as a stand alone tool – feel free to let them know at info@1e.com.)

In my next post, Getting Started with MBR2GPT, we will talk a look at this tool in action and keep in mind that this is pre-release software for now so do not use it in production yet!

Originally posted on https://miketerrill.net/

In my previous post, BIOS to UEFI made easier with Windows 10 Creators Update, I uncovered a hidden gem in the 15007 build of the Windows 10 Enterprise Insider Preview called MBR2GPT. The benefits of this MBR to GPT conversion utility is that it makes it easier to convert systems from BIOS to UEFI and be able to take advantage of all the security features that comes in Windows 10 like Secure Boot, Device Guard and Credential Guard (to name a few). Currently, in order to stay supported by Microsoft, the hard disk needs to be completely repartitioned and formatted when switching from MBR to GPT. This is a destructive process and requires the user data to be backed up off of the hard drive, applications to be re-installed and then the user data restored once the new OS is up and running. Without the proper tools (shameless plug – see the 1e Windows 10 Now Solution), this can be a cumbersome task.

You still want to put some thought into applications as it relates to an in-place upgrade. There will be some applications that will be upgrade blockers (mainly 3rd party antivirus that is not compatible with the Windows 10 in-place upgrade process or 3rd party disk encryption) and need to be uninstalled prior to the in-place upgrade. There will also be applications that you will want upgraded – do you really want to run Office 2003 which may have been your standard on Windows 7 on Windows 10 or would you like to uplift it to Office 365 as part of the process? You might also want to replace an application with a less costly application (like swapping an expensive FTP client with a less expensive one). And lastly, you might want to uninstall applications that are not used in order to reduce your security foot print and eliminate unnecessary patching. These are things to consider when venturing down the in-place upgrade deployment method.

Applications aside for now, let’s get back to MBR2GPT…

You are probably wondering what are the options for using this utility – well, I can tell you if you have already deployed Windows 10 to BIOS systems you are fortunately in luck. Also, if you have not even started your Windows 10 upgrade, you are also in luck. The basic upgrade process will look like the following:

Windows* running on BIOS > In-place upgrade to Windows 10 (probably Creators Update) – still running BIOS at this point > MBR2GPT > Vendor BIOS Settings > Reboot > Windows 10 running UEFI.

Where Windows* is any version that supports upgrading to a Windows 10 version that supports MBR2GPT (like Windows 7 SP1 x64, Windows 8/8.1 x64 and previous versions of Windows 10-1507/1511/1607).

Now that we have that covered, let’s see how this tool actually runs. Below, I have an Insiders build of Windows 10 Creators Update (note that this is build 15002 and that MBR2GPT is in 15007). As you can see, BIOS Mode is Legacy and there is a single hard disk with Master Boot Record(MBR) volume:

I have copied the MBR2GPT utility from a 15007 build on to the C: drive of this system. Running MBR2GPT.exe /? displays the following help output:

First thing I want to do here is test it using the /validate switch to see if it is actually going to work and what kind of output is going to be displayed by running:

MBR2GPT.EXE /disk:0 /validate /allowFullOS

This results in the following on-screen output:

And the following output is logged in %windir% in the setupact.log:

Now, I am going to run the command without the /validate switch. Notice the additional output on the command line and refreshing the disk volume properties shows it to be GUID Partition Table (GPT):

Next, this is where we would run the vendor tool to change the correct BIOS settings (we will do that later in a Task Sequence when we automate the process), but for now I am going to reboot and hit the proper key to get into the BIOS settings.

After making the necessary changes (and I even enabled Secure Boot), notice that System Information displays the BIOS Mode as UEFI with Secure Boot State set to On:

This first look at the MBR2GPT conversion utility looks very promising. Hopefully in the coming months as we get closer to the release of Windows 10 Creators Update we will start to get more information on it as well as what versions of Windows 10 will support it.

In my next blog, Using MBR2GPT with Configuration Manager OSD, I am going to show how we can integrate MBR2GPT into an OSD Task Sequence.

Originally posted on https://miketerrill.net/

In my previous post, Getting Started with MBR2GPT, I showed a first look at the MBR to GPT conversion utility that is going to be released with the upcoming Windows 10 Creators Update. In this post, I am going to show how it can be integrated with a Configuration Manager OSD Task Sequence. In this test, I reset my test machine back to Legacy BIOS and disabled Secure Boot. Next, I installed build 15002 of the Windows 10 Enterprise Insider Preview, joined it to my test domain and installed the Configuration Manager 1610 client.

Starting off simple, the goal was to see if I could run MBR2GPT in a simple Task Sequence and automate what I did manually in the previous post. The first thing I did was add MBR2GPT.EXE to my 1E BIOS to UEFI OEM Toolkit Package – since I need to change the BIOS settings, it made sense to just add it to this package. The next step was to create a custom, simple Task Sequence – one that I can later just copy into a Windows 10 In-place Upgrade Task Sequence. The end result looks like this:

For the Options on this Group, I put the following Conditions:

I only want to run this on a Dell, HP or Lenovo that is currently running Legacy BIOS (no need to run it if the system is already UEFI).

The next step is to run MBR2GPT. This is the same command that I ran manually, but I added the /silent switch so that it would run without prompting for input:

Next, I run my 1E BIOS to UEFI OEM step (available to 1E Nomad customers) to configure the necessary BIOS settings. In this case I want to enable Secure Boot as well. The nice thing about this step is that conditions can be added so there can be multiple configuration – for example, one with Secure Boot and maybe one without Secure Boot (for systems that might have conflicts with Secure Boot because of bad video card drivers).

The last thing to do is reboot after running both of these steps in order for the configurations to take effect.

Running this Task Sequence on my test system yielded the following in the smsts.log where we can see that MBR2GPT ran successfully:

Adding this into an in-place upgrade Task Sequence might look something like this:

Keep in mind that this is only part of the Windows Insider release right now and should not be used in production, but initial tests seem to show promising results. Also, there are still some blockers for being able to use in-place upgrade like I mentioned in the previous post. Have a plan on how you plan on handling applications that need to be uninstalled, upgraded and replaced. In other words, just because you can do in-place upgrade, do you still want that old version of Office on your shiny new Windows 10 OS? In addition, Windows 10 content is going to have a massive impact to your network. Not just the Feature Updates, but the Quality Updates (i.e. security patches) are likely to have the biggest impact (especially if you have to patch multiple versions of Windows 10). Look into using a peer to peer solution (like 1E Nomad) sooner rather than later. Lastly, chances are, you are going to have to support multiple deployment methods in your environment – make sure the tools (and vendor) you choose is capable of handling all of them seamlessly (don’t settle for cheap knock offs – you get what you pay for and can open up your network to unwanted security vulnerabilities). Baremetal for new computers and break/fix, hardware refresh/replacement, wipe-and-load, and in-place upgrade.

Originally posted on https://miketerrill.net/

Now that the cat is out of the bag that Dell has a 64-bit Flash BIOS Utility, I can finally blog about it. Earlier this week, Warren Byle of Dell announced the following on Twitter:

@kidmystic @Dell we have a 64-bit BIOS payload installer tool that is currently only available through a support call. Ask for flash64w.exe

— Warren Byle (@WarrenByle) January 30, 2017

So there you have it, the wait is over (of course, after you get off the phone with Dell support) and you can now flash the Dell BIOS in 64-bit. You are probably thinking ‘big deal, I could do that already – flash the BIOS on 64-bit Windows 10’. Yea, you are right since full 64-bit Windows has a 32-bit subsystem, but the real magic is being able to flash the BIOS under WinPE. If your system is running UEFI (or you have a UEFI conversion Task Sequence), then it needs to boot the native architecture (in this case 64-bit). By only having a 32-bit flash BIOS utility before meant that we were unable to flash under WinPE x64. The Dell 64-bit Flash BIOS Utility is a much welcome (and needed) addition to the IT toolbox (thanks Warren)!

Using the tool is pretty simple, you use it in addition to the BIOS exe that you have already downloaded. I’ll cover off how I use it in a Configuration Manager Package in another post, but for now, here is how you use it:

I used the following command line under WinPE x64 to silently flash a Dell OptiPlex 7040 from version 1.4.5 to 1.5.4:

FlashUpDateWin64.exe /b=OptiPlex_7040_1.5.4.exe /s /f /l=1.5.4.txt

Which wrote the following output:

***BIOS flash started on 1/31/2017 at 18:38:32***
Command: F:\FlashUpDateWin64.exe /b=OptiPlex_7040_1.5.4.exe /s /f /l=1.5.4.txt

1.4.5 INSTALLED (Dell System OptiPlex 7040)
– Gigabit Ethernet : 0.8
– Intel Management Engine (VPro) Update : 11.0.18.1002
– System BIOS with BIOS Guard  : 1.4.5
1.5.4 UPDATE ( OptiPlex 7040)
– System BIOS with BIOS Guard  : 1.5.4
– Gigabit Ethernet : 0.8
– Intel Management Engine (VPro) Update : 11.0.18.1002
– System Map : 1.0.1
– PCR0 XML : 0.0.0.1

Exit Code = 2 (Reboot Required)
***BIOS flash finished at 1/31/2017 at 18:38:41***

I hope you are as excited as me about this new *SHINY* utility from Dell. Happy 64-bit BIOS flashing!

Originally posted on https://miketerrill.net/

When approaching any solution, it is a good idea to come up with a list of requirements that the solution needs to be able to meet. This way you will be sure to start off on the right foot and not have to rip and replace, add to, or redo over the solution in the future. In terms of Driver & BIOS management, I have come up with the following requirements that need to be met in order to have the best solution possible that can be used in multiple scenarios:

1. Runs in Full OS and WinPE
2. Same method works across baremetal, refresh and in-place upgrade Task Sequences
3. Dynamic without the need to edit the TS or scripts
4. Supports Production and Pre-Production in the same TS
5. Intuitive and easy to use

There are a lot of blogs out there on how to manage drivers and BIOS updates with Configuration Manager, however, each of them fall short of the above requirements in one way or another. I first started out on this quest back in 2015 when I was investigating what it would take to go from BIOS to UEFI. Long story short, you need to use the vendor utilities (or methods) to change the firmware settings and they worked the best when the BIOS was running the latest version. I wanted to be able to flash the BIOS in the full OS, as well as WinPE (requirement #1). This meant that Configuration Manager Packages needed to be used since Applications cannot be used in WinPE. This way, the same process could be used regardless if the system was bare metal from the vendor or an existing machine that was getting a refresh or in-place upgrade Task Sequence (requirement #2). By the way, some vendors still have limitations on flashing the BIOS in WinPE x64, but a lot of models now support this for the most part.

Another goal was to be able to do this without having a 5 mile long Task Sequence that needs to be edited every time there was a new model, new BIOS version or new Driver Package (requirement #3). Every time a Task Sequence changes, it has the possibility of stopping imaging for the environment while replication takes place. If you have a small environment, this may be okay, but in a large environment it can be like stopping a production assembly line (not good). Next, the solution needs to be able to support BIOS versions and Driver Packages that are marked as production, as well as support BIOS versions and Driver Packages that are pre-production (requirement #4). This way a proper Test > QA > Pilot > Production methodology can be carried out using the current production Task Sequence (this is the Total Control part). If you look at the BIOS releases or driver releases over the past two years, you will notice that the hardware vendors have been busy releasing updates. As newer versions of Windows 10 get released, the vendors usually release new drivers starting a month after the CB release. Lastly, the solution needs to be intuitive and easy to use so that it can be managed by junior level administrators (requirement #5).

At the 2016 Midwest Management Summit, I had come up with a solution that covered most of the above requirements for doing the BIOS updates. At the time, I had split each of the vendors because it made it more modular, but also because some vendors (to remain nameless) at the time did not support flashing under WinPE x64. The only thing that I did not have figured out was how to do the dynamic content location request. In the Task Sequence below, I was cheating by creating a dummy group handle the CLR (the dummy group is one that does not execute but the TS does not know it and will still do the CLR at the start of the TS).

Little did I know, the step that I was using to get the content locations for the BIOS packages (Download Package Content), actually can do a dynamic content location request (I learned this during a trip to Redmond last November). Fast forward a bit and this is what the Flash BIOS portion of the Task Sequence looks like now:

Now, ‘how do drivers fit into this?’ you say. Well, the same concepts can be applied – in fact, drivers are even easier. For a Wipe-n-Load Task Sequence, we can now do driver management in three easy steps:

And for an In-Place Upgrade Task Sequence, driver management can be done in two easy steps all using the same process:

So by now you are probably thinking that this is all too good to be true and there has to be a catch. No catch – it is really this simple. In Configuration Manager Dynamic Drivers & BIOS Management with Total Control Part 2, I go into detail on how to set up, configure and use the solution.

Originally posted on https://miketerrill.net/

In Configuration Manager Dynamic Drivers & BIOS Management with Total Control Part 1, I talked about the requirements for the various scenarios when coming up with a solution for driver and BIOS management. I also gave a glimpse of what the Task Sequence steps look like once the solution is in place. In Part 2, I am going to show what it takes to get the solution step up and running (at first glance it looks complicated, but it is actually pretty easy, especially if you download the templates below).

Video summary:

Before getting started, there are a few assumptions:
1. Configuration Manager is already running Current Branch
2. Windows ADK is Windows 10 Creators Update (1703) (required for MBR2GPT)
3. Microsoft Deployment Toolkit (MDT) 8443 is integrated with Configuration Manager
4. A MDT Toolkit package is available in Configuration Manager
5. A MDT database is setup and configured

If you do not already have MDT installed and configured, please see this excellent guide at windows-noob.com (just make sure to use the MDT 8443 release): How can I deploy Windows 10 with MDT 2013 Update 2 integrated with System Center Configuration Manager (Current Branch): https://www.windows-noob.com/forums/topic/14057-how-can-i-deploy-windows-10-with-mdt-2013-update-2-integrated-with-system-center-configuration-manager-current-branch/
For setting up the MDT database, see Use the MDT database to stage Windows 10 deployment information: https://docs.microsoft.com/en-us/windows/deployment/deploy-windows-mdt/use-the-mdt-database-to-stage-windows-10-deployment-information

Starting off, there will be a one time modification of the MDT database, extending the database to include some custom fields that we are going to define.

1. Add the following columns to the dbo.Settings table: TARGETBIOSDATE, FLASHBIOSCMD, BIOSPACKAGE, W10X64DRIVERPACKAGE, W7X64DRIVERPACKAGE. If you manage 32-bit operating systems, you can add columns for those as well. Also, as of now, there should not be a need for a build specific Windows 10 driver package (like one for 1607 and another for 1703), but if that changes then additional columns can be added to support them in the future. BIOS stepping – this is where you need to apply one or more BIOS versions to get to the latest version. Some older models require this and additional BIOSPACKAGE columns can be created to support this. This is not going to be covered in this blog, but if there is enough interest I will cover it in a future blog.

There is already a great blog called How to extend the MDT 2010 database with custom settings that is still applicable to MDT 8443 and can be used as a reference. Be sure to refresh the views after adding the columns.

2. Create BIOS Packages and Driver Packages for each make/model. If you do not already have them for each of the models you support or if you want to get the updated releases, then check out the Driver Automation Tool the awesome guys over at SCConfigMgr have created. This is a great tool and will save you a ton of time.

3. Define each make/model in the MDT database. I do not cover Lenovo systems in this blog, so if you manage those systems then check out The Deployment Bunny’s blog Modelalias User Exit for Microsoft Deployment Toolkit 2010/2012.

4. On the Details tab, scroll down to the bottom where the custom properties are listed and enter the Package IDs, Target BIOS Date and Flash BIOS command. The Target BIOS date is that that shows up in WMI for the BIOS version (also seen in msinfo32) in YYYYMMDD format.

For the Custom Settings and the Task Sequences, feel free to save some time and download them here:
Dynamic BIOS and Drivers Blog.zip

Disclaimer:                                                                                                                                                                                 Your use of these example Task Sequences is at your sole risk. This information is provided “as-is”, without any warranty, whether express or implied, of accuracy, completeness, fitness for a particular purpose, title or non-infringement. I shall not be liable for any damages you may sustain by using these examples, whether direct, indirect, special, incidental or consequential.

5. Create the following custom settings file and add it to an existing reference settings package or create a new one (feel free to replace SQL connection with a webservice of your choice):

[Settings]
Priority=CSettings,MMSettings,Default
Properties=TARGETBIOSDATE,FLASHBIOSCMD,BIOSPACKAGE,W7X64DRIVERPACKAGE,W10X64DRIVERPACKAGE

[Default]

[CSettings]
SQLServer=CM02
Database=MDT
Netlib=DBNMPNTW
SQLShare=DeploymentShare$
Table=ComputerSettings
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR

[MMSettings]
SQLServer=CM02
Database=MDT
Netlib=DBNMPNTW
SQLShare=DeploymentShare$
Table=MakeModelSettings
Parameters=Make, Model
ParameterCondition=AND

The following section is for a Wipe-n-Load Task Sequence

6. Create a MDT Gather step in the Task Sequence that uses the custom settings created above. This gather step will get the above entries that have been populated in the MDT database.

NOTE: Be sure to suspend BitLocker before flashing the BIOS in order to prevent being prompted for the recovery key. Also, if BIOS passwords are used, they will either need to be turned off or passed to the flash BIOS command line.

7. Create the Update BIOS Group with the following steps and conditions:

8. Set the BIOSUpdate Task Sequence variable. This variable will determine if a BIOS update is necessary based on the BIOS release date and also if TARGETBIOSDATE, FLASHBIOSCMD and BIOSPACKAGE exist.

9. Create a Flash BIOS group. The conditions on this group are if BIOSUPDATE is TRUE and IsOnBattery is False. Since many BIOS update utilities require AC, we do not even want to try to update the BIOS if it is running on battery. The IsOnBattery variable is set by the MDT Gather step. It also should be checked as part of pre-flight checks, but by also keeping it in the Update BIOS group, we keep it modular and this group can be used in a Software Distribution Task Sequence to update the bios existing clients.

10. Set BIOS Variables is where part of the magic happens and is a Set Dynamic Variables Task Sequence step. This is where we set the following variables: OSDDownloadDestinationLocationType, OSDDownloadContinueDownloadOnError, OSDDownloadDownloadPackages and OSDDownloadDestinationVariable. I talked about these variables in my Hacking the Task Sequence 2017 session at the Midwest Management Summit and they may lead to a future blog post. But for now, just understand that they work with the Download Package Content step executable. We are downloading the package found in the BIOSPACKAGE variable and we are going to store the download location in a base variable called BIOS. Since there is only one package, the location will get stored in the variable BIOS01. DISCLAIMER: Although these Task Sequence variables are not read only (meaning they do not start with an “_”), they are not publicly documented, which translates to “use at your own risk”.

11. The Download BIOS step is a Run Command Line step that calls OSDDownloadContent.exe. This exe is tied to the Download Package Content Task Sequence step and will consume and use the variables set in the previous step. This step is also part of the magic as it will do a dynamic content location request for the package and then download it to the TS Cache.

[Update] Directly after the Download BIOS step, it is important to insert a Reset Variables step. Since the variables are being set outside of the Download Package Content step, the variables do not get deleted. Resetting them to blank will allow any subsequent Download Package Content steps outside of this process to work normally if inserted into the Task Sequence.

12. The Flash BIOS step is another Run Command Line step that executes the command stored in the FLASHBIOSCMD variable. It also sets the working directory to the location where the BIOS package was downloaded (BIOS01). Use Continue on error or define the exit return codes so the Task Sequence does not fail.

13. The Flashing BIOS… step is also another Run Command Line step that executes timeout.exe for 60 seconds. Timeout.exe is not part of the MDT Toolkit Package, so you will need to add the correct versions (x86/x64) to your MDT Toolkit Package if you want to use it. The Windows 10 version of timeout.exe will not run on Windows 7. However, the Windows 7 version of timeout.exe will run on Windows 10. The alternatively, simply include timeout.exe in the path on your Boot Images and then it will run regardless of the operating system. Otherwise, I have seen ping commands being used to create a sleep cycle. The reason I do this is because some vendors recommend not rebooting right away (even though the main process finished). Therefore, I stick it in there for good measure.

14. Once the first phase of the BIOS update has run, the system needs to be rebooted so that the second phase can run. Since this is for a Wipe-n-Load Task Sequence, we will go ahead and reboot into the Boot Image after the BIOS update has completed. Provide the end user a message like “A new BIOS is being installed. DO NOT Power Off or unplug the system during this process. The computer must restart to continue.”

15. Directly below the Apply Network Settings step, create a new group called Apply Drivers. The condition on this group is if W10X64DRIVERPACKAGE exists. If the variable does not exist, then it was not populated in the MDT db and this group will be skipped. This is by design for the scenario where a model does not have a Windows 10 Driver Package and/or the out of the box Windows 10 drivers work just fine.

16. Set Driver Variables (similar to the Set BIOS Variables) is where part of the magic happens and is a Set Dynamic Variables Task Sequence step. This is where we also set the following variables: OSDDownloadDestinationLocationType, OSDDownloadContinueDownloadOnError, OSDDownloadDownloadPackages and OSDDownloadDestinationVariable. Here, we are downloading the package found in the W10X64DRIVERPACKAGE variable and we are going to store the download location in a base variable called DRIVERS. Since there is only one package, the location will get stored in the variable DRIVERS01.

17. The Download Driver Package step is a Run Command Line step that calls OSDDownloadContent.exe. This exe is tied to the Download Package Content Task Sequence step and will consume and use the variables set in the previous step. This step is also part of the magic as it will do a dynamic content location request for the package and then download it to the TS Cache.

[Update] Directly after the Download Driver Package step, it is important to insert a Reset Variables step. Since the variables are being set outside of the Download Package Content step, the variables do not get deleted. Resetting them to blank will allow subsequent Download Package Content steps outside of this process to work normally if inserted into the Task Sequence.

18. The Apply Driver Package step is another Run Command Line step that simply executes DISM to apply the drivers to the Windows installation contained in the OSDisk variable (which is set in the Format and Partition Disk step).

The following section is for an In-Place Upgrade Task Sequence

The same approach can be used for an In-Place Upgrade Task Sequence with a few changes.

[Update] Directly after the Download BIOS step, it is important to insert a Reset Variables step. Since the variables are being set outside of the Download Package Content step, the variables do not get deleted. Resetting them to blank will allow subsequent Download Package Content steps to work normally if inserted into the Task Sequence.

19. After the Flashing BIOS… step, change the Restart Computer step to restart to the currently installed default operating system. Provide the end user a message like “A new BIOS is being installed. DO NOT Power Off or unplug the system during this process. The computer must restart to continue.” NOTE: After the reboot, if using BitLocker on Windows 7, you will need to disable/suspend it again since the built-in Configuration Manager step only suspends it for one reboot.

20. Create a group called Download Drivers with the condition that the variable W10X64DRIVERPACKAGE exists (similar to the Apply Drivers group created above for the Wipe-n-Load Task Sequence).

21. The Set Driver Variables step is the same as Step 16 above.

22. The Download Driver Package step is the same as Step 17 above.

[Update] Directly after the Download Driver step, it is important to insert a Reset Variables step. Since the variables are being set outside of the Download Package Content step, the variables do not get deleted. Resetting them to blank will allow subsequent Download Package Content steps outside of this process to work normally if inserted into the Task Sequence.

23. Now we need to inform the Update Operating System step the location of the drivers. Enable the “Provide the following driver content to Windows Setup during upgrade” option and enter %DRIVERS01% for the “Staged content” location. Since we only want this to run when the Driver Package exists, add the condition Task Sequence Variable DRIVERS01 exists.

24. In the case that the Driver Package does not exist, duplicate the previous step, clear the “Provide the following driver content to Windows Setup during upgrade” option and add the condition Task Sequence Variable DRIVERS01 not exists. This can be reduced to using one step by using the undocumented variable OSDUpgradeStagedContent variable that Johan Arwidmark talks about in his blog post Improving the ConfigMgr Inplace-Upgrade Task Sequence.

25. Chances are, there will be a need to have more than BIOS Package or Driver Package in the production environment for a given model. As new BIOS updates and drivers are released, they can be pilot tested in the environment using the same exact Task Sequences without modification. There is no need to setup different Task Sequences, simply define your pilot systems in the MDT database under the Computers node.

26. This can be done by adding a new record in the MDT database using the Asset tag, UUID, Serial number or MAC address.

27. The same extended fields show up on the Details tab for the computer record. Add in the new BIOS package and Driver package information and the next time the system is built it will use these packages. Once the packages have passed the pilot testing phase and have been deemed production worthy, simply change the BIOS package and Driver package information in the Make and Model node for that particular model.

Lastly, as new models enter the environment, simply create the BIOS and Driver Packages in Configuration Manager and then create the entry in MDT for the new model – once again, all done without modifying either Task Sequence. In summary, this solution meets all of the five requirements that I defined in Part 1:
1. Runs in Full OS and WinPE
2. Same method works across baremetal, refresh and in-place upgrade Task Sequences
3. Dynamic without the need to edit the TS or scripts
4. Supports Production and Pre-Production in the same TS
5. Intuitive and easy to use

Now, who would like to see this functionality built into Configuration Manager out of the box?
And, who would like to see the hardware vendors publish the BIOS WMI date stamp so that it can be consumed electronically?

Originally posted on https://miketerrill.net/