PowerShell 101, Lesson 6

In Windows PowerShell, you access folders and files by providing a pathname, such as C: Windows\System32. In this case, the pathname begins with C, which is the drive name. Whenever you access a file-system resource, you must provide the drive name, or the drive must be implicit within the context of the command, such as when you’re retrieving a list of objects in the current working location.

File-system drives aren’t the only type of drives that PowerShell supports. PowerShell supports a number of drives that provide access to different data stores. For example, as I demonstrated in Lesson 5, you use the Variable drive to access built-in variables and the Env drive to access environment variables.

In this last lesson of the PowerShell 101 series, you’ll learn about the available drives and how to implement them through PowerShell providers that facilitate access to the data stores. You’ll also learn how to work with PowerShell’s built-in drives and how to create additional drives. By the end of the lesson, you’ll know how to access not only the file system but also the certificate store, the registry, and other data stores.

Understanding PowerShell Providers
At the heart of data-store access lies the PowerShell providers. A provider is a Microsoft .NET program that provides a data-access layer between PowerShell and the data. Providers abstract data access so that you can use the same mechanisms within PowerShell to interact with the various stores. For example, you can use the Get-ChildItem cmdlet to access the file system, registry, and certificate store.

PowerShell supports a number of built-in providers. To view a list of providers currently available on your system, you can use the Get-PSProvider cmdlet in the command

Get-PSProvider | select Name

Table 1 lists the providers that currently ship with Power- Shell. Because PowerShell is extensible, custom providers can be developed to access other types of data stores. You can then install those providers and access the data stores as you would access the data stores supported by the built-in providers. However, a discussion about custom providers is beyond the scope of this article. See the about_provider Help file for information.

Despite the important role that providers play, they are, for the most part, invisible to you within PowerShell. What are visible, however, are the PowerShell drives you use to access the providers.

Working with the Built-In Drives
Providers expose data through one or more PowerShell drives. For example, the File- System provider exposes file-system data through PowerShell drives that have a direct correlation to your Windows drives. For instance, the FileSystem provider exposes your Windows C drive through the Power- Shell C drive.

To view a list of PowerShell drives and their associated providers, you can use the Get-PSDrive cmdlet, as shown in the statement

Get-PSDrive | sort Provider, Name

This statement sorts the results first by provider, then by name so that the providers are grouped together, as Figure 1 shows. Notice that on my system, the FileSystem provider supports six drives, the Registry provider supports two drives, and the other providers each support only one drive.

The preceding statement also displays root information. The root refers to the location within the target data store that the PowerShell drive maps to. For example, the HKCU drive maps to the HKEY_ CURRENT_USER hive in the registry. For drives that access nonhierarchical data stores, such as PowerShell aliases and variables, the root value is blank.

You can also use Get-PSDrive to retrieve information about a specific drive. For example, the following statement retrieves data about the Function drive:

Get-PSDrive Function | Format-List

As Figure 2 shows, this statement returns details such as the name of the provider and a description of the drive. Notice that the figure also shows the statement

Get-PSDrive -PSProvider Registry

Continue to page 2

   Previous  [1]  2  3  Next