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.
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.
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.
So, as you may know, I have an ongoing hobby project called _Creating HTML Reports in PowerShell. _I’m working on an update for next year, and one of the things I’ve been looking at are embedded charts within the report. Problem is, I don’t know what people would actually chart. Now… I’m going to ask you for ideas, but you need to read this whole post before you go popping a comment in. Because there are some restrictions. First, I’m
not talking about historical data or trend reports
. Those require a data store of historical data. If you’re not using SQL Server for that (even free SQL Express), learn how. Excel isÂ
not
your trend database, no matter how little learning it requires (and I bet if you added up all the time you’ve spent becoming an Excel jockey, you’d be shocked). Once you’ve got the data in SQL (even Express), you can use SQL Server Reporting Services (SSRS) to generate truly kick-butt reports with very little effort. Reports which can be scheduled and e-mailed. Truly, folks, this is worth spending time on - and I may make that my next ebook project. **Second, **don’t tell me “disk space.” I know that one. Pie and stacked bar charts showing size/free space are a great idea. Got it. Anything else? **Third, **I’m not talking about performance charts. PerfMon does those, and also, see my first point. PowerShell is not a performance monitoring tool. Operations Manager is. Oh, and it dumps data into SQL Server and you can use SSRS to report on it. If your company needs historical performance reports (and most probably do) and is to cheap to get you a real monitoring solution, consider taking drastic measures. I’m not suggesting you put Ex-Lax in the boss’ coffee every time he asks you to re-create OpsMan on your own. He’d deserve it, and it might help, but I’m not suggesting it. In keeping with point 3, that means I don’t want suggestions like “charts showing network throughput.” That’s performance. I’m not suggesting such a thing wouldn’t be useful, because I know it would be. I’m saying it’s out of scope for this particular project. If you give me in-scope suggestions, I’ll build you a tool. Fire off out-of-scope stuff and I’m just going to go build a kegerator for my beer instead. SO… given those restrictions, what sort of data could you query from a computer (say, using WMI/CIM or something) that you’d want displayed in chart form? Anything?
A long time ago… about a year, in fact… Jason Helmick and I started talking about a community-owned PowerShell “certification.” It went nowhere. Well, not very far. Some background on exams: Microsoft, in my opinion, will never do a PowerShell cert. I say this having been part owner of a company that did outsourced exam development for the company. The deal is that Microsoft tries to certify _job tasks, _not _tools. _Nobody (well, maybe me) wakes up thinking, “gonna do me some PowerShell today.” No, PowerShell is the means to an end: “gonna automate me some user creation today” is more likely. And Microsoft tries to certify that end. PowerShell’s an important tool, and it already shows up on certification exams here and there. For the most part, I agree with Microsoft’s reasoning, there. The argument can be summarized as saying “bosses don’t hire IT pros based on their ability to operate a low-level tool, they hire them to perform job tasks, which encompasses the tool.” Except that, in the case of PowerShell, I think it’d be tremendously useful for an employer to use PowerShell expertise as a discriminating factor in hiring. I mean, “someone who can automate stuff” is more valuable than “someone who can only do stuff manually,” in any situation. So “PowerShell Verified” was intended to be a way for someone to prove - at least to themselves - that they’ve taken their PowerShell skills _to the minimum level necessary to be an effective automator. _Not a guru. Not an expert. Not Poshoholic. _Minimally effective, _who could then grow from there with experience. So that’s what I’m going to put together. I want to explain why I’m not using the word “Certification,” though. In my mind, certifications come from, mainly, first-parties like Microsoft. Microsoft has to jump through a lot of hoops to make sure their exam content is accurate, legally defensible, blah blah blah. They worry about security, brain dumps, and other stuff that diminishes the value of the certification. I don’t have that kind of bandwidth or their resources, so in many ways my little program will be less effective than a “real” certification. Plus, few bosses will give a rat’s patooty what that Don Jones guy said about your skillz (I can’t even convince bosses to buy you guys 12-core 64GB workstations for your desk). So my “Verified” program is going to be _low stakes, _meaning you take it to prove something to _
yourself
_. Here’s how this is going to go.
To cap off the 2013 PowerShell Summit the PowerShell Team is going to host a half day Windows PowerShell scenario walkthrough. This is designed to not only familiarize folks with specific PowerShell features, but also to help the team see how you interact with these features.
The event will take place on April 24 from 1pm - 5pm. Â During this time we will collectively solve a problem from the ground up using many of the new features in Windows PowerShell 3.0 and Windows Server 2012.
Starting from base Windows Server 2012 images, we will walk you through:
As we’ve been finalizing our speaker and session collection, we’ve been able to release a small block of Summit tickets into the general admission pool. Also, the end of October saw the expiration of a set-aside block for PowerShell MVPs, releasing that block’s unsold tickets back into the general admission pool as well. As it stands, the G.A. pool now has 57 tickets, of which we’ve sold 24. That leaves 33 tickets left for the April 22-24 event at Microsoft’s corporate headquarters in Redmond, WA. We currently have a total of 57 attendees, including speakers. That doesn’t include Microsoft team members who will be delivering sessions, nor does it include a small batch of tickets reserved for Microsoft staff who will be participating in the sessions for all three days. If you’re thinking of coming to the Summit, **now is the time to register. **We’ll be releasing our session and speaker lineup within the next few days, and that usually triggers a big rush in registration as people get even more exciting about the upcoming event. If you do happen to miss one of these final 33 tickets, you’ll have the opportunity to go on a waitlist, where you’ll be notified if anyone cancels. Don’t miss your chance to be a part of this first-ever community-owned and -operated event!
Idera’s gone and made PowerShell Plus free. Given that it’s been updated to support PowerShell v3, this will probably become many folks’ go-to editor (PowerGUI, the former champ, is more or less out of development and hasn’t been updated for v3). Idera says:
“Idera is dedicated to providing products that help our customers and community members be successful in their jobs,” said Rick Pleczko, CEO of Idera. “PowerShell Plus is a proven and essential productivity tool so we wanted to get it into the hands of IT professionals everywhere. It also complements our sponsorship of the PowerShell.com community, which features forums and resources for novice to advanced PowerShell users.”
One of the ballyhooed new features in PowerShell v3 is the new “simplified” syntax for Where-Object and ForEach-Object. I’m going to focus on the former for this article. In essence, instead of doing this:
Get-Service | Where-Object { $_.Status -eq 'Running' } You can now do this also:
Get-Service | Where Status -eq Running Last week, I had the opportunity to include this new syntax in a class I was teaching - mainly to beginners - and I came away with mixed feelings. Whereas once I’d felt awesome about the new syntax… now I’m conflicted.
For more than 200 weeks now (there’s an episode a week), Jon Walz and Hal Rottenberg have been bringing us the PowerScripting Podcast. It’s become an almost official “voice” of and for the PowerShell community. In it, the two don’t focus much on technical tips or anything like that. Instead, the highlight is a weekly interview with a mover and shaker in the PowerShell community. For me, they put a face on the community. One week you’re talking to the inventor of PowerShell, the next to a local user group leader who’s helping educate folks in his area, and the next an ISV who’s building PowerShell into their products. It’s Larry King Does PowerShell. If you’ve listened to the podcast, you know what I’m talking about here. But, if you’ve only listened to the podcast, you’re missing half the show. Maybe more. You see, on most Thursday nights at 9:30pm (US Eastern), Hal and Jon record the show live. With webcams. And a chat room.
(click for larger) This is where the podcast goes from being a hobby and into being a truly vital piece of community connective tissue. Pop into the chatroom and regulars, like the Scripting Wife, offer a “hello!” It’s a weekly clubhouse of sorts, where the chatroom conversations parallel the webcast, but also diverge onto tangents. It’s where you can offer up questions for the current speaker. It’s where you play drinking games (anytime Snover says “ecosystem,” drink!). And, when I’m the featured speaker, as I’m privileged to be a couple of times a year, it’s where you egg me on in my rant-of-the-season. I’m going to share a little secret that most software developers already know: _Community counts. _It isn’t just a word, or some marketing slogan. The ability to make connections with people in a similar boat - via Twitter, e-mail, forums, or a podcast recording - is important. For many IT pros, IT per se isn’t our personal passion. It’s a job. And so it’s easy, at the end of the workday, to go home and do our real passion - be with family, play Xbox, or whatever. So IT pro communities have traditionally never been as robust as developer communities. But _make the effort. _Community is how you’ll meet the guy (or gal) who has the solution to your next problem, and will share it free for the asking. Community is where your next job will probably come from. Community is, in fact, your _meta-career, _spanning employers and projects and giving you a foundation to really succeed in this business. The colleagues you meet through community will become, over time, more important to your personal success than your direct coworkers. In fact, PowerShell.org itself wouldn’t exist without the strong community connections Kirk Munro and I have made over the years. Giving up an evening with the family to go to a local user group meeting can be tough, if there’s even one in your area. You should do it anyway. But if you can’t, Hal and Jon have created a sort of virtual user group where you can connect with _people, _not just learn about technology. Trust me, the first time someone like Jeffrey Snover recognized me in-person and said “hi,” I got a little thrill - and it was because of opportunities like the PowerScripting Podcast that he got to know me. Much of my success in the IT field has some through community and connectedness, and I heartily recommend it to anyone. Hope to see you in the chatroom!
(click for larger)