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.
Hi there.
Great article. All examples worked, at least second time around. I've been following these articles and I enjoy them.
But give the referencesto web-cast on the topic. They are great fun, instrucional and not at least inspirational and motivating.
As for instance Sripting for dummies http://www.microsoft.com/norge/technet/spotlight/sessionh.aspx?videoid=214&PUID=000115874C3F7258 and
Windows, PowerShell, and Windows Management Instrumentation: Unveiling Microsoft's Best Kept Secret - Ben Pearce - 07/08/2008
http://www.microsoft.com/norge/technet/spotlight/sessionh.aspx?videoid=996
Try them. They are great.
Regards,
Martin T
Norway
Register
