Section 1.3. Access the Registry Like a Filesystem

1.3. Access the Registry Like a Filesystem

Historically, command-line shells have been intimately tied to the filesystem. With a well-defined hierarchical structure, commands are provided to move up, down, and around; work on items at some location within; or even to extend or contract the structure. Many years have shown a hierarchy is an effective representation of a data store, even if it does introduce a few problemsfor example when trying to manipulate a set of items scattered in different locations throughout the tree.

Of course, it hasn't always been possible to look at a filesystem in the single consolidated manner that we enjoy today. Even with the variety of stores and protocols now in usefrom FAT, NTFS, and CIFS to ISO9660modern operating systems abstract the differences away from us, leaving a single, simple view of hierarchical folders and files. MSH takes this concept a step further and embraces other hierarchical data stores, such as the registry, to enable us to navigate around them and act within them as if they were a simple folder structure on disk. As we're about to see, this makes many tasks much easier.

In MSH, a provider forms the abstraction layer that exposes a hierarchical store to the shell as another drive. In addition to the familiar A, C, and D drives, you can now see drives representing environment variables, MSH functions, shortcuts to My Documents, and parts of the registry. This list isn't fixed and drives can be added, each backed by a different provider.

Let's take a look at the simple example of Windows Notepad and how to change its configuration via the registry.

I Thought the Registry Was a Move Away from the Filesystem...

The MSH provider model isn't a throwback to the days of filesystem-based configuration. Instead, making the store look like a regular disk drive allows us to use a single toolset to manipulate a wide range of information stored in disparate locations.

Just think: a script designed to walk through a folder structure doing a global search and replace can now do exactly the same via the registry with few, if any, changes.

1.3.1. How Do I Do That?

The registry is divided into five primary divisions known as hives , two of which we'll look at here. HKEY_LOCAL_MACHINE (often abbreviated to HKLM) stores system-wide settings shared by all users of the machine. HKEY_CURRENT_USER (HKCU) contains the current user's settings and user-specific information.

When it starts, MSH installs two additional drives (named hkcu: and hklm:) that map to these two hives. You can start browsing around them right away:

     MSH D:\MshScripts> cd hkcu:     MSH D:\MshScripts> dir     SKC  VC ChildName                      Property     ---  -- ---------                      --------       2   0 AppEvents                      {}       0  31 Console                        {ColorTable00, ColorTable01,                                             ColorTab...      23   1 Control Panel                  {Opened}       0   3 Environment                    {MSHCOMMANDPATH, TEMP, TMP}       1   6 Identities                     {Identity Ordinal, Migrated5, Last                                             Us...       2   0 Keyboard Layout                {}       0   0 Network                        {}       1   0 Printers                       {}       5   0 Software                       {}       0   0 UNICODE Program Groups         {}       0   1 SessionInformation             {ProgramCount}       0   7 Volatile Environment           {LOGONSERVER, CLIENTNAME,                                             SESSIONNAME...

For comparison, it's easy to see the relationship between this output and the tree structure shown in the Registry Editor tool (regedit.exe), as displayed in Figure 1-1.

Figure 1.1. Registry Editor

Notepad stores its per-user settings in the HKCU hive under the \Software\Microsoft path. We can navigate to that path with a simple cd and use the get-property cmdlet to view its content:

     MSH D:\MshScripts> cd hkcu:\Software\Microsoft\Notepad     MSH D:\MshScripts> get-property .     lfEscapement         : 0     lfOrientation        : 0     lfWeight             : 400     lfItalic             : 0     lfUnderline          : 0     lfStrikeOut          : 0     lfCharSet            : 0     lfOutPrecision       : 1     lfClipPrecision      : 2     lfQuality            : 2     lfPitchAndFamily     : 49     iPointSize           : 100     fWrap                : 0     StatusBar            : 0     fSaveWindowPositions : 0     lfFaceName           : Lucida Console     szHeader             : &f     szTrailer            : Page &p     iMarginTop           : 1000     iMarginBottom        : 1000     iMarginLeft          : 750     iMarginRight         : 750     fMLE_is_broken       : 0     iWindowPosX          : 88     iWindowPosY          : 88     iWindowPosDX         : 600     iWindowPosDY         : 411

Return to REGEDIT for a moment and it's easy to see that this output directly corresponds to the content of the righthand pane when the Notepad node is selected. Notepad uses the lfFaceName key to store the font used for displaying content. We'll use the set-property cmdlet (notice we're using the same noun, just a different verb) to change this value to Verdana:

     MSH D:\MshScripts> set-property . -property lfFaceName -value "Verdana"

Now when we start Notepad, it'll load the new setting from the registry for the content area and display it in a different font, as seen in Figure 1-2.

1.3.2. What About...

...Using this approach to configure any application? It depends. Applications can store configuration settings in many places, such as XML files, INI files, Active Directory, and the registry. Each application may pick a different

Figure 1.2. Windows Notepad

approach that works well for its specific scenario, but this doesn't guarantee any consistency. Even applications that don't wholly rely on the registry don't follow one single format or naming convention in use, although typically you'll find settings under \Software\[Vendor name]\[Application name]. You can use the graphical REGEDIT tool or the commands we've seen here to explore the registry further.

Although we've only looked at the registry provider in this section, the same process works for other stores with providers offered by the shell.

At this point, it's fair to ask, "Aren't there other tools for this?" and "What about Group Policy and SMS?" Indeed, there are many tools on the Windows platform for application management that excel at their tasks. MSH isn't designed to replace those; instead, MSH levels the field, allowing immediate interactive exploration of the system. Group Policy and SMS are invaluable in large automated deployments, and MSH can be considered a complement for day-to-day administration. Use MSH if it makes sense for a task, but remember it supports, rather than replaces, the suite of management tools available today.

1.3.3. Where Can I Learn More?

The Windows registry is described in more detail at http://support.microsoft.com/default.aspx?scid=kb;EN-US;256986. As the article notes, changing values in the registry is not a subject to be taken lightly. Be sure you know which values you're changing and the effect they'll have before making any changes to production machines.

The get-provider cmdlet lists the providers currently registered with MSH, along with the drives that use them. Similarly, get-drive will list all physical drives (hard disks, removable media), as well as those relying on provider-based systems.

Moving on, it's time to take a look at some of the fundamental changes to the pipeline in MSH.