Summary: Microsoft Scripting Guy, Ed Wilson, talks about finding and using Windows PowerShell providers.  Hey, Scripting Guy! I recently heard a Windows PowerShell MVP say that understanding the Windows PowerShell provider system is fundamental to understanding Windows PowerShell. I think I am in trouble because I have no idea what he is talking about. Can you throw a fella a bone? —DP  Hello DP, Microsoft Scripting Guy, Ed Wilson, is here. I am sipping a rather bland cup of tea, but I don’t care because it is a great day. In fact, the weather in Charlotte, North Carolina was rather cold and rainy last week, and today, is also turning out to be nice. What makes it a great day? Well, I am at the Microsoft Office in Charlotte for the PowerShell Summit. That is right. It kicks off this morning, and it is a veritable Who’s Who of Windows PowerShell greats, including several way cool people from the Windows PowerShell team and nearly half of all the Windows PowerShell MVPs. I mean, this is Posh Geek Paradise (hmmmm…PGP…I wonder if that acronym is available). So who cares if the tea is weak because the day is awesome. DP, welcome to Provider Week on the Hey, Scripting Guy! Blog. And in fact, Windows PowerShell MVP, Jim Christopher, is presenting a session this afternoon called “Simplex: Stupid Simple Providers.”

Note  This year, all Windows PowerShell Summit sessions are being recorded. They will be posted on the PowerShell.org channel on YouTube. 

What is a Windows PowerShell provider?

A Windows PowerShell provider is basically a sort of abstraction layer that hides the complexities of different types of information stores. This means that by using a Windows PowerShell provider, I can access different types of data in exactly the same way. Because the Windows PowerShell team opened Windows PowerShell providers to developers, anyone can create a new provider to permit one to access data easily by using a standard set of Windows PowerShell cmdlets. In the past, creating a new Windows PowerShell provider was rather complicated, and there was not really easy documentation to show how to do the job properly. But with Jim Christopher’s provider project, this is no longer the case—it is actually pretty easy (even for non-developers) to create new providers. So what kinds of data do Windows PowerShell providers provide access to? One way to get an idea is to use the Get-PSProvider cmdlet and look at what returns. Here is an example:

PS C:WindowsSystem32WindowsPowerShellv1.0> Get-PSProvider

Name                 Capabilities                       Drives                           

—-                 ————                       ——                           

Alias                ShouldProcess                      {Alias}                          

Environment          ShouldProcess                      {Env}                            

FileSystem           Filter, ShouldProcess, Credentials {C, E, D}                        

Function             ShouldProcess                      {Function}                       

Registry             ShouldProcess, Transactions        {HKLM, HKCU}                     

Variable             ShouldProcess                      {Variable}                        Each Windows PowerShell provider exposes a drive called a PSDrive. The PSDrive is then used to display the data that is exposed via the Windows PowerShell provider. So by default, I have access to the Alias, Environment, FileSystem, Function, Registry, and Variable providers. But there are more. Two providers, the WSMan and the Certificate providers do not load by default. This is for performance reasons. When I access the drive, the provider loads. In the following example, I access the WSMAN and the Cert drives and force the respective providers to load.

PS C:WindowsSystem32WindowsPowerShellv1.0> sl wsman:

PS WSMan:> Get-PSProvider

Name                 Capabilities                       Drives                           

—-                 ————                       ——                           

Alias                ShouldProcess                      {Alias}                          

Environment          ShouldProcess                      {Env}                            

FileSystem           Filter, ShouldProcess, Credentials {C, E, D}                        

Function             ShouldProcess                      {Function}                       

Registry             ShouldProcess, Transactions        {HKLM, HKCU}                     

Variable             ShouldProcess                      {Variable}                       

WSMan                Credentials                        {WSMan}                            

PS WSMan:> sl cert:

PS Cert:> Get-PSProvider 

Name                 Capabilities                       Drives                           

—-                 ————                       ——                           

Alias                ShouldProcess                      {Alias}                          

Environment          ShouldProcess                      {Env}                            

FileSystem           Filter, ShouldProcess, Credentials {C, E, D}                        

Function             ShouldProcess                      {Function}                       

Registry             ShouldProcess, Transactions        {HKLM, HKCU}                     

Variable             ShouldProcess                      {Variable}                       

WSMan                Credentials                        {WSMan}                           

Certificate          ShouldProcess                      {Cert}                            The name of the Windows PowerShell provider provides clues as to the type of information that it exposes. For example, the Certificate provider exposes certificate data from the certificate store, the Registry provider exposes the HKLM and the HKCU registry hives, and the WSMan provider exposes the WSMan configuration data. The Alias, Environment, Function, and Variable providers are all single layers. That is, there are no subdirectories in the stores of information. All of the other providers, however, are multiple layers. The file system is used as the model for all Windows PowerShell providers. I navigate the Registry in the same way that I would navigate the file system on my laptop. For example, I change my working directory to the C:FSO folder. I then create new files, rename other files, and delete some additional files. I then go to the C:Program Files folder to check on some other things or to copy folders and subfolders to a different location. I can use the same methodology with the other providers. For example, I can set my working location to the HKCU:Software folder, obtain a directory list of all the subfolders, and copy stuff to a different location for backup purposes. I create new registry keys the same way that I create a new file or folder. Because the Windows PowerShell provider system is extensible (meaning others can create additional providers), I do not need to learn new techniques to work with the data exposed via their providers. For example, in addition to Jim Christopher’s project, the Microsoft SQL Server and Active Directory teams created providers (see Introduction to the SQL Server 2012 PowerShell Provider and Playing with the AD: Drive for Fun and Profit). So what cmdlets should I become familiar with if I want to work with Windows PowerShell providers? Here is a list:

DP, that is all there is to using Windows PowerShell providers. Provider Week will continue tomorrow when I will talk about way more cool stuff. I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy