Summary: Microsoft PFE, Heath Lawson, talks about using Windows PowerShell to set advanced properties in Configuration Manager.
Microsoft Scripting Guy, Ed Wilson, is here. Back today is Heath Lawson. You may want to read the first post of this series before you begin this post: Apply Common PowerShell Concepts to Configuration Manager.
Greetings! Heath here. I’m back with another post in the series about Windows PowerShell for the System Center Configuration Manager Admin. In the last post, we explored using the native Windows PowerShell cmdlets for Configuration Manager to create a device collection. We saw that we can use a combination of Get-Command and Get-Help to explore our way around the Configuration Manager PowerShell module and ultimately create a new Configuration Manager collection.
In this section, we’re going to turn it up to 11 and set some more advanced properties to show how we can interact with our Configuration Manager objects at a deeper level. As an example, we’re going to look at how we can loop in other cmdlets, as well as outside data to create a more realistic device collection.
Explore the collection object
Let’s get started in the lab. We’re going to start where we left off in the last section—using New-CMDeviceCollection to create a new collection. The difference here is that we are going to create an object that is based on the output of that cmdlet, and I’ll show you why.
$CMCollection = New-CMDeviceCollection –Name “All Windows Server 2012 R2 Devices” –LimitingCollectionName “All Systems”
Wait? What happened? We didn’t get the output that we had last time?
Well, here we created a new object ($CMCollection) to hold the resulting output in the form of an object from our cmdlet. Similarly, we could have used Get-CMDeviceCollection to get an existing collection. We can then use the Get-Member cmdlet to find out where all that went:
$CMCollection | Get-Member
Awesome! We can see several things of interest here. Get-Member simply lists all the properties and methods of our object, so we can see what we’re working with. Properties are just that—elements that reflect specific information about an object. Methods are the “verbs” (so to speak), and they allow us to call specific behavior from an object.
Now, we’re going to change a few properties of this collection. Super simple to do, we just need to reference the properties of our object, and set them accordingly:
$CMCollection.Comment = “This collection contains all Windows Server 2012 R2 clients”
We’ve updated the collection comments. Or have we? When I check the properties, it doesn’t show in the console. Why is this? Well, at this point we’ve committed the changes to our instance of the object without committing them via the SMS Provider to the database. To do that, we need to use the Put method to commit the changes:
$CMCollection.Put()
Cool! You might be wondering two things. First, what other methods are available, and second, how can I check this without peeking in the console? Well, I’m glad you asked. We can use the Get() method to update the instance of the object we are working with and show the changes!
$CMCollection.Get()
$CMCollection.Comment
By using this methodology, we can see that we can set almost any property that is available on this object, including properties that are not available when we initially create the new collection, as you can see in the previous example.
Although we used a collection in this section, this same information will hold true on all of the Configuration Manager cmdlets. As an example, being able to set deployment properties on a software updates deployment or on deployment type information is now available.
In the past two posts, I’ve introduced how to incorporate the Configuration Manager cmdlets into your day-to-day administrative work in addition to automation scenarios. In the next and last post, I’ll introduce how to work with items directly via the SMS Provider in Configuration Manager!
~Heath
Thank you, Heath, for this post. Looking forward to Part 3 tomorrow.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy