After much discussion with Aaron Nelson and Chrissy LeMaire, and thanks to the enormous amount of support for this item, we’ve recognized that this is something we need to accomplish, one way or another.

We don’t want to offer an ETA on this as the work is not well understood by our team yet, and no one currently has immediate bandwidth on starting that investigation. But I want to stress the fact that is an important ask that we’re taking seriously as a priority.

In the meantime, it would be immensely useful if someone with expertise in the DataTable space could submit an RFC (basically a brief spec) to our PowerShell-RFC repository on GitHub. That way, we can have a discussion about what the design of a ConvertTo-DataTable cmdlet might look like before we dive in on an implementation. The process for doing so is located here: https://github.com/PowerShell/PowerShell-RFC/blob/master/RFC0000-RFC-Process.md#draft

I should also note that, given our desire to shrink the size of the PowerShell runtime over time, we believe that the development of this cmdlet/module should start on the PowerShell Gallery. However, this does not preclude us adding it to PowerShell 6.x as its quality improves and as others validate its usefulness.

Thanks everyone!
-Joey

After much discussion with Aaron Nelson and Chrissy LeMaire, and thanks to the enormous amount of support for this item, we’ve recognized that this is something we need to accomplish, one way or another.

We don’t want to offer an ETA on this as the work is not well understood by our team yet, and no one currently has immediate bandwidth on starting that investigation. But I want to stress the fact that is an important ask that we’re taking seriously as a priority.

In the meantime, it would be immensely useful if someone with expertise in the DataTable space could submit an RFC (basically a brief spec) to our PowerShell-RFC repository on GitHub. That way, we can have a discussion about what the design of a ConvertTo-DataTable cmdlet might look like before we dive in on an implementation. The process for doing so is located here: https://github.com/PowerShell/PowerShell-RFC/blob/master/RFC0000-RFC-Process.md#draft

With PowerShell 6.0, we’ve already begun updating our versioning system to be more descriptive. Right now, PSVersion returns 6.0.0-alpha as a System.Management.Automation.SemanticVersion object (with Major, Minor, Patch, and Label properties), and we’ve also added a GitCommitId property to PSVersionTable that matches perfectly with tags on GitHub: https://github.com/powershell/powershell/tags

PowerShell needs a Compile verb, especially in a world of DevOps. Looking at the approved verb list, there are mediocre subtitutes that could be used in its place (Start-Compilation, Invoke-Compile, etc.), but these all use an inappropriate verb with the a variant of the verb in the noun. When the verb is finding its way into the noun, it's time for a new verb. Please add Compile to the list of approved verbs in an upcoming release.

Thank you for your input. Based on its current ranking compared to other feedback items and product schedule, work on this item is pending (and will be driven by) further customer input. If you did not open this issue and are also impacted by it, please vote this item up.

Problem Description:
Right now Test-Path has no way of checking for the existence of a hidden file. I would suggest -force to search all files (hidden or not), and/or -hidden to test only for hidden files.

I am unable to authenticate with a client certificate generated from OpenSSL or New-SelfSignedCertificate from a Windows 10 or 2012R2 powershell remoting client (likely broken in 8.1 but I did not test). I receive the following error:

new-PSSession : The WinRM client cannot process the request. If you are using a machine certificate, it must contain a DNS name in the Subject Alternative Name extension or in the Subject Name field, and no UPN name. If you are using a user certificate, the Subject Alternative Name extension must contain a UPN name and must not contain a DNS name. Change the certificate structure and try the request again.

The UPN is correctly specified in the SAN and there is no DNS entry.

I CAN authenticate with the same certificates from windows 7 or 2008R2 and I can also authenticate from windows 10/2012R2 if I use the ruby or python winrm libraries.

I checked the binary contents of both an ADCS gernerated cert and an OpenSSL one and my SAN contents are binary identical.

I am unable to authenticate with a client certificate generated from OpenSSL or New-SelfSignedCertificate from a Windows 10 or 2012R2 powershell remoting client (likely broken in 8.1 but I did not test). I receive the following error:

