Using MBR2GPT with Configuration Manager OSD


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

Getting Started with MBR2GPT


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

BIOS to UEFI made easier with Windows 10 Creators Update


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

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

PXE Booting in the Real World

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''
exec NBS_GetPXEBootAction N'16777279',N'2046820353',N'2DCFD0F8-9134-44A3-84BB-0BFC114ADD87',N'1E:1E:1E:1E:1E:B2',N''

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

Originally posted on

Deploying Office 365 with System Center 2012/R2 Configuration Manager and 1E Nomad


1 Overview

Microsoft Office 365 introduces a new way to deploy and update Office 365 using Click-to-Run technology. Office 365 is typically installed using the Office 365 portal. However, this presents several challenges in a managed environment. The first challenge is that users must be local administrators on their computers in order to install Office from the Office 365 portal. Hopefully in a well-managed environment, end users do not have local administrator rights, but that is a topic for another time. The second challenge is that the install binaries come from the Office Content Distribution Network (CDN). In other words, the necessary files are streamed down from the Internet to the user’s computer. This also presents a challenge in corporate environments where Internet network connections and Wide Area Network links are already bandwidth constrained. Lastly, Office 365 does not integrate with System Center 2012/R2 Configuration Manager Software Updates (or Windows Update), and instead use the Office CDN for updating and patching Office 365 installations.

Fortunately the Office 365 Team has released the Office Deployment Tool which aides in deploying and updating Office 365 installations from on-premises locations. This document will outline one method on how the Office Deployment Tool can be used to deploy Office 365 with System Center 2012/R2 Configuration and 1E Nomad and leverage the bandwidth efficiencies and peer to peer capabilities from 1E Nomad.


Your use of these example scripts 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.

2 Getting Started

The first thing that is required is the Office Deployment Tool. This is available here on the Microsoft Download Center or simply search for “Office Deployment Tool Download” using your favorite search engine (Note: there is a new version of the tool for the Office 2016 release). After downloading the exe, run it, accept the license agreement and click continue.

001 O365

Create a folder called Office 365 in a preferred location, for this example we will use \Downloads\Office 365.

002 O365

After running, it should display a “Files extracted successfully.” message. If not, make sure you have proper access to the target directory.

003 O365

The target directory should contain two files – a sample configuration.xml and setup.exe.

004 O365

Make a copy of the configuration.xml file and call it download.xml. Edit the file so that it contains the following contents (be careful of word wrap):

<Add SourcePath="\\\ContentSource\Packages\Microsoft\Office 365 x86" OfficeClientEdition="32" >
<Product ID="O365ProPlusRetail">
<Language ID="en-us" />
<Product ID="VisioProRetail">
<Language ID="en-us" />

This will download the source files for the 32-bit version of Office Professional Plus and also the 32-bit version of Visio Professional. Adjust the products accordingly, downloading all of the Office Products that are used in your environment. If there are users that do not use some products (like Visio Professional), then multiple deployment configuration files can be created. For more information on the various options, please refer to the Reference for Click-to-Run configuration.xml file.

For the SourcePath, enter the location of your Configuration Manager package repository.

3 Setup the Office 365 Source Files

Open a command prompt and navigate to the directory containing the Office Deployment Tool (for my example this is C:\Users\Administrator.CONTOSO\Downloads\Office 365). Run setup.exe using the following command line:

Setup.exe /download download.xml

005 O365

This could take a few minutes depending on the speed of your Internet connection. The above configuration downloads about 1.08 GB of source files. The following directory structure will look like the following (the screen shot is from the April 2015 release and the version changes monthly):

006 O365

Copy setup.exe (from the Downloads\Office 365 directory) to the Office 365 x86 folder.

Create a file called Install.xml in the Office 365 x86 folder with the following contents (be careful of word wrap):

<Add SourcePath="C:\Preload\Office365" OfficeClientEdition="32" >
<Product ID="O365ProPlusRetail">
<Language ID="en-us" />
<Product ID="VisioProRetail">
<Language ID="en-us" />
<Updates Enabled="TRUE" UpdatePath="C:\Preload\Office365" />
<Display Level="None" AcceptEULA="TRUE" />
<Logging Level="Standard" Path="%temp%" />
<Property Name="AUTOACTIVATE" Value="1" />

