Automate 3rd party software, drivers and BIOS updates with the new System Center Update Publisher 2011

With System Center Update Publisher (SCUP) Microsoft provides a platform for adding 3rdparty updates to your conventional WSUS updates. Until last week SCUP 4.5 was available for adding 3rd party software, driver and BIOS updates to a WSUS server. With SCUP you can either use a catalog file to import multiple updates from a vendor’s website at once or just simply add your own update packages to SCUP to deploy it in your enterprise environment as they were Microsoft updates. Now, with SCUP 4.5 there were some issues which are resolved within SCUP 2011. Some of the issues include the following:

  • Limited configuration options for download behavior (i.e. metadata only vs full content)
  • Expired updates cannot be removed from the updates server easily
  • Approval and publishing updates requires multiple steps to be taken

With SCUP 2011 you now have a so called ConfigMgr integration. This integration option can be used to regulate download behavior for an update. In general you probably want clients to download only metadata from SCCM/SCUP if only a few clients request an update. When the number of clients increase it would be better to download full content so that clients will use common distribution points instead of an internet location to download the update to avoid unnecessary bandwidth utilization. With the thresholds you can regulate this now.

Expiring and removing updates properly was a hell of a job if an update was removed from a vendor’s catalog. In SCUP 2011 you can use a new Software Update Cleanup Wizard for this. So now, expiring a software update that exists on the update server but is not in the SCUP repository is an easy job.

SCUP 2011 has a Publish tab where you can bundle updates that you want to deploy to your clients. This is a new feature that makes it somewhat easier to manage and administer the SCUP update repository.

What I like the most about SCUP is that you are able to deploy software with the WSUS functionality available. In large enterprise environments normal software distribution requires lots of steps to be taken by various departments for each individual software update. These steps include scripting, testing, configure SCCM packages, collections, advertisements, etc. New software updates like Adobe’s Flash Player are being released very rapidly. It requires that you’ll have to execute the same procedure over again to deploy it in your enterprise. Using SCUP and Adobe’s update catalog instead will save you a lot of time.

Installing drivers, BIOS, hardware utilities and firmware for instance on Dell systems is an easy job using SCUP. Minor disadvantage is that you will need the OpenManage client running on client systems to provide some necessary WMI classes. These extra classes will be used to identify the hardware peripherals. WSUS uses this information to compare with the catalog logic rules:



With SCUP you can use the logic which comes with the catalogs to deploy a software update bundle that include multiple updates at once. Compare the logic within the catalog with the queries you normally use in SCCM collections for grouping the client systems what you’ll need for targeting the software.

You can also create your own updates. As an example i’ve added the Google Chrome browser installer as a required update with Adobe Flash Player as a prerequisite :-)


Read More

HOWTO: Bitlocker Status Reporting in SCCM 2007

I recently had to come up with a solution that will enable administrators to build reports for client’s bitlocker status. To do so i found a few articles on the web that pointed me in the right direction, however i didn’t found a complete howto for it so that’s a good reason for me to post a complete one.

To enable bitlocker status reporting in a centralised management environment with SCCM you need to follow some steps because bitlocker is not integrated that far (yet??) in the Windows OS. First, let’s first take a look at the status information that bitlocker provides:

  • Volume name, example: C: [OSDisk]
  • Disk size, example: 148,75 GB
  • BitLocker Version, example: Windows 7
  • Conversion Status, example: Fully Encrypted
  • Percentage Encrypted, example: 100%
  • Encryption Method, example: AES 128 with Diffuser
  • Protection Status, example: Protection On
  • Lock Status, example: Unlocked
  • Identification Field, example: None
  • Key Protectors (Note: multivalue), example: TPM, Numerical Password

You can check the above on clients using the commandline tool manage-bde.exe -status on Windows 7 clients. For Vista clients use cscript manage-bde.wsf -status.

Step 1. Modify and deploy SMS_DEF.MOF

We want bitlocker status information to be inventoried to SCCM. A proper way of doing that would be to add the bitlocker class to the SMS_DEF.MOF file on the management point (found in %SCCMinstallpath%\inboxes\clifiles.src\hinv). Make a copy of this file and edit with your favorite app. Add the following lines at the end of the file:

#pragma namespace (“\\\\.\\root\\cimv2\\SMS”) //make sure to use normal quotes!
#pragma deleteclass(“SCCM_BitLocker”,NOFAIL)
[ SMS_Report     (TRUE),
SMS_Group_Name (“SCCM_BitLocker”),
SMS_Class_ID   (“CUSTOM|SCCM_BitLocker|1.0”) ]
class SCCM_BitLocker : SMS_Class_Template
[SMS_Report (TRUE), key ] string Drive;
[SMS_Report (TRUE)] string DriveLabel;
[SMS_Report (TRUE)] string Size;
[SMS_Report (TRUE)] string BitLocker_Version;
[SMS_Report (TRUE)] string Conversion_Status;
[SMS_Report (TRUE)] string Percentage_Encrypted;
[SMS_Report (TRUE)] string Encryption_Method;
[SMS_Report (TRUE)] string Protection_Status;
[SMS_Report (TRUE)] string Lock_Status;
[SMS_Report (TRUE)] string Identification_Field;
[SMS_Report (TRUE)] string Key_Protectors;
[SMS_Report (TRUE)] string Automatic_Unlock;
[SMS_Report (TRUE)] string ScriptLastRun;

[edit] Make sure to replace any fancy double quotes with normal quotes after copying because otherwise compiling or parsing will fail. Or download this file: bitlocker_mof.

You should check the file for errors with mofcomp.exe -check SMS_DEF.MOF. To enable the MOF file on a single client run the following command on the client mofcomp -class:forceupdate %pathtofile%\SMS_DEF.MOF. Copy the edited file back to enable it on your ConfigMgr site.

Step 2. Install Bitlocker

Create and link a GPO to apply on the bitlocker clients that contain the following settings (or similair based on your own requirements):

Machine | Administrative Templates | System | Trusted Platform Module Services
Turn on TPM backup to Active Directory Domain Services Enabled
Machine | Administrative Templates | Windows Components | BitLocker Drive Encryption | Operating Sytem Drives
Choose how BitLocker-protected operating system drives can be recovered Enabled
Allow data recovery agent Disabled
Configure user storage of BitLocker recovery information: Require 48-digit recovery passwordAllow 256-bit recovery key
Omit recovery options from the BitLocker setup wizard Enabled
Save BitLocker recovery information to AD DS for operating system drives Enabled
Configure storage of BitLocker recovery information to AD DS: Store recovery passwords and key packages
Do not enable BitLocker until recovery information is stored to AD DS for operating system drives Disabled

Enter the BIOS on your client or use tools like the Dell client configuration utility to turn on TPM, clear the TPM and activate it. After doing this enable bitlocker encryption on the machine. You can use any method to achive this.

Step 3. Add Bitlocker status to WMI & run hw inventory

Although there are multiple ways of manipulating bitlocker through WMI you still need a script to read, update and store bitlocker status information in the WMI repository (see This is because Managed Object Format (MOF) files are not installed as part of the Windows SDK and therefore the included classes are not added to the WMI repository automatically by Windows itself.

[update: A handy colleague wrote a powershell version of the script for adding the bitlocker status into WMI with some nice enhancements. All credits go to Daniel Last.]

The scripts (use only one):

  • VBS version: UpdateBitlockerStatus.vbs
  • Powershell verion: Bitlocker_Status.ps1 Bitlocker_Status_v1.1.ps1 [update]

Run the script and after that initiate a hardware inventory on the client. Note that the powershell version of the script already triggers a hardware inventory. Additionally, the powershell script need to be run with the powershell execution policy to be set to RemoteSigned. Do this using the following cmdlet: Set-ExecutionPolicy RemoteSigned

[edit] You could trigger the inventory in the vbscript by adding this line: WshShell.Run “WMIC /namespace:\\root\ccm path sms_client CALL TriggerSchedule “&Chr(34) & “{00000000-0000-0000-0000-000000000001}” & Chr(34) & ” /NOINTERACTIVE”,,true

After a while you will find 2 new tables and 1 new view in the SCCM site database:

Step 4. Create the Report

I created a report in SCCM with the following query:

SELECT     v_R_System.Name0 AS Computername, v_GS_SCCM_BitLocker0.Bitlocker_Status0 AS [Bitlocker Status],
v_GS_SCCM_BitLocker0.BitLocker_Version0 AS [Bitlocker Versie], v_GS_SCCM_BitLocker0.Conversion_Status0 AS [Converstion Status],
v_GS_SCCM_BitLocker0.Drive0 AS Drive, v_GS_SCCM_BitLocker0.DriveLabel0 AS DriveLabel, v_GS_SCCM_BitLocker0.Encryption_Method0 AS [Encryption Method],
v_GS_SCCM_BitLocker0.Identification_Field0 AS [Identification Field], v_GS_SCCM_BitLocker0.Key_Protectors0 AS [Key Protectors],
v_GS_SCCM_BitLocker0.Percentage_Encrypted0 AS [Percentage Encrypted], v_GS_SCCM_BitLocker0.Protection_Status0 AS [Protection Status],
v_GS_SCCM_BitLocker0.ScriptLastRun0 AS [Script Last Run]
FROM         v_GS_SCCM_BitLocker0 INNER JOIN
v_R_System ON v_GS_SCCM_BitLocker0.ResourceID = v_R_System.ResourceID

And there it is, the Bitlocker report (note: old screenshot based another query but more or less similar):

Tested on SCCM R2 with a Windows 7 Enterprise bitlocker client.

Feel free to comment on this post.

Douwe van de Ruit

Read More