new-PSSession : The WinRM client cannot process the request. If you are using a machine certificate, it must contain a DNS name in the Subject Alternative Name extension or in the Subject Name field, and no UPN name. If you are using a user certificate, the Subject Alternative Name extension must contain a UPN name and must not contain a DNS name. Change…

Problem Description:
In the "DevOps" world, YAML is a first class citizien in products like Kitchen CI, Elasticsearch, Appveyor, Travis CI, rubocop etc.
It would be great to have commands similar to https://github.com/dfinke/PowerYaml native without the need to import a module.

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:

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.

Thanks,
Jason

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:

currently Powershell does not provide a native cmdlet to manipulate timezone. this functionality would help enable desktop, server and DSC scenarios. I realize that calling tzutil.exe is a viable workaround. but it seems like an easy thing to expose as a cmdlet

Right now, if an exception occurs in the argument completer, then it immediately returns, and "falls back" to the built-in filesystem / item-based auto-completion. If an exception occurs in my custom argument completers, I'd rather be able to cancel auto-completion altogether, rather than have a bunch of useless results be thrown at the user.

Frequency: Always Happens
Regression: No, this is new to the most recent version

Problem Description:
In PSv3, the pipeline can be stopped. Select-Object supports this with its -First parameter by raising a (non-public) StopUpstreamCommandsException exception.

It is of great value to be able to stop the pipeline if your mission is completed before the emitting cmdlet has provided all results.

In fact, the PS pipeline would gain a completely new "feature". Currently, it is a memory throttle and provides realtime feedback at the cost of performance. If stopping the pipeline was something available to users, it could also be a generic means of running cmdlets only partially.

Select-Object is a great start but you do not always know beforehand how many elements you need. So it would be beneficial to have a Stop-Pipeline cmdlet or at least a public StopUpstreamCommandsException that a script programme can throw.

Instead of having to passing in the Project Name for each call I would like to store it in an environment variable. When I do it would allow me to call Get-Info with no parameters and the value in the environment variable would be used. If the environment variable does not exist or is empty the user would be prompted for a value if it was not provided on the command line.
I tried writing the code as I have above but it never seemed to work. Even when the environment variable was set I was always prompted for projectName.
I know I could remove the mandatory attribute and add code in my function to set to the environment variable if it exists. But it would be much easier if what I am proposing was possible.

When defining a function, I would like to use an environment variable as the default value. If the environment variable exists and has a value that value will be used. For example,

Instead of having to passing in the Project Name for each call I would like to store it in an environment variable. When I do it would allow me to call Get-Info with no parameters and the value in the environment variable would be used. If the environment variable does not exist or is empty the user…

"In version 5, Power Shell now reduces its functionality to "Constrained Mode" for both interactive input and user-authored scripts when it detects that Power Shell scripts have an ‘Allow Mode’ policy applied to them. Constrained Power Shell limits the language mode to Constrained Language (as described in about_Language_Modes), a mode first introduced for Windows RT.

Constrained Language doesn’t limit the capability of the core Power Shell language – familiar techniques such as variables, loops, and functions are all supported. It does, however, limit the extended language features that can lead to unverifiable code execution such as direct .NET scripting, invocation of Win32 APIs via the Add-Type cmdlet, and interaction with COM objects.

Scripts that are allowed by the AppLocker policy (for example: signed by the enterprise’s trusted code signing certificate, or in a trusted directory) are not subject to Constrained Language. They have access to the extended capabilities of the Power Shell language disallowed by Constrained Language. This includes unverifiable extensions such as .NET scripting, and invocation of Win32 APIs."

Upon launching a PowerShell script as a non-admin on a computer running Windows 7 Pro with SP1 where a Software Restriction Policy is enabled and the security level is set to ‘Disallowed’ and the enforcement is set to apply to ‘All users except local administrators’, the script runs in Constrained Language mode.