This will point both the SourePath and the UpdatePath to a local path called C:\Preload\Office365 on the user’s computer. It will install Office 365 from this location and it will also update from this location. The UpdatePath could be defined as an internal share, however, you would lose the intelligent bandwidth and peer to peer capabilities that Nomad provides when deploying updates.

The above configuration file will install the following components:
Access 2013
Excel 2013
InfoPath Designer 2013
InfoPath Filler 2013
OneDrive for Business 2013
Outlook 2013
PowerPoint 2013
Publisher 2013
Send to OneNote 2013
Skype for Business 2015
Visio 2013
Word 2013
Office 2013 Tools

Chances are not all components will be installed in your environment, so for more information on the various options, please refer to the Reference for Click-to-Run configuration.xml file. You can even create multiple configuration files (and corresponding CM Programs as seen below) all within the same package.

Next, create a file called Install.bat (yes I know – a bat file, right?  But you would be surprised how many companies have not switched to PowerShell yet) in the Office 365 x86 folder with the following contents (be careful of word wrap):

REM Install.bat
REM Version 1
REM 4/25/2015


MD C:\Preload


IF EXIST C:\Preload\Office365 GOTO CLEANUP

MD C:\Preload\Office365


IF EXIST C:\Preload\Office365\Office (

RD /S /Q C:\Preload\Office365\Office


DEL /F /Q C:\Preload\Office365\*.*


SET O365CACHE=C:\Preload\Office365\

XCOPY *. %O365CACHE% /T /E


for /R %~dp0 %%G IN (*.*) do (



fsutil hardlink create !DEST! !SOURCE!



REM Delete Install.bat from the Preload\Office365 directory

DEL /F /Q C:\Preload\Office365\Install.bat

IF "%1"=="/pre-cache" GOTO END

%O365CACHE%Setup.exe /configure %O365CACHE%install.xml


Since we are installing and upgrading Office 365 from the local disk, we create a set directory that will be used throughout the process. This is done because the directory in the CCM Cache will be a random character and the configuration file needs a set path. The contents will be hard linked from the CCM Cache to the C:\Preload\Office365 directory in order to minimize required disk space (it is already hard linked from the Nomad cache in to the CCM Cache). Effectively, the contents are only on the disk once with three pointers.

Since the files change between updates, the Office 365 cache location is cleared of any previous files and then new hard links are created with the new files. This keeps the Office 365 cache from growing and taking up unnecessary disk space. Since the script is creating hard links, the process takes a split second.

The contents of the Office 365 x86 directory should now look like the following:

007 O365

4 Create the Office 365 Package in CM

In the Configuration Manager Console, create a new Package in the Software Library.

008 O365

Populate the following package information using the same source folder as above:

009 O365

Choose Standard program as the program type:

010 O365

Populated the following information about the standard program:

011 O365

Enter the corresponding requirements:

012 O365

On the Nomad Settings page, enable Nomad and set the desired Cache Priority:

013 O365

Confirm the information on the summary screen:

014 O365

Confirm the successful creation and click Close:

015 O365

Back in the console under Packages, right-click on the Office 365 package and select Create Program:

016 O365

Select Standard program:

017 O365

For the program name use Update Office 365 Cache with the command line: Install.bat /pre-cache:

018 O365

Use 1 GB for the estimated disk space and the same platform requirements as before:

019 O365

Confirm the information on the summary screen:

020 O365

Confirm the successful creation and click Close:

021 O365

5 Distribute the Package to the DP(s)

Back in the console under Packages, right-click on the Office 365 package, select Distribute Content:

022 O365

Review the selected content and click Next:

023 O365

Select the correct Distribution Points or Distribution Point Group:

024 O365

On the summary page confirm the settings and click Next:

025 O365

On the completion page, confirm success and click Close:

026 O365

6 Create the Office 365 Collection

Create the collection that will be used to deploy Office 365 and also update the local Office 365 cache. Depending on your preference and deployment strategy, two collections can be created instead of one. One can be for the initial deployment and the other can be for updating the Office 365 cache on a monthly, quarterly or as needed basis. For this purposes of this document, we will keep it simple and only create one collection.

In the CM console under Device Collections, right-click and select Create Device Collection:

027 O365

Give the collection the name Office 365 and select a corresponding limiting collection:

028 O365

Add a couple of test systems to the Office 365 collection that is being created:

029 O365

Confirm the settings on the summary page:

030 O365

On the completion page, confirm the successful completion and click Close:

031 O365

7 Create the Office 365 Installation Deployment

Now create the Deployment that will install Office 365 on systems that are in the collection that was just created in the previous step. In the console under Packages, right-click and select Deploy.

032 O365

Select Install Office 365 for the software and Office 365 for the collection:

033 O365

Verify that the content is on the required Distribution Points/Groups:

034 O365

On the Deployment Settings page, leave the Purpose set to Required for an unattended installation:

035 O365

Set the schedule and rerun behavior:

036 O365

Click Next on the User Experience:

037 O365

On the Distribution Points page, since we are using Nomad we can safely select Download content from distribution point and run locally for slow and unreliable network boundaries (which also includes undefined network boundaries). That is another benefit of Nomad is the fact that you do not need to ever worry about managing boundaries in order for it to work (unlike other solutions). In addition, enabled Allow clients to use a fallback source location for content (since with Nomad, you probably only have a couple of Distribution Points in the datacenter).

038 O365

On the Summary page, verify the settings and click Next:

039 O365

Verify that the Deploy Software Wizard completed successfully:

040 O365

8 Verify Installation

Logging onto PC01, we see using the Nomad Branch GUI that it is the master and is downloading the package from the CM Distribution Point:

041 O365

Whereas on PC02, it is pulling the Office 365 package from PC01 (notice the mode – SMB from Peer):

042 O365

Back in the CM console, we see that both installed successfully:

043 O365

Using fsutil, you can see that the files are only on the disk once and have multiple pointers (i.e. hard links). One points to the Nomad cache, one to the CM Cache and the last one to the Preload\Office365 directory:

044 O365

9 Create the Update Office 365 Cache Deployment

Now it is time to create the Update Office 365 Cache Deployment. Office 365 is updated on the second Tuesday of the month with updates and/or security patches. The process is combined, so there is currently no way to split out just the security updates. The version is displayed on the Account page of anyone of the Office applications. This is from the April 2015 release (version 15.0.4711.1002, which is the same as a subdirectory in our Office 365 package as seen above):

045 O365

The following knowledge base article lists all of the Office 365 updates:

The Office 365 package can be updated monthly, every other month, or quarterly depending on your company’s patching frequency. Keep in mind that each of the files change in the monthly download, so the majority of the files will need to be cached. Also, it is probably best to test them out on a pilot group prior to releasing them to the entire enterprise. This discussion goes beyond the subject of this article, but there is a version property that can be used in the configuration file.

In the CM Console under Packages, right-click on the Office 365 package and select Deploy:

032 O365

Select Update Office 365 Cache for the software and Office 365 for the collection:

047 O365

Verify that the content is on the required Distribution Points/Groups:

034 O365

On the Deployment Settings page, leave the Purpose set to Required for an unattended installation:

035 O365

Set the schedule and rerun behavior. Since this is just updating the Office 365 Cache, this example configures it to run on the third Tuesday of every month and the rerun behavior is set to Always rerun program:

050 O365

Click Next on the User Experience:

037 O365

Just like the Install Office 365 Deployment, on the Distribution Points page, since we are using Nomad we can safely select Download content from distribution point and run locally for slow and unreliable network boundaries (which also includes undefined network boundaries). That is another benefit of Nomad is the fact that you do not need to ever worry about managing boundaries in order for it to work (unlike other solutions). In addition, enabled Allow clients to use a fallback source location for content (since with Nomad, you probably only have a couple of Distribution Points in the datacenter).

038 O365

On the Summary page, verify the settings and click Next:

053 O365

Verify that the Deploy Software Wizard completed successfully:

054 O365

Now on the third Tuesday of every month, the clients will update their Office 365 cache with the latest binaries. Office 365 updates are done from a scheduled task on the local system and will be updated accordingly after the next cycle.

10 Summary

The above process outlines one method for deploying and updating Office 365 in a managed environment by leveraging the current investment in System Center 2012/R2 Configuration Manager and 1E Nomad. This process will overcome the challenges that were mentioned in the beginning of this article. It will allow companies to deploy and update Office 365 without causing negative impact to the corporate WAN links and Internet connections.  It can be used without Nomad, but then you lose the P2P functionality and intelligent bandwidth management when downloading from a DP.  So a word to the wise if you don’t use Nomad – be careful!!!!  Or better yet – head over to!

11 Reference Links

Office Deployment Tool for Click-to-Run

Deploy Click-to-Run for Office 365 products by using the Office Deployment Tool

Overview of the update process for Office 365 ProPlus

Managing Updates for Office 365 ProPlus – Part 1

Managing Updates for Office 365 ProPlus – Part 2

System Center 2012 R2 Configuration Manager

1E Nomad

Originally posted on

Automating Dell BIOS-UEFI Standards for Windows 10


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.

001 Create TS

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.

002 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%"

003 Dell Group conditions

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  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

004 Enable UEFI

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

Originally posted on

Pre-staging Content during OSD

1E Nomad

In System Center Configuration Manager Operating System Deployment, content can be obtained in one of two ways for network deployments. The first way is to configure the Task Sequence Deployment to “Download all content locally before starting task sequence”. There are a few downsides to this option – it is only available to ConfigMgr clients (sorry, no media or PXE), and second, it downloads ALL packages referenced in the Task Sequence. The second way is to configure the Task Sequence Deployment to “Download content locally when needed by running task sequence”. As the Task Sequence engine gets to a step that has referenced content, it will download the content prior to running the step. This effectively a just in time process. What is missing is the ability to download specific items during the Task Sequence ahead of actually needing them.

Rewind – several years ago (back in the ConfigMgr 2007 days) I was working on an OSD project. While we were brainstorming ideas on what we could do to make the process better and more resilient, I came up with the idea of staging content during a running Task Sequence. The thought was, if we know that we were going to need something (like the WIM, Driver Package, CM Client, etc.), wouldn’t it be good if we could get it before we started the main execution phase of the Task Sequence. Instead of waiting until we were in WinPE (after the disk had already been wiped) and experienced a failure (maybe a network glitch), we could be proactive by staging only the critical content ahead of time. This way, we can get past the point of no return in the Task Sequence, minimize failure and have a useable system with at least the new OS installed. This is when the concept of Pre-staging Content Using Nomad was born.

This feature first appeared in 1E Nomad version 4.1 for ConfigMgr 2007. It has been in every version of Nomad since that time and this functionality extends both ConfigMgr 2007 and ConfigMgr 2012/R2. To make things easy, there is a custom action in the Task Sequence editor called Pre-stage Content Using Nomad. Simply add the step to the Task Sequence and select the Packages that are required during WinPE and OOBE.

01 Pre-stage

The core OSD packages are: WIM, Boot Image, CM Client, USMT, MDT Toolkit, MDT Settings, and Nomad Agent (as well as any additional scripts used in the Task Sequence). Since this is a Task Sequence step that can be configured with Options, Driver Packages can be selectively pre-staged based on the target system. In other words, it is as simple as adding an additional step to pre-stage the correct Driver Package using the same condition that is used later in the Task Sequence to apply the Driver Package. The Pre-stage section of the Task Sequence might look like the following for environments with HP systems:

02 Pre-stage

The Pre-stage step works in WinPE as well as a full OS, so pre-staging can be done under a Baremetal scenario as well as the Refresh scenario (and very soon the Upgrade scenario for Windows 10). The Pre-stage concept is also helpful when needing to perform OSD Refresh over WiFi. Since there is not any WiFi support in the current version of WinPE, simply pre-stage the necessary content before rebooting into WinPE.

If you have used this feature and like it or have other suggests, let me know!

Originally posted on