When it comes to identifying what department a device belongs too, it can either be easy or beyond complicated.

For some it is a simple case of relying on a well-organised Active Directory Site layout, or Organisational Unit structure, but for other SCCM administrator sorry souls, branding from external directories and sources is haphazard and unreliable.

If you are in the latter category, and are fed up with a poorly run external branding mechanism, branding devices can be made to be a cinch using SCCM, some patience and a multi-pronged form of attack.

I’ve got a simple solution here that helps you get an existing estate branded, and which can then lead on to efforts to perform mandatory branding when new devices are introduced, or existing devices are rebuilt.

There isn’t anything here more complicated than leveraging an SCCM feature called Collection Variables, the usage of you’ll pick up as you follow the guide.

The key components needed for this solution are a PowerShell Script, in a Package, in a Task Sequence as an Run PowerShell Script step, some Collections hosting Collection Variables, and RegKeyToMof by Mark Cochrane to extend Hardware Inventory out easily, so we can return the branding data back to the Site server for ‘usage’.

With this guide you can walk through a two phased approach to branding your existing desktop estate, firstly brand what is already out there, so that you can reliably query against devices Hardware Inventory, so as to eek out which department it belongs too.

The second phase would be up to you to cover, and that would be making sure the branding of a device is performed during the Operating System build process. This, if done right, will make sure all new devices coming in are branded and compatible with the SCCM hierarchies collection queries that revolve around the branding itself.

Before we get going let’s make some assumptions about you:

  • You don’t need me to explain when to finish completing a wizard, choosing defaults to wrap up

  • If I do not mention a setting, that’s because it is supposed to stay as it is, in its default setting

  • If this all looks like rocket science, you really should park yourself up and read material on the subjects, keywords for you to look up and research in the documentation library would be:

Collection Variables
Collection Queries
Package Source
Task Sequences
Hardware Inventory
Extending Hardware Inventory
Windows Registry
PowerShell (well okay, don’t deep dive it, take an eternity, if you don’t know it at least look up what a PowerShell variable is)

I bet you all can tick those boxes, if you can great, move on, otherwise if you proceed with the intent of building this tool out in your lab, without doing any reading whatsoever, you’ll get a big tut from me if I find out, and a Low-Quality-Grade sticker posted to you. Put in the burn and effort to soak up the detail as it is important, not to remember it all, but to have been there a few times, forms muscle memory, an important aid for someone trying to cover a product as vast as SCCM is.

Let’s begin.

  • Create your Package Source Folder

  • Visit your Content Source location used for SCCM content, create yourself an SCCMBranding folder

  • Create the PowerShell script

  • Copy the following script to the new folder, and call the file SCCMBranding.ps1, don’t save it yet, copy it then go to the next instruction

# SCCM Branding Tool

# Written by Robert Marshall EM MVP

$ToolVersion = "1.0"

$CompanyName = "SMSMarshall"

$HKLMCompanyPath = "HKLM:\SOFTWARE\" + $CompanyName # Company Path

$HKLMBrandingPath = "HKLM:\SOFTWARE\" + $CompanyName + "\Branding" # Company Branding path

$companyID = "DepartmentID" # Name of Registry Value and Collection Variable

$TSEnv = New-Object -COMObject Microsoft.SMS.TSEnvironment

$TSLogPath = $TSEnv.Value("_SMSTSLogPath")    
$TSLogFile = "$TSLogPath\$($MyInvocation.MyCommand).log"

# Start the logging

Start-Transcript $TSLogPath

Write-host "SCCM Branding Tool $ToolVersion"

