Use the PowerShell Registry Provider to Simplify Registry Access

Doctor Scripto

Summary: Microsoft Scripting Guy, Ed Wilson, shows how to use the Windows PowerShell registry provider to simplify access to registry keys and properties.

Hey, Scripting Guy! Question Hey, Scripting Guy! I know that I am not supposed to mess around with the Registry on my computer, but the simple fact is that many times there are Registry values that need to be changed. In addition, there are always lots of TechNet articles that talk about changing the registry. So here is my question: In the past I used WMI to modify Registry settings. It worked. In fact, it worked remotely, but it was pretty much a mess. Does Windows PowerShell make it easier to edit the registry?


Hey, Scripting Guy! Answer Hello MG,

Microsoft Scripting Guy, Ed Wilson, is here. This is a great time to be using Windows PowerShell. In Windows PowerShell 2.0, we got true remoting, which makes it easy to run a single command or a series of commands on one or more remote computers. In fact, you can open a Windows PowerShell console that targets a remote computer, and work as if you were logged on to the console. You may ask, “Why is Ed talking about remoting when I asked about the Registry?” Well, it is because of the way that you will work with the registry in Windows PowerShell. In Windows PowerShell 1.0, there was no remoting. This meant that if you wanted to edit the Registry on a remote computer, you might very well end up using the same WMI classes that you used in the VBScript days. (There were other ways, but for one coming from a VBScript background, using the WMI classes makes sense.)

Understanding the Registry provider

In Windows PowerShell 1.0, the Registry provider made it easy to work with the registry on the local system. Unfortunately, without remoting, you were limited to working with the local computer or using some other remoting mechanism (perhaps a logon script) to make changes on remote systems. With Windows PowerShell 2.0 the inclusion of remoting makes it possible to make remote registry changes as easily changing the local registry.

The Registry provider permits access to the Registry in the same manner as the file system provider permits access to a local disk drive. The same cmdlets that are used to access the file system (for example, New-Item, Get-ChildItem, Set-Item, and Remove-Item) also work with the Registry.

The two registry drives

By default, the Registry provider creates two registry drives. To find all of the drives that are exposed by the Registry provider, use the Get-PSDrive cmdlet. These drives are shown here.

PS C:\> Get-PSDrive -PSProvider registry | select name, root


Name                                       Root

—-                                       —-

HKCU                                       HKEY_CURRENT_USER

HKLM                                       HKEY_LOCAL_MACHINE


Additional registry drives are created by using the New-PSDrive cmdlet. For example, it is common to create a registry drive for the HKEY_CLASSES_ROOT registry hive. The code to do this is shown here.

PS C:\> New-PSDrive -PSProvider registry -Root HKEY_CLASSES_ROOT -Name HKCR


WARNING: column “CurrentLocation” does not fit into the display and was removed.


Name           Used (GB)     Free (GB) Provider      Root

—-           ———     ——— ——–      —-

HKCR                                   Registry      HKEY_CLASSES_ROOT


When created, the new HKCR drive is accessible in the same way as any other drive. For example, to change the working location to the HKCR drive, use the Set-Location cmdlet or one of its aliases (such as cd). This technique is shown here.

PS C:\> Set-Location HKCR:

To determine the current location, use the Get-Location cmdlet as shown here.

PS HKCR:\> Get-Location





When set, explore the new working location by using the Get-ChildItem cmdlet (or one of the aliases for that cmdlet such as dir). This technique is shown in the image that follows.

Image of command output

Retrieving Registry values

To view the values that are stored in a registry key, use the Get-Item or the Get-ItemProperty cmdlet. Using the Get-Item cmdlet reveals that there is one property (named default). This is shown here.

PS HKCR:\> Get-Item .\.ps1 | fl *

PSPath        : Microsoft.PowerShell.Core\Registry::HKEY_CLASSES_ROOT\.ps1

PSParentPath  : Microsoft.PowerShell.Core\Registry::HKEY_CLASSES_ROOT

PSChildName   : .ps1

PSDrive       : HKCR

PSProvider    : Microsoft.PowerShell.Core\Registry

PSIsContainer : True

Property      : {(default)}

SubKeyCount   : 1

ValueCount    : 1

Name          : HKEY_CLASSES_ROOT\.ps1

To access the value of the default property requires using the Get-ItemProperty cmdlet as shown here.

PS HKCR:\> Get-ItemProperty .\.ps1 | fl *


PSPath       : Microsoft.PowerShell.Core\Registry::HKEY_CLASSES_ROOT\.ps1

PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_CLASSES_ROOT

PSChildName  : .ps1

PSDrive      : HKCR

PSProvider   : Microsoft.PowerShell.Core\Registry

(default)    : Microsoft.PowerShellScript.1

 The technique for accessing registry keys and the values associated with them is shown in the image that follows.

Image of command output

To return only the value of the default property requires a bit of manipulation. The default property requires using literal quotation marks to force the evaluation of the parentheses in the name. This is shown here.

PS HKCR:\> (Get-ItemProperty .\.ps1 -Name ‘(default)’).'(default)’



MG, that is all there is to using the Registry provider in Windows PowerShell. Registry Provider Week will continue tomorrow when I will talk about creating and modifying registry keys.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy 


Discussion is closed.

Feedback usabilla icon