Please feel free to provide feedback or file bugs here.

We need a proper set of built-in, easy-to-use, dedicated registry cmdlets

Managing registry keys and values on local and remote systems with PowerShell is a pain.

Reviewing the articles, forums and blogs on the Internet clearly shows that new PowerShell users struggle to understand how to use registry provider drives and the cmdlets like New-Item, Get-ItemProperty, New-ItemProperty, and so on. This has prompted the creation of a variety of home-brew modules and functions to deal with the problem, like this one, which is extremely useful, but is not built into PowerShell by default of course:

PowerShell needs a proper set of built-in, dedicated registry cmdlets that 1) are easy to understand and use, even by PoSh newbies, 2) work on both local and remote registries, 3) can handle default values in keys, 4) can create the entire subkey path to a target value in one shot, 5) can create and set a value in one shot, 6) can handle all registry value types, including REG_BINARY, 7) export and import entire branches, 8) query and edit registry key permissions, and 9) which handle problems somewhat gracefully in a way that does not always require coders to write a bunch of tests or Try{}Catch{} constructs.

In general, just as we need a PowerShell version of ROBOCOPY.EXE, we need a PowerShell replacement for everything REG.EXE can do (and more).

For remote registry access, it would be nice to have support for both WSMAN and RPC, but RPC at a minimum (for those who don't configure WinRM/WSMAN on client devices). These registry cmdlets also need a -Credential parameter for connecting to stand-alone boxes in a workgroup that only have local accounts.

It's not enough to just have a nice registry module in the PSGallery, it needs to be built in so that we can rely on it everywhere; for example, these new registry cmdlets should ideally work on Linux or Mac OS machines using PowerShell to access the registry on remote Windows boxes.

REG.EXE is not good enough either: it's not object-oriented, does not support tab completion, does not support -WhatIf or -Verbose or -Recurse, etc. Same for ROBOCOPY.EXE.

And having just a DSC resource module is not good enough either. DSC is too complex or heavyweight for many organizations or scenarios.

Adding new registry cmdlets would not break any existing scripts that modify the local registry. And depending on how the network registry access is implemented, might not require a particular minimum version of WMF/PowerShell at the remote system either (though it may require WinRM to be configured).

Just as others have proposed or written functions for already, the names of the cmdlets might be like:

And so on...

As others have already done, the cmdlets might just be wrappers for existing cmdlets, providers, classes or modules, which would be just fine, but they need to be built-in by default in the next version of WMF/PowerShell.

The above suggestion is not new and definitely not my idea, but I was hoping a new post in UserVoice would help to spark discussion about what is (not) needed and attract enough votes to get the ball rolling before the next version of WMF/PowerShell gets feature-locked.


27 votes
Sign in
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Jason Fossen shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


    Sign in
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      • Tim Curwick commented  ·   ·  Flag as inappropriate

        Implementing the IContentCmdletProvider interface on the registry provider should be considered as a means to gives us improved access to the registry. This may not be a complete solution, but it would allow us to use Get-Content and Set-Content as well as ${HKLM:\SOFTWARE\Microsoft}

      • whiggs commented  ·   ·  Flag as inappropriate

        OR.. Alternatively, if you have powershell 5 (or just the packagemanagement module), just run "Install-module Carbon". Carbon has a bunch of registry related cmdlets, as well as an insane number of other useful functions. As for importing registry keys, you could simply just run:
        Start-Process regedit.exe -ArgumentList "/S C:\Path\to\regfile.reg"

      • Warren F. commented  ·   ·  Flag as inappropriate

        Agreed. Although, not sure how it could be included. Maybe as a module in Windows PowerShell, included (a la Pester), but also available in the Gallery for use with PowerShell Core (on Windows), or down-level systems?

        This module from Shay works everywhere, and has been around a while. It might be a good start

        Also: Providers should never be the sole way to access something. IMHO we should see the following progression:

        * API
        * Module/Cmdlets
        * Provider

        Providers are often even more abstracted than Cmdlets, to a point where the Registry provider is IMHO *too* abstract. What does an item correspond with? An itemproperty? It's a cool trick, browsing like the filesystem, but when folks need to actually extract data and change data, you find confusion. Oh... And no remote capabilities outside of using inside a pssession? Working with the registry in PowerShell outside of modules like Shay's is frustrating, and I say this as someone with 6 years writing PowerShell - imagine someone starting out.

        Apologies for the wall of text. This has been a thorn for a while : )

      Feedback and Knowledge Base