I think it's time for an overhaul of Group Policy and GP Preferences. You can still keep the GUI to allow everyone to have something familiar, but I would love to see if Group Policy can be converted to start using PowerShell DSC under the hood. I think this would make things much simpler in terms of deployment and wouldn't require logon/logoff or restarts anymore (unless you wanted a script to run at those times). For everything else like IE/Edge settings, registry settings, mapped drives/printers, desktop backgrounds and such I think having everything exposed in PowerShell would both make it more secure (as we've recently seen with the SMB signing problems) and easier to troubleshoot. It might even make it easier to deploy a Linux version of Group Policy since DSC can work against Linux...

In PowerShell ISE, if you invoke the exit command, it closes the entire application regardless of how many tabs you have open. It would be better if the exit command simply closed the current tab (if you have multiple tabs open) or the entire application if you only have one runspace open. This would prevent accidentally closing runspaces that you wanted to go back to just because you used the all-too-familiar exit command.

Also, making this change would address this issue within PowerShell ISE: when you invoke exit, the Runspace.StateChanged event is only fired for the current/active runspace (tab), even if you have multiple tabs open, so all tabs other than the current one that want to do cleanup of some resource when the runspace is closed cannot do so.

In order to register external module dependencies (dependencies living in another repository), the name has to be registered in a string array property within the PSData Hashtable property in the PrivateData section in the psd1 manifest like so for registering module 'psFtp':

PrivateData = @{
PSData = @{

ExternalModuleDependencies

ExternalModuleDependencies = @('psFtp')
}
} # End of PrivateData hashtable

However, the new-modulemanifest doesn't have an -ExternalModuleDepencies parameter, nor is it possible to register externalmoduledependencies like so:

-PrivateData @{ PSData = @{ ExternalModuleDependencies = @('psFtp') } }

Which from a client perspective of the the existing new-modulemanifest api, would be an intuitive way of setting ExternalModuleDependencies.

Suggestion is:
Either make -ExternalModuleDependencies available as parameter or let the processing of the -PrivateData arguments handle nested hashtables (such as PSData in this case).

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

I have just installed Windows Management Framework (WMF) 5.0 RTM on my Windows
7 SP1 and tested it. Get-ChildItem -LiteralPath -Include -Recurse started to
work differently in v5.

This command

Get-ChildItem -Path $PSHOME -Include *.exe -Recurse

gets expected powershell.exe and powershell_ise.exe.

The same command with -LiteralPath instead of -Path

Get-ChildItem -LiteralPath $PSHOME -Include *.exe -Recurse

in PowerShell v5 RTM unexpectedly gets all items in $PSHOME.

I cannot test this with previous versions right now (by the way,
PowerShell.exe -Version 2 seems to have the same issue in v5 RTM). But I
believe in PowerShell v3 and v4 this was not the case. I found this issue
because this command

Get-ChildItem -LiteralPath <path> -Include <some temp files> -Recurse | Remove-Item

tried to remove all files in <path> instead of specified temp files.
This command used to work work as expected before installing v5 RTM.

Here is confirmation from Stack Overflow:
http://stackoverflow.com/questions/33684178/powershell-5-get-childitem-literalpath-doesnt-work-with-include-anymore

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: 35

Original Date Submitted: 9/22/2010 9:56:58 PM

Description:
Contact Information
Handle: Joel "Jaykul" Bennett
Site Name: PowerShell
Feedback ID: 603415

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

Problem Description:
Currently PowerShell has it's own system (based on type.ps1xml files) for creating extension methods -- while this would have been admirable in the .Net 1.1 or 2.0 era, in the modern .Net Framework we already have Extension methods, and they do not work in PowerShell.

As more and more of the .Net Framework itself and 3rd Party APIs begins to depend on extension methods to create "fluent" programming interfaces, it is critical that PowerShell support pre-compiled .Net extension methods.

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

Repro Steps:
Expected Results:

Internal BugId: 2690

We've been lucky, from what I'm gathering from web searches! Until December last year, Exchange Online Powershell cmdlet help was available using Get-Help in the shell. However, after the Christmas break, the only response we get is:

Get-Help : Exception calling "Invoke" with "0" argument(s): "Cannot find path '' because it does
not exist."
At line:1 char:1
+ Get-Help Get-Mailbox
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : NotSpecified: (:) [Get-Help], MethodInvocationException

+ FullyQualifiedErrorId : CmdletInvocationException

It's the same issue irrespective of the cmdlet.

Consequently, I'm forced to contend with painful searches of the documentation website for information of the relevant cmdlets.

Raised this question on the Github Exchange documentation site (https://github.com/MicrosoftDocs/office-docs-powershell/issues/2440) and Chris Davis, who noticed the issue since June, suggested I raise a support case. So not sure this is the right place to do so.

Powershell 5.1 on both Windows 7/10

In 5.0, objects returned from a script will appear in the console only after the script has completely finished if no formatting data is defined for that object type.

Example:

Write-Warning "Before"

Get-Service E* | select Status, Name, DisplayName

Write-Warning "After"

Output:

WARNING: Before


WARNING: After

 Status Name        DisplayName                       

 ------ ----        -----------                       

Stopped EapHost     Extensible Authentication Protocol

Running EFS         Encrypting File System (EFS)      

Running eventlog    Windows Event Log                 

Running EventSystem COM+ Event System               

Details
- This did not happen before PowerShell 5.0
- This happens both in the PowerShell console and ISE
- The issue affects all objects that have no formatting data, for example:

<anything> | Select-Object -Property …

[pscustomobject]@{one=1;two=2}

Get-Acl C:\

Get-Location

• Output that is sent to other streams is not affected (errors, Write-Host, Write-Warning, Write-Verbose etc.)


• The issue only occurs in table view (i.e. does not happen if the object has more than 4 properties)


• The issue also occurs if the script output is piped to a file, but not if it is piped to another command (e.g. Out-GridView).

This issue can create unexpected results for scripts that worked fine in previous PowerShell versions. Running this (contrived) script will highlight the issue:

$RandomProcess = Get-Process | Get-Random

Write-Host "Random process:"

$RandomProcess | select Name, ID

Read-Host "Press Enter to stop the listed process"

$RandomProcess | Stop-Process -WhatIf

What makes this potentially dangerous is that making subtle changes to the code (e.g. in the previous examples, removing the select command) could change the output significantly. At the very least it violates the "principle of least surprise".

This may be caused by the new default formatter waiting for all pipeline objects so it can display them in the new auto-sized column layout (essentially an implicit Format-Table -AutoSize). It would be better if the behavior reverted to the previous formatting style for “unknown” objects so it displays all output in the proper order.

Workarounds:

• If the objects do not really need to be sent to the pipeline, append “| Out-Host" or "| Out-String" to the command generating the objects.

At the moment to use encrypted credentials in partial configurations with ConfigurationNames it is necessary to share certificate across all nodes, else decryption will fail. I believe it should be technically possible to use more dynamic approach:
- encrypt MOF with certificate for which pull server has private key
- during registration client would send over certificate for which it has private key so that pull server can encrypt any credentials in the mofs sent to this node with this certificate.

At the moment it's manual labour on the operators side: make sure that encrypt/decrypt just works. It would be nice if pull server could do more of the heavy-lifting here.

Votes from Connect: 8

Original Date Submitted: 8/22/2014 11:58:54 PM

Description:
Contact Information
Handle: Aaron Jensen
Site Name: PowerShell
Feedback ID: 952833

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

Problem Description:
Currently, when using comment-based help, you're limited to one line of code for an example. This is extremely limiting, especially when trying to document DSC resources, since they span multiple lines by default. Also, some examples would be more useful with some extra lines. The current alternative is to use XML-based help, but the MAML schema is extremely verbose and complicated.

What I'd like to see is everything until the first empty line is treated as a code sample, e.g.

.EXAMPLE

User CreateUser

{

    Username = 'fubar';

    Credential = $credential;

}


Demonstrates the minimum amount of code needed to create a user with the `User` resource.

Would render as:

-------------------------- EXAMPLE 1 --------------------------

PS C:\> User CreateUser

{

    Username = 'fubar';

    Credential = $credential;

}


Demonstrates the minimum amount of code needed to create a user with the `User` resource.

Other ideas:

• Prefix on each line of the example code


• Use the ` at the end of each line to mean "continue the example code onto the next line".

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

Repro Steps:
Expected Results:

Internal BugId: 8968

At some point in the 5.0 time period, Update-Help installed About topic files in the en-US directory for the PSWorkflow module with .txt (not .help.txt) file name extensions.

e.g. about_Foreach-Parallel.txt

Later, this was fixed and Update-Help installed the same help files in the same directory with the (correct) ".help.txt" file name extension.

e.g. about_Foreach-Parallel.help.txt

Now, the PSWorkflow\en-US directory has 9 pairs of files that are identical except for the file name extension.

aboutActivityCommonParameters.help.txt
aboutActivityCommonParameters.txt
aboutCheckpoint-Workflow.help.txt
aboutCheckpoint-Workflow.txt
aboutForeach-Parallel.help.txt
aboutForeach-Parallel.txt
aboutInlineScript.help.txt
aboutInlineScript.txt
aboutParallel.help.txt
aboutParallel.txt
aboutSequence.help.txt
aboutSequence.txt
aboutSuspend-Workflow.help.txt
aboutSuspend-Workflow.txt
aboutWorkflowCommonParameters.help.txt
aboutWorkflowCommonParameters.txt
aboutWorkflows.help.txt
aboutWorkflows.txt

Get-Help should ignore the .txt files (must have changed in 4.0), but it does not. Instead, it finds both .txt and .help.txt. So, when you run Get-Help, instead of displaying help for the topic, it lists the duplicate base names.

PS C:\ps-test> Get-Help about_Foreach-Parallel

Name Category Module Synopsis

aboutForEach-Parallel HelpFile Describes the ForEach
aboutForeach-Parallel HelpFile Describes the ForEach

I'm not sure why Get-Help is recognizing About.txt files.

But, we had a similar problem in a module when we shipped a file with corrected capitalization in the base name.

aboutFileName.help.txt
aboutfilename.help.txt

We might want to tweak Get-Help so that when it detects an exact duplicate base name, it displays the content in the newest file.

Also, in modules, Get-Help should display the help only for the version of the module that it's processing. That would allow module authors to update help topic names without causing unintended duplicates.

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.