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

    Posted on November 17, 2013 by in Certifications, Latest News, Studying

    Well firstly, thank for the great feedback I’ve had from PowerShell Part 1  - It’s quite clearly a topic of interest for many people, and having been on the Exchange 2013 course this week it’s something I’m going to be covering again when I get round to the study blogs for Exchange 2013 as that is non-stop PowerShell!

    Anyway, let’s crack on with Part 2 of PowerShell V3.0 where I’ll be looking at new feature’s  of V3.0 as well as managing Server 2012 using PowerShell.

    Quick over view first of the improvements which come with V3.0 over V2.0

    • More than 260 core cmdlets
    • Management of all Windows Roles and Features
    • Windows PowerShell Workflow
    • Windows PowerShell Web Access
    • Scheduled Jobs
    • Enhanced Online Help
    • ISE IntelliSense
    • Robust Session Connectivity

    This means that within Server 2012 we now have over 130 cmdlets for managing Active Directory, such as:

    • Computer Accounts
    • User Accounts
    • Service Accounts
    • Groups
    • Organizational Units
    • Replication
    • Trusts
    • Central Access Policies
    • Password Polices

    So who really need’s a GUI anymore!? – only kidding, I realise most people are comfortable with managing objects via AD Users and computers, and managing those objects via PS may at first be daunting but it’s like anything, the more you do it the more natural it becomes.  Going back to the course I was on this week, it’s still very apparent as soon as you mentioned “PowerShell” most administrators would like to run a mile….

    Anyway, back to the good stuff…

    PowerShell as we know (and most people) is a good way for pulling out reports/data we require. But PS also enables us to retrieve, modify and filter the data from many different sources.

    As an example, wouldn’t it be great if you could “GET” all the members of a security group, and then modify the description field for each user? Well with PS you can.

    This is what “variables” are. Variables are used to store and retrieve data in memory during a PS Session.

    A variable will always being with a dollar sign ($) and can then be named with descriptive text or numbers such as $variable1, $michael, $memberlist etc..

    There are two ways to declare a variable, the first is to use the  Set-Variable cmdlet

    Set-Variable -Name MichaelADDS -Value (Get-ADDomain)

    If we then issue $MichaelADDS we get the output from Get-ADDomain

    The second method is the same method we used to define aliases (in Part 1 of PS).

    $MichaelADDS2 = Get-ADDomain

    Again if we issue $MichaelADDS2 we get the same output

    Now we have this defined, we can also obtain further properties about ADDS. For example to find out the domain functional level we can issue the following:

    $MichaelADDS.DomainMode (which returns our current domain mode)

    You can Also access methods or actions from a variable, as an example if I wanted to determine the base type of what $MichaelADDS was, I could use GetType() (which is a method) and issue the following command:


    I can now see the variable $MichaelADDS is assigned to the AD DS Managment object.

    Just to go back to the term “method” as mentioned in the above example, If you use a Method you must follow the method with () to indicate that it is a method and not a property. A method is simply a way of being able to examine, compare or format many properties of a PowerShell object.

    Turning our attention to variables, let’s turn PowerShell in to a calculator for a moment…

    We are going to define two variables: $A as 10, and $B as 7, then add them both together

    Quick word to the wise – When you use variables in calculations ensure they are typed correctly, because like all things if you type the wrong value you are going to get unexpected results!

    E.g. – If I issue the same as above but this time make the numbers 10 and 7 enclosed in brackets, what do you think the result will be?

    You can see rather than adding the two numbers numerically, it simply adds the numbers together in a combined sense, so just watch out for that in the future…


    I’m now going to explain a little about the PowerShell Pipeline. (I did try to search for a good diagram but struggled, so bear with me on the diagram below!)

    The above shows an example you may want to use, whereby you take the output from one cmdlet and pass it to another cmdlet for additional actions.

    In the above example, we could use the Get-ADUser and pass this to another cmdlet Enable-ADAccount 

    This would allow us to issue the below to enable ALL AD users

    Get-ADuser -Filter * | Enable-ADAccount

    Notice the “|” this is the PIPE. (As you become more familiar with PS you will use this regularly to PIPE values out to formatted lists (| FL) or formatted table (| FT))

    Piping can be used extensively in PS which allows us to write more complex commands.

    For example let’s take the above where we enabled all users account:

    Get-ADUser -Filter * | Where-Object {$_.Enabled -eq $false} | Enable-ADAccount

    Obviously you would not run that on your own production environment, and it fails anyway as shown below, due to the built-in users.

    In your own environment you would be much more likley to issue the following command:

    Command: Get-ADUser -Filter * -SearchBase “ou=Michael,dc=riccioni,dc=ad” | Where-Object {$_.Enabled -eq $false} | Enable-ADAccount

    Explanation: Get the ADUser, Filter * (everything), Search the OU Michael, Pipe these results, and any accounts which are disabled (enabled=false) Pipe these results to the next cmdlet which enables them.

    By piping an object with a list of all users from that OU we can then use the Where-Object cmdlet to filter the accounts that are disabled base on the enabled property of the account.


    So you now understand PowerShell a little, and you want to start trying this out and creating/running your own scripts…Well this brings me on to the next topic, creating and running PS Scripts.

    What exactly is a PS script? Quite simply it’s a text based file that includes at least one Windows PowerShell Command, and is this saved with the .PS1 file extension.

    You also need to consider the execution policy you are going to use. By default the execution policy does not enable PS scripts to be executed automatically. This is purely a safety net, so scripts the administrator is unaware of can’t be run.

    The execution policies are:

    • Restricted (Default)
    • AllSigned – Requires all scripts to be signed by a trusted publisher
    • RemoteSigned – Requires all scripts that are downloaded from the internet to be signed by a trusted publisher
    • Unrestricted – As the name suggests.. It’s a free for all
    • Bypass – Exactly the same as the above, except in the above if you run a downloaded script it will warn you, when in Bypass mode it won’t even warn you..

    As you can see I’m currently running in “Restricted” mode (Get-ExecutionPolicy)

    If I try to run a script (to run a script browse the directory and type ./<PS file name>)

    You can see the script won’t run, as it’s being blocked. Let’s take a look at the script quickly

    Nothing major going on there, but in order to allow me to run this script I would need to change the setting to unrestricted (which let’s face it you don’t really want to do in your production environment do you!) – But if you wanted to take the easy way out (and show you that it works…See below….)

    I’m going to set the execution policy to “AllSigned”.

    You will see I still can’t run it, as I have to sign the PS Script. Let’s get this signed (I won’t cover signing scripts as that’s a blog in itself and you also don’t need to know it for the exam!).

    But as you’ll see at the end of my script (now it’s been signed) I now have a massive text block

    And if I now attempt to run the same script, it should now let me…

    Now let’s move on to managing servers using PS 3.0 (as I could go on and on about PS but I’ll save it for later blogs)

    At the end of the day why should you use Windows PowerShell for server management?

    Well it can make life easier, for example:

    • Automate configuration tasks to reduce error and perform tasks faster.
    • To configure servers that have Windows Server Core, which do not have a graphical user interface.
    • To remotely configure servers through remote Windows PowerShell instead of having to sign in by using a Remote Desktop connection or locally installed management tools.

    Which opens us up to the question what tasks will you use Windows PowerShell to perform?

    Many of you I’m sure will use it for simplifying deployment of new Windows Server computers, or for provisioning and managing users (in bulk) or single accounts, and of course for creating reports.

    And to make your lives EVEN easier, this has to be my favourite new feature….I bring you PowerShell Web Access.

    What’s that? – Well you know OWA (Outlook web access), we now have the ability to login to a PS prompt from any browser in the world!

    Once your security team has finished picking themselves up off the floor, it can of course be locked down with all the usual security gubbins as you’d expect, but you can effectively administer your infrastructure using PowerShell from any computer, tablet, smart phone in the world….

    How do we go about doing this? Well we need to install the features first..

    We also need to create an IIS website for Remote PowerShell

    Finally by DEFAULT no one will be able to use this, until you assign a remote PS authorization rule.

    Add-PswaAuthorizationRule -UserName riccioni\Administrator -ComputerName MRDC01.riccioni.ad -ConfigurationName *

    The above example is allowing the administrator access..

    If we now browse to http://mrdc01/pswa you are presented with a logon screen

    Enter in the administrator credentials

    And we’re in!…

    Everyone is going to have their own view on remote PS but personally if it’s locked down correctly I can only see benefits of having this feature available to you.


    Finally (yes we are nearly done!) I’m going to cover PowerShell Jobs. No these don’t pay the mortgage i’m afraid…and PowerShell Workflow.

    PowerShell jobs can be summed up as:

    Background Jobs:

    • Enable extended tasks to be performed in the background
    • Perform tasks on a number of remote servers

    Scheduled Jobs:

    • Registered background jobs that can run on a schedule
    • Triggers that are created to define schedule

    They basically allow for a set of commands or a single command to be run without interacting with the current PS session.

    You can start a background job by using the Start-Job cmdlet, this allows you to continue to work in the session.

    It’s a way of making it easier/more helpful to you if something is going to take a long time to complete. You can kick off the job, then continue to work on something different in the same PS sessions.

    Other cmdlets you will use are Get-Job (for viewing the status of the current job) and the Remove-Job for removing the job. Likewise if you have a job running in the background which outputs data to the console you can view this output by using the Receive-job cmdlet.

    Likewise you can also schedule a job. These are used by using the Register-ScheduledJob cmdlet. As an example if we use the last logon script above we would issue the following:

    Register-ScheduledJob -Name MRLastLogonJob -FilePath \\mrdc01\scripts\Lastlogon.ps1

    To enable this scheduled job we have to define either a schedule or a trigger. Triggers are created by using New-JobTrigger, (or for existing jobs Add-JobTrigger) if you wish to add to the already defined trigger.

    Triggers can be scheduled just like the familiar scheduled tasks.  Once a day, once a week, only Monday – Wednesday @ 10am.

    In the example below we are going to schedule this job to run at 4:30PM on a Sunday, You will notice we are combining a number of items discussed in this blog (defining a variable for example):

    $MRTrigger = New-JobTrigger -Weekly -DaysOfWeek Monday,Friday,Sunday -At 04:30PM
    Register-ScheduledJob -Name MRScheduledLastestLogon -FilePath \\MRDC01\Scripts\LatestLogon.ps1 -Trigger $MRTrigger

    If we view the Scheduled Job’s (both examples above)

    If you issue $MRTrigger you will also view the details for the scheduled job

    You don’t have to use a .ps1 file when scheduling a job either, in the example below we will schedule another job (to get all ADUsers) but this time by simply defining the cmdlet as a script block. When this then run’s it simply calls the script block.

    First let’s start a new job:

    Start-Job -ScriptBlock {Get-ADUser –Filter *}

    We can view the status by issuing “Get-Job

    As you can see this has now completed. But what we really want to do is schedule this to run every Monday/Wednesday/Friday @ 3:00am

    $GETUSERTrigger = New-JobTrigger –Weekly –DaysOfWeek Monday,Wednesday,Friday –At 03:00AM
    Register-ScheduledJob –Name ScheduledJob1 –ScriptBlock {Get-ADUser –Filter * } -Trigger $GETUSERTrigger

    And there we have another scheduled job…BUT what happens if we want to kick this off now? Well simply use the Start-Job cmdlet…

    The job is now running.

    I suppose I best just cover off how you view the job!… I did mention above that you would simply issue Receive-Job cmdlet

    And there we have the results displayed to the console.


    Finally, and I mean finally I’m going to cover off PS Workflows.

    PowerShell workflow:

    • Enables automating long-running and complex activities
    • Enables automating multiple server management and application provisioning
    • Enables processes to be resumed, paused, and restarted
    • Are created by using Windows PowerShell or Visual Studio Workflow Designer

    Note: Windows Server 2012 includes over 60 predefined workflows.

    Why use a workflow? Well it’s simple, if you are building out a new server (in this example a Remote Desktop Gateway Server). Windows has a built in workflow Add-RDGatewayServer

    This specific workflow will then configure the server (or specified servers) as Remote Desktop Gateway Server’s.

    This allows for easy configuration / building out of specific types of servers.

    When using workflows, commands can be performed in either parallel a sequenced manner. For example:

    Workflow running commands in Parallel (so it doesn’t matter which order they are executed in)

    Get-ADUser -Filter *

    Or sequenced:

    Set-ADUser Michael -Description “Test Account”
    Get-ADUser Michael -Properties Description

    In the above examples, you can see the Parallel process it doesn’t matter if we get the running processes first or if we get all the AD Users, however in the second example we want to first update the description field before getting the properties of it.

    And that wraps up this blog. Fairly intensive blog this one with a lot going on and a lot to get your head round, but PS is no different to any other scripting language…The more you use it the easier it becomes!



Protected by WP Anti Spam