Once you get passionate enough about PowerShell to start looking for swag, you know you have a problem. Unfortunately, there is very little available in that regard. If you haven’t seen /n Software’s sticker yet, here’s a bunch of people that picked one up while the promo was live. I haven’t seen anything calling out the end to the promo, but the page generates an error when you visit now.

If that still doesn’t satisfy your craving, then you might have a real problem and consider making some yourself.

Once you’ve been using PowerShell for awhile, it’s natural to want to spread the word. We frequently get questions asking for a standard “Introduction to PowerShell” slide deck, but haven’t really had one to share. The problem is that they tend to be pretty customized to the audience – even a “standard intro talk” becomes much more engaging when you target it to a specific audience.

However, those customizations tend to be centered around specific themes, so I’ve reduced a recent presentation to its core and attached it here. This presentation is demo-heavy. Talk all you want about objects, but it doesn’t really click until they see it in action.

A question came up on an internal discussion list today about how to let a cmdlet support both simple and detailed views. For example, a –Detailed flag to tell the cmdlet to emit additional information during the request.

The original approach was to do all of this filtering inside of the cmdlet. When –Details is not specified, run through some additional code to remove the extraneous properties.

The goal is noble, but the implementation decision is misguided.

One of the biggest accomplishments in getting your private pilot’s license is the “Solo Long Cross-Country.” It marks the home-stretch of a lot of training, practice maneuvres, landing drills, and solo flights of increasing complexity.

This flight is where it all comes together: 150 nautical miles total, landing at a minimum of 3 airports, with one leg at least 50 nautical miles.

I planned this flight as a tour of the San Juans and airports I have never been. It took me from Renton (RNT,) to Skagit Regional (BVS,) through Orcas Island (ORS,) Friday Harbor (FHR,) Sequim Valley (W28,) and then finally back to Renton.

One bit of feedback we frequently get is that PowerShell’s learning curve has some steeper bumps than we would like. Or simply, is strongly affected by habits learned from other languages or shells.

Interestingly enough, many of these problems aren’t new to us – we just don’t have a good way (aside from help) of exposing them to the user. This was something I touched on in the footnotes of a blog in 2005, and started implementing personally shortly after that. Here’s an example of its output:

One tension that sometimes arises in the PowerShell community is between the hard-core developers, and hair-on-fire administrators. As a broad technology, this tension and desire for balance drives our design decisions every day.

PowerShell is all about striking a balance between a range of experiences:

• Task oriented, and consumption-only. AKA “Copy and Paste Admin.”
• How do I use PowerShell to restart a computer?
• Problem oriented, and composition-based. AKA “Admin Scripter.”
• How do I collect a log file from a cluster of machines I need to parse out of a web page?
• Technology oriented, and interoperability-focused. AKA “Developer” / ISV
• How do I expose my product’s transacted object model to PowerShell users?

In general, the output of each category empowers the categories that come before it. As a product becomes PowerShell-enabled, admin scripters can then leverage the cmdlets and providers to solve their problems and scenarios. They might blog them, wrap them in a script or module, or otherwise share them. At that point, they become pre-packaged tasks ready for copy and paste.

Pain is Temporary

… Quitting lasts Forever.

I hadn’t heard this before yesterday, but it makes a good quote for the whiteboard!

Once problem that often arises when trying to manage machines is when the management layer itself is the thing you need to diagnose. For example, trying to diagnose Remote Desktop connectivity issues when port 3389 is blocked, or using PowerShell Remoting when WSMAN is misconfigured.

Alternatively, you might not have the client you need to manage the machine – such as an SSH client, or a version of PowerShell V2 installed.

If you have a PowerShell script that you are calling from cmd.exe, you might run into the following error:

Write-Host : The OS handle’s position is not what FileStream expected. Do not use a handle simultaneously in one FileStream and in Win32 code or another FileStream. This may cause data loss.

This is bug in PowerShell V1 and V2, and happens when:

• a PowerShell command generates both regular and error output
• you have used cmd.exe to redirect the output to a file
• you have used cmd.exe to merge the output and error streams

Note: This bug was fixed in December 2012 along with the release of Windows Management Framework 3.0. This is the version of PowerShell that ships with Windows 8. Applying this update will resolve your issue. You can also install Windows Management Framework 4.0, which is the version released with Windows 8.1.

Once in awhile, we get questions about the best practice for PowerShell’s execution policy when it is included as part of a standard desktop image.

This is one of the main reasons that PowerShell ships with a “Restricted” execution policy. Since you have to explicitly enable or install PowerShell, we’ve frequently been asked why we aren’t more permissive by default. After all, you did just install / enable it! The reason is that separating the execution policy decision from the installation decision gives you a lot more freedom on installing PowerShell. It lets you push PowerShell to your whole enterprise via SMS (or include on a standard image,) and then later selectively configure the Execution Policy via Group Policy or other mechanisms.