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.

Please see http://www.hurryupandwait.io/blog/certificate-password-less-based-authentication-in-winrm for more details

Votes from Connect: 24

Original Date Submitted: 10/25/2012 1:54:42 PM

Description:
********Contact Information********
Handle: TobiasWeltner
Site Name: PowerShell
Feedback ID: 768650
***************************************

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.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 768650 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=768650).

Repro Steps:
none applicable

Expected Results:

Internal BugId: 3902

Votes from Connect: 4

Original Date Submitted: 11/14/2015 5:05:21 AM

Description:
********Contact Information********
Handle: June Blender
Site Name: PowerShell
Feedback ID: 2014667
***************************************

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!).

Product Studio item created by Connect Synchronizer due to creation of feedback ID 2014667 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=2014667).

Repro Steps:

Internal BugId: 15970

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])

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,

function Get-Info ([Alias("name")] [Parameter(Mandatory=$true, ValueFromPipelineByPropertyName=$true)] [string] $projectName = $env:Project_Name)
{
}

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.

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:

https://gallery.technet.microsoft.com/RegistryLibrarypsm1-b38a81ba

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:

Get-RegistryValue
Set-RegistryValue
New-RegistryKey
Remove-RegistryValue
Remove-RegistryKey
Export-RegistryKey
Import-RegistryKey
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.

Thanks,
Jason

Votes from Connect: 130

Original Date Submitted: 7/24/2014 11:42:29 PM

Description:
********Contact Information********
Handle: Joel 'Jaykul' Bennett
Site Name: PowerShell
Feedback ID: 928085
***************************************

Frequency: Always Happens
Regression: Yes, this happens in previous released versions

Problem Description:
Powershell is not a case sensitive language, and yet, ParameterSet names are case sensitive, and mixing up the case of a name can results in multiple sets. This should not be so.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 928085 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=928085).

Repro Steps:
function test-case {
param(
[Parameter(ParameterSetName="Test",Mandatory=$true)][Switch]$TitleCase,
[Parameter(ParameterSetName="test",Mandatory=$true)][Switch]$LowerCase,
[Parameter(ParameterSetName="TEST",Mandatory=$true)][Switch]$UpperCase
)
$PSCmdlet.ParameterSetName
}

# Both of these commands will demonstrate that this function has THREE parameter sets instead of one:
(Get-Command Test-Case).ParameterSets.Count
Get-Help Test-Case

Expected Results:
The Test-Case function should have only one parameter set with three mandatory switches.

Internal BugId: 8912

Excerpt from this article ‘Constrained PowerShell’ https://blogs.msdn.microsoft.com/powershell/2015/06/09/powershell-the-blue-team:

"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.

I have implemented a workaround which is to create a path rule to ‘%temp%’ with the security level set to ‘unrestricted’. I discovered this workaround on the following sites: https://social.technet.microsoft.com/Forums/en-US/e81bd4e8-d5e0-4aa9-a1af-928e536c2a69/ps-constrainedlanguage-mode-on-windows-10-with-srp?forum=winserverpowershell and https://community.spiceworks.com/topic/1451109-srp-whitelist-causing-odd-behavior-in-powershell-v5

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.