Summary: Microsoft PFE, Heath Lawson, talks about applying common Windows PowerShell concepts to Configuration Manager.

Microsoft Scripting Guy, Ed Wilson, is here. Today we welcome guest blogger, Heath Lawson. Heath is a System Center premier field engineer based in Kansas City, Missouri. He often posts about System Center-related scripting and automation in his blog, HeLaw's Blog: System Center…Tying it all together!

Heath Lawson here, checking in for the first of three posts. My background is heavy in Configuration Manager, although I love all aspects of automation and scripting, so the opportunity to write guest posts here is amazing! This series is intended to help Configuration Manager folks jump into scripting and automation by helping them gain an understanding of how common Windows PowerShell concepts can apply to Configuration Manager.

There are three posts to this series, the first will cover how to interact with the Windows PowerShell support starting with Configuration Manager 2012 Service Pack 1, the second is an advanced look at using cmdlets to get work done, and the third is about taking care of business without using the native Windows PowerShell cmdlets. These posts will assume that you have a very basic understanding of Windows PowerShell; and if you don’t, you’re in the right spot because the Scripting Guys have some fantastic resources here to get you up to speed.

System Center Configuration Manager 2012 introduced Windows PowerShell support starting with Service Pack 1. Each cumulative update typically finds new or updated Windows PowerShell functionality, although the differences can be subtle. The most current version is System Center 2012 R2, so all of the examples here will be shown with the System Center 2012 R2 versions of the cmdlets. Understand that there may be differences if you’re not using System Center 2012 R2.

The goal of this post is to take a common action, and then create a new collection and set a few properties…all with Windows PowerShell. I like to show and tell when it comes to scripting, so we’ll jump into the lab and get started. We can easily do that that within the Configuration Manager console by clicking the upper-left corner and launching the Windows PowerShell session.

After we click the menu item that is highlighted, we’ll be presented with a Windows PowerShell session with the Configuration Manager module loaded:

What is P35?

Now, we have our Windows PowerShell session, but why is it referencing P35? Well, for the astute readers out there, you’ll notice in the top screenshot, that is my site code for Configuration Manager. The reason for this is that the Configuration Manager module registers itself as a Windows PowerShell provider and creates a Windows PowerShell drive.

It’s just a Windows PowerShell drive

A little background on the Configuration Manager PowerShell module…

First, all of the Windows PowerShell functionality in Configuration Manager is contained within the ConfigurationManager.psd1 module, which is located in the <Install Path>\AdminConsole\Bin\i386 directory. Additionally, the module references the site code of where the console has connected. This is important to understand for automation scenarios because we have to fire up the console as the user running Windows PowerShell at least once to make sure we reference our site code via the provider.

Now that we have our Windows PowerShell session loaded and we understand that our functionality is going to come from the Configuration Manager module, let’s get started creating our collection. First, we need to understand which cmdlet to run to create a new collection. To find that, we’ll run a quick command to find all of the commands in our Configuration Manager module that have a name that contains Collection:

Get-Command -Module ConfigurationManager | Where-Object {$_.Name -like '*Collection*'}

A new Configuration Manager collection

Well, this seems great. In true Windows PowerShell verb-noun form, we can see that there is a New-CMDeviceCollection cmdlet available! Also, from this view, you’ll notice all of the Configuration Manager cmdlets are easily identifiable because the noun portion of the cmdlets is prefixed with CM.

One of the great things about Windows PowerShell is that it contains plenty of built-in documentation, and that documentation updates on a regular basis. One point here, the Configuration Manager module ships with older documentation. You can issue the Update-Help cmdlet to update your Configuration Manager documentation. With that out of the way, let’s get more information on the New-CMDeviceCollection cmdlet and see what we need to do to use it to create a collection for us.

Get-Help New-CMDeviceCollection

As we can see in this image, New-CMDeviceCollection gives us a few options, such as name and refresh type. Collections in Configuration Manager 2012 must be limited to another collection, so we know we’re going to have to specify the limiting collection and a collection name. As we can see in this image, it calls that out for us.

Optionally, for those who feel like experimenting, we can use the Tab key to auto-complete for us in Windows PowerShell. One of my common short cuts is to simply type the cmdlet and then “–“. From there, press the Tab key and you’ll see it auto-complete the parameters that are available for the cmdlet. Cool, huh?

Anyway, back to it…

Let’s create a new collection! We’re going to stack together the previous information and put together a single line of Windows PowerShell that will create a collection:

New-CMDeviceCollection –Name “All Windows Server 2012 R2 Devices” –LimitingCollectionName “All Systems”

With that, we have a Configuration Manager collection!

In this section, we learned how to look at the cmdlets that are available within the Configuration Manager module and how to get additional Help about a cmdlet, and we were able to create a collection using nothing but one line of Windows PowerShell. There are 560 Windows PowerShell cmdlets available with Configuration Manager 2012 R2, so I encourage you to get to know them and understand how they can make administration simpler.

~Heath

Thank you, Heath, for writing this series and sharing. I am looking forward to Part 2.

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