Using MBR2GPT with Configuration Manager OSD

devices-windows-10-creators-update-banner

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:

001-using-mbr2gpt

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

002-using-mbr2gpt

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:

003-using-mbr2gpt

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

004-using-mbr2gpt

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

005-using-mbr2gpt

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

006-using-mbr2gpt

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

007-using-mbr2gpt

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/

Getting Started with MBR2GPT

devices-windows-10-creators-update-banner

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:

001-getting-started-mbr2gpt

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:

001-mbr2gpt

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:

002-getting-started-mbr2gpt

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

003-getting-started-mbr2gpt

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

004-getting-started-mbr2gpt

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:

005-getting-started-mbr2gpt

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/

BIOS to UEFI made easier with Windows 10 Creators Update

devices-windows-10-creators-update-banner

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

001-mbr2gpt

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.

003-1e-bios-to-uefi

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

Getting Started with 1E BIOS to UEFI

1E BIOS to UEFI is a component of the 1E OSD Solution Accelerator that comes with 1E Nomad and enables administrators to create a true Zero Touch BIOS to UEFI Task Sequence method. This enables enterprises to get to secure Windows 10 by enabling feature like Secure Boot, Credential Guard and Device Guard to name a few, without requiring a high-touch and costly manual process.

The Challenge

There are two challenges when it comes to converting a system from BIOS to UEFI during an OSD Task Sequence. The first part of the problem is manipulating all the necessary BIOS settings that are required on class 2 UEFI devices to make them boot up in UEFI mode (class 3 UEFI devices like Surface Books only have the option of running UEFI). Fortunately, most of the major vendors, like Dell, HP and Lenovo, provide methods and tools that allow this to be done programmatically on their enterprise class systems. The downside is that this often needs to be scripted and getting the right combination to work on all your supported models can be tricky and time consuming. Some settings can vary even between models from the same vendor (some vendors are worse than others). Also, the order in which the settings are applied is important. The utility or method might return a success on a setting change but not actually change the setting because of a dependency on another setting. The second part of this problem is to be able to get the Task Sequence to reboot successfully and continue the Task Sequence after the BIOS/UEFI changes take effect. Microsoft is addressing this problem starting in the Configuration Manager 1610 release. For more information on this step, see the Task sequence steps to manage BIOS to UEFI conversion. Also, my good friend Nickolaj has written a blog called Convert from BIOS to UEFI during Windows 10 deployments with ConfigMgr Current Branch – Introduction, where he talks about what is happening with the new Task Sequence variable called TSUEFIDrive.

The Solution

1E BIOS to UEFI contains two simple Task Sequence actions that overcomes both challenges and can be used with any version of Configuration Manager Current Branch (1511, 1602, 1606, as well as the recently released 1610), and Configuration Manager 2012 SP2/R2 SP1. The first task sequence action is the 1E BIOS to UEFI step. I call this the magic step (which drives 1E Marketing crazy). The reason I call it the magic step is because it was the first solution to address the BIOS to UEFI problem in a single reboot (and no, we aren’t doing anything dodgy like flipping read-only variables). Microsoft now includes this capability in the 1610 release, but this step is still beneficial to older versions. Maybe someday I will blog on what is happening behind the scenes, but that will need to come later since there are certain companies that take an interest in my work and like to copy it (and no, I am not talking about Microsoft).

This clever step has no configuration and only needs to be placed twice in the Task Sequence as seen below:

001-1e-bios-to-uefi

The other custom action is called 1E BIOS to UEFI OEM. This step is the one that everyone loves as it has buttons and check boxes that can be set. This step works on Dell, Lenovo and HP enterprise class systems.

002-1e-bios-to-uefi

This step calls the right commands in the correct order for the make and model it is running on. Simple, right? That was the goal – to be able to abstract all the commands that need to be run (and the order they need to be run) from the administrator so that he/she can go on with more important thing (like deploying Windows 10 in UEFI). Before getting into the details of the settings, you are probably wondering what the OEM Toolkit Package is that is referenced at the bottom of the step. Well, when installing the 1E BIOS to UEFI solution, you have the option of the installer automatically downloading the vendor utilities, creating a Configuration Manager Package and distributing it to a Distribution Point Group so that you can get on with your Task Sequence. In other words, it automates the process and you do not have to follow some step-by-step document and manually create a toolkit package.

