Generic filters
Exact matches only
Filter by Custom Post Type

PowerHour: Community Lightning Demos!

One of my favorite events at the PowerShell + DevOps Global Summit is the community lightning demos. It's a fun format:

For the audience:

  • Fast paced (max 10 minutes)
  • Many speakers
  • Topic or speaker not what you're looking for? They'll change in a few minutes
  • Demos offer enough material to give you ideas and point out where to learn more
  • Content is more likely to have a high signal-to-noise ratio given the time constraints

For the speakers:

  • No need to come up with a full length session and the content behind it
  • It can be comforting knowing you have a bunch of peers joining you
  • You can get enough info to the audience for them to get excited and want to learn more
  • You get a platform to share something awesome with the PowerShell community

So! This isn't about the summit. We're starting a new thing, PowerHour: An Hour of Community Lightning Demos.


PowerHour will be like a virtual PowerShell User Group, with a lightning demo format, and leeway for other topics not directly related to PowerShell.

This adds some more fun:

  • No need to stand on stage (yet!), with Jeffrey Snover sitting right in front of you
  • Folks reviewing CFPs for the PowerShell + DevOps Global Summit will likely see these... You could give a condensed demo of a CFP topic, or just showcase something cool to give us an idea of how you prepare and present
  • More time! We always run short on time at the summit; we'll hold these on a regular basis to give more folks a chance to show something fun!
  • Everything is recorded

So! Where can you go to find out more?

When does it start?

Our first session is scheduled for Tuesday August 21st @ 6:00 PM EST!

We hope you'll join us - feel free to drop by the #powerhour channel in!


PS: a huge thanks to Michael Lombardi for his help with the summit community lightning demos, and partnering up to make PowerHour a thing!

Do Anything in One Line of PowerShell

PowerShell provides a tremendous boon to productivity for computer professionals of all types. But, you have to admit: it can be a bit daunting to get up to speed! Indeed, as someone who has a fair amount of experience using it, I still find myself having to look up how to do things--frequently. So I started keeping track of the recipes I was using the most. And came up with a list of 400 or so, published in 4 parts.

Though I actually wrote these a couple years back they are certainly still relevant today, just covering a bit less of the ever-expanding PowerShell universe of discourse!

(Note that at the end of each web article listed above is a link to download it as a PDF that is more tidily formatted.)

UPDATE / Tug: The Open-Source DSC Pull Server

If you haven't taken a look at Tug, now's a great time. Eugene Bekker has been doing a ton of heavy lifting, taking my .NET Core proof-of-concept code and turning it into a formal ASP.NET MVC project.

Read more

PowerShell Gotchas

You can certainly find a number of articles around that present PowerShell pitfalls that can easily trip you up if you are not careful. I took a different approach in my three-part series, A Plethora of PowerShell Pitfalls.

The first two parts are presented in quiz format, together covering the top 10 "gotchas". They will help you test your awareness to see if you even realized the danger and did not know you've been skirting those traps for awhile. After you've had an opportunity to consider the conundrums presented, I then go into detailed explanations for why they happen and how to fix them.

The third and final part is a compendium of all the common "gotchas" that I put together after reviewing all the other lists out there. The more than 35 entries in the list cover, I believe, a good 98% of the issues you would likely encounter. Yes, there are more esoteric pitfalls as well, but I ran out of web page... 🙂

Part 1: Pesky Parameter Problems

Part 2: A Portion of Potential Puzzles

Part 3: The Compendium


Pitfalls of the Pipeline

Pipelining is an important concept in PowerShell. Though the idea did not originate with PowerShell (you can find it used decades earlier in Unix, for example), PowerShell does provide the unique advantage of being able to pipeline not just text, but first-class .NET objects.

Pipelining has several advantages:

  • It helps to conserve memory resources. Say you want to modify text in a huge file. Without a pipeline you might read the huge file into memory, modify the appropriate lines, and write the file back out to disk. If it is large enough you might not even have enough memory to read the whole thing.
  • It can substantially improve actual performance. Commands in a pipeline are run concurrently-even if you have only a single processor, because when one process blocks, for example, while reading a large chunk of your file, then another process in the pipeline can do a unit of work in the meantime.
  • It can have a significant effect on your end-user experience, enhancing the perceived performance dramatically. If your end-user executes a sequence of commands that takes 60 seconds, then until 60 seconds has elapsed he/she would see nothing without pipelining, whereas output could start appearing almost immediately with pipelining.

