Once we have our pull server in place and we’re starting to create configurations, we need to set up our client nodes to be able to connect to the pull server and how we want the node to behave.
The High Points
Examining the Local Configuration Manager
The Desired State Configuration agent included in Windows Management Framework 4 (or natively on Server 2012 R2 / Windows 8.1) is exposed through the Local Configuration Manager.
Attention Microsoft training centers! Microsoft’s Courseware Marketplace now offers course 55039AC, “Windows PowerShell Scripting and Toolmaking.” Designed as a 5-day course, it’s a spiritual “Part 2” to Microsoft Official Curriculum course 10961.
With 10961, the goal was to provide a founding in PowerShell basics, in a somewhat product-neutral way. That is, the course doesn’t cover Exchange, or SharePoint, or AD; it focuses on pure PowerShell. Unlike its predecessor, 10325, the 10961 course kind of “stops short” of actual scripting. It shows you how to build a parameterized script, but doesn’t dig into advanced functions, debugging, error handling, and the like. There was a feeling - which has been largely upheld through customer feedback - that a sizable audience needed to get the shell basics under their belt, and weren’t necessarily comfortable leaping into coding. 10325 kind of breezed through scripting at a somewhat high level, and didn’t have time to offer much in the way of practices and other guidance, and it didn’t really set you up for building reusable units of automation.
That’s where 55039AC comes in. It is a scripting class, pure and simple, and it focuses on building reusable units of automation according to best practices and patterns. More time is devoted to design, structure, procedural error handling, and so on. There’s also deeper coverage of module building, including building custom formatting views, and there’s even an introduction to Workflow. Although designed for v3, the course is pretty version-agnostic, meaning it’s suitable for someone who wants to use PowerShell v2, v3, or beyond. And, because it’s a Courseware Marketplace offering, it’s compatible with Software Assurance (SA) training vouchers.
Training centers are welcome to combine 10961 and 55039 to create an “accelerated” class that includes heavier scripting coverage than 10961 alone. I do that myself, actually, although it’s a pretty hardcore week. If you’re interested in doing that, contact me and I can provide some of the accelerated-delivery outlines that I use.
55039’s modules are all standalone - with a twist. Students are encouraged to use and evolve a single code project throughout several modules. However, if you’re not teaching all of the modules, or if a student falls behind, each lab comes with a complete “starting point” that keeps everyone on the same page.
55039 has already been beta-taught, and of course I welcome feedback if you’ve taught the course or taken it as a student.
My company also offers licensing for this course outside the Courseware Marketplace, mainly geared to training centers who want an unlimited perpetual license to reproduce the course materials on their own. We know courseware costs are a significant concern, so we’re trying to offer something reasonable there.
Both 10961 and 55039 (or at least a subset of 55039; we’re still working on exactly what) will be considered pre-requisites for the upcoming 3-day 10962 course, which will focus on advanced PowerShell techniques for us in production environments, including database connectivity, report generation, and so on.
Well, it isn’t your enemy, of course, but it’s definitely a tricky little beast.
Get-Content is quickly becoming my nemesis, because it’s sucking a lot of PowerShell newcomers into its insidious little trap. Actually, the real problem is that most newcomers don’t really understand that PowerShell is an object-oriented, rather than a text-oriented shell; they’re trying to treat Get-Content like the old Type command (and why not? type is an alias to Get-Content in PowerShell, isn’t it?), and failing.
Worse, PowerShell has just enough under-the-hood smarts to make some things work, but not _everything. _
For example, this works to replace all instances of “t” with “x” in the file test.txt, outputting the result to new.txt:
One thing that’s often very confusing about PowerShell is the difference between the shell itself - what I’ll call the engine in this article - and the application that hosts the engine.
You see, you as a human being can’t really interact directly with PowerShell’s engine. Instead, you need a host application that lets you do so. The standard console - PowerShell.exe - is one such host; the Integrated Script Environment (ISE) is another. Those hosts “spin up” a _runspace, _which is essentially an instance of the PowerShell engine. When you type a command and hit enter, the host creates a pipeline, jams your command into it, and then deals with the output.
A number of standardized PowerShell commands actually require the host to implement some kind of command support. For example, most of the core Write- cmdlets actually depend upon the host to do something. Write-Verbose is a great example: The command causes the engine to spew text into the Verbose pipeline; the host is responsible for doing something with it. In the case of the console host, the Verbose text is displayed as yellow text (by default) preceded by the word “VERBOSE:”.
When you develop a script using the ISE or the console (which behave pretty similarly for most of the core commands), you get used to your script behaving in a certain way. If you then move that script over to another host - perhaps a runbook automation system that runs PowerShell scripts by hosting the engine, rather than by launching PowerShell.exe - you may get entirely different behavior.
Here’s a perfect example: most of the “built-in” variables you’re used to working with in the ISE or the console aren’t actually built into the _engine, _they’re built into those _hosts. _For example, since the host is responsible for presenting verbose output, the host is what creates and uses the $VerbosePreference variable. When your script is running in a different host, $VerbosePreference may not exist, and indeed verbose output may simply be ignored. An off-the-shelf PowerShell runspace doesn’t actually come with very much “built-in” at all, so scripts can behave very differently.
It’s pretty important to understand these potential differences. When a developer sets out to create their own host application - like most of the commercial script editors do - it can be very confusing and frustrating, because they essentially have to reverse-engineer much of what the PowerShell.exe console application is doing, so that they can provide an equivalent experience. But you should never assume that a script’s behavior under one host will be consistent in all other hosts; test and verify.
So, I got hold of one of the Summit planning spreadsheets and have the list of speaker names. Now, these folks haven’t yet confirmed, so there are obviously possible changes, but here’s who’ll be invited based on their proposals:
- Augh, they caught me! The complete session list isn’t yet finalized, and there are a few on the “final cut list” that may not actually physically fit, so stay tuned…
Lotta Jasons in there. Hmm, maybe I shouldn’t put Helmick in charge of this again. He appears to be partial. There’s also several slots for PowerShell product team members that haven’t yet been sorted; they may come in a bit closer to the show, once the team has a better grip on their short-term work schedule.
That’s about 63 sessions total. Wow. We’re planning to run continuous sessions from 9am to noon, and then from 1pm to 5pm every day, spread across three tracks. There’ll also be welcome address at 8:15am Monday morning.
Please - tell a colleague. Help us get the word out, because this is going to be _amazing. _
PowerShell DSC, along with Windows Server 2012 R2 has reached General Availability! Yay!
However, there is (at least one so far) breaking change** **in Desired State Configuration (DSC).
Fortunately, the change is in an area I haven’t blogged about yet.. creating custom resources. Unfortunately, it does mean I’ll have to update the GitHub repository and all my internal content (should be done by early next week).
The short version is that DSC resources are now resources inside modules, rather than each resource being independent modules. The benefit of this is that now DSC resources won’t pollute the module scope, each resource won’t need its own psd1 file (the source module will require one though), and it provides an easier way to group resources, which wasn’t really possible before.
So, with GA, resources should go under the module root in a folder DSCResources. You can have one or more resources in one PowerShell module. The PowerShell module version is what will be used for the resource version number, so if you have several resources, a version number bump affects all the resources in the module.
I’ll be picking back up with the DSC series next week with how to configure DSC clients, so stay tuned.
I’m looking to hear from folks who attended the PowerShell Summit North America 2013. Specifically, I’d love to hear what you thought of it. What value did you get? If someone were considering attending in 2014, what advice would you offer them? How should they approach the boss? What did you, personally, “take home” from the Summit in the way of new information or skills?
Drop a comment below. Some comments might be re-published as standalone posts as we try to help people understand what the Summit is all about, and why they might want to attend. Thanks!
Ok, that post title is deliberately provocative. Twitter and all that.
So look, we’re designed this advanced PowerShell class. One of the top five constant suggestions I get whenever I say “advanced” and “PowerShell” is “.NET Framework.”
And I get it. When there’s no cmdlet, .NET has a ton of goodies that can solve a lot of problems. Maybe you don’t like turning to it, but you’ll do it if you have to.
My problem is, what’s that look like in a class?
I mean, for me, using .NET basically works like this:
As we continue collecting responses to an outline survey about an Advanced PowerShell class, I’ve come up with a couple of questions and would appreciate any feedback you’d care to leave here.
Keep in mind that we’re a bit bound by this course being Microsoft Official Curriculum. I gotta make sure, in other words, that the average MCT can teach it. Ahem. I also have to face facts that people don’t read or obey course pre-requisite suggestions, and that a lot of people taking the course will have zero programming background.
Ok, let’s get back to creating a DSC configuration. If you haven’t read the last post in this series, go back and do that now, I’ll wait. Now with that out of the way, let’s get back to it…
The High Points
Picking Back UP
Now that we have some of the basics down, we can start to look deeper at how composable these configurations are. A DSC configuration defined in PowerShell offers several advantages, not the least of which is that a configuration can be parameterized.
