Chapter 16. The Registry

You can navigate the Windows registry just as you would the file system because PowerShell treats the file system concept discussed in Chapter 15 as a prototype for all hierarchical information systems.

Topics Covered:

• Table 16.1: The most important commands for working with the registry
• "Provider": Locations Outside the File System
  • Available Providers
    • Table 16.2: Default providers
  • Creating Drives
    • Figure 16.1: Roots in the registry
• Searching the Registry
  • Recursive Search
  • Individual Registry Keys
    • Table 16.3: Properties of a Microsoft.Win32.Registry object (registry key)
  • How PowerShell Addresses Registry Keys
    • Figure 16.2: PowerShell settings in the registry editor
    • Values of Keys
    • Subkey of a Key
• Creating and Deleting Keys and Values
  • Table 16.4: Permitted ItemTypes in the registry
  • Deleting Keys with Contents
  • Setting, Changing, and Deleting Values of Keys
    • Adding New Values
      • Figure 16.3: Writing various data types in the registry
    • Reading Values
    • Deleting Values
    • Default Entry
  • Example: Extending the Context Menu
    • Executing and Editing PowerShell Scripts
• Permissions in the Registry
  • Taking Ownership
  • Setting New Access Permissions
  • Removing an Access Rule
  • Controlling Access to Subkeys
  • Revealing Inheritance
  • Controlling Your Own Inheritance

You can navigate the Windows registry just as you would the file system because PowerShell treats the file system concept discussed in Chapter 15 as a prototype for all hierarchical information systems:

The keys in the registry correspond to directories in the file system. However, key values don't quite behave analogously to files in the file system. Instead, they are managed as properties of keys and are displayed in the Property column. Table 16.1 lists all the commands that you require for access to the registry.

"Provider": Locations Outside the File System

PowerShell has a modular structure and uses what are called "providers," Which are responsible for a particular information store. In the last chapter, you used a file system provider so you'll need a registry provider if you want to access the Windows registry instead of the file system. In other respects, everything works the way it did in the last chapter. You use the same commands in the registry that you use in the file system.

Available Providers

Get-PSProvider retrieves a list of all installed providers. Your list could be longer than in the following example, because providers can be added later on. For example, PowerShell doesn't have its own provider for Active Directory.

What's interesting here is the "Drives" column, which names the drives that are managed by respective providers. As you see, the registry provider mounts the drives HKLM: (for the registry root HKEY_LOCAL_MACHINE) and HKCU: (for the registry root HKEY_CURRENT_USER). These drives work just like traditional file system drives. Try this out:

From this location, you could navigate through the "subdirectory" in exactly the same way you did through a genuine file system. The same special characters apply here as well. The symbol for the root directory "~" is unknown in the registry and generates an error.

While the other providers do not have a role in this chapter since we will be focusing on the registry, they are listed in Table 16.2 for reference.

Creating Drives

Registry provider provides access to the registry. You address them through drives. If you would like to see which drives are already used by registry provider, use Get-PSDrive with -PSProvider:

Here it might have struck your attention that the registry consists of more roots than just these two.

Figure 16.1: Roots in the registry

The root HKEY_CLASSES_ROOT is actually not an independent root but corresponds to HKEY_LOCAL_MACHINE\SOFTWARE\Classes. That means you could use New-PSDrive to create a new drive that has its starting point there:

You already have access to this registry branch. In fact, you could get direct access to any of the roots listed in Figure 16.1.

Searching the Registry

Using Dir, you can search the registry just like you did the file system in Chapter 15. Simply use the new drives that the registry provider uses. The drive HKCU: provides an overview of the contents of the HKEY_CURRENT_USER root key:

Redirect the result to Format-List if you'd rather list contents below each other:

Recursive Search

The registry provider doesn't support any filters so you may not use the Dir parameter -filter when you search the registry. However, the parameters -recurse, -include, and -exclude are supported; you used them in the last chapter to search the file system recursively. This works in the registry as well. For example, if you wanted to know the location of registry entries that include the word "PowerShell", you could search using:

This instruction searches the HKEY_CURRENT_USER root first and then the HKEY_LOCAL_MACHINE root. It finds all the keys that contain the word "PowerShell." Because there could be a large number of these, search for registry keys that have the word "PowerShell" in their names without using any wildcard characters. Search operations of this kind usually generate error messages because when you search, segments of the registry are read to which you may have no access authorization. To filter the messages out of the result, use the parameter -ErrorAction and set its value to SilentlyContinue:

Individual Registry Keys

Every element that Dir retrieves corresponds to a registry key (Microsoft.Win32.Registry object) that includes these important properties:

How PowerShell Addresses Registry Keys

Let's take a closer look at the allocation of individual properties to a real key. In the example, the HKLM:\Software\Microsoft\PowerShell\1 key is used and in Figure 16.2 shown as displayed in the registry editor. This is the registry location where PowerShell stores its internal settings.

Figure 16.2: PowerShell settings in the registry editor

Use Get-Item from within PowerShell to access the key:

As expected, the Name property retrieves the complete name of the key. Of greater interest are the properties that begin with "PS" and which PowerShell subsequently adds. They split the path of the registry key into various segments.

Values of Keys

Values of keys are in Figure 16.2 in the right column of the registry editor. There are three values. PowerShell reports just two values:

One value seems to be missing. You'll see which values PowerShell records if you look more closely at the Property property:

These names correspond to the names of values in Figure 16.2. The value (Default) is missing, and rightly so, because as you can see in Figure 16.2, the default value is empty. The registry editor, Regedit, reports: (value not set).

If you want to retrieve the contents of values, use Get-ItemProperty and pass the path from the PSPath property:

In this way, all the values of the registry key are automatically retrieved and displayed. As you see, along with usual properties, the value contains other properties added by PowerShell. You should access their corresponding properties if you want to retrieve only some particular values:

If you want to retrieve all the values of a key, without including the properties added by PowerShell, you could proceed as follows:

Subkey of a Key

In Figure 16.2, you can see in the left column that this key contains four subkeys. PowerShell also reports four subkeys:

Dir retrieves the names of subkeys. To accomplish this, pass to Dir the PowerShell path of the key that you find in the PSPath property:

Creating and Deleting Keys and Values

Use New-item or the md function to create new keys. Keys in the registry behave like directories in the file system.

But the two statements create a key that is completely empty: its default value is not defined. If you want to define the default value of a key, use New-Item instead of md, and specify one of the values in Table 16.4 as -itemType. Set the value of the default entry using the -value parameter:

If you want to delete a key, proceed the way you did in the file system and use Remove-Item or the short Del:

Deleting Keys with Contents

If a key name includes blank characters, enclose the path in quotation marks. Unfortunately, you can't create more than one key in one step the way you could in the file system. The parent key has to exist. That's why this statement has caused an error; the parent key, First key, was missing:

You have to split up the statement into several steps:

If you try to delete the First key now, you'll be queried, like you were in the file system, because the key includes subkeys and isn't empty:

Use the -recurse parameter to explicitly delete keys that have contents:

Setting, Changing, and Deleting Values of Keys

The registry editor distinguishes between keys and values in a well-structured way: keys are in the left column with values in the right. The keys correspond to directories in the file system, and values correspond to files in the directory. If you want to create a new key, use md as you did above or, even better, New-Item, and then use New-Item and the -itemType and -value parameters to assign a default value to your new key.

Adding New Values

Unfortunately, the file system analogy won't help you if you want to add additional values to a key, because normally you would use Set-Content to create new files inside a directory. But the registry provider is not the right tool:

Instead, use Set-ItemProperty to add new values to a key:

The values that you add in this way are automatically registered as REG_SZ values in the registry, that is, as a string. If you want to use another data type, use New-ItemProperty and the -propertyType parameter. It accepts the types listed in Table 16.4:

The registry editor shows the result in Figure 16.3.

Figure 16.3: Writing various data types in the registry

If you have the Microsoft.Win32.Registry object of a key available, you can add and read out additional values easily by using the SetValue() and GetValue() methods. When you use md or New-Item to create a new key, this object is what you will get as a result, and all you have to do is to save it so that you can add additional values to it in the next step:

Reading Values

Reading registry values is the only area in which the rules are not particularly clear. Normally, you would assume that values created using Set-ItemProperty could be read using Get-ItemProperty. Unfortunately, that's only partly true because when you use Get-ItemProperty, PowerShell retrieves not only the value you're looking for but also an object with extraneous PowerShell properties:

You'll get the information you want only when you explicitly retrieve the right property from the object that That is, Get-ItemProperty retrieves the name of the value that interests you. An incidental consequence is that the difference between the file types REG_SZ and REG_EXPAND_SZ becomes clear.

Because Entry3 was stored as a REG_SZ value, you will get the precise string value that was stored there when you read it. Entry4 is of the REG_EXPAND_SZ type. Windows automatically resolves environment variables contained in the string when they are retrieved. That's why the Windows directory was retrieved, instead of the environment variable.

Deleting Values

Use Remove-ItemProperty to remove a value. The next instruction deletes the Entry5 value that you created in the previous example:

