This category contains my articles that, in one way or another, include the usage of PowerShell. That’s a lot of posts – such a large share of what I write about contains different configuration steps, and those are most often easiest to do with PowerShell.

While most of the time there’s a configuration option available using the GUI as well, creating a reusable and debuggable script is generally speaking the preferred option for me.

But what is PowerShell, exactly? If you’re reading this blog, you probably already know I’m not the biggest fan of reinventing the wheel – so I’m not going to reinvent the definition, either. The following is adapted from Microsoft’s documentation for PowerShell:

Windows PowerShell (PowerShell, or PoSh for short) is a Windows command-line shell that includes an interactive prompt and a scripting environment that can be used independently or in combination.

Unlike most shells, which accept and return text, Windows PowerShell is built on top of the .NET Framework common language runtime (CLR) and the .NET Framework, and accepts and returns .NET Framework objects. This makes it a powerful tool for most configuration and automation tasks.

Windows PowerShell introduces the concept of a cmdlet (pronounced “command-let”), a simple, single-function command-line tool built into the shell. You can use each cmdlet separately, but their power is realized when you use these simple tools in combination to perform complex tasks. Straight out of the box there’s over a hundred basic core cmdlets, and you can write your own cmdlets and share them with other users.

The Power of PowerShell certainly does NOT come from the environment itself or the built-in commandlets – not at all. It comes from the hugely useful modules written and published by vendors and community. The ones I mostly use are probably the modules for Azure, SharePoint, Exchange and PnP commandlets.