Tag Archives: microsoft

SCCM – Updating and configuring HP BIOS/UEFI in a task sequence – An update

Lately I’ve bee working on a little more SCCM operating system deployment work and I’ve got an updated toolset for configuring and updating UEFI firmware for HP machines easily in a task sequence. This is a reasonably long post, so bear with me.

A lot of the same techniques from my earlier posts on the subject apply. We are still using HPBIOSUPDREC, BiosConfigUtility and an SCCM package for the source files. I’ve updated the batch files to take an argument for the configuration or update file, as well as the previous architecture detection. The good thing about this method is that it supports all current HP laptop, desktop and workstation models with no change, you just give the update file, or the configuration as an argument and away you go.

I considered using PowerShell for this, however it takes a little while to start in WinPE and unless I add more logic to the process for particular models or action types, I don’t see the need to convert it yet.

I’ve set up the package for HP machines I need to configure and update as follows:

    68ICF.CAB (UEFI firmware - EliteBook 8x70p)
    BiosConfigUtility.exe   (BIOS config utility - x86)
    BiosConfigUtility64.exe (BIOS config utility - x64)
    BIOSPW.bin              (Encrypted BIOS password)
    ConfigureUEFI.cmd (UEFI config command file)
    EliteDesk800G2-Win7.cfg (UEFI configuration - Win 7)
    EliteDesk800G2-Win10.cfg (UEFI configuration - Win 10)
    EliteBook8x0G3-Win7.cfg (UEFI configuration - Win 7)
    EliteBook8x0G3-Win10.cfg (UEFI configuration - Win 10)
    EliteBook8x70p-Win7 (UEFI configuration - Win7)
    N75_0110.bin (UEFI firmware - EliteBook 8x0 G3)
    N21_0219.bin (UEFI firmware - EliteDesk 800 G2 SFF)
    UpdateBIOS.cmd (UEFI update command file HPqflash models)
    UpdateUEFI.cmd (UEFI update command file HPBIOSUPDREC models)

A sample set of files for all of this can be found on GitHub, except the HP binaries and firmware, which need to be downloaded from HP.

You can follow the larger package format, with all models together, or spread the update and configuration files over multiple packages, whichever suits your requirements best.

You may notice that I’ve included an odd DLL file ‘oledlg.dll’. This is needed to make HPqflash work on WinPE 10 (10.0.10586.0). If you run HPqflash in WinPE 10 without it, you get an exit code of -1073741515 (0xC0000135), which means a DLL needed for the program is missing.

I did a bit of investigation with procmon on a full windows system and found oledlg.dll was required, but missing from WinPE. I put this DLL in the same folder next to HPqflash and all was good!

Both ConfigureUEFI.cmd and UpdateUEFI.cmd are general for all models using HPBIOSUPDREC and the HP BIOS config utility and look like this:

There’s also a slightly different version for deploying updated firmware, if you’re still using HPqflash:

We can use the same SCCM ‘Run command line’ task we used in the past for this, with a little tweak to run the command file with the right update or configuration. This is done in the same way as before, with the extra exit code for successful completion.

This is the configure command line:


Followed by the update command line, along with the success exit codes shown.



The update command line needs to follow the configure step if as it requires a password bin file.

Hopefully this has been helpful updating things in the journey to support newer HP models.

System Center Endpoint Protection – Updated ADMX Template for the March 2016 Update – KB3106514

The new update has been out for a little while now (KB3106514) and brings with it three new settings.

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Microsoft Antimalware\MpEngine
DWORD name: MpEnablePUS

This setting enables detection and removal of Potentially Unwanted Applications (PUA) downloaded through IE, Firefox or Chrome. One thing about this is that it will only apply to new detections going forward. This setting will not cause existing PUAs to be detected and removed.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Microsoft Antimalware\UX Configuration

DWORD name: SuppressRebootNotification

This is a setting to suppress the reboot notification from the client if it detects that a reboot is required to finish the clean-up of any malware. This is useful in shared environments (RDS, etc.), where a this kind of thing would not be fun.

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Microsoft Antimalware

DWORD name: ThreatFileHashLogging

This setting records an event with ID 1120 to the log file containing the SHA-1 hash of the affected file for more research and correlation with other infections or threats.

There’s also a link from the knowledge base page to a script on the PowerShell gallery for setting up anti-malware client updates on a UNC share, which is quite nice for new deployments, without using something like System Center Configuration Manager (SCCM) or Windows Server Update Services (WSUS).

I have added these updates to my ADMX template for System Center Endpoint Protection, which can be downloaded from GitHub. Note that from this update on, the file names and data drop the 2012R2 version number from the file name, which makes more sense going forward. The old files are still there for reference.

The direct links to the files are:


It’s been just over a year since the last policy template settings change from Microsoft for their Endpoint Protection products and still no sign of an official file! I’ll keep on with the updates for this until Microsoft sort it out.


I’ve made a couple more changes to add two new policy options that I had previously overlooked, these are:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Microsoft Antimalware\Real-Time Protection

DWORD name: DisableScriptScanning

This setting provides an admin override to disable script scanning.

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Microsoft Antimalware\Real-Time Protection

