Deciphering PowerShell Providers
The mere word “provider” can send a shiver down your spine. This is especially true as you contemplate an abstract concept that only developers truly understand. The word is really only a fancy word for adapter or translator.
Read the Best Personal and Business Tech without Ads
Staying updated on what is happening in the technology sector is important to your career and your personal life but ads can make reading news, distracting. With Thurrott Premium, you can enjoy the best coverage in tech without the annoying ads.
A PowerShell provider translates a storage system into a concept familiar to developers and non-developers alike, a disk drive. PowerShell comes with a few providers built in, which you can display with the get-PSProvider cmdlet. You will see provider names for stores that you are already familiar with in Windows. In addition, you can also see which built-in drives are accessed by which provider. Besides the C drive, which is listed under the FileSystemProvider, the rest of these “drives” are not actual drives. Many are stores that Windows administrators are familiar with.
Navigating a FileSystem Drive
All the drives have a similar structure:
- They all have a root or entry point into the drive, also known as the parent.
- They can all have children.
- The type of children varies by provider. Typically, there are two types of children, container children and endpoint children.
The simplest example is a filesystem drive. It has a root and the drive or mount point itself. It can have a container child/directory or an endpoint child/file. You navigate the file system using the cd alias, the set-location cmdlet to move between folders, and the dir alias or the get-childitem cmdlet to list the files.
How Do Providers Help Me?
The providers create that translation between the storage system and “disk drive” but it also provides a common set of cmdlets and aliases to access them. For example, I am going to try to change directories (cd) from my C:\temp folder into the HKEY_LOCAL_MACHINE/SYSTEM part of the registry. I am going to try to list its contents using dir.
Wow. This works but why? It is because the registry provider provides that interface between the registry and the registry appearing like a drive inside PowerShell. Therefore, the SAME cmdlets or aliases can be used to navigate any of the “drives” that have a provider to translate for them.
Different Providers — Same Cmdlets
Not only do the navigation cmdlets work for all the drives, but the cmdlets to query, create, modify, and delete items are the same within each drive. I have hinted at the syntax by using the word item. The get-item, get-childitem, new-item, set-item, and remove-item cmdlets allow item manipulation under any of the drives. For example, I created a new file item, new registry item, and new alias item all using the new-item cmdlet.
In the first example, new-item file.txt creates a file object. In the second example, new-item HKCU:/test creates a new subkey that is named test. In the third example, new-item fails because the provider for alias requires a value along with the path. It needs the alias itself and it needs a value. The cmdlet needs to run when the alias is used.
Same Cmdlet — Different Behaviors
In prior versions of PowerShell, new-item required a type parameter. Using the example of a new-item to create a file, new-item file.txt would have prompted for a type of directory or file. In later versions of PowerShell, the type defaults to file. If you need to specify a type, you can specify file, directory, symboliclink, or a few other types. When using new-item to create a registry subkey, the itemtype is to denote a registry value type, such as DWORD or STRING. For a new alias, the ItemType parameter is not even used. If I specify an itemtype of blah, the parameter is ignored. It all depends on what the provider requires or allows.
Actions Not Supported
Some cmdlets do not make sense in the context of a certain provider. For this reason, some cmdlets will return errors stating that the provider does not support the action or other descriptive error when you run it. For example, get-itemproperty makes sense in the context of a file. Files have many properties, such as create and modify date, read-only, and hidden switches. Get-ItemProperty makes less sense in the context of a registry subkey but it returns the child items. It also returns some provider information about the subkey. Running Get-ItemProperty against the alias drive will return an error that the iPropertyCmdletProvider interface is not supported. Therefore, providers may not always support every one of the cmdlets.
Take Time to Explore
The important concept to grasp here is that providers translate between something unfamiliar, a distinct data layout, and something familiar, a disk drive layout. This translation is also shown in a set of cmdlets used to access the familiar layout, *-item and *-itemproperty cmdlets. Required parameter cmdlets vary by provider and not every provider has an interface for every cmdlet. Take the time to explore and experiment with these cmdlets. As a result, you can become more familiar with the similarities and differences among the providers. Become familiar with these cmdlets and you will be able to retrieve the information you seek.