Find and Use Windows PowerShell Providers

Doctor Scripto

Summary: Microsoft Scripting Guy, Ed Wilson, talks about finding and using Windows PowerShell providers. Hey, Scripting Guy! Question 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 Hey, Scripting Guy! Answer 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:

Name

Synopsis                                                           

Get-PSProvider

Gets information about the specified Windows PowerShell provider.    

Drive cmdlets

 Work with Windows PowerShell drives

Get-PSDrive

Gets drives in the current session.                                  

New-PSDrive

Creates temporary and persistent mapped network drives.              

Remove-PSDrive

Deletes temporary Windows PowerShell drives and disconnects mapped network drives.                                                          

Location cmdlets

Work with current location

Get-Location

Gets information about the current working location or a location stack.                                                               

Pop-Location

Changes the current location to the location most recently pushed to the stack. You can “pop” the location from the default stack or from a stack that you create by using the Push-Location cmdlet.      

Push-Location

Adds the current location to the top of a location stack.

Set-Location

Sets the current working location to a specified location.           

Item cmdlets

Work with items exposed via providers

Clear-Item

Deletes the content of an item, but does not delete the item.       

Clear-ItemProperty

Deletes the value of a property, but does not delete the property.    

Copy-Item

Copies an item from one location to another.                         

Copy-ItemProperty

Copies a property and value from a specified location to another location.                                                            

Get-Item

Gets files and folders.                                              

Get-ItemProperty

Gets the properties of a specified item.                             

Invoke-Item

Performs the default action on the specified item.                   

Move-Item

Moves an item from one location to another.                          

Move-ItemProperty

Moves a property from one location to another.                       

New-Item

Creates a new item.                                                  

New-ItemProperty

Creates a new property for an item and sets its value.

Remove-Item

Deletes files and folders.                                           

Remove-ItemProperty

Deletes the property and its value from an item.                     

Rename-Item

Renames an item in a Windows PowerShell provi der namespace.          

Rename-ItemProperty

Renames a property of an item.                                       

Set-Item

Changes the value of an item to the value specified in the command.  

Set-ItemProperty

Creates or changes the value of a property of an item.               

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

0 comments

Discussion is closed.

Feedback usabilla icon