DWORD name: LocalSettingOverrideDisableScriptScanning

This setting allows the local client setting for script scanning to take precedence over a group policy setting.

SCOM 2012 – Run an SQL query in a script monitor with a Run as account

I got asked a little while ago if SCOM could query an SQL database and generate an alert in certain circumstances. I was sure it could, since I’ve seen things do it before, but it wasn’t something i’d done myself. It seems like a fairly basic thing to do, but all the documentation I found was a bit scattered across the web, so I’m noting it down here, with links to the sources I used!

Somehow I’ve managed to get a long way without doing any real SCOM Management Pack authoring… Until now! This made my day a nice learning curve,

Here’s the summary of how I went about it.

  • Create a new Management Pack (MP) to contain the changes.
  • Create the run as profile in the MP.
  • Create the monitor in the MP.
  • Export the management pack.
  • Add the run as reference to the monitor.
  • Re-import the management pack.
  • Complete the configuration, set up alerting and overrides, etc.

To make things easier we create the framework of the monitor and the run as profile first, to make the manual editing step easier.


Massive thanks to the following people and everyone posting about SCOM stuff, a lot of this stuff would be incredibly difficult without their help.

Create a new Management Pack (MP) to contain the changes

I started by creating a management pack for whatever monitors I create using this method, since it will need editing. This should help to keep things tidy, allowing me to isolate the changes I’m making from the rest of the system, as is good practice.

Browse to Administration, then right-click on “Management Packs” and choose to create a new management pack.


I’ve named and described my management pack, obviously these will be different in your case.

Create the run as profile in the MP

Browse to the Administration tab, then right-click “Run As Configuration” and choose to “Create Run As Profile…”


Name and describe the profile how you need it, then choose to put it in the management pack we created. Add the run account you need, then create it.

Create the monitor in the MP

To create the monitor, I browsed to the Authoring tab, then to “Management Pack Objects > Monitors” and filtered the scope to the following “SQL Server YYYY DB”, depending on the SQL Server version containing the database you need to target. I’ll be working with SQL Server 2014 for this example, but this method applies to all recent versions of SQL server.


Next we can go ahead and create a new Unit Monitor to hold our script we need to run against the DB. In this example I’ll be using a timed script two state monitor.


The script monitor should be created in the new management pack we’ve just created, given a reasonable name and not enabled, since we will create overrides later for the databases this monitor will apply to.


For testing, I’ll be setting the schedule of the script to 5 minutes (not shown) and I’ll be using the following script as a test monitor, it’s just a simple script to grab the last updated time of a collection and pass that back to the property bag for the alert if it’s over 20 minutes old. Here’s the script and just as importantly the parameters screen to show how the script has been set up.

Here’s the script itself:

Take note that the SQL query in the script is made up for this example, but the rest script can be used for many other things. I’ve used parameters for the database server and database name in the script, so the solution just relies on the script and return values being specified correctly in the lower half of the script.


Now we have the script and the parameters sorted out, we can turn our attention to the health expressions. In this example they are set up simply. If we get some records back, there’s a problem. It’s a simple way to go, and this way round we can hopefully extract some useful reason for why things are unhealthy.



We can grab the data from the property bag returned by the script and use the details in the health expression by grabbing the property by name as shown. Since this is a test monitor and isn’t really critical, I’m going to leave the “Configure Health” step as default, and not configure an alert yet, then create the monitor.

Export the management pack

To export the management pack, browse back to the management pack we created at the beginning, right click it and choose to export it. This will give you an XML file we can go ahead and edit.

Add the run as reference to the monitor

I’ve attached the original and the run as versions of the management pack here, showing almost no difference between the two files! All I’ve done is bump up the version number and add the “SecureReference” ID from the secure references section to the chosen UnitMonitor. It’s a little easier this way than adding the secure reference from scratch and makes the whole process a bit quicker.

Here’s the diff between the two files on GitHub.

Re-import the management pack

To re-import the management pack, import the MP back from disk. Make sure you don’t change the filename, as this will cause issues with importing, as will any XML validation errors that may have been introduced.

Complete the configuration

Now we’ve got over all that, we can now apply an override and try out the monitor!

Navigate back to the Authoring tab and find the monitor you created earlier. Right click it, choose “Overrides > Override the monitor > For a specific object of class: SQL Server YYYY DB”. Choose the database you want this monitor to apply to, then click OK.


Choose to override the “Enabled” parameter, then click OK.

You’ll be able to see the management pack importing on the destination server, if you look at the event viewer for the destination server.


Eventually, you should see the script run. It will log an event under the source “Health Service Script” and should hopefully post the data you need! In this example is a shot of the script failing and posting the error text specified in the script to the event log.


I remove the error state by updating the collection. A while later, the script runs again and sees that the error is resolved.


Now we’ve confirmed it’s all working, we can set up the alert. Navigate back to the “Authoring” tab in SCOM and get to the “Alerting” tab in the properties of our monitor.


This is an example of a basic alert, including the collection last update time in the alert description by adding the property returned by the script.

I’ll cover troubleshooting these kinds of scripts in another post soon, there’s a few things to look at to make sure you’ve covered all the bases. The most important thing is returning the right variable types in the property bag.