According to Microsoft's documentation, PowerShell providers "provide access to data and components that would not otherwise be easily accessible at the command line." A PowerShell provider and its associated PowerShell drives are a unique concept. Knowing that a lot of data is represented hierarchically, Microsoft created this concept of PowerShell providers and drives to treat all kinds of data like a file system drive.

As you probably know, a file system comprises a hierarchical structure of files and folders with one or more files being in a folder. It's hierarchical because we can nest folders inside other folders.

If you think about this, this nesting concept also extends to many different types of data such as the registry (keys and values), Active Directory (forests, domains, and organizational units), certificates (certificate stores and certificates), and so on. We can represent each, and everyone is familiar with how to browse a file system. Why not represent these data types just like the file system?

PowerShell comes with eight default providers. Other than the apparent file system, you can "cd" into the certificate store, the registry. or even get meta by browsing around via the defined functions and aliases within PowerShell itself.

PowerShell providers

PowerShell providers

You can't access a PowerShell provider directly. The provider is merely the "translator" between the data source and the user. To interact with the data the provider exposes, you use PowerShell drives. A provider can host one or more drives. It's similar to a file system drive like C:, which is, in fact, a PowerShell provider itself. A PowerShell drive allows a user to navigate a data source just like the file system.

PowerShell drives

PowerShell drives

For example, the registry provider by default exposes two drives: HKCU and HKLM. These drives represent registry hives, which contain keys and values.

PS C:\> Get-PSDrive -PSProvider Registry | ft -a

Name Used (GB) Free (GB) Provider Root               CurrentLocation
---- --------- --------- -------- ----               ---------------
HKCU                     Registry HKEY_CURRENT_USER
HKLM                     Registry HKEY_LOCAL_MACHINE

I can navigate into the registry just as I would a file system by using Get-ChildItem. You can see below that I can reference the HKEY_LOCAL_MACHINE hive by using HKLM: and then specifying the key SOFTWARE. This returns all the keys and values underneath that parent key.

PS C:\> Get-ChildItem -Path HKLM:\SOFTWARE\


Name                           Property
----                           --------
7-Zip                          Path64 : C:\Program Files\7-Zip\
                               Path   : C:\Program Files\7-Zip\

Likewise, I could do the same with the Certificate PowerShell drive too. You can see below that the certificate locations (current user and local machine) are at the top of the hierarchy. I can then drill down into those locations, which then exposes the individual certificate stores as well.

PS C:\> Get-ChildItem -Path cert:\

Location   : CurrentUser
StoreNames : {TrustedPublisher, ClientAuthIssuer, Root, UserDS...}

Location   : LocalMachine
StoreNames : {TrustedPublisher, ClientAuthIssuer, Remote Desktop, Root...}

PS C:\> Get-ChildItem -Path Cert:\LocalMachine\

Name : TrustedPublisher

Name : ClientAuthIssuer

Name : Remote Desktop

Name : Root

Even though you can do a lot with the built-in PowerShell providers and drives, developers can create custom drives as well. For example, the information in Dropbox would make a great provider and drive, right?

We can see from Jim Christopher who built a Dropbox provider, we can represent any source of hierarchical data with a PowerShell provider. Another example is Azure SHiPS. Imagine how much data is in Azure! Azure SHiPs is an excellent example of how extensible the provider model is.

Subscribe to 4sysops newsletter!

PowerShell providers are like data translators. They can understand all sorts of hierarchical data and can represent that data via drives. This way of presenting data to users cuts down on the complex tasks that sometimes go into navigating information. By using a provider, we can manage data more intuitively and can significantly reduce the learning curve.

1 Comment
  1. Alvaro Torres 4 years ago

    Great post Adam. If someone wants to write a custom PSProvider, SHiPS and simplex are a good studying material or better extend it and you’ll save a lot of time.

Leave a reply

Your email address will not be published.


© 4sysops 2006 - 2022


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account