• Upgrading Your Skills to MCSA Server 2012 – PowerShell V3.0 Part 1 (70-417)

    Posted on November 10, 2013 by in Latest News, Studying

    PowerShell…I’m sure we’ve all heard of PowerShell by now and most likely know it’s a scripting language of some sort…. Now as there is a fair amount I want to cover on PowerShell, I’ve decide to split the blogs into two parts, so in this part we are going to be looking at some of the PowerShell basics, with Part 2 covering managing Server 2012 with PowerShell as well as any new features.

    I guess we better start with the big question “What is PowerShell?”

    Well PowerShell is an object-based management environment. I’m sure many of you are familiar with VBscript and the likes, but PowerShell is more than just a simple command line to perform specific tasks. PowerShell can also manage Server Roles and Features, as well as being used to provision manage and report on various objects, directors and components.

    As an administrator what exactly does this enable me to do?

    Well quite simply some of the below:

    • Create automation scripts
    • Perform batch modifications
    • Access unavailable settings

    The final bullet point there “unavailable settings”, this is pretty much how I first came about using PowerShell.

    Going back to Exchange 2007, most of the tasks/maintenance I wanted to perform within an Exchange environment was simply not available to me from the GUI, which meant I had to take to the Exchange Command Shell (PowerShell).

    This allowed me access too many many features simply not available via the GUI.

    Actually speaking about the GUI, all the GUI is effectively doing is building the PowerShell script as you select different options, and then executes the final PowerShell command. Those of you familiar with Exchange 2010 will notice when you finish a task via the GUI, it provides you with the PowerShell output.

    This is not just Exchange, this is the same for Server 2012. Everything you do via the GUI is effectively just building a PowerShell script “underneath” which you can’t see. Once you click OK or Finish, it executes the script in the background.

    Let take a brief look at the PowerShell Syntax…

    Command-lets (cmdlets) are named with a verb-noun combination. For example:

    Verb Noun Cmdlet
    Get EventLog Get-EventLog
    Set ExecutionPolicy Set-ExecutionPolicy
    New VM New-VM

    You use cmdlet parameters to modify actions and provide configuration information.

    Parameters include:

    • Named:  -EventLog System, -UserName MichaelRiccioni
    In the above example I’m specifying the System EventLog, or the user MichaelRiccioni
    • Switch: -Verbose, -Debug, -Confirm
    In the above you are specifying a specific switch. For example -Confirm to be presented with a confirmation prompt.
    • Positional: Get-EventLog System, Get-EventLog –LogName System

    Both of the above would return the System EventLog.

    Now let’s look at Cmdlet Aliases….

    Some of the “built-in” aliases allow for backward comparability and you also most likely already know the commands. For example:

    • cd = Set-Location
    • dir = Get-Child-Item
    • ls = Get-Child-Item
    • copy = Copy-Item
    • kill = Stop-Process
    • rm = Remove-Item
    • type = Get-Content

    I’m sure we’ve all used the cd, dir, ls etc.. commands before, and they still work as they are set as Aliases.

    You can also create your own aliases, in this short and sweet example I will set Michael as an alias for get-date.

    Effectively I will be executing the following:

    • Get-Date
    • Set-Alias michael Get-Date
    • michael

    Very simple.

    Server 2012 comes with Microsoft’s latest PowerShell Integrated Scripting Environment (ISE).

    This is available as a download (previous versions), and can be access from the Server Manager.

    Upon launching the ISE you will notice down the right, pretty much every cmdlet you can think of (and is available).

    In the example below I run the simple cmdlet I ran above (Get-Date) and (Set-Alias), but the ISE is more than a “help” for PS cmdlets.

    If you select script on the right you now have an editor available for you.

    This means the ISE is now a one-stop shop for writing and executing PowerShell scripts.

    Select the Green Play button or press F5 to run the script

    Personally I always use the ISE if I need to write any PS scripts.

    Apart from the ISE, you can also use the built-in “Help” of PowerShell.

    You can access this at any time by simply running Get-Help

    As an example:

    • Get-Help Get-EventLog

    Get-Help also has different parameters to help adjust the amount of help you wish to be displayed.

    The parameters are:

    • -detailed
    • -examples
    • -full
    • -online  (checks online)
    Using the -detailed parameter:
    Using the -example parameter:

    As well as the above you can also use other cmdlets to help assist:

    • Update-Help
    • Show-Command
    • Get-Command
    • Tab completion

    “Tab completion” – What is this? Well simply put if you are typing out a command, you can press tab to “auto-complete”/”cycle through” a list of related commands.

    *Handy Tip* – Shift Tab scrolls back (only recently found this out!). Handy for if you are using tab to cycle through available commands and you accidentally go past the command you needed.

    The good thing about PowerShell is it’s not just limited to the Exchange environment, or basic Server environment. By importing other modules it allows you to then manage those via PowerShell

    For example:

    • Import-Module Hyper-V
    • Import-Module ActiveDirectory

    (No clues for guessing what the above import)… Of course these Roles need to be installed before you can import the module, so if you don’t have Hyper-V installed, guess what import-module Hyper-V won’t work.

    Get-Module allows you to see which modules are currently loaded, as in the example below i’m importing the Active Directory module.

    Finally in this blog i’m going to cover off PowerShell Remoting.

    As the name kind of suggests, it’s effectively allowing you to connect to a remote computer, run the command, and then bring the results back to your computer.

    The goals of Windows PowerShell remoting are:

    • Single-seat administration
    • Batch administration
    • Lightweight administration

    The three ways to use Windows PowerShell remoting are:

    • One-to-One remoting
    • One-to-Many (or Fan-Out) remoting
    • Many-to-One (or Fan-In) remoting

    You are most commonly going to use either a one to one, or one to many remoting.

    In the example below I am going to connect to MRSVR01 and return the system event log

    And that pretty much wraps up Part 1 for the basics, Part 2 will go on to cover the “new” features in PowerShell V3.0, as well as managing AD DS….

Protected by WP Anti Spam