Powershell Basics
Published Oct 16 2018 05:13 PM 990 Views
Microsoft
First published on CLOUDBLOGS on Mar 13, 2013

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.


The Cmdlet


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-Date
Tuesday, 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.


For all versions of Windows and Windows Server


PS C:> Get-Location


Path


----


C:usersdavid


PS C:> Get-History


Id CommandLine
-- -----------
27 clear-history
28 get-location
29 get-uiculture
30 get-date


You should see the list of commands you’ve previously typed.


Now, to clear the history:


PS C:> Clear-History
PS C:>


Now, if you do:


PS C:> Get-History


You should see:


Id CommandLine


-- -----------


4 clear-history


For Windows 8 and Windows Server 2012 Users


PS C:> Get-WindowsErrorReporting
Enabled


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-WindowsErrorReporting
True
PS C:>


Now, check the Windows Error Reporting status by using the “Get-WindowsErrorReporting” cmdlet.


PS C:> Get-WindowsErrorReporting
Disabled

Just to clean up after myself, I’ll re-enable Windows Error Reporting.


PS C:> Enable-WindowsErrorReporting
True


So, there you go!  You’ve done it!  You’ve successfully run several Windows PowerShell cmdlets.  Onward and upward!


The Variable


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.


For Windows 7 and Windows Server 2008 Users


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-Location
C:usersdavid


PS C:> $MyPath


To assign the results from ourGet-Locationcmdlet, just say that your variable “=” the cmdlet.


PS C:> $MyPath = Get-Location
PS C:>


Now, to see the value of your variable, just type the variable name and press Enter.


PS C:> $MyPath
C:usersdavid


For Windows 8 and Windows Server 2012 Users


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-WindowsErrorReporting
PS C:>


Now, to see the value of your variable, just type the variable name and press Enter.


PS C:> $WERState
PS 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 Module


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


-- Dave Randall


This posting is provided "AS IS" with no warranties and confers no rights.


Version history
Last update:
‎Oct 16 2018 05:13 PM
Updated by: