All about PowerShell providers and modules

I think it’s time to talk in depth about some of the most important features of PowerShell: Providers and modules. (Snap-ins have also been important, but they are being gradually phased out.) These are really the core of the universe when it comes to all of the commands available for use within PowerShell, so I want to teach you what they are, how they work and how to use them in your daily activities. Let’s dive in!

When you hear the term “providers,” I bet the non-developers among us (and I include myself in this group) start to tune out. That sounds like something you do along with creating a class and instantiating a for-loop with strings that pass through a model view controller.

But that’s not the case here. Let me unpack this for you a little bit, at least in the context of PowerShell.

PowerShell providers are essentially like drivers for the operating system, where you install some code to help your copy of Windows talk to the graphics hardware, the storage and disk subsystems, and the chipset on your motherboard. The drivers contain the “translation layer,” which is not an official term, so that Windows knows how to drive the hardware and make it work for your use.

PowerShell providers are drivers for PowerShell to navigate things besides the file system. Providers allow PowerShell to traverse the Registry, the File System, Windows Management Instrumentation (WMI) functionality, and more. Third parties can create providers: For example, there is a SQL Server provider that Microsoft installs that lets you do PowerShell operations on databases.