Votes from Connect: 22

Original Date Submitted: 2/8/2013 8:32:38 AM

Description:
********Contact Information********
Handle: antize
Site Name: PowerShell
Feedback ID: 778798
***************************************

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

Problem Description:
Discussion about this at stackoverflow - http://stackoverflow.com/questions/563600/can-i-get-to-work-in-powershell

Jeffery Snover said to request it here so here I am :D

Here is a description of what they do -- http://www.gnu.org/software/bash/manual/bashref.html#Lists

An AND list has the form
command1 && command2

command2 is executed if, and only if, command1 returns an exit status of zero.

An OR list has the form
command1 || command2

command2 is executed if, and only if, command1 returns a non-zero exit status.

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

Repro Steps:
Expected Results:

Internal BugId: 4111

Votes from Connect: 13

Original Date Submitted: 11/1/2012 3:56:26 AM

Description:
********Contact Information********
Handle: J Stangroome
Site Name: PowerShell
Feedback ID: 769359
***************************************

Frequency: Always Happens
Regression: I don't know if this issue existed previously

Problem Description:
In the PSv3 documentation, $PSScriptRoot is now an automatic variable that is populated for both modules and ps1 scripts. It works from PowerShell.exe but not from the ISE

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

Repro Steps:
1. Create a new script (eg c:\test.ps1) with the contents: gv PSScriptRoot
2. From PowerShell.exe, execute the script and see PSScriptRoot has a value.
3. From the ISE Console pane, execute the script and see PSScriptRoot had a value.
4. Open the script file in the ISE Script Pane and press F5 to run the script and see PSScriptRoot is blank.

Expected Results:
The $PSScriptRoot automatic variable should have a value when run via F5 in the ISE.

Internal BugId: 3931

Object Oriented Programming seems to be supported now in PowerShell, but custom classes defined in modules don't seem to behave the way they should.

There only seem to be two consistent ways to make these work when importing a module that has classes defined:
1. Import the module, then run "using module ..." to make the classes available in the session. Alternatively, you can import the module with the using statement, but this isn't ideal (no versioning).
2. Add the class definition file(s) to the ScriptsToProcess attribute of the module. This isn't ideal either as it runs the scripts in the global session which is bad practice.

Please provide a method that allows classes to be packaged with a module to support OOP scenarios. Thanks!

Votes from Connect: 3

Original Date Submitted: 10/30/2014 5:41:25 PM

Description:
********Contact Information********
Handle: ulrichb
Site Name: PowerShell
Feedback ID: 1015225
***************************************

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

Problem Description:
New-ScheduledTaskTrigger offers just a subset of the trigger options. Things like "On an (event log) event", or "On workstation (un)lock" are missing.

We just found ugly workarounds to add these (e.g. event log) triggers by using "schtasks.exe /create /xml" or using the COM "TaskScheduler" class.

New-ScheduledTaskTrigger should allow specifying all options the Task Scheduler UI offers. As there already exists an XML representation of these triggers (e.g. <EventTrigger>, <SessionStateChangeTrigger>, ...) it would also be possible to offer a "-Custom" parameter which takes such an XML fragment to specify a trigger.

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

Repro Steps:
Expected Results:

Internal BugId: 13076

Votes from Connect: 8

Original Date Submitted: 9/5/2014 9:43:02 PM

Description:
********Contact Information********
Handle: NPherson
Site Name: PowerShell
Feedback ID: 964601
***************************************

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

Problem Description:
With the WMF, there is no good consistent way to detect what version is installed. You can query for installed KB's, but that only works if the version of the WMF wasn't already baked into the operating system.

With PowerShell, you can find out what version you have from within PowerShell with $psversiontable, but that information is not available in the OS itself through WMI or the Registry.

For both of these, right now people resort to looking at the version metadata on powershell.exe and letting that imply what version of WMF and PowerShell are there because there is no other method that works. It would be much better if the WMF and PowerShell version information was explicitly available to the operating system.

Suggestion:

