PowerShell Not your Father’s Command Line Part 11 of 31: PowerShell Providers and You!

imageOne of the great areas you can do a lot of work in PowerShell is with providers.  Providers are little .NET programs built-in to PowerShell that allow you to work with data structures that are not typically easy to access in the command prompt.  PowerShell has several built-in providers for your environment to work with data structures like the registry, Active Directory, certificate store, even the file system is considered a provider…etc.  To see a list of the Providers currently available to you on your system run the following cmdlet:


What makes working with providers extremely cool is that you navigate inside a provider like you navigate a file system, so commands like cd or dir will allow you to quickly move through these data stores.  Each provider will also have some unique tools or cmdlets to work directly with the specific provider.   In the next three posts Sarah and I will take you on quick tours through the registry, Active Directory and IIS providers.  You will get to some of the uniqueness first hand.  When you ran Get-PSProvider you may have noticed a column called capabilities.  The capabilities help to determine how the provider can be used, and what can be passed to the provider.  For example if you see credentials in the capabilities column, this will allow you pass credentials via the command line.  You can learn more about capabilities here: Windows PowerShell Provider Capabilities.

So how do you navigate into a provider?  Very similar to how you would navigate to a different drive on your file system you would use the follow base syntax, cd <provider>: If you wanted to change to the environment variables provider you would run the following command:

cd env:

This particular provider allows you to work with the environment variables.  Notice after you switch into the provider, the PowerShell prompt shows that you are in the provider, and will look something like this: PS Env:\> .  So what fancy command do you need to run to see a listing of the environment variables.  Remember providers allow you to navigate these data structures just like a file system, so your magic command:


(your results will look similar to below)


Now to work with the variables you will work with what I like to call the “item” cmdlets.  In fact when you ran dir, you actually used a item cmdlet, you may be aware dir is the alias for  …wait for it, wait for it: Get-ChildItem .  Get-ChildItem is a very useful cmdlet when you are working with all of the providers and even the entries in the providers.  If you want to see a specific variable you can run this command while in the provider,  this example will show you the value of the windir variable:

Get-ChildItem windir

You could also run dir windir when you are in the provider and it would yield the same results.  So a couple of useful cmdlets for working with providers in general in addition to Get-ChildItem are these two:

  • New-Item  is used primarily used to create new items, and can be used in the various providers, although some providers like Active Directory may have some dedicated cmdlets to work with the specific roles or functions.  In the env: provider the following command would create a temporary new-item called test with the value of true: New-Item test-value true
  • Set-Item is used to change the values of existing items in the providers (also if the value does not exist it will create one), the following command would change the value of the test environment variable to False: Set-Item test –value false

Lastly you can also use Remove-Item to delete an entry for the current session or Clear-Item will delete the item.  This post introduced the concept of providers, and each provider is can be very different.. As you will see in the next few posts, there will be variations to how you can work with specific providers, but they will follow the basic principles.

Again thanks for reading and if you missed any of the previous posts you can find a master list of series postings located here: PowerShell Not Your Father's Command Line: 31 Days of PowerShell or on Sarah’s blog here: PowerShell Not Your Father's Command Line: 31 Days of PowerShell. Lastly Sarah and I want to hear from you email either of us with your comments or suggestions for future postings let us know, we look forward to hearing from you. Have a great day!

Comments (0)

Skip to main content