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)!

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.

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…

Check out the show here..

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..

Set-PSBreakpoint offers some additional options of which I was not aware.

1. Setting a breakpoint in relation to a variable (read, assigned, or both)
2. Setting a breakpoint when a function or command is called
3. Setting a breakpoint based on the column number for the referenced line
4. Run a scriptblock when a breakpoint is hit
5. 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.

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!

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.

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.

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”.

The short summary of the post is if you had six months free of distraction, what would you turn your attention to.  Tim’s choices included backups, security, and monitoring, which I think is a great “solid foundation” to work from.

Brent posits that if he became more effective at data mining, he would be able to provide a business with critical insight with which to improve sales, product focus, and develop key personnel.

If I had more time (and skills), I could tell executives things like:

• These are the top five customers who are about to leave us.
• These are the top five products that are about to go viral, and we need to stock more ASAP.
• These are the top five salespeople who need coaching to produce more revenue.

Walk into an executive’s office with this kind of information, and you’re a hero.

Here’s the shocker Brent… I agree. 

I agree that delivering that kind of data to management is the Holy Grail of IT projects.  Before coming into the IT realm, I ran a small business and I would have killed for information along those lines. 

One thing I think is missing from Brent’s discussion is that there are three parts to this type of data mining:

• The first part is the technical aspect on how to retrieve the data from databases and other sources of information, which Brent probably has handily covered. 
• The second part is not a technical question at all.  The second part of the data mining is actually coming up with questions you have for your data.  The quote above from Brent’s post highlights those, and point to an area of expertise outside the technical.  Brent is demonstrating (and probably should have said explicitly) that a domain/business knowledge is very important in determining these requests.  This is often difficult for the stereotypical IT person, but is essential if you are interested in moving your career past a technical implementer. 
• So, it appears Brent’s real goal is the the third part of this process, which is translating these questions (taking the business knowledge) and retrieving and correlating the data (using his technical skills) that he will need to make these determinations.

Brent continues on to cover a common area of disagreement between us.

I kick the PowerShell horse a lot, and here it comes again. If you’re in IT, listen up: you’re either cutting costs, or making money.  Guess which one has more upside.  If you truly bust your hump, become an amazing scripting deity, and save 99% of your time, you just saved 99% of your salary.  If you’re really good, you might save 10 people 99% of their time.

I work as the sole admin/accidental DBA/desktop support/multimedia support/”if it has a blinking LED light” support for an agency that collects lots and lots of data.  As a scripting practitioner, if I save myself 25%, 40%, or even 60% of my time not having to solve the same problems over and over, I’m free to plume the mysteries of my database and convert the bits stored their into meaningful data and even information that is usable and actionable. 

Not every environment has the luxury of being able to afford someone of Brent’s caliber to come in and learn their business and help them develop methods of turning their data into knowledge.  In my situation and that of many small to medium businesses, scripting is the tool that enables the IT generalist to explore and branch out into these other areas.

Brent may feel ” you can go into data mining and make 100 salespeople twice as effective” and that IT people who keep things running are replaceable and he may be right, but I believe, especially in tighter economic times, specialists become a luxury that only a few can afford where efficient generalists that know the business become more in demand.

Don’t be mad Brent… it’s okay to be wrong every once in a while!

So if I had six months of no interruptions and could focus on certain specific projects, I would:

• Finish automating (via PowerShell, SQL, or other means) common tasks
• Develop the questions my administrators (not technical admins, but departmental administrators) would like to ask our data sources
• Build tools to answer those questions via reports, graphs, network maps, or other data visualization techniques (like the cool stuff Doug Finke and Chad Miller have been doing)

I personally think that EVERY technical person should have a grasp on the basic business environment, be aware of what is happening in their company’s industry (or at least their department’s industry for larger organizations), and begin to develop more in depth domain knowledge as to the business processes.

Due to the odd path I took to becoming an IT person, I’ve actually accumulated quite a bit of domain knowledge about the law enforcement, the various jobs, information requirements, and the ins and outs of our workflows and data.  This background gives me a great starting place when going to look at my data, since scripting has given me the time to do so. 

Judging from the pattern in Tim’s and Brent’s posts, I’m supposed to tag a few people..

How about:

• Doug Finke (developer, data visualization explorer,  and PowerShell MVP),
• Hal Rottenberg (administrator, VMWare vExpert, podcaster, and PowerShell MVP),
• and Wes Stahler (administrator, blogger, and PowerShell enthusiast)

Get-Process –Name iexplore | Where-Object {$_.WorkingSet –gt 50000000 } | Stop-Process

In the above (often overused, but illustrates the point well) example, Get-Process, Where-Object, and Stop-Process all accurately describe the task that they perform.

We can take this same approach with our scripts and functions.  By keeping your scripts and functions focused on performing discreet tasks, you keep with the composable nature of PowerShell and provide yourself the most flexibility in reusing the functions you create.

One of the most common “errors” I see in PowerShell scripts that are shared is the embedding of formatting in the output of the script.  If your script generates output, it should be in the form of objects (custom or otherwise).  (The only caveat here is if your script’s functionality is to handle the output of data, in which case it’s sole focus should be the handling that output.)

The PowerShell ecosystem provides a number of tools for formatting the output of your scripts, whether you want to display your scripts in the console window (Format-List, Format-Wide, Format-Custom, Format-Table), as a web page (ConvertTo-HTML), sent to a CSV file (Export-CSV) or XML (Export-CLIXML), in Version 2 to a sortable, groupable grid (Out-GridView), as well as a number of other options (Visifire graphs via PowerBoots, Excel, PDF, or Image via the Reporting Services Redistributable, or as a netmap using NodeXL).

Take advantage of these, or write your own.  If you write your own, it should work with custom objects, to keep with the composable nature of PowerShell.

DRY is a principle that can be very familiar to the PowerShell aficionado with a development background.  DRY means Don’t Repeat Yourself.  Keeping your scripts DRY means that our scripts don’t contain repeated code.  Copy/Paste is not your friend!

Why should PowerShell scripters care about keeping their PowerShell DRY?  One major reason – script maintainability.

PowerShell has a huge advantage over scripting environments/shells in that the noun/verb structure lends itself to very readable scripts.  If there is duplication in your code, that readability can give a PowerShellers a bit of overconfidence when reading/modifying scripts that are new to them or that have not been looked at in a while.

If you find yourself copying and pasting lines of PowerShell between different sections of your script, you could be setting yourself up for some interesting times when you need to make a change.