|
Executive Summary: In Windows PowerShell, providers facilitate access to data stores, such as the Windows file system and registry. Despite their important role, providers are, for the most part, invisible to you within PowerShell. What are visible, however, are the PowerShell drives you use to access the providers. In this lesson, you'll learn about the available drives and how to implement them. |
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
In this case, Get-PSDrive returns a list of drives associated with the Registry provider.
After you know what drives are available, you can access those drives within your commands. For example, you can change your working location to the Env drive with the statement
cd Env:\
This statement uses the cd alias to reference the Set-Location cmdlet. Figure 3 shows how the command prompt now reflects the new location. Once in that folder, you can run other PowerShell commands, such as
dir | where \{$_.Name -like “*path*”\}
In this command, I use the dir alias to reference the Get-ChildItem cmdlet, then filter out all variable names that don’t contain the string path. The results in Figure 3 show that the Get-ChildItem cmdlet works the same as if this were a file-system drive.
You can access any drive type from any other drive type. For example, the following statement retrieves a list of objects in the HKCU drive:
dir HKCU:\
As you can see in Figure 4, Env is still my working location, but the results are pulled from the HKCU drive.
You can also change to any drive type from any drive type. For example, the following command changes the working location to a registry key:
cd HKCU:\Software\Microsoft\Office\
As this command shows, not only can you change to a different drive, but you can also change to folders within that drive, whether it’s in the registry, the file system, or another hierarchical data store. In this case, I’ve set the working location to HKEY_CURRENT_ USER\Software\Microsoft\Office.
It also doesn’t matter whether you access data through different providers or the same provider. For example, the following statement retrieves information from a registry key in a different hive:
dir HKLM:\Software\Microsoft\Office\
By using PowerShell drives, you can jump from location to location without taking any special steps, as shown in Figure 5.
To view specific information about an item such as a registry key, you can use the Get-ItemProperty cmdlet. The following statement retrieves information about the HKEY_LOCAL_MACHINE\Software Microsoft\ASP.NET key:
Get-ItemProperty ` HKLM:\Software\Microsoft\ASP.NET
As you can see in Figure 6, the statement retrieves a list of properties and their values. Notice that the results also include Power- Shell-specific information, such as the name of the PowerShell drive and provider.
Besides using the PowerShell built-in drives to retrieve data, you can use them to take any action applicable to the data store. For example, you can use the New-Item cmdlet to create an object in the registry:
Continue to page 3
New-Item ` HKLM:\Software\Microsoft\TestKey1
This command creates the TestKey1 key in HKEY_LOCAL_MACHINE\Software\Micro soft. Figure 7 shows this command’s results.
After you create the key, you can use the New-ItemProperty cmdlet to add a property to the key. (Adding a property in PowerShell is the same as adding an entry in the registry editor.) The following statement adds the TestProperty property to TestKey1:
New-ItemProperty ` HKLM:\Software\Microsoft\TestKey1 ` -Name TestProperty -PropertyType string ` -Value “test value”
The added property has a value of test value, which is a string data type. When you run the statement, PowerShell returns a list of all properties and their values. As Figure 7 shows, the new property has been added.
You also can take other actions through the PowerShell drives. For example, the following command uses the Rename-Item cmdlet to rename TestKey1 to TestKey2:
Rename-Item ` HKLM:\Software\Microsoft\TestKey1 ` TestKey2
In this command, the first argument identifies the original key and the second argument provides the new name. You can also use the Remove-Item cmdlet to remove a registry key:
Remove-Item ` HKLM:\Software\Microsoft\TestKey2
As these statements demonstrate, working with a registry drive is similar to working with a file-system drive. You can just as easily use the New-Item, Rename-Item, and Remove Item cmdlets with files and folders—or items in any other drive for that matter.
Creating PowerShell Drives
Up to this point, I’ve shown you only statements
that use the built-in PowerShell
drives. However, you can also create drives
based on existing providers. This can be useful
when you want to simplify commands
that you use often.
To create a PowerShell drive, you use the New-PSDrive cmdlet. For example, the following statement creates a drive named ps:
New-PSDrive -Name ps ` -PSProvider FileSystem -Root $pshome
The statement identifies the name of the new drive, then the provider, and finally the root. In this case, I use the PSHOME built-in variable to retrieve the PowerShell home folder name. When you run this statement, PowerShell creates the drive and displays information about the drive, as shown in Figure 8. Notice that PowerShell displays the actual root name, not the variable name. (For more information about variables, see Lesson 5.)
After you’ve created your drive, you can use it just like the built-in drives. For example, the following statement changes the working location to the ps drive:
cd ps:\
As Figure 8 shows, the PowerShell command prompt reflects the name of the new drive. You can now work in this drive as though you had changed the working location to C:\Windows\system32\Windows PowerShell\v1.0.
To test whether you’re working in the correct folder, you can run the Get-ChildItem cmdlet. Figure 9 shows you the type of results you should expect. Notice that the results include the correct name of the working location. (In this example, PowerShell is running on a Windows XP computer. If you run PowerShell on a different OS, you might see different results because the Power- Shell home directory is set up differently for different OSs.)
PowerShell also includes the Remove- PSDrive cmdlet, which lets you remove user-defined drives. To use the cmdlet, you must be in a working location other than the one you want to delete. For example, the following code changes the working location, then deletes the ps drive:
cd C:\; Remove-PSDrive ps
Note that any drives you create within a session persist only until you end that session, so you don’t need to remove a drive unless you have a reason to explicitly delete it. For example, you might want to simplify your list of available drives when you’re no longer using a particular drive. You can persist custom drives across sessions by modifying your profile file. In a later lesson, you’ll learn how to create and customize profile files. However, if you’re anxious to learn more about profile files now, see the TechNet article “Window PowerShell Profiles” (technet.microsoft.com/en-us/library/cc162758.aspx).
That’s All for Now
In this lesson, I introduced you to Power-
Shell providers and drives. As the examples
demonstrate, you can access a number of
data stores in a manner similar to accessing
files and folders. In addition, because
PowerShell uses providers and drives, the
methods used to access data are consistent
among the data stores. In fact, much of
what you’ve learned in the PowerShell 101
series can be applied to the various drives.
When the PowerShell 201 series begins,
you’ll be able to use the information from
this lesson as well as the other lessons to
create complex statements that can access
and manipulate a wide range of resources.