Planning the PowerShell Summit North America 2014

We’re already planning for the 2014 Summit… you have to get way out in front of these things to secure space, plan a budget, and more.
Here’s what we know:

We’ll definitely still be in the Seattle metro area. That’s the best way to ensure participation from the PowerShell team, since it doesn’t require them to leave town for days at a time.

• We’ll be in April 2014. We’re going to try for April 14-16 to avoid Easter, or April 28-30.
• We’ll be in a bigger venue. We hope to support a crowd of up to 300, although we’re still aiming for a smaller group. That’ll give us more flexibility in session planning, along with the possibility of on-site evening events.
• We will open up early bird ticketing for 2013 alumni the week of April 29-May 3. 50 tickets will be available. If there are any of those tickets left after May 3, they’ll be offered to the public May 6 through 10. Any remaining early bird tickets will be converted to full-price tickets after May 10, when general sales will begin. Early bird pricing will be in the $650 range. Full pricing will be around $850. This is more than 2013, but will help us (a) fully reimburse speaker travel expenses, which we couldn’t do in 2013, (b) pay for the larger conference venue, (c) offer a full hot breakfast every day and beverages throughout the day, and (d) allow for bussing to the event venue (see below). Early Bird tickets will be fully refundable until the end of 2013.
• We are going to try and hold a percentage of our full-price tickets for release in January 2014. That way, people who can’t get budget until the year-of will still have a shot at tickets. This will be a small block of tickets, though - probably less than 30 - so if you can get budget to buy your tickets in 2013, do it.
• We will offer bussing from one hotel complex to the event venue in the mornings, with return busses at night. It will be crucial that you book your hotel as soon as possible once we announce, so that you can lock in a room. This can help eliminate the need for a rental car, and lower your trip expenses. At least one hotel option at around $100-$110 a night will be offered, although it may be a limited room block. For folks in the US, you should be able to attend for about $2,000 including air, hotel, and registration. Add in dinners (which we don’t provide) and you should be able to attend for under $2500 including expenses. Not bad!

As you can see, we’re still trying to keep things as affordable and accessible as possible, in keeping with the nature of a community-owned event. We’re also trying to build this event into one that can support itself and continue to grow.
I know a lot of folks who wanted to come in 2013 missed out… so that’s why I’m giving you as much heads-up as possible. Start getting the boss on board. Get purchasing on board. Start planning to have the credit card ready in April 2013. We’ll get as many folks as we can into the 2014 Summit!

Writing 10961A: The Damn Variables