1. For both the WMF and PowerShell, come up with a place where the version information will be stored in the Registry and WMI so it can be easily inventoried and acted on with tools like ConfigMgr. (I'm sure the ConfigMgr team would jump at the chance to help you come up how to do this in a way that makes systems management easier.)
2. Publish this information like both the .NET Framework and Internet Explorer and teams have done.
http://msdn.microsoft.com/en-us/library/hh925568(v=vs.110).aspx
http://msdn.microsoft.com/en-us/library/ms537509(v=vs.85).aspx
3. Release updates to previous versions of WMF that add this information to the Registry and WMI so you can use it consistently.
4. When its time to start working on WMF 6 and beyond, ensure the detection methods and versioning information remain consistent.

I know that this might not seem all that important to developers who only touch a handful of devices. However, as a systems management professional, not having this information easily (and consistently) available on devices makes it more difficult to deploy and manage applications.

Thanks for your help!

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

Repro Steps:
- Decide to deploy the current version of WMF to all workstations in your organization with ConfigMgr.
- Try to make a collection of all workstations that don't have the current version.
- Realize there is no way to inventory this information directly.
-- Ask a computer what version of Windows Management Framework is installed.
-- It doesn't know because that isn't expressly there. (Depending on OS and WMF version, there may or may not be a KB listed. The only thing that can be done today that is consistent across OS's is to imply the WMF version from the powershell.exe file metadata.)
- Go vote up feedback asking the team to make sure version information is available to be easily inventoried and acted upon.

Expected Results:
WMF version and PowerShell version information is explicitly defined in the Registry and WMI.

Internal BugId: 8988

Votes from Connect: 63

Original Date Submitted: 11/29/2012 12:00:27 AM

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

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

Problem Description:
The PowerShell team should ship it's modules via a Module Repository (like NuGet), and add commands for retrieving and installing modules to the Core module.

They should use that mechanism to further separate releases from the Windows Server ship schedule. In fact, I suggest that you should externalize *all* of the non-core modules (everything which is currently loaded on-demand) to separate them from the ship schedule in the same way (and for the same reasons) that Help is separated now.

Just as the ASP.NET team has been able to accelerate releases of new features and fixes by separating much of their code from the Visual Studio and Windows Server release cycles and putting it into NuGet packages (and shipping NuGet built into Visual Studio), so the PowerShell team could benefit from a similar separation.

As a side note, I think it would probably help to create a default profile that did something like:

if(!(get-command add-type)) {
Install-Module Microsoft.PowerShell.*
Update-Help
}

It would probably be necessary (as with NuGet) for the module repository commands to support using a folder share (or external drive) as a simple module repository (and to open source the core module repository code) so that companies could run module repositories in-house to satisfy the need to get modules onto machines with pre-approval and without internet access. The default repository (and perhaps a list of allowed repositories) would need to be controlled via global policy.

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

Repro Steps:
Expected Results:

Internal BugId: 3982

Votes from Connect: 26

Original Date Submitted: 4/5/2014 3:29:10 AM

Description:
********Contact Information********
Handle: Stephen Owen
Site Name: PowerShell
Feedback ID: 846658
***************************************

Frequency: Always Happens
Regression: I don't know if this issue existed previously

Problem Description:
Hi all,

With this awesome new addition of official Chocolatey (I cannot spell this word) support, we at The Scripting Guys group on FB realized that the only thing missing to have full feature parity with BASH is Sudo!

Sudo has become equivalent with nerdy coolness and now that PowerShell is growing in support and fandom at such a pace, we need our own Sudo, in order to temporarily run commands as super-user without launching PowerShell as an admin.

Give us sudo, and make sure that it has a cool name. I'd recommend 'PowerUp' or something similar, to keep the coolness levels up.

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

Repro Steps:
Launch PowerShell as local, non-privileged user. Attempt to change the execution policy to run a script.

>PS C:\Users\Stephen> Set-ExecutionPolicy Unrestricted

Execution Policy Change
The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose
you to the security risks described in the about_Execution_Policies help topic at
http://go.microsoft.com/fwlink/?LinkID=135170. Do you want to change the execution policy?
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): y
Set-ExecutionPolicy : Access to the registry key
'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell' is denied. To change the execution
policy for the default (LocalMachine) scope, start Windows PowerShell with the "Run as administrator" option. To
change the execution policy for the current user, run "Set-ExecutionPolicy -Scope CurrentUser".
At line:1 char:1
+ Set-ExecutionPolicy Unrestricted
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : PermissionDenied: (:) [Set-ExecutionPolicy], UnauthorizedAccessException
+ FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft.PowerShell.Commands.SetExecutionPolicyComma
nd

Expected Results:
Launch PowerShell as local, non-privileged user. Attempt to change the execution policy to run a script.

>PS C:\Users\Stephen> PowerUp Set-ExecutionPolicy Unrestricted

Execution Policy Change
The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose you to the security risks described in
the about_Execution_Policies help topic at http://go.microsoft.com/fwlink/?LinkID=135170. Do you want to change the execution policy?
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): y

