TechEd NZ: Windows Server 2012 PowerShell Crash Course

I was fortunate enough to be asked to present at TechEd NZ this year. I had a standing-room only room (Yay!), and a really good response from the crowd.

All the sessions that were recorded at TechEd NZ 2012 are now available.

And here’s my session:

Windows Server 2012 PowerShell Crash Course

Enjoy!

Advertisements

PowerShell 3.0 Workflow Basics

There are lots of new features and functionality in PowerShell 3.0, a brief overview of them found here: http://technet.microsoft.com/en-us/library/hh857339

One of the features that I find most exciting is the new scripting construct, Workflow. If you are familiar with creating a custom Function in PowerShell, then you know most of what you need to know about creating a workflow.

So what’s the difference?  The difference is that when you creating a new command using “Workflow” instead of “Function” in a script, the new command has access to a built-in library of common management parameters, such as PSComputerName, which enable multi-computer management scenarios.  This will make your scripts more powerful, and can be developed in a much simpler fashion.

Below you can see a very basic Workflow that I’ve created and saved on a member server in a domain.

As you can see, the Workflow itself is very basic, doing nothing more than gathering information about the powershell environment and writing it out to a text file that will site on the root of the C: drive. In reality this would need a lot more work, as it assumes that PowerShell is running, which is not a safe assumption if you’re getting this to execute on remote machines.  But ignore that, and assume that you do have a powershell console open on your remote machine.

I could have done the exact same thing with “Function” and it would work just fine on the local machine in which I ran the script.

However,  a look at the help for Get-PowerInfo reveals a host of parameters that are built in to the workflow.

Of immediate interest is -PSComputerName.  This parameter allows the code to run on remote machines (running PowerShell 3.0 and w/ remoting enabled) without me having to specifically add code to the workflow to manage remote sessions or import modules etc.

You can see that my workflow executes successfully, and when I go look at the C: drive on jfin-dc, the output text file has been created.

Obviously, a very simple use (and not all that practical in an of itself), but hopefully you can see that there is a great deal of power in this new Workflow construct in PowerShell 3.0.  As a scripting administrator, I can see how this will make my remote management scripts more powerful and easier to write.