PowerShell provides a variety of techniques for using pipelining but it is all to easy to do it wrong, so you think you are pipelining but in fact you are not. In my article Ins and Outs of the PowerShell Pipeline, I discuss the most common things that can trip you up with implementing pipelining and how to avoid them.

Create Custom Monitors with PowerShell

Sometimes, as a developer, you want to be be able to keep track of free space on a drive, the size of a log, the load on your CPU, the number of users logged in, etc. With PowerShell, it is typically just a matter of finding the right cmdlet amidst the large (and rapidly growing) pool of cmdlets provided by Microsoft and by third parties. Then you just run Get-Foo to check details about the foo resource. And then you come back 5 minutes later and run it again because you want to see how it changes over time.

But wouldn't it be nice if you could just have it run automatically at regular intervals in a separate window that you could just keep in the corner of your screen? Well, I found the barebones of just such a utility sometime ago (authored by Marc van Orsouw,  aka ‘thePowerShellGuy’). His original post is no longer available, but I expanded upon his code and, over time, added features, bug fixes, and enhancements, making it more useful and more user-friendly. Here are a few screenshots of the Monitor Factory in action.

Monitor the size of a database

Start-Monitor -AsJob {
    Invoke-Sqlcmd 'DBCC SQLPERF(logspace)' |
    Select-Object 'Database Name','Log Size (MB)','Log Space Used (%)',HasErrors

Database Size Monitor

Monitor drives on a system
Drive Capacity Monitor

Monitor longest running DB queries
Long-runnning DB Query Monitor

Build Your Own Resource Monitor in a Jiffy reveals how quick and easy it is to get started with the Monitor Factory.

PowerShell is Open Sourced

For those of you that have been at PowerShell Summits over the last few years you’ll have heard Jeffrey Snover state that he wanted to take PowerShell to other platforms.
Now its happened
Jeffrey has announced that an ALPHA release of PowerShell is now available for Linux and Mac.  Currently available for Ubuntu, Centos, Red Hat and Mac OS X with more to come
The announcement is at
Also see PowerShell blog
Some  points to note:
ISE isn’t available as part of the alphas release but VSCode is available for Linux and Mac giving an consistent editor across the platforms
PowerShell remoting will be extended to use Open SSH as well as WSMAN
Planned enhancements include:
Additional Linux Distros covered – parity with .NET Core.
Writing Cmdlets in Python and other languages
PSRP over OpenSSH
WSMan based remoting to downlevel versions of Windows and WSMan based PSRP on Linux.
Editor Services and auto-generated GUI
Unix-style wildcard expansion
Increasing test code coverage for Windows and Linux editions
Continue increasing cmdlet coverage for Linux and Windows
REMEMBER this an ALPHA release – there’s still a lot to do and its a open source project so community effort is required

Every pithy witticism begins with quotation marks

"To be or not to be". Without getting into a debate over whether Shakespeare was musing about being a logician, suffice to say that in writing prose, the rules of when and how to use quotation marks are relatively clear. In PowerShell, not so much. Sure, there is an about_Quoting_Rules documentation page, and that is a good place to start, but that barely covers half the topic. It assumes you need quotes and then helps you appreciate some of the factors to consider when choosing single quotes or double quotes.

But do you need quotes? Remember PowerShell is a shell/command language so "obviously" you can do things like this:

PS> Delete-Item C:\tmp\foobar.txt
PS> Get-ChildItem *.log
PS> Get-Process svchost, conhost, powershell

It would certainly be cumbersome if you needed to quote each of those arguments, so PowerShell was designed well, in that respect.

But what if you ran the same commands just slightly differently?

PS> "C:\tmp\foobar.txt" | Delete-Item 
PS> "*.log" | Get-ChildItem 

Here you must use quotation marks or you will suffer the wrath of a terminating error from the PowerShell host most certainly!

Those are just a couple of the many examples I consider in When to Quote in PowerShell. Accompanying the full article, I also included a wallchart that condenses all the article's salient points into a single-page reference. Here's a fragment of the wallchart:

Guide to PowerShell Quoting wall chart

Read the article and download the wallchart here.

High-Level: Designing Your PowerShell Command Set

So you've decided to write a bunch of commands to help automate the administration of ____. Awesome! Let's try and make sure you get off on the right path, with this high-level overview of command design.

Start with an inventory

You'll need to start by deciding what commands to write, and an inventory is often the best way to begin. Start by inventorying your nouns. For example, suppose you're writing a command set for some internal order-management system. You probably have nouns like Customer, Employee, Order, OrderItem, CustomerAddress, and so on. Write 'em all down in an Excel spreadsheet, one noun per row.

Then inventory your verbs. For each noun, what can you do with it? For example, you can probably create orders, so a New-Order command will be needed. Make a "New" column in your spreadsheet, and put an "X" in the row next to the Order noun. However, you probably can't remove an order from the system, so although your spreadsheet might have a "Remove" column to cover things like Remove-Employee, that column won't get an "X" in the Order row. Orders might be voidable, though, so what's a good verb for that? has the official verb list, but there's no "Void" or "Cancel" that seems appropriate. Don't go making up new verbs!!! Instead, it might be that Set-Order could be the answer, enabling approved changes to orders, including cancelling them (but retaining the record).

Finally, pick a prefix for your nouns. If your order system is named "Order Awesomeness," then maybe OAwe is a good noun prefix, as in Set-OAweOrder. The prefix will help keep your command names from bumping up against other people's, so making sure that noun prefix is pretty unique... is pretty important.

Design individual commands

Now it's time to start designing individual commands. This is usually a kind of iterative process, meaning you'll go back and change your mind, expand, and so on a few times before you're done.

Start by writing examples of how each command will be used to accomplish whatever tasks you'll be accomplishing. Save these examples, too - they should become examples in your commands' help files. Write as many examples as possible, covering as many situations and needs as you can think of. Enlist users to help.

As you write the examples, try to pay attention to the following:

  • Parameter names should be consistent across the commands. If order objects have an ID, and you need to be able to specify it, then it should be something like -OrderId every time. Don't use -OrderId on some commands and -Id on thers. Also pay attention to what the underlying software objects' property names are. For example, if customer names are exposed through a CustNameFirst and CustNameLast property, consider using those as corresponding parameter names, or at least as parameter name aliases.
  • Start thinking about which parameters are going to be mandatory.
  • Give some thought to different ways that commands might be used, and start denoting those as different parameter sets.

This kind of example-based specification will help you think through how you want the commands to work, and it may highlight cases where you need more commands, where commands may need to be combined, and so on.

Sketch out your help files

Believe it or not, it's not a bad idea to start drafting out your help files at this point. Define parameter sets, parameters, and examples. Briefly describe what each parameter is for - you can always make the language nicer and more formal later, so just a brief draft should work at this point. This kind of forces you to think through how your commands will work, and how other people will end up approaching them. It also gives you a good start on writing documentation! "Documentation as specification" helps a lot of people write specs that can end up being repurposed as docs, killing two birds with one stone.

Define expected results

Go back to your examples, and provide some examples of the results you'd expect to see if you actually ran those commands as shown in your examples. This helps you to start defining the tests that you'll run against your code. "For this command, we should get this output" is exactly what testing is all about. "This command should generate this error, this command should do this," and so on.

Start coding

With some good design work out of the way, you can start coding. Not just your commands, mind you, but also the Pester tests you'll use to validate those commands. Code 'em at the same time, if you like, and use those tests in unit testing as you work.

Complete Guide to PowerShell Punctuation

Quick as you can, can you explain what each of these different parentheses-, brace-, and bracket-laden expressions does?

(1,2,3 -join '*')
(8 + 4)/2
{param($color="red"); "color=$color"}

When you're reading someone else's PowerShell code, you will come across many of these constructs, and more. And you know how challenging it can be to search for punctuation on the web ( not withstanding) !

That is why I put together a reference chart containing all of PowerShell's symbology on one page. making it much easier when you need to look up a PowerShell symbol as you read code--or to browse for the right construct when you are writing code.

PowerShell Punctuation wall chart

Download the Complete Guide to PowerShell Punctuation wallchart from here.

Skip to toolbar