Default Entry

The default entry of the key plays a special role. It is always shown in the right column under the name (default). But this entry is actually unnamed: it is the only value of a key that has no name.

The default value of a key doesn't have to be defined. If the value isn't set, the registry editor will display "value not set." Normally, you would set a value when using New-Item and the -value parameter to create new keys. But you can also directly address the value by the name (default):

Example: Extending the Context Menu

Entries in the registry can have widely varying consequences. Among others, this is where Windows sets the entries for the Explorer context menu. In the next example, you will, as a test, add three new commands to the context menu for PowerShell scripts: "Execute and Leave Open," "Execute and Close," and "Edit".

Executing and Editing PowerShell Scripts

To do this, you have to know first how to launch PowerShell scripts outside the PowerShell console. It's easy. First, create a little example script:

Inside the PowerShell console, invoke the script by typing its relative or absolute path:

But how to invoke PowerShell scripts outside the PowerShell console? Start powershell.exe and specify the -NoExit option so that the console will stay open after the script has been processed, allowing you to see and evaluate the results of the script. After the -Command parameter, specify the command line that PowerShell is supposed to execute. Enclose the path in single quotation marks and put the call operator in front of it because you don't know whether the path of the script contains blank characters. Put this command inside double quotation marks:

If you would like to edit a script, the command is much simpler: invoke the editor of your choice and pass the script to it:

The context menu extension will be entered into the registry next. This requires administrator privileges:

Permissions in the Registry

In Chapter 15, you learned in detail how to control permissions for files and directories. The same mechanisms also work in the registry as you could use Get-Acl to show current permissions of a key:

Because you manage permissions exactly the way you do in the file system, you should take another look at Chapter 15 and review the basics before assigning new permissions to a registry key.

The .NET classes that are required for permissions in the registry are a little different from the ones in the file system. Instead of a FilesystemAccessRule, you will need a RegistryAccessRule, and the fundamental difference between them is the diverging access rights that can be set in them. In a RegistryAccessRule, permissions do not correpond to the FilesystemRights enumeration, but to RegistryRights:

Taking Ownership

Make sure that you are the "owner" of the key before modifying key permissions as a test. Only if you are the owner you will be able to undo possible mistakes. This is how to take ownership of a registry key (to the extent that your permissions allow it):

Setting New Access Permissions

The next step is to assign new permissions to the key. The group "Everyone" is prohibited from making changes to this key:

The modifications immediately go into effect.Try creating new subkeys in the registry editor or from within PowerShell to check and you'll get an error message:

Removing an Access Rule

The new rule for Everyone was a complete waste of time and didn't stand the test. So, how do you go about removing a rule? You can use RemoveAccessRule() to remove a particular rule, and RemoveAccessRuleAll() to remove all rules of the same type (permission or restriction) for the user named in the specified rule. ModifyAccessRule() changes an existing rule, and PurgeAccessRules() removes all rules for a certain user.

To remove the rule that was just inserted, proceed as follows:

However, removing your access rule may not work the way you expect because you have now locked yourself out. Because you no longer have the right to modify the key, that also applies to changes to your security settings. You can correct the problem only if you take ownership of the key. If this occurs, open the registry editor, navigate to the key, and by right-clicking and then selecting Permissions open the security dialog box and manually remove the entry for Everyone.

Controlling Access to Subkeys

In the next example, you can do things better and use rules not on restrictions but on permissions. In the following test key, only administrators are supposed to be able to modify the values of the key. However, all others, may read the key:

Note that in this case the new rules were not entered by using AddAccessRule() but by ResetAccessRule(). This results in removal of all existing permissions for respective users. Nevertheless, the result still isn't right because normal users can still create subkeys in the key and write values:

Revealing Inheritance

Look at the current permissions of the key: to determine why your permissions may not be working the way you planned:

The key includes many more permissions than what you assigned to it so it gets these additional permissions by inheritance from parent keys. If you want to turn off inheritance, use SetAccessRuleProtection():

Now, when you look at the permissions, the key will contain only the permissions that you explicitly set so it no longer inherits any permissions from parent keys:

Controlling Your Own Inheritance

Inheritance is a sword that cuts both ways. You have just turned off the inheritance of permissions from parent keys, but what about your own inheritance permissions? Launch a PowerShell console with administrator privileges so that you can create additional subkeys for your protected key:

Then take a look at the permissions for these new subkeys:

The result doesn't correspond to the access permissions that you set. The reason: you specified None as inheritance. If you want to pass on your permissions to subdirectories, change the setting: