With System Center Update Publisher (SCUP) Microsoft provides a platform for adding 3rd party updates to your conventional WSUS updates. Until this 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.

Software Update Cleanup Wizard

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.


Whenever you are in a situation that you have to migrate from an Altiris based deployment infrastructure to a SCCM one (or just need both) you’ll probably will find some issues when using PXE boot to deploy OS images to your clients when both systems must be in use at the same time. Which PXE server will answer to which PXE request? How will Altiris and SCCM determine who will answer the client request?

With some simple but clever configuration you will be able to have Altiris and SCCM in a co-existant environment. Before explaining these configurations first a quick list about PXE behaviour from both the Altiris PXE and SCCM PXE Service Point:

When a client boot using PXE Altiris can be used to do the following:

  • based on an Altiris DS job send a boot image to the client
  • let the client boot to next device in order
  • ignore the PXE request

SCCM can do:

  • offer F12 for deploying an advertisement
  • deploy unattended in case of an assignment
  • let the client boot to next device in order

I know that Altiris and SCCM/WDS can do a lot more but they are more or less designed for the above scenario’s. Because Altiris supports ignoring PXE requests when no active DS job is assigned it can be used to let OS deployments be serviced by SCCM. To do this you need to configure both Altiris and SCCM:

1. Altiris: Open PXE configuration > find the option “only respond to clients with active DS job only” > enable this option
After this configuration Altiris will ignore PXE request from clients with no active DS job assigned to it. This makes it possible for SCCM to reply because the client will still wait for a reply for about 30 seconds. You need to make sure that Altiris always can reply earlier than SCCM.

2. SCCM: Open the console > Site systems > PXE Service point properties > change the Delay to 5 10 seconds
After this configuration Altiris will always be able to service clients as the first in order. When no job is available SCCM is the next in line to service. When SCCM has no advertisements or assignments it will send the abortpxe.com boot program to the client. When executed abortpxe.com will let the system boot the next device in order of the BIOS boot sequence.

3. Optional, use IP helpers instead of DHCP scope options. Because the client PXE requests have to be forwarded to both the Altiris as the SCCM PXE server you can better use IP helper addresses on your routers/switches to do this. The IP helper function converts PXE broadcasts into unicast traffic and can be forwarded to a list of IP addresses (so DHCP, SCCM and Altiris).
Note: This can also be used to eliminate the need for a PXE server to be on the same network segment as the clients :-).

Bitlocker status reporting in SCCM

Posted: November 19, 2010 in Uncategorized

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

[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 http://msdn.microsoft.com/en-us/library/aa376409.aspx). 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.

The script (credits go to Daniel Last):

# Name : Bitlocker_Status.ps1
# Purpose : Create a WMI provider for Bitlocker to report Bitlocker Status to SCCM
# Date : 19 oktober 2010
# Version : Initial Release
# Author : Daniel.Last@kpn.com
# Date : 25 oktober 2010
# Change : Created the ability to process script to check Bitlocker status for every persistent volume (removeable drives excluded)
# Changed the way how to write the key protectors column to use “,” as delimiter
# Version : 1.1
# Author : Daniel.Last@getronics.com

# Create Hash Table
$Arguments = @{}

# Getting WMI Objects
$Bitstatus = @(Get-WmiObject win32_EncryptableVolume -Namespace root\cimv2\Security\MicrosoftVolumeEncryption -ErrorAction SilentlyContinue) #| where-object {$_.PersistentVolumeID -ne “”})

# Check if Bitstatus is $null
If ($Bitstatus -eq $null) {
# Bitlocker is Disabled
$Arguments.Add(“Bitlocker_Status” , “Disabled”)

# Create SCCM_Bitlocker WMI Class
Remove-WmiObject SCCM_Bitlocker -ErrorAction SilentlyContinue
$newWMIObject = New-Object System.Management.ManagementClass
$newWMIObject.Name = “SCCM_BitLocker”
$newWMIObject.Properties.add(“Bitlocker_Status”, “”)
$newWMIObject.Properties.item(“Bitlocker_Status”).Qualifiers.Add(“Key”, $true)

# Write Bitlocker Status into the WMI SCCM_Bitlocker Repository
Set-WmiInstance -Class SCCM_Bitlocker -Argument $Arguments
else {
# Create SCCM_Bitlocker WMI Class
Remove-WmiObject SCCM_Bitlocker -ErrorAction SilentlyContinue
$newWMIObject = New-Object System.Management.ManagementClass
$newWMIObject.Name = “SCCM_BitLocker”
$newWMIObject.Properties.add(“Drive”, “”)
$newWMIObject.Properties.add(“Bitlocker_Status”, “”)
$newWMIObject.Properties.add(“DriveLabel”, “”)
$newWMIObject.Properties.add(“Size”, “”)
$newWMIObject.Properties.add(“BitLocker_Version”, “”)
$newWMIObject.Properties.add(“Conversion_Status”, “”)
$newWMIObject.Properties.add(“Percentage_Encrypted”, “”)
$newWMIObject.Properties.add(“Encryption_Method”, “”)
$newWMIObject.Properties.add(“Protection_Status”, “”)
$newWMIObject.Properties.add(“Lock_Status”, “”)
$newWMIObject.Properties.add(“Identification_Field”, “”)
$newWMIObject.Properties.add(“Key_Protectors”, “”)
$newWMIObject.Properties.add(“ScriptLastRun”, “”)
$newWMIObject.Properties.item(“Drive”).Qualifiers.Add(“Key”, $true)

# For each drive in Bitdrive process drive(s)
Foreach ($Bitdrive in $Bitstatus) {
$Drive = $Bitdrive.DriveLetter

$Volume = Get-WmiObject Win32_Volume | where-object {$_.Driveletter -eq $Drive}

# Capture status values in Hash Table which don’t require name translation
$Arguments.Add(“Drive” , $Drive)
$Arguments.Add(“DriveLabel” , $Volume.Label)
$Arguments.Add(“ScriptLastRun” , (Date))
$Arguments.Add(“Percentage_Encrypted” , ($Bitdrive.GetConversionStatus()).EncryptionPercentage)

# Proccessing status values for translation
$Version = ($Bitdrive.GetVersion()).Version
$ConversionStatus = ($Bitdrive.GetConversionStatus()).ConversionStatus
$EncryptionMethod = ($Bitdrive.GetEncryptionMethod()).EncryptionMethod
$ProtectionStatus = ($Bitdrive.GetProtectionStatus()).ProtectionStatus
$LockStatus = ($Bitdrive.GetLockStatus()).LockStatus
$IdentificationField = ($Bitdrive.GetIdentificationField()).IdentificationField

for($i=1; $i -le 8; $i++) {
$VolumeKeyProtectorID = ($Bitdrive.GetKeyProtectors($i)).VolumeKeyProtectorID
If ($VolumeKeyProtectorID -ne $Null) {
Switch ($i) {
1 {$KeyProtectorIDTypes = “Trusted Platform Module (TPM)”}
2 {$KeyProtectorIDTypes += “,External key”}
3 {$KeyProtectorIDTypes += “,Numeric password”}
4 {$KeyProtectorIDTypes += “,TPM And PIN”}
5 {$KeyProtectorIDTypes += “,TPM And Startup Key”}
6 {$KeyProtectorIDTypes += “,TPM And PIN And Startup Key”}
7 {$KeyProtectorIDTypes += “,Public Key”}
8 {$KeyProtectorIDTypes += “,Passphrase”}
Default {$KeyProtectorIDTypes = “None”}
$Arguments.Add(“Key_Protectors” , $KeyProtectorIDTypes)

# Translating integer values into logical names
$Size = “{0:N2}” -f ($Volume.Capacity / 1GB) + ” GB”
$Arguments.Add(“Size” , $Size)

Switch ($Version) {
0 {$Arguments.Add(“BitLocker_Version” , “UNKNOWN”)}
1 {$Arguments.Add(“BitLocker_Version” , “VISTA”)}
2 {$Arguments.Add(“BitLocker_Version” , “Windows 7”)}

Switch ($ConversionStatus) {
0 {$Arguments.Add(“Conversion_Status” , “FULLY DECRYPTED”)}
1 {$Arguments.Add(“Conversion_Status” , “FULLY ENCRYPTED”)}
2 {$Arguments.Add(“Conversion_Status” , “ENCRYPTION IN PROGRESS”)}
3 {$Arguments.Add(“Conversion_Status” , “DECRYPTION IN PROGRESS”)}
4 {$Arguments.Add(“Conversion_Status” , “ENCRYPTION PAUSED”)}
5 {$Arguments.Add(“Conversion_Status” , “DECRYPTION PAUSED”)}

Switch ($EncryptionMethod) {
-1 {$Arguments.Add(“Encryption_Method” , “The volume has been fully or partially encrypted with an unknown algorithm and key size.”)}
0 {$Arguments.Add(“Encryption_Method” , “The volume is not encrypted.”)}
1 {$Arguments.Add(“Encryption_Method” , “AES 128 WITH DIFFUSER”)}
2 {$Arguments.Add(“Encryption_Method” , “AES 256 WITH DIFFUSER”)}
3 {$Arguments.Add(“Encryption_Method” , “AES 128”)}
4 {$Arguments.Add(“Encryption_Method” , “AES 256”)}

Switch ($ProtectionStatus) {
0 {$Arguments.Add(“Protection_Status” , “PROTECTION OFF”)}
1 {$Arguments.Add(“Protection_Status” , “PROTECTION ON”)}
2 {$Arguments.Add(“Protection_Status” , “PROTECTION UNKNOWN”)}

Switch ($LockStatus) {
0 {$Arguments.Add(“Lock_Status” , “UNLOCKED”)}
1 {$Arguments.Add(“Lock_Status” , “LOCKED”)}

# Check if Identificationfield is $null
If ($IdentificationField -eq $null) {$Arguments.Add(“Identification_Field” , “None”)} else {$Arguments.Add(“Identification_Field” , $IdentificationField)}

# Check if Bitlocker status is Enabled
If ($Bitdrive.GetConversionStatus().EncryptionPercentage -eq 100) {$Arguments.Add(“Bitlocker_Status” , “Enabled”)} else {$Arguments.Add(“Bitlocker_Status” , “Disabled”)}

# Write Bitlocker Status into the WMI SCCM_Bitlocker Repository
Set-WmiInstance -Class SCCM_Bitlocker -Argument $Arguments

# Clear Hash table

} # End foreach Bitdrive
} # End Check if Bitstatus is $null


Note that this script is written for Windows 7. 

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

The most simple report would be a report of the table containing the bitlocker inventory data. By joining other tables/views with SQL queries the possibilities are endless, however i placed that out of scope of this howto . The following tables and views are provided for this:

  • dbo.SCCM_BitLocker_DATA
  • dbo.SCCM_BitLocker_HIST
  • dbo.v_GS_SCCM_BitLocker0

I created a report in SCCM with the following query using the SQL view:

  • select * from v_GS_SCCM_BitLocker0

And there it is, the Bitlocker report:

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

Feel free to comment on this post.