Now that we have that covered, let’s talk about the settings. The most important is the UEFI Configuration. Here we provide three options – 1: UEFI Native with Secure Boot 2: UEFI Native without Secure Boot 3: UEFI Hybrid with CSM. Here are the use cases for each one:

1: UEFI Native with Secure Boot – this will configure the BIOS/UEFI settings so that the system boots native UEFI and has Secure Boot enabled. NOTE: This is the only way currently to switch to UEFI on Lenovo systems as they do not provide a separate Boot Mode setting (at least one that pertains to UEFI).

2: UEFI Native without Secure Boot – this is the same as above but Secure Boot will not be enabled. You might be wondering ‘why would you not enable Secure Boot?’ Some low level drivers that get loaded at boot time might not be signed properly and if Secure Boot is enabled, then the system is not going to boot. Since Secure Boot can only be programmatically enabled (and not disabled), then someone needs to physically disable Secure Boot by going into the BIOS/UEFI settings. So, if you have a tricky system that has bad drivers then you can simply put a condition on this step so that Secure Boot is not enabled on these systems. Hint: once the issue is resolved you can use this step again to programmatically enable Secure Boot down the road.

3: UEFI Hybrid with CSM – you are probably thinking ‘what the heck is this and when would I use it?’ Well, for those of you that did not know this, Windows 7 does support running in UEFI mode. Still not getting it? If you are still deploying Windows 7 (which I bet most of you still are), you could have been deploying it in UEFI mode all this time. What this means is that you could have taken advantage of the fancy Windows 10 in-place upgrade and not had to worry about apps and user data. Since the disk will already be GPT there is no need to format and partition.

The last setting worth mentioning is the UEFI PXE setting. What this does is enable PXE in the UEFI network stack (which is not the same as PXE in the legacy BIOS). This is important as Configuration Manager will format and partition the disk based on the how the system was booted (Hint: look up _SMSTSBootUEFI).

Lastly, we continue to certify this step on all kinds of hardware models from each of the three vendors (that is how I know about all of the setting differences between models). Also, we have tons of ideas and features planned for this step. In fact, there were other tabs that originally showed up on early releases but got cut for the initial release – but that is top secret for now.

Configuration Manager 1610

So the burning question is ‘do I still need this if I have Configuration Manager 1610?’ Well, like I mentioned above, 1610 does take care of the magic step. However, you are on your own for handling the vendor settings. So that makes the 1E BIOS to UEFI OEM step still a valid component when it comes to doing BIOS to UEFI.

Here is the Microsoft Task Sequence that contains the new Task Sequence variable mentioned above along with the 1E BIOS to UEFI OEM step:

003-1e-bios-to-uefi

In summary, the 1E BIOS to UEFI solution is extremely useful, even with the new ability to format a disk for UEFI while still booted in BIOS mode in Configuration Manager 1610.

Originally posted on https://miketerrill.net/

How to Inventory Dell BIOS and UEFI Settings with ConfigMgr Part 2

Dell LaptopWhen starting any operating system deployment project, it is a good idea to know what systems are in your environment so that you can determine which of these systems need to support the new OS. Some systems may need to be replaced, where as others might only need a BIOS UEFI update. It is also a good idea to standardize on the BIOS UEFI settings for each supported model in the environment. This ensures that consistent settings are used so that certain systems management features function correctly (for example, like wake-on-lan).

Now that Windows 10 is here, now is the time to standardize on native UEFI as the default boot mode. When making this switch, it is also important to enable Secure Boot at the same time. But, before you can do that, you need to determine not only what is in your environment, but how each system is configured.

You can inventory these hardware specific settings with System Center Configuration Manager. In How to Inventory Dell BIOS and UEFI Settings with ConfigMgr Part 1 I went through the steps for deploying the Dell Command | Monitor application to your Dell workstation clients. This is required in order to get the Dell specific information into WMI so that we can inventory it with ConfigMgr. Now we need to add the Dell classes to the Default Client Settings Hardware Inventory.

  1. Open the Default Client Settings, select Hardware Inventory and click the Set Classes button.
    01 Dell-Default Client Settings
  2. On the Hardware Inventory Classes window, click the Import button.
    02 Dell-Hardware Inventory Classes
  3. On the Add Hardware Inventory Class window, click the Connect button.
    03 Dell-Add Hardware Inventory Class
  4. If the system that is running the ConfigMgr Console is a Dell with the Dell Command | Monitor installed, leave the pre-populated computer name. Otherwise type the computer name of a Dell system that has Dell Command | Monitor installed and is currently on the network. For the WMI namespace field, enter: root\dcim\sysman and check the Recursive box. Enter credentials if connecting to a remote system and click the Connect button.
    04 Dell-Connect to WMI
  5. On the Add Hardware Inventory Class window, select the following class: DCIM_BIOSEnumeration and click OK. This enables us to inventory BIOS UEFI settings (current and possible).
    05 Dell-Add Hardware Inventory Class
  6. Back on the Hardware Inventory Classes window, I recommend un-selecting the class for the Default Client Settings (in fact, I recommend trimming the Default Client Hardware Inventory Classes down to just a few and target only the necessary classes via Custom Client Settings). We will add them to a Custom Client Settings designed for Workstations. Unselect DCIM_BIOSEnumeration and click OK.
    06 Hardware Inventory Classes
  7. On the Default Settings windows, click OK.
    07 Dell-Default Settings
  8. Next, create a Custom Client Device Settings, give it the name Workstation Client Settings, select Hardware Inventory (or use a previously created one).
    08 Dell-Create Custom Client Device Settings
  9. Click on Hardware Inventory in the left pane and click Set Classes.
    09 Dell-Create Custom Client Device Settings
  10. Select DCIM_BIOSEnumeration and the following fields should be selected: AttributeName, CurrentValue, DefaultValue, IsReadOnly, PossibleValues, PossibleValuesDescription (InstanceName gets selected by default) and click OK. These are the fields that have useful information that we can use for reporting.
    10 Dell-Hardware Inventory Classes
  11. On the Create Custom Client Device Settings window, adjust the desired Hardware Inventory schedule and click OK.
    11 Dell-Create Custom Client Device Settings
  12. Deploy the newly created Workstations Client Settings out to a collection that contains Dell workstation systems. I have one called All Workstation Clients.
    12 Dell-Workstation Client Settings
  13. On a targeted Dell system, kick off a Machine Policy Retrieval & Evaluation Cycle and then a Hardware Inventory Cycle. In the InventoryAgent.log on the client, you should find an entry being inventoried for the newly defined namespace.
    13 Dell-Inventory Agent Log
  14. Back in the ConfigMgr Console, use the Resource Explorer and open up the Hardware Inventory for the system that was used in the previous step. Here you will see that the new class and corresponding values have been added.
    14 Dell-Resource Explorer

Hopefully you found this post useful and it helps you to gather and report on Dell specific settings using System Center Configuration Manager.

Originally posted on https://miketerrill.net/

How to Inventory Dell BIOS and UEFI Settings with ConfigMgr Part 1

Dell monitor logo

WARNING 9/30/2016: Installation of Dell Command | Configure version 9.1 will break Hyper-V on workstations that are running it. Basically, the Dell Command | Monitor overwrites some Hyper-V WMI entries and renders it inoperable. The simple fix is to run the following command after installing Command | Monitor on a system running Hyper-V: ‘mofcomp %systemroot%\system32\WindowsVirtualization.V2.mof’. Step numbers 6 &  9 have been updated below.

Similar to the Dell Command | Configure utility, Dell recently released the Dell Command | Monitor utility (previously known as OMCI or OpenManage Client Instrumentation). Where as the Dell Command | Configure utility enables IT administrators to configure Dell Enterprise client systems, the Dell Command | Monitor allows IT administrators to monitor and inventory system configurations and system health with enterprise management consoles, like System Center Configuration Manager. Now that Windows 10 is here, organizations are going to want to be able to report on UEFI capable systems as part of their planning so that they can be reconfigured for UEFI (instead of legacy BIOS). Running UEFI is a requirement in order to take advantage of the new security features in Windows 10 like Secure Boot, Device Guard and Credential Guard.