--Operation completes--

Internal BugId: 7701

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

Votes from Connect: 13

Original Date Submitted: 1/21/2011 3:36:17 AM

Description:
********Contact Information********
Handle: jim christopher
Site Name: PowerShell
Feedback ID: 637184
***************************************

Frequency: Always Happens
Regression: I don't know if this issue existed previously

Problem Description:
When passing large (e.g., >650) host names to the test-connection cmdlet, the cmdlet raises a WMI quota violation exception.

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

Repro Steps:
$ra = @(0..1000) | %{ $env:computername };
test-connection $ra;

Expected Results:
I expect test-connection to manage the WMI underpinnings so I don't receive the quota violation.

Internal BugId: 2788

Votes from Connect: 26

Original Date Submitted: 9/18/2013 10:01:50 PM

Description:
********Contact Information********
Handle: Mark E. Schill
Site Name: PowerShell
Feedback ID: 801353
***************************************

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

Problem Description:
ConvertFrom-JSON doesn't allow you to modify the maxJSONLength value. By default it is set to 2MB so if you have a JSON string that is longer it will error out trying to convert to a PowerShell object.

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

Repro Steps:
Use ConvertFrom-JSON on any string over 2MB.

Expected Results:
Should successfully convert the JSON string to a PowerShell object.

Internal BugId: 5391

Votes from Connect: 4

Original Date Submitted: 10/6/2014 10:15:42 AM

Description:
********Contact Information********
Handle: DScripter
Site Name: PowerShell
Feedback ID: 993163
***************************************

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

Problem Description:
I had an issue recently with generating JSON files that needed to be encoded in 'UTF-8 without BOM.' Cmdlets with the -Encoding parameter do not have this format as a possible encoding option.

It looks like the Unicode standard recommends not using the BOM, either, as mentioned in this conversation:
http://stackoverflow.com/questions/2223882/whats-different-between-utf-8-and-utf-8-without-bom

Here is the Standard documentation:
http://www.unicode.org/versions/Unicode5.0.0/ch02.pdf
Quote given from Page 30:
"... Use of a BOM is neither required nor RECOMMENDED for UTF-8, but may be encountered in contexts where UTF-8 data is converted from other encoding forms that use a BOM or where the BOM is used as a UTF-8 signature."

Workaround:
http://stackoverflow.com/questions/5596982/using-powershell-to-write-a-file-in-utf-8-without-the-bom

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

Repro Steps:
Use any cmdelt with the -Encoding parameter to see only UTF-8 (which is, by default, WITH the BOM)

Expected Results:
That is would, by default, be WITHOUT the BOM -- as it is not required nor recommended by Unicode standard

Internal BugId: 11033

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.

Votes from Connect: 57

Original Date Submitted: 3/24/2014 10:15:46 AM

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

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

Problem Description:
Currently PowerShell has it's own systems (based on "Jobs") for doing asynchronous tasks -- while this was admirable in the .Net 2.0 and 3.0 era, in the modern .Net Framework we have new "IAsyncResult" task APIs, and they do not work in PowerShell at all.