if ( -Not (Test-Path $HKLMCompanyPath)){

    Write-host "Creating new key $HKLMCompanyPath"

    New-Item -Path $HKLMCompanyPath -ItemType RegistryKey -Force

if ( -Not (Test-Path $HKLMBrandingPath)){

    Write-host "Creating new key $HKLMBrandingPath"
     New-Item -Path $HKLMBrandingPath -ItemType RegistryKey -Force

Write-host "Checking if $companyID exists"

$valueExists = Get-ItemProperty $HKLMBrandingPath $companyID -ErrorAction SilentlyContinue

if ($valueExists -eq $null){

    Write-host "ID $companyID does not exist"
     # Determine where to do the logging            
     Write-Host "Creating Branding registry key" $companyID

    New-ItemProperty -Path $HKLMBrandingPath -Name $companyID -Value $tsenv.Value($companyID)

     Write-host "ID $companyID exists"

Write-host "Finished."
# Stop logging

  • Before you save this file, change the $CompanyName value to the name of your company or some identifier for your Lab, branding will live in a sub-key called Branding (HKLM\Software\CompanyName\Branding)

  • What does this script do? It logs a lot, and looks for the Collection Variable then imprints it on the Registry

  • Create a new Package

  • Call it SCCM Branding Tool

  • Set the data source to point at the SCCMBranding folder

  • No need for a Program, we’re running content from the package using a task sequence

  • Create a Task Sequence

  • Call it SCCM Branding Tool

  • Add Run PowerShell Script action

  • Set the Package to the SCCM Branding Tool

  • Enter SCCMBrandingTools.ps1 as the script name

  • It should look a lot like this:



  • Edit the task sequences properties

  • Select suppress task sequence notification, however skip this step if you want the deployment to be visible for troubleshooting\first time around purposes

  • Create a Collection

  • Call it SCCM Branding Tool


  • Add a new Collection Variable

  • Call it DepartmentID

  • Give it a value of CompanyTechnicalGroupA


What we’ve done is created a collection that will be used for both the Deployment of our Task Sequence, and for defining what DepartmentID is, so that the branding tool can place that value in the registry of the devices being targeted.

If you were taking this from the lab into production, you’d have a single collection for deploying the branding tool, and then you’d define the collections you will use to hold each collection variable, one collection per department so as to break down your devices into their respective departments.

This will introduce lots of collections, and you’ll need to manually add existing devices into respective department collections, so that it is given the right DeploymentID value when the branding task sequence is run on it.

You can add devices to these collections manually, or automate it a bit with query logic on the collections to process AD Site, Organisational Unit, Username, even software installed; Choose whatever way you can manipulate inventory and discovery data, to determine if a device belong in a departmental branding collection.

We now have to tell SCCM to inventory this new registry key on the devices in the Hierarchy.

  • Modify SCCM Hardware Inventory Definition and Reporting

  • Open RegEdit on the target device you’ll be using for branding

  • Navigate to HKEY Local Machine, Software

  • Create a Key, and name it as whatever you specified in the SCCMBranding.ps1 script as the $CompanyName variable value (It needs to look like HKLM\Software\CompanyXYZ)

  • Create a sub-key under your Company name key, and call it Branding

  • Create a string value (REG_SZ) and call it DepartmentID, it does not have to have a value

  • Download RegKeyToMOF and run it on the device you just created the registry keys on

  • It will start up and show the HKLM registry hive, navigate to Software, find your Company Name key, expand it and click on Branding

  • On the right make sure the tick box is ticked for DepartmentID

  • Tick 64bits only unless you have 32 bit Operating Systems that’ll need this running on, in which case don’t tick it, then check out the class names and how they are defined as this will change how you write queries for collections

  • Below you’ll see I’ve highlighted the reporting class, copy that to the clipboard


  • Copy the clipboard contents to a file called SCCMBranding-DepartmentID-Reporting.mof anywhere of your choosing, somewhere safe, consider when\if you rebuild the site server, you’ll need this file again

  • Now return to RegKeyToMOF and select the configuration.mof tab

  • Do the same and copy the text (with or without the // comments) into a file called SCCMBranding-DepartmentID-Definition.mof

  • We’re done with RegKeyToMOF now, that really made extending SCCM Hardware Inventory a breeze, thanks Mark!

  • You can also delete the registry value, and key all the way back to Branding, do this is if the device you just used to obtain the registry key from is going to be the test device

  • Now open the dataldr.log log file on the site server in readiness to watch MOFCOMP process the definition change we’re about to make to Hardware Inventory

  • On the site server open the SCCM installation folder, navigate into Inboxes, CLIFILES.SRC, and into the HINV folder

  • Open the configuration.mof file in WORDPAD

  • Navigate to the bottom of the file, and put the cursor between the extension start and end comment blocks like so, then paste in the contents of the SCCMBranding-DepartmentID-Definition.mof file


  • Save the file, return to the data loader (dataldr) log file and see MOFCOMP process the MOF successfully, if not check what you are doing, the definition mof contents go into this definition file, not the reporting mof content

  • If all is good in the data loader log, open the SCCM Console, navigate to Administration, Client Settings, edit the Default Client Settings

  • Select Hardware Inventory then select Set Classes…

  • Select the Import… button and navigate to the SCCMBranding-DepartmentID-Reporting.mof file


  • Accept all the prompts with default options selected, and click apply to update the default client settings for the Hierarchy

Let’s deploy the task sequence to the combined deployment and branding collection, we’re almost there.

  • Deploy the SCCM Branding Task Sequence

  • Make it Required, as soon as possible, or available if you are troubleshooting\passing through this solution for the first time

  • Tick Do not show task sequence progress, you can untick this if you’ve already decided to make the task sequence available and visible

  • Override maintenance window for Software installation

  • Allow remote or fallback, share if using BranchCache

  • Download when needed or before, either works, choose appropriate to your hierarchy

  • Kick the tyres – Run the branding tool on the device

  • Add the device to the SCCM Branding collection, it will then pickup that Collection Variable and the Deployment

  • Make sure it shows in the collection before proceeding, obviously a very important step!

  • Perform a Machine Policy Retrieval for the device, either at the device or using the client notification channel, quite important to make sure the device gets the very latest policy payload or you’ll be testing with old policy containing your previous edits and such like, voiding your test and forcing you to repeat it

  • Keep an eye on PolicyEvaluator for new policy coming in, once you see it carry on (no policy update? try nudging it again)

  • If you made the deployment interactive (available) and the task sequence visible, it’ll be showing in Software Center, from where you can install it


    • Check out the ExecMgr and SMSTS log files, they will show you the launch of the task sequence, and the task sequence logging file, the ContentTransferManager log will show you the script content being brought down.

    • If SMSTS log doesn’t exist, the deployment hasn’t run, you’ll have to figure out what went wrong using the device logs, and check how you’ve configured everything on the Site server.

This is a clean run through task sequence execution, that branded a device correctly:

Transcript started, output file is C:\WINDOWS\CCM\Logs\SMSTSLog RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
SCCM Branding Tool 1.0 RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
reating new key HKLM:\SOFTWARE\SMSMarshall\Branding RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
   Hive: HKEY_LOCAL_MACHINE\SOFTWARE\SMSMarshall RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
Name                           Property                                         RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
----                           --------                                         RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
Branding                                                                        RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
Checking if DepartmentID exists RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
D DepartmentID does not exist RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
reating Branding registry key DepartmentID RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
epartmentID : CompanyTechnicalGroupA RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
PSPath       : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\ RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
               SMSMarshall\Branding RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\ RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
               SMSMarshall RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
PSChildName  : Branding RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
PSDrive      : HKLM RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
PSProvider   : Microsoft.PowerShell.Core\Registry RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
Finished. RunPowerShellScript 12/08/2017 14:50:48 10052 (0x2744)
Process completed with exit code 0 RunPowerShellScript 12/08/2017 14:50:49 10052 (0x2744)

  • Open RegEdit



  • The device has been branded!

Let’s check out what SCCM can see.

  • Back to the SCCM Console, Assets and Compliance and show members for the All Systems collection

  • Find the test device, right click it and select Start and then Resource Explorer



  • As if by magic, our registry key value has appeared in the hardware inventory for our test device. Sweet.

Whatever device you add to the collection will now be branded with the DepartmentID value CompanyTechnicalGroupA.

Let’s reflect on what we’ve achieved so far.

We have:

  • A basic but cool PowerShell script, that will brand devices using a Task Sequence Collection Variable if we run it inside a Task Sequence (to get at Collection Variables)

  • A Package containing the PowerShell script

  • A Task Sequence with the Run PowerShell Script action invoking our PowerShell script

  • A single collection that we’re using to set a Collection Variable, and to deploy to any members

  • Hardware Inventory returning the registry key value if it exists on any device in the Hierarchy (we can narrow this down using custom client settings to switch it off on grouped devices if we so wished)

What we don’t have is a way to determine what is branded and what isn’t. So let’s build that out now using two collections dedicated for that exact purpose.

If we want to keep track of what hasn’t been branded, we need a collection to query for them, however it isn’t straightforward to do due to collection logic limitations, so we’re going to need two collections and those very useful INCLUDE\EXCLUDE collection rules.

  • Create a Collection for all branded devices

  • Name it SCCM Branding – Branded Devices

  • Limit it by a All Desktop and Server devices, or another collection of your choosing

  • Create a new Query

  • Name it IsBranded

  • Select Edit Query Statement…

  • Select Criteria

  • Select Starburst

  • Set the Criterion Type to Null Value

  • Select Select…

  • For Attribute Class and Attribute select SCCMBranding and DepartmentID

  • Select OK

  • For Operator select is not NULL

  • Finish up the creation of the collection

  • This collection will show all devices that have been branded

  • Create a Collection for all unbranded devices

  • Name it SCCM Branding - Unbranded Devices

  • Limit it by a All Desktop and Server devices or another collection of your choosing

  • Add an INCLUDE rule and select All Desktop and Server devices (or whatever you want to limit with)

  • Add an EXCLUDE rule and select SCCM Branding – Branded Devices
  • Finish up the creation of the collection

  • This collection will show devices that have not been branded by including all devices (according to what you chose for the include rule) and then excluding those known to be branded in the SCCM Branding – Branded Devices collection

If you check out the Collection Evaluator log, you will be able to see your new collections queries run, and the resulting devices added to each like so:


* 2 Devices in this Hierarchy, a fresh bud just built, one device is branded, the other not

Finally, we’ll build a collection into which we will pour all the devices for a specific department (or even multiple departments), using a query that looks for DepartmentID having a specific value.

Since we only have one value coming back as a branding value, CompanyTechnicalGroupA, we’re going to build around that.

  • Create a new Collection

  • Name it SCCM Branding – CompanyTechnicalGroupA

  • Limit it to All Desktop and Server clients (you can limit by any collection obviously, giving this solution a high level of granularity)

  • Add a new Query Rule

  • Call the rule SCCMBranding

  • Click Edit Query Statement …

  • Select Criteria

  • Select Starburst (yellow star icon)

  • Select Select …

  • Now look for your new SCCMBranding class


      • Select OK

      • Select Values…


    • It should list the data discovered from the test device or devices

    • Choose the DepartmentID listed, select OK four times to finish up the Query

Let Collection Evaluator run the collections query, and eventually, you’ll see your first device or devices dropping into the collection:


So there you go, a very basic branding tool, that you can easily build out further, by hybridising it to wrap around your organisation and hierarchy setup.

An immediate step you could take forward, is to use Compliance Settings to figure out who doesn’t have branding, but since you cannot pass Collection Variables down using Compliance Settings, you cannot use it to brand via this solutions approach of pivoting off of Collection Variables.