When I wrote Microsoft course 10325A, their original 5-day Windows PowerShell course, I saved variables until Module 11. My thought at the time was to focus on teaching just what students needed for what they were about to do - and no more. “Just in time learning” can be effective, because it lets you immediately experiment with whatever you’ve just learned, and helps minimize the need to store up concepts for later use. I’d also had a lot of class experiences where bringing up variables too soon engaged a defensive mechanism in some students: “I’m not a programmer, variables are programming, and I’m shutting down right now.”
The biggest piece of MCT feedback from 10325A was, “don’t do that.” Trainers told me they were often teaching module 11 much sooner. Jeff Hicks had what I think is the best explanation for why: Without variables, you’re locked into the one-liner approach in PowerShell. While one-liners are neat, and effective, they aren’t always easy to read or to mentally de-construct. Using variables earlier in the course, Jeff argued, let you break things down into smaller logical chunks.
Now, one thing I’ve had to accept in writing 10961A is that I can’t please everyone. The feedback on 10325A is incredibly contradictory. Some MCTs want more programming, others want none at all. Some want classes to run 9am-4pm; others want 8am-6pm. Some want less content on the slides (actually, most wanted that). So what I decided to do is try and provide the material to accommodate what it felt like everyone was asking for, and rely on MCT’s ability to mix things up as needed for their classes.
(As an aside, I do think some MCTs jump into the “programming” aspect of PowerShell too quickly. It’s fine if you’ve got a room of people with programming experience, but it keeps students from learning some valuable fundamentals and turns the class into a “scripting” class awfully quickly. I’m not sure every MCT has done a really thorough cognitive analysis of their class results to determine if the programming-first approach is best; my experience with Month of Lunches readers suggest it isn’t.)
But I still didn’t want to do the full deep-dive on variables super-early in the course. So here’s what I think I’m doing: early in the course, you’ll be exposed to variables, in a very simplistic sense. They’re described as a named place to store objects, and used to de-construct a complex one-liner into a multi-line series of logical steps. Early in the course, I don’t go into naming rules, the double quotes tricks, or anything else. You learn exactly enough about variables for the task at hand - and no more.
In module 7, which is right before the module where you turn a command-line into a parameterized script, I cover variables more formally. I cover their rules, usage, double quotes, all that stuff. So you learn a wee bit about variables early, and then learn the full details later - just before you need to use variables more seriously in a script. So, keeping with the just-in-time learning.
The variables material is broken out into its own lesson in module 7, so an MCT hell-bent on teaching everything about variables right up-front can do so.While the feedback from 10325A suggests that MCTs think every course should be designed for the way they teach, I’m not sure they all realize how differently they all teach. The best I can do is provide the material in standalone chunks that MCTs can rearrange as needed. After all, the whole point of having a live instructor, as opposed to a recording, is the instructor’s ability to teach to your specific needs. So MCTs will have to be happy rearranging the material a bit as-needed; my outline is the recommnded approach that will work best across the broadest array of students, but it isn’t perfect for everyone. Nothing could be.
As a point of reference, 10961A doesn’t dive into scripting as deeply as 10325A did. PowerShell 3.0 has enough new, extra stuff that a 5-day course doesn’t allow for deep programming topics. You do take a command and walk it through to being a script module, so you see the range of scripting options, but you don’t practice them in depth. It’s inch-deep, mile-wide coverage of scripting, as opposed to something deeper and more focused. I’m hoping Microsoft can find budget for a full-on “scripting/toolmaking” class in the future, but 10961A ain’t it.
So… what do you think of this approach?

3 Updated Free PowerShell eBooks in January 2013!

I’ve been working to update my three free PowerShell ebooks for this month:

• Secrets of PowerShell Remoting
• Creating HTML Reports in PowerShell
• Making Historical and Trend Reports in PowerShell

The updated versions will be made available to subscribers of the PowerShell.org TechLetter on January 15th. If you’re not already signed up to receive this, you can [sign up right now][1]. The January issue will also feature a walkthrough article of how I started creating a new, better ConvertTo-HTML command, which gets used in the ebook on HTML reporting. Going forward, I’ll be making updated ebooks available primarily through the TechLetter.
If you’re not a subscriber and don’t want to be, well fine. I’ll just take my ball and go play in someone else’s sandbox. Kidding . I’ll post the updates at the end of January. However, right now access to the books still requires a subscription to the newsletter, although you can immediately unsubscribe if you want to. I had to put that “hurdle” in the way because we were losing a ton of bandwidth to people direct-linking the download files. Mostly from China, for some reason. You’re welcome to host the files on your own server, if you want to (they’re licensed for that), but bandwidth costs me money, so I’m trying to conserve a bit.
Anyway, keep an eye out for the TechLetter in your inbox on Jan 15th. Check those spam filters, and make sure newsletter@powershell.org is in your address book, so that your mail server will know it’s a legitimate sender.

Writing 10961: Trademarks

Microsoft’s a big company, and that makes it a big target for lawsuits. We all know that. But what doesn’t always sink in is how careful the company has to be.
For example, in Microsoft Official Curriculum course 10961, Automating Administration with Windows PowerShell 3.0, I have to type Windows PowerShell every single time. I’ve actually been using “the shell” a lot, just to break things up a bit. We all casually refer to the shell as PowerShell, but Microsoft never does. Their trademark is on Windows PowerShell, and believe it or not someone has a trademark on PowerShell. I think it’s a sporting equipment manufacturer.
As I’m writing the course, I started using Windows PowerShell on first reference, and then naturally - for me, at least - used just PowerShell from then on. Nope. Had to go fix ’em all.
Weird, huh?
I mean, technically… legally… you don’t trademark an entire word. You trademark it for use in a particular field. So it’s theoretically possible for Microsoft to own the trademark PowerShell in the world of computer software, and another company to own the same trademark for making backpacks or ski boots or whatever. But… I get it. You gotta be careful, and it’s easier just to not overlap with someone else’s trademark.
Maybe they should have named it FrabulouShellâ„¢ instead, just to be really sure.

