SCEP 2012 R2 - Group Policy ADMX Template

I’ve been working a lot with System Center Configuration Manager (SCCM) and System Center Endpoint Protection (SCEP) recently and as part of the work, I’ll be migrating servers over to using SCEP. We have decided on a two part move, firstly moving antivirus to SCEP with Group Policy management, then later adding the SCCM client if we feel it would be better. Obviously reporting, status, definition updates and other useful features are nice, but we have System Center Operations Manager (SCOM) for monitoring, so we will certainly write some monitors for this!

Initially theres a roadblock, as the only ADMX provided is as part of the Forefront Endpoint Protection 2010 tools and it’s not obvious it applies to SCEP 2012. Fortunately Microsoft haven’t changed anything since then, so it’s essentially a drop in solution. However, if you want to be nice and use the right names for things, you need to do a little bit of work to alter the friendly names, which I’ve done here. Copy the files into the “%systemroot%\PolicyDefinitions” folder locally to test, then into the policy central store for your domain when it makes sense.

SystemCenterEndpointProtection2012R2.admx

SystemCenterEndpointProtection2012R2.adml

EDIT: Latest versions are:

SystemCenterEndpointProtection.admx

SystemCenterEndpointProtection.adml

SCCM 2012 R2 - Updating and configuring HP ProBook 6470b/6570b BIOS in a task sequence - Part 1

Continuing my recent foray into System Center Configuration Manager (SCCM) 2012 R2, I’ve been working on getting a task sequence to automatically update and configure the BIOS for our HP ProBook laptops. I’ve started with our most popular models, the HP ProBook 6470b/6570b. Fortunately, apart from their screen size, they are almost completely identical, which makes the job a lot easier.

Prerequisites

The first thing we’ll need to do is take care of the prerequisites and the downloads, so we’ve got all the files required to complete the work.

Files Needed

• The HO ProBook 6x70b BIOS is available here and should work with both the 6470b and the 6570b.
• HP BIOS Configuration Utility (HP BCU). I’m using version 3.0.13.1, there could be changes if you are using something newer.
• HP System Software Manager (HP SSM). Again, I’m using version 3.1.10.1, so be aware.

First of all, we’ll get the BIOS configuration working and we’ll do the BIOS update second. This may sound backwards, but it simplifies things if you will be imaging a mix of factory fresh and pre-provisioned machines. This is because we’ll be setting the BIOS password in the configuration stage and putting the logic there to deal with whether the machine already has a password set. This means when we come to the BIOS flash, we can just run the tool in a straightforward way.

NOTE: If you’re not using a BIOS password, you can do this in any order, but I highly recommend you secure things properly. The last thing your service desk needs is someone changing the boot order and installing their own OS or something, because users.

Encrypting your BIOS password

Extract the HP System Software Manager download and install it. You’ll then have to browse to either “%ProgramFiles(x86)%\Hewlett-Packard\SystemSoftwareManager”, or “%ProgramFiles%\Hewlett-Packard\SystemSoftwareManager” to find “ssm.cab”. The files you need are in here:

• “HPBIOSUPDREC.exe” (BIOS updater tool we may need later)
• “HpqPswd.exe” (BIOS password encryption tool)

NOTE: For the ProBook 6x70b, we’ll be using the hpqFlash.exe utility that we’ll get later, as that’s the one that works with these models. If you are using newer models (like the EliteBook 840G1), you will need to use HPBIOSUPDREC.exe.

If you run HpqPswd.exe, it will ask you for the BIOS password you wish to encrypt into a “.bin” file. Enter your BIOS password, then save the file somewhere useful, as this we will use this later to as the credential for configuring/updating the BIOS.

Preparing the BIOS configuration

Now, you’ll need a test machine of the right type to get a BIOS configuration from. You could in theory specify the configuration file from scratch, but that would take a while. The easiest way to do it is to set up a computer how you want it, export the BIOS config, tweak it to suit, then deploy!

To start this process, you’ll need to install the HP BIOS configuration utility, then browse to “%ProgramFiles(x86)%\Hewlett-Packard\BIOS Configuration Utility”, or “%ProgramFiles%\Hewlett-Packard\BIOS Configuration Utility” and get the following files:

• “BiosConfigUtility.exe” (BIOS configuration tool, for x86)- - “BiosConfigUtility64.exe” (BIOS configuration tool, for x64)

NOTE: Both of these files seem to work fine on x64 build of Windows 7, so I’m not too sure why there is a specific x64 version. The “BIOS Configuration Utility User Guide.pdf” is also quite useful, so you may want to grab that too.

BIOSConfigurationUtilityHelp

If you take BiosConfigUtility and run it on the machine you’ve configured, you can get it to export the current configuration to file, using “BiosConfigUtility.exe /get:”ProBook 6x70b\BIOSConfig.cfg””

The file format for the BIOS configuration isn’t particularly great, with tab indented options, but with the export, the current settings are all selected for you, with an asterisk (*) denoting the active option.

Here’s an example of part of my config file:

Data Execution Prevention
    Disable
    *Enable
SATA Device Mode
    IDE
    *AHCI
Reset of TPM from OS
    Disable
    *Enable
OS Management of TPM
    Disable
    *Enable
Activate TPM On Next Boot
    Disable
    *Enable
TPM Device
    Hidden
    *Available
TPM Activation Policy
    F1 to Boot
    Allow user to reject
    *No prompts

You can tweak the file however you need, It seems the general recommendation is to remove anything you’re not actively going to set, as this provides a more concise config file and makes it easier to track down issues.

In the next part, I’ll cover setting up the SCCM side of things now we are nearly ready to deploy the new settings and upgrade the BIOS. Read on to Part 2!

SCCM 2012 R2 - Validating and setting OSDComputerName with PowerShell

I’ve recently been doing some work with System Center Configuration Manager (SCCM) 2012 R2 recently and I was interested in validating a computer name supplied during an Operating System Deployment (OSD) task sequence before actually attempting to set it and possibly causing an error (with the computer name being too long, for example). Since that sounds like a job for PowerShell, I immediately had a look and found a reasonable solution that almost fit my needs.

As an aside to this, I’m not currently using the Microsoft Deployment Toolkit (MDT) in any real way, however my solution does use a component of it in order to display the PowerShell script to the user. This gave me a good excuse to run through it and start to check it out with the idea of using it more down the line.

The solution I found that almost did what I wanted can be found here (I’ve contributed my alterations there too in the comments. Thanks very much to Nickolaj for his script, as it saved me a fair bit of work!

To run the script, a few things have to be done first (Instructions with screenshots can be found in Nickolaj’s post on scconfigmgr.com.

• Add the ‘WinPE-NetFx’ and ‘WinPE-Powershell’ features to the boot image you will be using with the OSD. (in “Boot Images > Boot image > Properties > Optional components”)
• Download a copy of MDT that matches the boot image architecture you want (x86/x64), then extract the ServiceUI.exe file from it, usually located at “%ProgramFiles%\Microsoft Deployment Toolkit\Templates\Distribution\Tools”
• Create an SCCM package containing the script, plus ServiceUI, but don’t create a program for it, as we’ll deal with that bit when adding it to the task sequence.

Then, you add a ‘Run Command Line’ task in your task sequence, then use the package created  in the previous step, along with a command line like:

ServiceUI.exe -process:TSProgressUI.exe %SYSTEMROOT%\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -WindowStyle Hidden -ExecutionPolicy Bypass -File MYSCRIPTFILENAME.ps1

After testing the script and running it, there were a couple of things I saw that could be improved:

• First was the ability to hit enter and have that correspond to the OK button. It’s  minor thing, but makes a massive difference to the user experience!
• Next, was the validation/correction of the computername. The original script will silently strip out invalid characters, which may leave some wondering why the computer name appears differently to how it was originally typed.

I started with making the enter button correspond to the OK button. I did this by adding the following code just before the call to load the form:

$Form.KeyPreview = $True
$Form.Add_KeyDown({if ($_.KeyCode -eq "Enter"){Set-OSDComputerName}})

Next, I wanted to remove the silent removal of user input and make it obvious to the user that they had entered an invalid computer name. I did this by re-using the existing ErrorProvider and moving the validation code to another clause in the if statement.

This meant that instead of having:

else {
    $OSDComputerName = $TBComputerName.Text.Replace("[","").Replace("]","").Replace(":","").Replace(";","").Replace("|","").Replace("=","").Replace("+","").Replace("*","").Replace("?","").Replace("<","").Replace(">","").Replace("/","").Replace("\","").Replace(",","")
    $TSEnv = New-Object -COMObject Microsoft.SMS.TSEnvironment
    $TSEnv.Value("OSDComputerName") = "$($OSDComputerName)"
    $Form.Close()
}

We end up with something slightly different (ignoring the use of a Regular Expression to validate the computer name instead of a multiple string.Replace())

#Validation Rule for computer names.
elseif ($TBComputerName.Text -match "^[-_]|[^a-zA-Z0-9-_]") {
    $ErrorProvider.SetError($GBComputerName, "Computer name invalid, please correct the computer name.")
}
else {
  $OSDComputerName = $TBComputerName.Text.ToUpper()
  $TSEnv = New-Object -COMObject Microsoft.SMS.TSEnvironment
  $TSEnv.Value("OSDComputerName") = "$($OSDComputerName)"
  $Form.Close()
}

As you can see, this makes the script a little easier to read, which always bodes well for improvements in the future. One thing that still slightly annoys me is the format of the if elseif elseif else. This is quite close to being made a switch statement, but it’s OK until I find the need to add another clause. I’d also like to find a way to remove the MDT dependency of ServiceUI.exe, as this requires a different SCCM package or invocation based on architecture (x86/x64). However, this may not be possible due to the way the OSD task sequence works.

Here is the current script I’m using in full. Please let me know if you have any improvements you can suggest, as it’s always a good day to learn!

OSDComputerName

Reading and podcasts about that DevOps thing

The Phoenix Project (Book)

A book that explains in real terms what the future of IT might just look like in a few years. I don’t know whether it will or not, but it’s a good read and really raises some great points where IT people can work towards improving systems and integrating with the business in a real way to help them reach their goals. The same guys involved in this also seem to have another book in the pipeline, called The DevOps Cookbook. It’s definitely on my list to read as soon as it comes out.

Ops All The Things (Podcast)

A really good podcast by a couple of really really smart guys in the ops/sysadmin field. It’s only just started, but each episode is jam packed full of interesting topics to think about. Every episode so far has given me some things to take into my day to day to help constantly improve what i’m doing and giving me ideas to share.

PowerScripting Podcast

One of my go-to podcasts when I’m just wanting to hear something new or interesting about the tech world. Loads of really really cool guests from all over the world, not just Windows/Microsoft. Even though it’s the official PowerShell.org podcast it’s about a lot of general tech/automation and just cool stuff as well, not just PowerShell focused.

Active Directory Permissions and C#

I’ve been doing some work recently with C# querying AD for locked out users. One of the requirements for this was to only show users that can be altered by the user running the program.

Fortunately there is a computed AD attribute available for this to do the job, called allowedAttributesEffective. Here is some sample code to check a user for attributes you can write to:

allowAttributesEffective