As more and more of the .Net Framework itself and 3rd party APIs begin to depend on Tasks, IAsyncResult, and C#s "async" and "await" keywords to create asynchronous programming interfaces and web-based APIs, it is critical that PowerShell support working with these APIs, whether through extensions to the language (like C#'s await keyword) or via wrapper cmdlets which map these tasks to the existing Job mechanism, lest PowerShell find itself locked in the past and unable to access modern toolkits or manage modern apps.

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

Repro Steps:
Expected Results:

Internal BugId: 7681

Currently you can define what parameters are exposes and if needed, you can provide a validateset or validatepattern for the parameter. What I can't do is specify the parameter in question should be mandatory even though the cmdlet or function does not enforce its usage.
E.g.: I define the following in my psrc
VisibleCmdlets = @{
Name = 'Get-Process'
Parameters = @{
Name = 'Name'
ValidateSet = 'ZoomIt'
}
}

this does not restrict the user from just typing Get-Service and have every service returned.
Current workaround is to create a proxy function and expose that instead of the cmdlet.
I think overwriting the Mandatory attribute on parameters like these would be a common thing so I'm hoping the implementation can be expanded to also implement the Mandatory attribute without the need for my own proxy functions.

It would be very useful if Out-Gridview provided a build in display of the number of objects in the grid. This could be in a status bar at the bottom or at the top along with the Add Criteria button.

This would update as the filters are applied. It would also be nice if the selected items had a count as well.

It would be especially useful with -passthru as you could have an estimate on the number of objects being passed to the next cmdlet in the pipeline.

You can come up with the count by using measure-object, but that number only comes after committing to pass objects back through the pipeline.

I often pass things from the clipboard or csv files to cmdlets and it would be nice to know how many are going through at execution time.

Love PowerShell!

ConvertTo-Html works as desired when the output contains two or more columns.

ConvertTo-Html works as desired when the output contains only one column derived from a property that was explicitly named in the -Properties parameter.

However, if a match string is used for the -Property parameter, or the -Property parameter is omitted (and presumably defaults to match string "*"), and the output contains only a single column, the column header incorrectly contains the match string instead of the name of the property.

For example, this:

$X = [pscustomobject]@{ Name = 'Joe' }
ConvertTo-Html -InputObject $X -Fragment

Results in this:

<table>
<colgroup><col/></colgroup>
<tr><th>*</th></tr>
<tr><td>Joe</td></tr>
</table>

Additional examples and comparisons (results omitted)

# Examples with one property
$X = [pscustomobject]@{ Name = 'Joe' }

# Property selected by default, undesired result
ConvertTo-Html -InputObject $X -Fragment

# Property selected by match, undesired result
ConvertTo-Html -InputObject $X -Property * -Fragment
ConvertTo-Html -InputObject $X -Property N* -Fragment

# Property selected explicitly, desired result
ConvertTo-Html -InputObject $X -Property Name -Fragment

# Examples with two properties
$X = [pscustomobject]@{ Name = 'Joe'; Number = 21 }

# Property selected by default, desired result
ConvertTo-Html -InputObject $X -Fragment

# Property selected by match, desired result
ConvertTo-Html -InputObject $X -Property * -Fragment
ConvertTo-Html -InputObject $X -Property N* -Fragment

# Property selected explicitly, desired result
ConvertTo-Html -InputObject $X -Property Name, Number -Fragment

I understand when Get-Help shows me multiple results for the same command when there are different sources of the same command e.g.:

4> get-help format-hex

Name Category Module Synopsis
---- -------- ------ --------
Format-Hex Function Microsoft.PowerShell.U... ...
Format-Hex Cmdlet Pscx PSCX Cmdlet:

However this doesn't make sense when it is just different versions of the same command:

8> get-help about_psreadline

Name Category Module Synopsis
---- -------- ------ --------
about_PSReadline HelpFile
about_PSReadline HelpFile

I think Get-Help needs to be smart about this latter situation and A) only list the version of about_PSReadline that corresponds to the loaded module or B) if the module is not loaded, display the one that would be loaded (based on the version rules).

Also, Get-Help might want to add a -Version parameter where I can look at the help from a specific version of a module. You "could" work around this by importing that version of the module and then run Get-Help but that isn't always a convenient thing to do.