Writing 10961: First Module in For Review

Microsoft course 10961, which will be a 5-day course on PowerShell 3.0, is officially in development! We received signoff on the outline this week, and I’ve submitted a first module for review. A big part of that review is making sure I’m using the template properly, as the authoring tool is fairly complex. It does, however, offer (more-or-less) one-touch publishing of the student manual, instructor slide deck, OneNote trainer pack, Lab Answer Key, and other documents, so it’s worth a bit of complexity.
The outline process, along with the actual details of the writing, has been challenging. I pored through the feedback for 10325A, and the only consistent thing I took away was a general feeling that students and instructors worldwide are really, really different!
Some European instructors cautioned against running class longer than 3 or 4pm. US instructors pointed out that a short day ending at 3pm often left students feeling shortchanged. Er. To try and accommodate both crowds, most days in 10961A will end in a significant lab, letting folks kind of free-form the end of the day however they want.
Many folks pointed out that they liked to get into variables early in the course, not so much for scripting purposes but to simplify command-line stuff. Other instructors suggested I avoid variables too early, since they created the impression of a programming course, which scared off some students. Again… er. So I’m officially waffling on that one: I don’t formally cover variables until fairly late in the course (well, midway), but I introduce them quite early. It means students can potentially see and use variables on day 1, although I don’t get into all the details about how they work, naming rules, and so on. The way I’m writing them in, instructors also have the option to just gloss over them or skip them entirely if their students aren’t ready.
I asked a few MCTs to look over some of my draft material and give me a delivery time estimate. I had pacing ranging from 2 minutes per slide to almost 8. Er. So I’m going with fairly simple slides that have minimal bullets (always, in most folks’ opinion, the right thing to do). Instructors can then decide how deeply they’ll cover the material based on their class’ needs. It does mean the instructor will need to be familiar with the material in advance - this will be a tough course to just pick up and teach ad-hoc. As, I believe, it should be.
If there’s a theme here, it’s that you need a good instructor teaching you. As a courseware author, all I can really do is provide raw material, and an instructional design that leads most students through a sensible learning progression. But the instructor’s value-add is to be able to switch things up to meet the specific needs of their class. Every time an instructor tells me, “oh, I always move Module 11 to the second day of class,” I don’t take it as a sign of bad instructional design - I take it as the sign of a good instructor who hopefully is making the change to benefit his class. But classes vary widely, and I kind of have to write for the worst-case scenario. That can sometimes make a course seem overly timid - but that’s why the instructor is there, to add their own value, experience, examples, and demonstrations to further instruct and clarify.
So the one thing I’m keeping in mind as I write 10961 is to leave room for the instructor to shine. Don’t fill the course so full of information that the instructor has no wiggle room. Give the instructor the ability to go slowly and less deep for classes that need it, and to go faster and deeper for classes that need that. Provide instructors with notes on what can be skipped if necessary, and what’s absolutely critical, so that they can triage. I’ll be doing a prep video to help provide even more context to instructors in that regard, and to let them know that customizing the delivery is absolutely okay, provided they’re doing so with an understanding of the original instructional design.
Fingers crossed.

PowerShell.org: Our First Year in Review

In September 2012, we incorporated PowerShell.org, Inc., and founded PowerShell.org. Our goal was to provide a solid Q&A forum, and to act as a portal to the rest of the PowerShell community.
By any measure, we’ve had a great first showing.
We have more than a dozen shareholders in PowerShell.org, Inc., making this the first community-owned PowerShell organization ever. We’ve signed on three Platinum sponsors - CBT Nuggets, SAPIEN Technologies, and Interface Technical Training. We’re now funded for 2-3 years of operation, including providing (upon request), gift cards to help local user groups pay for pizza and other monthly meeting expenses.
PowerShell.org is now taking an average of 18,000 visits per month from more than 12,000 unique visitors, with a total of almost 57,000 monthly page views. Our forums have helped more than 760 people answer more than 850 questions.
Microsoft’s Scripting Guy, Ed Wilson, has handed off the Scripting Games for 2013, and we’re preparing for a small-scale “Winter Scripting Camp” trial run that will include a purpose-built platform for reviewing events, submitting entries, and judging. And by the looks of things, that platform will run on PowerShell itself.
We’ve announced our first PowerShell Summit North America, and have completely sold out. We’re already doing initial planning for 2014, aiming for a larger venue and hoping to accommodate twice as many attendees, and to fully cover speaker travel expenses.
We’ve launched PowerShell People, accessible via PowerShell.net, where you can write a PowerShell script to create and post your own profile and “brag” page about your PowerShell activities and accomplishments.
We’ve launched three free PowerShell.org-branded ebooks, and are preparing to launch our PowerShell.org TechLetter monthly (!!!) e-mail newsletter complete with feature articles, news updates, and more. That’s by (free) subscription only, so sign up if you haven’t done so already! We’ve also had help from Jason Hofferle on our new Books page, rounding up all the free and commercial PowerShell books out there.
It’s been a whirlwind year, and it’s all thanks to you for supporting it. By asking questions in the forums, offering answers, creating your People page, registering for the Summit, signing up for the Newsletter - all of these little activities spur us all on to new heights, and we appreciate all the feedback you’ve offered. There will be more to come - follow the community on Twitter (and the Summit too, while you’re at it) for the latest announcements.If you’d like to contribute, just drop a note in the Suggestion Box forum - whether you want to help monitor a discussion forum, write book reviews, or whatever, there’s always room to contribute.
There have been some setbacks. Will Steele, who had volunteered to populate our Events page, has had to step down due to health problems. Will has been a great contributor to the site and to the overall community, and we miss him. Our thoughts are with him and his family this holiday season.
As we all wind down and look forward to the New Year, I wanted to personally express my gratitude to everyone who’s helped make all of this happen. Happy Holidays, Happy New Year, and I’ll see you again in 2013!
Don Jones
President and CEO, PowerShell.org, Inc.

Writing 10961: Remoting

As I write this, we’re close to sign-off on the outline of 10961A, which is a new 5-day Microsoft course on PowerShell v3. I sat down yesterday and starting doing some detailed-level design work on the proposed Module 9, which will cover PowerShell Remoting.
I love Remoting (and yes, I capitalize the “R” when referring to the specific feature, much as I would for Workflow). And although I’ve taught Remoting over and over and over since it was introduced in v2, although with this course I’m trying something a bit new.
I’m going to start by covering the basics: What Remoting is, what WS-MAN is (and yes, I know it’s formally called WS-Management, but you never see it referred to that way in-product), what WinRM is, and so on. I cover Invoke-Command and Enter-PSSession. Then I get into some advanced stuff, primarily covering how to pass arguments to Invoke-Command via its -ArgumentList parameter and an in-scriptblock Param() block. Surprisingly, this isn’t covered in the examples of Invoke-Command in the help. I was shocked to discover that. I need to use that technique in Module 10, so I’m covering it in 9.
Then I get into sessions, and I also cover disconnected sessions. Then the cool begins.
I cover both implicit remoting (which is tons easier to do in v3) and delegated administration via custom session configurations (also vastly easier in v3). In the penultimate lab for the module, students will create a Remoting endpoint that contains a single command (Set-ADAccountPassword), have that command run under Domain Admin credentials, and restrict the endpoint to members of a HelpDesk domain user group. Voila, delegated administration! We don’t go so far as to build a GUI tool atop it all, but that would be out of scope for this course. As-is, the lab covers an extremely real-world use of PowerShell and Remoting, and does it in a very practical and production-ready way. I think it’s gonna be awesome.

Writing 10961: The Ultimate Lab

My company has been contracted by Microsoft to design and author Microsoft Official Curriculum (MOC) course 10961A, Automating Administration with Windows PowerShell v3. While there is no announced release date I can share, I did want to share some of the experience.
As I write this, 10961A’s proposed outline is going through several review cycles. In the meantime, I wanted to sit down and start doing some detail-level design on some of the more complex labs in the course - the most complex of which is a proposed Module 10, consisting of little more than a big, 2-hour lab where you write a script to provision a newly installed Server Core computer.
This, for me, is the ultimate lab. It’s practical, meaning it focuses on a scenario that’s extremely real-world. It’s also not “perfect,” meaning it doesn’t throw you into an everything-just-works environment and hand-hold you though a few self-guided demos. Initiating communications between a domain client and a non-domain machine is tricky in PowerShell, and automating that is not entirely straightforward.
The approach I’m planning to take will break down all the major sub-tasks, and then walk students through some of the considerations for each. What commands will you need? What information will you need up front in order to run them? Where will you get that information - and how? I think it’ll be a very nice “putting it all together” module (although there are two modules after it, so it isn’t exactly the end of the course). It should occupy the entire afternoon of the course’s fourth day (Thursday), which makes for a nice open-ended wrap to that day (meaning faster students can finish and leave early, while leaving time for slower students to work through everything without feeling rushed).
In the lab, you’ll write a parameterized script that saves off your old Remoting TrustedHosts list, queries DHCP for the new server’s IP address, and saves that IP address into your TrustedHosts. You’ll make a Remoting connection to the new machine and have it join itself to the domain while renaming itself, wait for it to reboot, and then add a role (IIS) to it. You wrap by putting TrustedHosts back to where it came from.
This is actually a trimmed-down, more methodical version of a workshop I just did last week at Live! 360 in Orlando. That workshop took four hours, which I don’t have in the class’ time budget, so I trimmed out a few things that were cool, but not entirely necessary, such as testing to see if a DHCP reservation already exists before creating one (without testing, you can potentially get an error, but it’s non-tragic).
I’m looking forward to getting into the actual writing of the module once the outline is approved; I think this’ll really be the highlight of the course. It replaces a module in the older 10325A course (which I also wrote) where you break down a script someone else wrote, customizing it to run in your environment. While I think that’s a useful skill, the feedback I got was that it wasn’t the most interesting lab possible, and that the script I provided (written by Jeffery Hicks, actually) was pretty complex given the time allotted. This new lab provides the same beginning-to-end scripting opportunity, but hopefully folks will find it to be a lot more practical and useful, both educationally and when they get back to the office.

What To Do If You Don't Score a PowerShell Summit Ticket

As I write this, we’re down to one ticket for the PowerShell Summit North America 2013. So what do you do if you really wanted to go, but miss that last, golden ticket?

Cry a Little

Let’s face it, this was totally avoidable. It’s probably your boss’ fault for not approving the expense, and so some subtle retribution may be in order. Burn the coffee for a week. Reboot domain controllers randomly. You know, just sulk.

Help Beta-Test a New Free eBook on PowerShell Reporting

I’ve written previously about my frustration with reporting in PowerShell - how I see admins struggle with ugly, low-level COM code to manipulate Excel spreadsheets, just so they can get nice-looking reports with a degree of automation.
Enough.
The right thing to do is put your data in SQL Server, and use SQL Server Reporting Services to generate awesome looking reports, complete with charts and graphs. With the right setup, you can completely automate data collection, report generation, and delivery. And it doesn’t have to cost a single dime. Plus, the learning curve isn’t too steep, and the skills you’ll learn along the way will be massively beneficial to you over the long haul - far more so than the time sunk into becoming an Excel jockey.
So I’ve written a little book about it, which you’ll find on at https://powershell.org/ebooks, entitled Making Historical and Trend Reports in PowerShell. Unlike my earlier book on HTML reporting, which was mainly around producing inventory reports, this one’s specifically designed to make reports based on collected-over-time data, like disk utilization, performance, and so on. And I’ve bundled in a PowerShell module that should make this easy, insulating you from 99% of the SQL Server-related stuff.
Right now (November 2012) I’m looking for folks to test stuff out and let me know (via comments here) if you find any problems. I want to make sure that what I’ve got in here works and is understandable. Final publication is scheduled for January 2013, after which I’ll start taking suggestions for stuff to add to the book.