Not sure what this part of the script is doing

As part of the learning process i find it interesting to look at other scripts and see how people construct things. The below script has got me interested and i’m trying to understand what it does.

The line i’m referring to is

$objPCSet.psbase.properties["ResourceID"].value = $ResourceID

What part is the [“ResourceID”] playing ? isn’t the indexing ?

#   Notes 
#   Script name: Add-MachineVariables.ps1
#   Author:      Paul Winstanley
#   Contact:     @SCCMentor
#   DateCreated: 21/01/2015
#
#   Parameter variables description
#
#   $ComputerName = Hostname of computer to receive the Machine Variables
#   $SiteServer = ConfigMgr Site Server hostname
#   $SiteCode = ConfigMgr Site Code
#
#   Usage Example:
#   ./Add-MachineVariables.ps1 -ComputerName HostName-01 -SiteServer ConfigMgr-01 -SiteCode CMR 
#
#   $ComputerVariablesName & $ComputerVariablesValue arrays need to be completed below. Replace Name1, Name2 etc and Value1, Value2 with your 
#   required Machine Variables
#

param (
 [string]$ComputerName,
 [string]$SiteCode,
 [string]$SiteServer
 )

#Set Machine Variables Name and Value
$ComputerVariablesName  =  @("Name1", "Name2", "Name3", "Name4")
$ComputerVariablesValue = @("Value1", "Value2", "Value3", "Value4")


$MachineSettings = [WmiClass]"\\$SiteServer\ROOT\SMS\site_$($SiteCode):SMS_MachineSettings"
$ResourceID = (Get-WmiObject -ComputerName $SiteServer -Namespace root\SMS\Site_$($SiteCode) -Query "SELECT * FROM SMS_R_System where Name = '$ComputerName'").ResourceID
$objPCSet =  $MachineSettings.CreateInstance()
$objPCSet.psbase.properties["ResourceID"].value = $ResourceID
$objPCSet.psbase.properties["SourceSite"].value = $SiteCode


#Check that the number of Machine Variables type Name matches the number of Machine Variables type Value
if ($ComputerVariablesName.Count -eq $ComputerVariablesValue.Count) {  
for ($i = 0;$i -lt $ComputerVariablesName.Count; $i++)
{
   $objPCSet.MachineVariables = $objPCSet.MachineVariables + [WmiClass]"\\$SiteServer\ROOT\SMS\site_$($SiteCode):SMS_MachineVariable" 
}

# Get an array of the Variables
$MachineVariables =  $objPCSet.MachineVariables

# Set the Variables - Name and Value
# Loop for the amount of variables in $ComputerVariablesName
for ($i = 0;$i -lt $ComputerVariablesName.Count; $i++)
    {
    $MachineVariables[$i].name= $ComputerVariablesName[$i]
    $MachineVariables[$i].value= $ComputerVariablesValue[$i]
    }

$objPCSet.MachineVariables = $MachineVariables

# Store the variables
$objPCSet.put()
}
    else {
        Write-Host "The number of Machine Variables type Name and Value must match. Check your array."
        break
    }

Hi Graham,

It’s referring to an element in the properties hash table, and has the same effect as referring to it via [pre]$objPCSet.ResourceID[/pre]

Thanks Tim. So why do it this way ? (Apart from looking better !)

So by adding .Psbase, that is looking at the raw properties ? Why would you need to do this ? Sorry, just trying to get an understanding.

Pretty much what you said. PowerShell tries to establish the properties and methods available for an object, but it some cirumstances can get it wrong, and you find you’re missing a method or property.

Using psbase looks directly at the raw object

As for why it’s been done that way, not certain. Might be because SCCM does have what are referred to as ‘lazy properties’, which means some properties and methods are not immediately visible by a wmi query. That’s not for all of its WMI Classes though.

Normally though, you get round this by using the wmi path to get the full object, which (personally) i think is a bit nicer.

Of the format :

[WMI] ‘Path’

Where ‘Path’ is the value you see in the __PATH property of the wmi object.