The official blog of the Microsoft System Center Configuration Manager Product Group
Hello Configuration Manager administrators. It’s time to get acquainted with Windows PowerShell!
We’ve finally introduced native Windows PowerShell support with System Center 2012 Configuration Manager SP1. Many of you know that Windows PowerShell is the new way to automate, but you haven’t yet made the leap. Don’t be afraid, it’s time to dip your toes into the big Windows PowerShell ocean and give it a try.
To help you get going with Windows PowerShell, I’ll be writing a weekly blog that’ll cover Windows PowerShell integration with Configuration Manager. This blog series assumes you haven’t used Windows PowerShell at all, so our first installment will be to go over a few basics. If you’ve done a bit of Windows PowerShell, just play along, we’ll tackle some topics for you PowerShell veterans too.
Ready to get started? First, you need to make sure Windows PowerShell 3.0 is installed. Grab it here: http://www.microsoft.com/en-us/download/details.aspx?id=34595. Like many applications, Windows PowerShell comes in a 32-bit version and a 64-bit version. Configuration Manager needs the 32-bit version. Hit your Windows Key and type “PowerShell” – then right-click PowerShell (x86) and choose “Run as administrator”. You should now see a “command prompt” type Window. Welcome to Windows PowerShell!
I’m going to pause here for just a moment to share a few concepts.
“Cmdlet” is sometimes also called “Command-let”. The cmdlet is a basic instruction you give Windows PowerShell. All cmdlets are made up of two parts: a verb and a noun. They are separated by a hyphen ‘-‘ character. Cmdlets are what do all the work for you. Some cmdlets come with Windows, and others are installed with programs like Configuration Manager. An example of a Configuration Manager cmdlet that retrieves a ConfigMgr site is:Get-CMSite. An example of a Windows cmdlet that restarts a print job is:Restart-PrintJob. Before we jump into our second concept, let’s try a few cmdlets.
Go to your Windows PowerShell window, and type:
PS C:\> Get-Location
You don’t need to worry about upper/lower case, Windows PowerShell doesn’t care. Windows PowerShell should return the current path. Windows PowerShell knows a lot about your computer, so let’s try a few more cmdlets.
PS C:\> Get-Service
PS C:\> Get-UICulture
LCID Name DisplayName---- ---- -----------1033 en-US English (United States)
PS C:\> Get-DateTuesday, February 26, 2013 8:21:33 AM
I think you get the idea. Besides retrieving information, Windows PowerShell can perform actions. For this next part, there are different commands to try depending on the version of Windows you’re using.
PS C:\> Get-History
Id CommandLine-- -----------27 clear-history28 get-location29 get-uiculture30 get-date
You should see the list of commands you’ve previously typed.
Now, to clear the history:
PS C:\> Clear-HistoryPS C:\>
Now, if you do:
You should see:
PS C:\> Get-WindowsErrorReportingEnabled
In the last example, you saw that Windows Error Reporting was Enabled or Disabled. In my case, it was Enabled. Turns out, there’s a cmdlet that you can run which enables Windows Error Reporting and another that disables Windows Error Reporting. My computer had Windows Error Reporting turned on already, so I’ll turn it off by running the Disable-WindowsErrorReporting cmdlet. After I run the Disable-WindowsErrorReporting cmdlet, Windows PowerShell confirms the action by reporting “True”.
PS C:\> Disable-WindowsErrorReportingTruePS C:\>
Now, check the Windows Error Reporting status by using the “Get-WindowsErrorReporting” cmdlet.
PS C:\> Get-WindowsErrorReportingDisabledJust to clean up after myself, I’ll re-enable Windows Error Reporting.
PS C:\> Enable-WindowsErrorReportingTrue
So, there you go! You’ve done it! You’ve successfully run several Windows PowerShell cmdlets. Onward and upward!
Remember back to your last programming class where the instructor made you create variables? We’ll do that too, but with Windows PowerShell, you can stuff all kinds of data into a variable, not just text and numbers. But unlike your instructor, I promise not to make you do another "Hello World" application.
Again, I have some examples that are specific to Windows 7, WindowsServer 2008 and Windows 8, Windows Server 2012.
In the previous Windows 7 example, you saw how Get-Location returned the current path. We can have Windows PowerShell store the path information result in a variable for use later.
To store the result of our cmdlet, we first need a variable. Variables all start with a $. We could just call it “$a” but that’s not very descriptive, so we’ll call it: $MyPath. Go ahead and type that part in your PowerShell window.
PS C:\> Get-LocationC:\users\david
PS C:\> $MyPath
To assign the results from ourGet-Locationcmdlet, just say that your variable “=” the cmdlet.
PS C:\> $MyPath = Get-LocationPS C:\>
Now, to see the value of your variable, just type the variable name and press Enter.
PS C:\> $MyPathC:\users\david
In the previous Windows 8 example, you saw that the Get-WindowsErrorReporting cmdlet returned a value “Enabled” or “Disabled”. We can have Windows PowerShell store its result in a variable. To store the result of our cmdlet, we first need a variable. Variables all start with a $. We could just call it “$a” but that’s not very descriptive, so we’ll call it: $WERState. Go ahead and type that part in your PowerShell window.
PS C:\> $WERState
To assign the results from our Get-WindowsErrorReporting cmdlet, just say that your variable “=” the cmdlet.
PS C:\> $WERState = Get-WindowsErrorReportingPS C:\>
PS C:\> $WERStatePS C:\> Enabled
There are lots more things you can do with variables – but we’ve covered the most important one you’ll need as we go further with the blog series.
The last concept we'll cover here is the Module. All Windows PowerShell cmdlets are coded and stored in a module. The modules for Windows are available by default in your Windows PowerShell window and you can add more modules. You add modules to your Windows PowerShell session by importing them. We’ll cover importing in the next blog.
Now that we've covered these three basic concepts, I’ll let you explore a bit. The Show-Command cmdlet allows you to select from all the modules currently installed and browse the available cmdlets. Give it a try!
PS C:\> Show-Command
You can see – there are lots of different things you can do with Windows PowerShell. Thanks for hanging in there. It’s going to be fun! In the next blog, I’ll show you how to import the Configuration Manager module and retrieve information from your Configuration Manager site.
If you want to learn more of the basics, jump over to the PowerShell User’s Guide here: http://technet.microsoft.com/en-us/library/cc196356.aspx
This posting is provided "AS IS" with no warranties and confers no rights.
"We’ve finally introduced native Windows PowerShell support with System Center 2012 Configuration Manager SP1"
Does this mean the cmdlets that came with SP1 are now the final RTM cmdlets and not a pre-release version like has been stated repeatedly? If so, what is the new plan for the changes that were supposed to come with the RTM?
You're joking, right? If Windows PowerShell is a big ocean, you've provided us a teaspoon here. Better to just post links to to a couple of the better PowerShell textbooks out there.
I know you must cover the basics first, but I'm looking forward to read advanced feature of Powershell with Configuration Manager. I'm a huge Powershell fan and I recently installed my first CM site.
PowerShell in SCCM is a welcome addition.
Microsoft is rightly positioning PowerShell as a 'dev-ops' tool. (Who doesn't like scripting away some simple tasks?) But, often the CM scripts you see out there are very similar. You can usually find maintenance tools (delete old CM objects not found in AD) or bulk changes from a CSV file - collection members or variables - for example.
It might be a good idea to just look at all the scripts out on the Internet, then take the top 20 processes and implement them directly into the CM Console.
I think my suggestion is - since CM is a very powerful tool already, why not add simple, but clearly desired features directly to the Console instead of asking people to learn PowerShell? The new Console is really great, and Microsoft has already added nice features. Just keep going! (Maybe we should be able to manage Active Directory objects from the CM Console as well - keep integrating System Center into a single product :-))
On the other hand, any simple automation features - like PowerShell - are valuable to businesses. So, I do appreciate you taking the time to explain these current features.
Hi, yes the add-on of Powershell to CM12 SP1 is great. But a short question about one of the cmdlets. When I run get-CMSITEmaintenancetask -Sitecode CAS, the answer show for the maintenance setting a tasktype entry 1, 2 or 3. For what stay "tasktype"
thanks and regards
Thanks for the post. PowerShell availability is certainly great news! I look forward to future posts with tips and insights on using it with ConfigMgr.
There are however, a couple points of consternation.
In the Ready to get started? paragraph, you provide a link to the powershell 3.0 download and explicitly state that you need the 32 bit version with ConfigMgr. This made me think that I ought to select the 32 bit version for download but this is not necessary since the 64 bit will install the 32 bit version of the console as well. In fact, for Win 2008 R2, you must download the 64 bit because the 32 bit is not supported.
The second point of trouble came from reading the powershell download page (not sure why I was doing that). It states:
IMPORTANT: Windows Management Framework 3.0 is not currently compatible with the following applications:
System Center 2012 Configuration Manager. For more information, see KB 2796086.
Googling (excuse me, binging) either of the KB numbers in the download page results in dire warnings about installing this with ConfigMgr 2012. They say your server will blow up and end users' heads catch fire. This corroborates the download page and were I not in a test domain, this would have been the end of the line for me.
Some points of clarification to expressly address these issues would be nice. Another KB article or an edit of the download page would help as well.
This is great! Thank you! Can't wait for future blogs! Please keep this up!
@ZapB - My goal is to let people take 5-10 minutes once a week to get familiar with PowerShell & ConfigMgr integration. This post gives the minimum information needed by subsequent posts on the ConfigMgr module for those who have never used PowerShell. Do you have a favorite book or link you'd like to share for those getting started?
Great post Dave and looking forward to future posts in the series.
Thank you so much for the wonderful article.
Does it mean that, we can not create powershell scripts for SCCM 2012 if we don't have SP1 implemented.
I am asking this because in our current environment SP1 is not implemented and I want to create powershell scripts for current SCCM 2012 infrastructure.
Please suggest me on this.