In a previous post, Inventory Secure Boot State and UEFI with ConfigMgr, I provided a method that will inventory systems that are running Secure Boot. This method results in the return of three possible values On (1), Off (0) or not detected (Null). Since UEFI is a requirement for Secure Boot, we can determine that UEFI is not enabled for a device if the Secure Boot state is not detected. This is great for high level reporting on how much of the environment is running UEFI, but it does not tell us how many systems (that are not running UEFI) can run UEFI.  Using Dell Command | Monitor and System Center Configuration Manager, we can determine not only which systems are running UEFI, but also which systems are UEFI capable. Dell Command | Monitor creates the necessary classes and properties in WMI that enables the monitoring and reporting of this information programmatically.

Part 1 of this post will show you what you need to do in order to distribute Dell Command | Monitor out to your existing systems using System Center Configuration Manager.

Part 2 of this post will show you how to extend System Center Configuration Manager to be able to collect this information and show the exact class that needs to be enabled.

The first thing you need to do is download the x86 and x64 versions (from here: Download 32-bit Dell Command | Monitor v9.1/Download 64-bit Dell Command Monitor v9.1) and install/extract it on a Dell system that is already running Windows 7/8/8.1/10 (there is an option to just extract the contents of the package as well). As of this post, version 9.1 is the latest release.

  1. After downloading (starting with the 64-bit version) and running the exe, click on extract.
    01 Extract package
  2. Create a temporary folder to extract the contents.
    02 Extract temp folder
  3. After the extraction completes, click View Folder.
    03 Extract complete
  4. Create a new folder structure on your Application repository (for this example I use Applications>Dell>Command-Monitor>9.1>x64) and copy the extracted contents to this location.
    04 App repository
  5. Download, extract the contents and copy to your Application repository (place the contents in Applications>Dell>Command-Monitor>9.1>x86).
    05 App repository x86
  6. [Updated for Hyper-V Fix] In the same directory, create the following file and call it Install-x64.ps1
    #Install Dell Command | Monitor
    Start-Process -FilePath "msiexec.exe" -ArgumentList "/i Command_Monitor_x64.msi REBOOT=ReallySuppress /qn" -Wait -Passthru
    
    #Check to see if Hyper-V is installed
    $HypverV = Get-WindowsOptionalFeature -online -featurename Microsoft-Hyper-V-Hypervisor
    $HypverV.State
    
    #Fix Hyper-V Install
    If ($HypverV.State -eq "Enabled") {
    $Path = '$env:SystemRoot\System32\WindowsVirtualization.V2.mof'
    $MofComp = Get-Item 'C:\Windows\System32\wbem\mofcomp.exe'
    Invoke-expression "& $MofComp $Path" }
    

     

  7. In the ConfigMgr Console, create a new Application by browsing to the MSI in the x64 subdirectory on the Application repository and click Next.
    06 New App
  8. View the imported information from the MSI and click Next.
    07 New App
  9. [Updated for Hyper-V Fix] On the General Information screen verify the following information and change the Installation program to: powershell.exe -ExecutionPolicy Bypass -file “.\Install-x64.ps1”. NOTE: We only need to do this for x64 since Hyper-V is not available on x86.
    08 New App
  10. Confirm the settings on the Summary screen and click Next.
    09 New App
  11. Verify that The Create Application Wizard completed successfully and click Close.
    10 New App
  12. Next, open up the Properties of the newly created Application.
    11 New App
  13. Select the Deployments Types tab and edit the listed Deployment Type.
    12 DT x64
  14. On the Deployment Type Properties, select the Requirements tab. Note: I like to add x64 to the name of the Deployment Type.
    13 DT x64
  15. On the Requirements tab, click the Add button.
    14 DT x64
  16. Select all of the 64-bit workstation versions of Windows that are supported in your environment and click Ok.
    15 DT x64
  17. Back on the Deployment Type Properties screen verify the following and click Ok.
    16 DT x64
  18. Now we need to add in the 32-bit Deployment Type. Back on the Deployment Types tab, click the Add button.
    17 DT
  19. On the General screen of the Create Deployment Type Wizard, browse to the Application repository for the 32-bit MSI and click Next.
    18 DT x86
  20.  Verify the that import succeeded and click Next.
    19 DT x86
  21. On the General Information screen, verify the following information and click Next. Note: I like to x86 to the Name and add REBOOT=ReallySuppress and /qn to the command line.
    20 DT x86
  22. On the Requirements screen, click the Add button.
    21 DT x86
  23. Select all of the 32-bit workstation versions of Windows that are supported in your environment and click Ok.
    22 DT x86
  24. Back on the Requirements screen, verify the following information and click Next.
    23 DT x86
  25. On the Dependencies screen, click Next.
    24 DT x86
  26. On the Summary screen, verify the settings and click Next.
    25 DT x86
  27. On the Completion screen, verify success and click Close.
    26 DT x86
  28. Back on the Deployment Types tab click Ok.
    27 App DT tab
  29. You will now see the Application with two Deployment Types listed in the console. Now we need to distribute the content to our Distribution Point(s). Right-click and select Distribute Content.
    28 Distribute Content
  30. On the General screen of the Distribute Content Wizard, click Next.
    29 Distribute Content
  31. On the Content screen, click Next.
    30 Distribute Content
  32. On the Content Destination screen, select the desired Distribution Point Group (or Distribution Point) and click Next.
    31 Distribute Content
  33. On the Summary screen, confirm the settings and click Next.
    32 Distribute Content
  34. On the Completion screen, verify the wizard completed successfully and click Close.
    33 Distribute Content
  35. Now we need to create a collection that contains only Dell workstation clients that we can use to deploy the newly created Dell Command | Monitor Applications. Create a new collection called All Dell Workstation Clients. On the General screen of the Create Device Collection Wizard, enter the following information and click Next. Note: I like to limit workstation collections to my All Workstation Clients collection.
    34 Dell Collection
  36. On the Membership Rules screen, click Add Rule and select Query Rule.
    35 Dell Collection
  37. On the Query Rule Properties screen, type All Dell Systems for the Name and then click Edit Query Statement.
    36 Dell Collection
  38. On the Query Statement Properties screen, select the Criteria tab and use Computer System.Manufacturer is like “%Dell%” and click Ok.
    37 Dell Collection
  39. Back on the Query Rule Properties screen, verify the following information and click Ok.
    38 Dell Collection
  40. Back on the Membership Rules screen, verify the following information and click Next.
    39 Dell Collection
  41. On the Summary screen, confirm the settings and click Next.
    40 Dell Collection
  42. On the Completion screen, verify the wizard completed successfully and click Close.
    41 Dell Collection
  43. Once the collection evaluation has completed, verify that the collection membership is working as expected and only contains Dell Workstation Clients.
    42 Collection
  44. Create a test deployment of the Dell Command | Monitor Application and verify that it is installing correctly. Back in the Software Library in the ConfigMgr Console, right click on Dell Command | Monitor Application and select Deploy.
    43 Deploy
  45. On the General screen of the Deploy Software Wizard, select the All Dell Workstation Clients collection and click Next. Note: Be sure to thoroughly test this in a lab first!
    44 Deploy
  46. On the Content screen, verify that the content has already been distributed to the Distribution Point Group(s)/Distribution Point(s) and click Next.
    45 Deploy
  47. On the Deployment Settings screen, choose Required for the Purpose and click Next.
    46 Deploy
  48. On the Scheduling screen, select the desired schedule and click Next.
    47 Deploy
  49. On the User Experience screen, select the desired settings and click Next.
    48 Deploy
  50. On the Alerts screen, click Next.
    49 Deploy
  51. On the Summary screen, verify the settings and click Next.
    50 Deploy
  52. On the Completion screen, verify the wizard completed successfully and click Close.
    51 Deploy
  53. Next, verify that it installed successfully by looking in Software Center and Programs and Features.
    52 Software Center52 Programs and Features
  54. Using Wbemtest, you will now see all of the Dell specific classes in root\dcim\sysman.
    53 Wbemtest

Now that Dell Command | Monitor is deployed, we can now use this information in a whole new way with System Center Configuration Manager. We can use it in Reports, Settings Management, and query criteria (just to name a few). Part 2 of this blog will show you how to extend System Center Configuration Manager to be able to collect this information and show the exact class that needs to be enabled to report on BIOS-UEFI settings.

Originally posted on https://miketerrill.net/

Automating Dell BIOS-UEFI Standards for Windows 10

Uefi_logo

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

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 x64.zip

Originally posted on https://miketerrill.net/