Configuration Manager Dynamic Drivers & BIOS Management with Total Control Part 2

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

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/

BIOS and Secure Boot State Detection during a Task Sequence Part 1

With all of the security issues and malware lately, BIOS to UEFI for Windows 10 deployments is becoming a pretty hot topic (unless you have been living under a rock, UEFI is required for a lot of the advanced security functions in Windows 10). In addition, with the Windows 10 Creators Update, Microsoft has introduced a new utility called MBR2GPT that makes the move to UEFI a non-destructive process. If you have already started deploying Windows 10 UEFI devices, it can be tricky to determine what state these devices are in during a running Task Sequence. The Configuration Manager Team introduced a new class called SMS_Firmware and inventory property called UEFI that helps determine which computers are running in UEFI in Current Branch 1702. This can be used to build queries for targeting and reports, but it would be nice to handle this plus Secure Boot state (and CSM) during a running Task Sequence. We do have the Task Sequence variable called _SMSTSBootUEFI that we will use, but we need to determine the exact configuration in order to execute the correct steps.

There are three different BIOS modes that a system can be running:
Legacy BIOS – also known as BIOS emulation, this requires a MBR partitioned disk in order to boot. Most Windows 7 systems are running this configuration.
UEFI Hybrid – this mode is when a system is running in UEFI, but with the Compatibility Support Module (CSM) (also known as Legacy ROMs) enabled. Unlike Legacy BIOS, this mode requires a GPT partitioned disk in order to boot. Windows 7 can run in this configuration and before there was MBR2GPT, this was the recommended mode to deploy Windows 7 in so that it could be easily upgraded to Windows 10 at a later date without repartitioning the disk.
UEFI Native – this mode is when a system is running in UEFI without the CSM. It also requires a GPT partitioned disk in order to boot. Windows 7 cannot run on a system that is configured for UEFI Native.

Now let’s talk about Secure Boot. Secure Boot and CSM are incompatible – if the CSM is enabled, then you cannot enable Secure Boot. When Secure Boot is enabled, you cannot enable the CSM. Based on this information, we know that Secure Boot will be unsupported in Legacy BIOS and UEFI Hybrid modes (Note: When I say unsupported, I am not talking about if the device is capable of running Secure Boot. Secure Boot requires a device running UEFI 2.3.1 Errata C or later and an operating system capable of running Secure Boot). Configuration Manager currently does not have out of the box functionality for reporting on Secure Boot, but the feature has showed up in the Technical Preview 1703 release. In the meantime, see my blog called Inventory Secure Boot State and UEFI with ConfigMgr on how to extend hardware inventory in Current Branch 1702 or older in order to collect this information.

From this information, we can create a handy chart to help visualize the configuration options:

NOTE: For UEFI Hybrid, Secure Boot State is unsupported if the CSM is enabled, however, an operating system that supports Secure Boot will show that status as Off (Disabled) in System Information.

Now, with this information and MBR2GPT, we should be able to create a single Windows 10 Feature Update Task Sequence for clients Windows 7/8/8.1/10 and it should not matter if they are already running UEFI or Legacy BIOS. The actions that we need to perform do matter and this is where we can set some Task Sequence variables to help with the logic on the various steps. But first, let’s see what needs to be done based on the four configurations above. We already said that Legacy BIOS is the only configuration that uses a MBR partitioned disk. Therefore, this will be the only configuration that we need to run MBR2GPT. When we run MBR2GPT, we also need to configure the device’s firmware settings for UEFI and enable Secure Boot (the Microsoft solution does not do this for you, you are on your own to use the vendor methods to do this piece).

If you are one of the few that took last year’s recommendation and started deploying Windows 7 in UEFI mode, then those systems will be running UEFI Hybrid. We do not need to run MBR2GPT on these systems since they are already running a GPT partitioned disk. We simply need to turn off the CSM (or Legacy ROMs) and enable Secure Boot (once again, the Microsoft solution does not do this for you).

For systems that are running UEFI Native but Secure Boot is not enabled, we simply need to enable Secure Boot. Lastly, for systems that are already running UEFI Native with Secure Boot enabled, we do not need to do anything additional for these systems. Adding these actions to our chart, it makes it very clear what actions need to be done under each scenario:

In a follow blog post, I will go into more detail on how we can use this logic in a single Windows 10 In-Place Upgrade Task Sequence, what the steps look like and where each of them go.

Originally posted on https://miketerrill.net/