The excerpt above states that a script is not subjected to Constrained Language mode if it has been allowed by an AppLocker policy. However, no such provision has been made for Software Restriction Policies (AppLocker’s predecessor), as creating a path rule to the script location with the security level set to ‘Unrestricted’ has no effect, the script continues to run in Constrained Language mode.

Naturally, unblocking ‘%temp%’ within an SRP is highly undesirable, therefore the workaround suggests creating a separate block-rule for each extension in %temp%, eg: "%temp%\*.exe". I have found that this does not work and that executables continue to launch. It appears that the path rule to ‘%temp%’ with the security level set to ‘unrestricted’ takes precedence.

Therefore with no sensible way to implement a Constrained Mode bypass, users of Software Restriction Policies that require a script to launch with Full Language mode have no choice but to make a modification to their SRP with a detrimental impact on security.

"In version 5, Power Shell now reduces its functionality to "Constrained Mode" for both interactive input and user-authored scripts when it detects that Power Shell scripts have an ‘Allow Mode’ policy applied to them. Constrained Power Shell limits the language mode to Constrained Language (as described in about_Language_Modes), a mode first introduced for Windows RT.

Constrained Language doesn’t limit the capability of the core Power Shell language – familiar techniques such as variables, loops, and functions are all supported. It does, however, limit the extended language features that can lead to unverifiable…

It is annoying when I’m debugging in the ISE and an unhandled exception occurs - the ISE debugger just exits. It gives me no chance to debug the issue that caused the unhandled exception while still debugging. The importance of stopping **in** the debugger, is that I can examine the state of variables throughout the call stack which can be very helpful in tracking down "why" the unhandled exception occurred.

So first, I want to set an "unhandled" exception breakpoint that would cause PowerShell to “break into” the debugger on any unhandled exception i.e. put the brakes on just before the script is about to exit.

Second, scripts can get a bit happy with try/catch and you can run into scenarios where exceptions get swallowed. While this scenario is a bit more corner-case, I have found it extremely useful to be able to set an exception breakpoint such that the debugger stops at the point it first sees the specified exception type thrown.

Since PowerShell allows for exception such as “throw ‘Oops’”, setting a breakpoint on exception type [RuntimeException] might also warrant use of the Action parameter e.g. if ($_.Exception.Message -eq ‘oops’) {break}.

So perhaps there is two new parameters sets added. One with the Parameter -UnhandledException (of type [switch]) and another with the parameters -Exception (of type [string[]] - names of exception types) and -Action (of type [scriptblock])

It is annoying when I’m debugging in the ISE and an unhandled exception occurs - the ISE debugger just exits. It gives me no chance to debug the issue that caused the unhandled exception while still debugging. The importance of stopping **in** the debugger, is that I can examine the state of variables throughout the call stack which can be very helpful in tracking down "why" the unhandled exception occurred.

So first, I want to set an "unhandled" exception breakpoint that would cause PowerShell to “break into” the debugger on any unhandled exception i.e. put the brakes on just before…

Problem Description:
To require the exact version of a module, I need a RequiredVersion option in #Requires.

The ModuleVersion key in the #Requires -Module hashtable: @{ModuleName=''; ModuleVersion=''} behaves as a minimum version requirement. Not all versions of all modules are backward-compatible. With the proliferation of versions, including side-by-side in PowerShell 5.0, we need to be able to require a particular version.

Also, about_Requires describes the ModuleVersion, but does not mention that it's a minimum (because I didn't know that when I wrote it -- should have tested!).

Problem Description:
To require the exact version of a module, I need a RequiredVersion option in #Requires.

The ModuleVersion key in the #Requires -Module hashtable: @{ModuleName=''; ModuleVersion=''} behaves as a minimum version requirement. Not all versions of all modules are backward-compatible. With the proliferation of versions, including side-by-side in PowerShell 5.0, we need to be able to require a particular version.

Also, about_Requires describes the ModuleVersion, but does not mention that it's a minimum (because I didn't…