Use PowerShell
Real Admins Script
General
Chicago Code Camp – May 1
Apr 28th
The Chicago Code Camp is being held on Saturday, May 1st. I’ll be presenting a PowerShell Deep Dive. If you are in the Chicago area and want to get down into the guts of the PowerShell language and runtime (or many other great sessions!), come on out. There were 100 97 tickets available last time I checked…
April Script Club – Special Guest
Apr 14th
The Greater Milwaukee Script Club will be meeting on April 20th and we will have a special guest – James Brundage (twitter | blog | blog). James is a member of the PowerShell team at Microsoft, as well as a blogger, community member, guest on the PowerScripting Podcast, and author of the PowerShellPack – part of the Windows Resource Kit.
Last month, we used the Admin Development Model to solve a particular problem one of our brave volunteers was trying to deal with in his environment.
We have planned to talk a bit about error handling, and as always, work on your scripts.
If you are a PowerShell user or need to become a PowerShell user and are in southeastern Wisconsin, come on down, all are welcome (free registration requested)!
Wisconsin Virtual SQL Server Lunch and Learn
Feb 26th
I just finished taking up 13 people’s lunch hour to talk a bit about PowerShell V2, SQL Server, and the admin development model.
I want to thank John Allman and the Wisconsin SQL Server User Group for allowing me the time to share a bit about PowerShell. I believe John will be posting the recording for those who are interested.
My slide deck is available here. The slides aren’t worth much, but the resources on the last two are where the real meat is.
Deep Fried PowerShell
Feb 26th
Back in August, I was offered a chance to make a fool of myself on yet another podcast tremendously honored by the opportunity to talk with Keith Elder and Chris “Woody” Woodruff on their podcast – Deep Fried Bytes – about PowerShell.
Keith and Chris are great guys, very sharp, and asked some good questions. If you pop over to take a listen to my appearance, make sure to go back and take a look through their archives. They’ve got 45 other shows, all worthwhile. (I’m a few podcast behind.. still working through show #37 – where they are talking about Windows Workflow. Jut to pull in some PowerShell, there is a PowerShell Activity in WF 4.) I’m quite looking forward to show #44 on soft skills with Brian Prince, as I don’t think we in the tech fields focus enough on these.
If you want to hear more on PowerShell related development, send Keith and Woody some feedback on the show or bother your favorite podcaster to do a show on PowerShell – maybe they’ll ask you to put your Shell where your mouth is…
Greater Milwaukee Script Club – Take 2
Jan 27th
We had a pretty good turnout for the first Greater Milwaukee Script Club and a lot of interest in keeping it going, so I’ve set up a home page for the group on Joel “Jaykul” Bennet’s PowerShellGroup.Org site, which serves as a portal page for PowerShell user groups.
Rod Gabriel (who heads up our local VMWare User Group) has an excellent review of the event. He covers why he considered attending (including why learning PowerShell was becoming a priority for him), as well as the event itself.
Registration is available for our next meeting – which will be February 16th at 6:00 PM at the Greenfield Municipal Court (details here).
More details and information to follow..
Script Injection with Set-PSBreakpoint
Jan 12th
I’ve used the integrated debugging features with PowerShell V2 since I’ve had it available, but I never really dug below the surface of setting breakpoints at certain lines.
Set-PSBreakpoint offers some additional options of which I was not aware.
- Setting a breakpoint in relation to a variable (read, assigned, or both)
- Setting a breakpoint when a function or command is called
- Setting a breakpoint based on the column number for the referenced line
- Run a scriptblock when a breakpoint is hit
- Breakpoints do not need to be set on a script
Let’s dig into these in a bit more detail:
1. Setting a breakpoint in relation to a variable (read, assigned, or both)
Set-PSBreakpoint can be used to find all the occurrences of access to a variable (in the current scope). This can be very useful when attempting to find out where things might be taking an unexpected turn with your variable’s contents.
2. Setting a breakpoint when a function or command is called
This is cool. You can configure breakpoints based on when cmdlets or functions are called. Great stopping at the entry point to a particularly troublesome function, so you can drop into the debugger and check the state of parameters about to go in, as well as other state related issues.
3. Setting a breakpoint based on the column number for the referenced line
I’m not so stoked about this feature. This merely allows you to specify which column to stop execution on in a particular line of code… Moderately useful, but not really exciting.
4. Run a scriptblock when a breakpoint is hit
This is where things get interesting. You can assign an action to occur when a breakpoint is hit. This action is a scriptblock that is run in the scope where it is set. Since breakpoints can be variable assignments or calls to commands, this opens up some interesting possibilities. First off, it allows for conditional debugging. If you only want to drop into a breakpoint if a particular value is less than zero before going into a function, you could do something like
$BreakpointAction = { if ($MyNumber -lt 0) { break } else { continue } }
This also has applications outside of debugging. Using the –Action parameter of Set-PSBreakpoint, you have the ability to run a scripblock of your choosing at any of the condition types described above – when variables are accessed, when commands are called, and at certain specific positions in the script.
5. Breakpoints do not need to be set on a script
Finally, breakpoints do not need to be set in a script, they can just be set to respond to variable access or command use. This means that you could use Set-PSBreakpoint in a profile script to configure a particular environment to respond in a certain way, perhaps prompting you before changing a critical environmental variable.
I’m definitely going to be exploring these additional features and applications of Set-PSBreakpoint as I go forward.
Additional debugging tips/info from the PowerShell Team Blog.
Please leave a comment as to how you think this functionality could be used.
I’ll be on the PowerScripting Podcast!
Jan 11th
We’ll be talking about PowerShellCommunity.Org, the Sync Framework, and more…
I love that podcast and am really looking forward to it!
Also, they recently posted an interview with Clint Huffman, who is the author of PAL. Good stuff!
Script Club – Coming to the Greater Milwaukee Area
Dec 8th
Register here.
About PowerShell Script Club
1. You Always Talk About Script club
2. You Always Talk About Script Club
3. If Someone asks for Help, And You Can Help, You Help
4. Two People Help One Person at One Time
5. One Module Per Person Per Night
6. All Scripts, All PowerShell
7. Scripts will be as short as they can be
8. If This is your First time at Script Club, You Have to Script
The first Greater Milwaukee PowerShell Script Club is being formed.
The first meeting will be on Tuesday, January 19th at 6:00 PM at the Greenfield Law Enforcement Center (in the Municipal Court Room), 5300 W Layton Ave, Greenfield, WI 53220. Register here.
All IT Professionals (sysadmins, network admins, developers, help desk, and all others) with any level of experience are welcome. If you DO NOT KNOW POWERSHELL, but you WANT TO – This is the place.
Pizza and soda will be provided, but please bring a laptop with PowerShell installed (version 1 or 2 is fine).
What is a Script Club?
Andy Schneider describes a script club:
Script Clubs are like a hands on lab with no set topic or teacher. You bring an idea for a script, and ask your fellow PowerShell users for help getting the script written.
This is not a lecture or presentation based group (though we may have presentations from time to time). Script Club is focused on creating working scripts that will help you get your work done or just enjoy yourself.
Register here.
All Sorts of New
Nov 12th
A lot has happened since I last had the opportunity to post.
Quick recap:
- PowerShell v2 is now out and available for XP, Server 2003, Vista, Server 2008, and installed and on by default for Windows 7 and Server 2008 R2
- SharePoint 2010 has an insane number (492)
- There is an open source cmdlet and help designer
- Try PowerShell is a great way to explore
- The PowershellPack provides some great modules that get you jump started with V2.
- Azure has cmdlets for management
- There is introductory PowerShell material in the Server 2008 R2 Developer Training Kit
- There are some PowerShell for Developers training videos on Channel 9
- James Kovacs released psake V2.00
- PsTFS has hit V1 – which is great for me now..
- I’m sure I’ve missed a ton of other cool PowerShell stuff that is happening too..
And that leads me to what I’m doing now.
In August, I left my job as a IT Specialist for a municipal police department and took a job heading up research and development for ProPhoenix, which is a software development company that make software for public safety agencies (police, fire, corrections, municipal courts).
I now live in a more software development focused world and will get to spend more time focusing on using PowerShell to automate my current activities, explore new frameworks, and to build a management API for our applications. I can’t wait to make PowerShell a requirement for our server products installation so I can get our support staff to start leveraging the capabilities PowerShell brings to the table.
Dear Devs, Give Us The Tools. K Thx
Jul 6th
I just finished listening to the latest Herding Code podcast (#52) where the hosts (K. Scott Allen, Kevin Dente, Scott Koon, and Jon Galloway) talked with Alan Stevens ( C# MVP and ASP Insider) and G. Andrew Duthie (author and Microsoft Developer Evangelist) about a debate that began on Twitter regarding “Real Software Development vs Microsoft Bubble Development”.
What does that have to do with PowerShell and administrative tools? The specifics of their conversation don’t have a lot of relevance to administrators and scripters, but one of the directions that their conversation took really resonated with me.
Alan throws the first punch – He likes Herding Code because it’s about real software development rather than development in the Microsoft bubble. It’s about the tool users rather than the tool builders and it’s about honest feedback.
As administrators, we need to make sure the developers of the applications that we use and administer provide us the tools we need to efficiently run our networks. Microsoft has gotten the message loud and clear. Windows 7, Server 2008 R2, and TechEd 2009 LA confirmed that. There weren’t many sessions where you didn’t hear something about PowerShell and there aren’t many products where PowerShell isn’t making inroads into the management structure.
Kudos to Jeffrey Snover and the awesome management technologies team for really selling this internally at Microsoft.
Another point made on the podcast was that Microsoft needed to do more to encourage better development practices… Can those same developers say that their products encourage better application management practices?
Now, we as the users of PowerShell need to step up and convince demand better administrative tooling from our vendors and internal development staffs. Companies like Quest, VMWare, Idera, Compellent, and others have gotten the message, but there are still many, many other products out there and many internal applications that suffer from inflexibility.
Web interfaces and GUI tools are nice and can be considered the icing on the cake. A true manageable application allows for consistent and repeatable actions in an easy to maintain structure, as well as providing flexibility to integrate other potential solutions. PowerShell provides a lot of that right in the box and allows administrators to bridge the gap and create their own solutions that might not have been supported yet (ever hear – “it’s in the next version”).
So, here is the call to action:
Rise up and demand proper administrative interfaces.
Talk to your managers about the benefits of streamlined application management using a consistent interface across multiple platforms and applications.
Take a developer to lunch and explain how you want to help make using his product a better experience from the application management side.
Let’s take our cue from the oft repeated concept in that Herding Code podcast – there is a need for candid feedback and it is all about the tools that we have to live in and work with every day.
If by chance one of the guys from the Herding Code podcast (or any other developer-centric podcast like .NET Rocks, Deep Fried Bytes, or StackOverflow) happens onto this post and wants to talk further, I’m available. There are also a good number of PowerShell MVPs and community bloggers who I’m sure would love to provide some “candid feedback” to “developers in the trenches doing real development”.
