Votes from Connect: 1

Original Date Submitted: 8/28/2015 1:18:57 AM

Description:
Contact Information
Handle: ProveIsso
Site Name: PowerShell
Feedback ID: 1721069

Frequency: PowerShell
Regression: You can use a public example script like this one http://poshcode.org/608
Result being:

Key Value

String Field

Secure String System.Security.SecureString

Numeric Value 0

Problem Description:
As described by Matt over at StackOverflow - https://stackoverflow.com/questions/26238881/host-ui-prompt-is-ignoring-the-attribute-defaultvalue-in-fielddescription
> $Host.UI.Prompt method accepts a collection of FieldDescription objects. each of those objects can be assigned with a DefaultValue attribute, which is supposed to be returned when no input is given by the user for this specific field.
> I've got everything working as desired, except the default value part.

I've tried the same on PS3.0 (he tried it on 4) and got the same problem.

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

Repro Steps:
You can use a public example script like this one http://poshcode.org/608
Result being:

Key Value

String Field

Secure String System.Security.SecureString

Numeric Value 0

Expected Results:
Result, without input, should be

Key Value

String Field Field1
Secure String System.Security.SecureString

Numeric Value 42

Internal BugId: 15764

Votes from Connect: 3

Original Date Submitted: 7/22/2015 3:24:55 PM

Description:
Contact Information
Handle: 响叮咚
Site Name: PowerShell
Feedback ID: 1576035

Frequency: PowerShell
Regression: 【test】
work:
limit-eventLog -logname "SYSTEM" -MaximumSize 204800kb

don't work:
limit-eventLog -logname @("SYSTEM","Application","Security") -MaximumSize 204800kb
limit-eventLog -logname "SYSTEM","Application","Security" -MaximumSize 204800kb
limit-eventLog -logname SYSTEM,Application,Security -MaximumSize 204800kb

Problem Description:
limit-eventLog -logname do not accept an array

【version】
all version.
from powershell 2.0 to powershell 5.0 in windows 10 preview 10159!

【reason】
manual say:
-LogName<String[]>, but after I test, does not support string array,only string!

【The reporter】
前进三 (QQ No：120944419)
in
chinese powershell communication salon ---（QQ group No：183173532）

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

Repro Steps:
【test】
work:
limit-eventLog -logname "SYSTEM" -MaximumSize 204800kb

don't work:
limit-eventLog -logname @("SYSTEM","Application","Security") -MaximumSize 204800kb
limit-eventLog -logname "SYSTEM","Application","Security" -MaximumSize 204800kb
limit-eventLog -logname SYSTEM,Application,Security -MaximumSize 204800kb

Expected Results:

Internal BugId: 15672

Votes from Connect: 6

Original Date Submitted: 6/4/2015 6:00:09 AM

Description:
Contact Information
Handle: AlexWeiss
Site Name: PowerShell
Feedback ID: 1397136

Frequency: PowerShell
Regression: Run a deployment of 10 VMs with a JSON on IaaS V2 using ARM REST API
These 10 VMs must also have a DSC Extension resource deployed.

Problem Description:
Hi Team,

Wanted to share an error that happens when deploying a VM in Azure using the DSC Extension and Azure Resource Manager.
When the DSC extension try to install, it needs the WMF5 Preview Update but it receive the error below when installing multiple VM at a time.

C:\Packages\Plugins\Microsoft.Powershell.DSC\1.10.1.0\RuntimeSettings\0.settings
VERBOSE: [2015-06-04T00:06:41] Retrieving WMF download information...
VERBOSE: [2015-06-04T00:06:41] WMF Version: 5.0
VERBOSE: [2015-06-04T00:06:41] OS Version : 6.3
VERBOSE: [2015-06-04T00:06:41] Server OS : True
VERBOSE: [2015-06-04T00:06:41] 64-bit OS : 64 64
VERBOSE: [2015-06-04T00:06:41] Verifying that WMF (KB3055381) is installed...
VERBOSE: [2015-06-04T00:06:43] Installing WMF (KB3055381)...
VERBOSE: [2015-06-04T00:06:43] Downloading
http://download.microsoft.com/download/4/9/6/496E0D89-F3B0-4FB0-B110-5F135C30325F/WindowsBlue-KB3055381-x64.msu ...
VERBOSE: [2015-06-04T00:06:56] [ERROR] Exception calling "DownloadFile" with "2" argument(s): "The remote name could not be
resolved: 'download.microsoft.com'"
VERBOSE: [2015-06-04T00:06:56] Writing handler status to C:\Packages\Plugins\Microsoft.Powershell.DSC\1.10.1.0\Status\0.status
VERBOSE: [2015-06-04T00:06:56] An error occurred during installation; creating

Sometimes the error message can also be :

{"status":"Failed","error":{"code":"ResourceDeploymentFailure","message":"The resource operation completed with terminal provisioning state 'Failed'.","details":[{"code":"VMExtensionProvisioningError","message":"VM has reported a failure when processing extension 'DscConfig'. Error message: &quot;File lock (C:\Packages\Plugins\Microsoft.Powershell.DSC\1.10.1.0\bin\..\DSCWork\ExtensionHandler.Lock.dsc) exists: another instance of the extension is already running&quot;."}]}}

Thanks
Alex

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

Repro Steps:
Run a deployment of 10 VMs with a JSON on IaaS V2 using ARM REST API
These 10 VMs must also have a DSC Extension resource deployed.

Expected Results:

Internal BugId: 14542

Votes from Connect: 3

Original Date Submitted: 5/27/2015 6:49:42 AM

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

Frequency: PowerShell
Regression: get-help Get-Help -Full | Out-String -stream | select-string "^\s+<CommonParameters>" -Context 0,5

Problem Description:
When you call Get-Help on a function right now the InformationAction and InformationVariable common parameters aren't mentioned:

PARAMETERS

<CommonParameters>

    This cmdlet supports the common parameters: Verbose, Debug,

    ErrorAction, ErrorVariable, WarningAction, WarningVariable,

    OutBuffer, PipelineVariable, and OutVariable. For more information, see

    about_CommonParameters (<a rel="nofollow noreferrer" href="http://go.microsoft.com/fwlink/?LinkID=113216)">http://go.microsoft.com/fwlink/?LinkID=113216)</a>.

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

Repro Steps:
get-help Get-Help -Full | Out-String -stream | select-string "^\s+<CommonParameters>" -Context 0,5

Expected Results:

<CommonParameters>

    This cmdlet supports the common parameters: Verbose, Debug,

    InformationAction, InformationVariable, ErrorAction, ErrorVariable, 

    WarningAction, WarningVariable, OutBuffer, PipelineVariable, and OutVariable. 

    For more information, see about_CommonParameters 

    (<a rel="nofollow noreferrer" href="http://go.microsoft.com/fwlink/?LinkID=113216)">http://go.microsoft.com/fwlink/?LinkID=113216)</a>.

Internal BugId: 14515

Votes from Connect: 3

Original Date Submitted: 5/6/2015 6:00:56 PM

Description:
Contact Information
Handle: FaustoNascimento
Site Name: PowerShell
Feedback ID: 1307824

Problem Description:
PowerShell are a great introduction to PowerShell, but I feel that they are lacking in a few areas currently:

• No $PSBoundParameters. With the inability to have fields (rather than properties) in PowerShell classes, and the fact that properties are always public (even with the keyword 'hidden' they can still be accessed externally to the class), it becomes impossible to determine whether a property has a value that is default because of PowerShell's coercion, or if a property has that value because the user specified that specific value. In advanced functions, this was possible using $PSBoundParameters, but such a thing does not exist in classes. Sure, we could make all of our [string]s, [boolean]s and [int]s (among others) [Nullable[string]], [Nullable[boolean]] and [Nullable[int]] but most of the people that PowerShell is targeted at do not know what System.Nullable is, which is probably the reason why $PSBoundParameters was implemented in the first place for functions.




• No $PSCmdlet - $PSCmdlet provides quite a good array of features, including but not limited to... WriteError and ThrowTerminatingException, but $PSCmdlet is not available inside a class. Sure, there is still Write-Error, but it generates a rather 'ugly' ErrorRecord that pales in comparison to $PSCmdlet.WriteError and there's also the throw keyword, but it doesn't really generate a terminating error (it can be stopped from being a terminating error by using ErrorAction Continue).




• No ability to push an object to the pipeline - While an object can be pushed to the pipeline through the return statement, there is no way to push one object at the time - yield return. It is also not possible to invoke $PSCmdlet.WriteObject() since $PSCmdlet is not present, and Write-Output gets ignored. This is probably the biggest issue I can see, as it breaks the whole concept of PowerShell's ability to process one record at the time without having to store everything in memory when using the new classes.

Thanks you,
Fausto Nascimento

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

Repro Steps:

Internal BugId: 14447

Votes from Connect: 4

Original Date Submitted: 4/6/2015 10:06:18 AM

Description:
Contact Information
Handle: Kirk Munro
Site Name: PowerShell
Feedback ID: 1228413

Problem Description:
While the $PSDefaultParameterValues variable offers many convenient use cases to control how individual or groups of commands behave, it should be automatically cleared in a module scope. Otherwise state configuration that a user sets up in the current runspace may break functionality in modules that are used in that runspace.

For example, June sent out a tweet suggesting you should consider forcing Get-Help to always show help in a window, like this:
$PSDefaultParameterValues['Get-Help:ShowWindow'] = $true

That suggestion is unwise today because any commands that internally perform automation using Get-Help will now apply the ShowWindow switch parameter (if the appropriate parameter set is being used). As a result, my Get-Snippet command from my SnippetPx module appeared broken for a user to followed June's suggestion, just because I didn't explicitly use the equivalent of -ShowWindow:$false in my binary module where Get-Snippet is implemented.

Since PSDefaultParameterValues automatically carries into Module scope today, it puts a lot of onus on the module author to write their module such that it has appropriate defenses against this, so that commands they write work as they were intended to work. Instead of pushing this task upon module authors, it would be much better for the PowerShell ecosystem if PSDefaultParameterValues simply did not carry over into the module scope as it does today.

The workaround for this is one or more of the following:
1. In a script module, invoke $PSDefaultParameterValues.Clear() at the top of the script module. Unfortunately, this should be done in every script module that exists to properly contain PSDefaultParameterValues behaviour. Also unfortunately, this workaround does not resolve the issue for nested binary modules.
2. If you are using a binary module, and if you invoke commands via the System.Management.Automation.PowerShell class, make sure that you either explicitly work around breaking scenarios by passing in parameters that you don't need (yuck) with values such that they won't break your module, or make sure that when you don't use the AddScript method, and if you do use the AddCommand method, do it with the CommandMetadata overload so that your command invocation won't be affected by PSDefaultParameterValues.

Having to keep track of these details and apply them time and again is just too much work for the developer, so please change this behaviour so that commands can work as they were designed to work. PSDefaultParameterValues should be limited to one scope area at a time (user session scope, or scope in a specific module).

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

Repro Steps:

Internal BugId: 14364

Votes from Connect: 3

Original Date Submitted: 2/10/2015 9:29:49 AM

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

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

Problem Description:
Example 4 of Receive-Job (the one with the $Using scope modifier) fails because the local variable ($j) holds a deserialized job object that Receive-Job can't convert.

Please change the example to:

$s = New-PSSession -ComputerName 'MyRemoteServer'
$j = Invoke-Command -Session $s -ScriptBlock {Start-Job -ScriptBlock {Get-Eventlog -LogName System}}
$iid = $j.InstanceID
$results = Invoke-Command -Session $s -ScriptBlock {Receive-Job -InstanceID $Using:iid}

Thanks (and sorry about the error),
June

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

Repro Steps:
$s = New-PSSession -ComputerName 'MyRemoteServer'
$j = Invoke-Command -Session $s -ScriptBlock {Start-Job -ScriptBlock {Get-Eventlog -LogName System}}

PS C:&gt; $results = Invoke-Command -Session $s -ScriptBlock {Receive-Job -Keep -Job $Using:j}
Cannot bind parameter 'Job'. Cannot convert the "System.Management.Automation.PSRemotingJob" value of type "Deserialized.System.Management.Automation.PSRemotingJob" to type
"System.Management.Automation.Job".

+ CategoryInfo          : InvalidArgument: (:) [Receive-Job], ParameterBindingException

+ FullyQualifiedErrorId : CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.ReceiveJobCommand

+ PSComputerName        : juneb-srv01

Expected Results:
PS C:&gt; $results
Index Time EntryType Source InstanceID Message

7667 Feb 09 16:32  Information Service Control M...   1073748860 The Windows Error Repo

7666 Feb 09 16:32  Information Service Control M...   1073748860 The Windows Error Repo

7665 Feb 09 16:30  Information Service Control M...   1073748860 The Windows Error Repo

7664 Feb 09 16:29  Information Service Control M...   1073748860 The Windows Remote Man

....

Internal BugId: 13232

Votes from Connect: 5

Original Date Submitted: 2/4/2015 1:35:58 PM

Description:
Contact Information
Handle: David Wyatt
Site Name: PowerShell
Feedback ID: 1114651

Frequency: Always Happens
Regression: I do not know if this issue existed previously

Problem Description:
One would expect -imatch to always be case-insensitive, and -cmatch to always be case sensitive. However, this is only true if you pass something other than a [regex] object on the right of the operator. Under those conditions, PowerShell builds a new regex object with the proper case sensitive setting. If you pass in a [regex] object, it just uses that object regardless of whether it matches the case sensitivity behavior of the operator.

The same is true of the -notmatch operator. The -replace operator is a bit funny; it has this same bug if you only pass in a pattern (allowing the behavior to replace text with a null string), but always constructs new regex objects if you pass in a list of arguments as the right operand.

-Split, on the other hand, always builds a new regex and works the way you would expect, except for one tricky case, when the pattern itself contains regex options which contradict (and override) the regex constructor. (as shown in the repro steps. This same behavior applies to the -match, -notmatch, and -replace operators when strings are passed rather than regex objects.)

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

Repro Steps:
$string = 'onetesttwo'
$regex = [regex]'TEST'

Demonstrating passing in regex objects to -match and -replace operators (no options in pattern)

$string -imatch $regex # False
$string -ireplace $regex, 'Replaced' # 'onetesttwo'

$regex = New-Object regex('TEST', [System.Text.RegularExpressions.RegexOptions]::IgnoreCase)

$string -cmatch $regex # True
$string -creplace $regex # 'onetwo'
$string -creplace $regex, '' # 'onetesttwo'

Demonstrating passing strings to these operators, when the string pattern contains embedded regex options.

$string -imatch '(?-i)TEST' # False
$string -cmatch '(?i)TEST' # True

$string -ireplace '(?-i)TEST', 'Replaced' # 'onetesttwo'
$string -creplace '(?i)TEST', 'Replaced' # 'oneReplacedtwo'

$string -csplit '(?i)TEST' # splits into array
$string -isplit '(?-i)TEST' # does not split

Expected Results:
-c operators should always be case sensitive, and -i operators should always be case insensitive, regardless of what types of objects or patterns the caller passed in. When constructing new regex objects for these operators, PowerShell should first parse for and strip out the case-sensitive regex option, if present, so it doesn't override the RegexOptions value passed into the constructor.

Internal BugId: 13218

Votes from Connect: 4

Original Date Submitted: 11/20/2014 5:43:42 AM

Description:
Contact Information
Handle: Tom Nolan [MSFT]
Site Name: PowerShell
Feedback ID: 1033948

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

Problem Description:
Most of the *-Object commands support the use of calculated properties, but Measure-Object doesn't. This would be a useful piece of functionality and would also put it in line with the other cmdlets.

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

Repro Steps:

The following code is a simple example showing the various *-Object commands that support calculated properties, along with

what the desired format would be for Measure-Object

$obj = @(

[pscustomobject]@{Caption="Lorem ipsum dolor sit amet, consectetur adipiscing elit."; Value=1},

[pscustomobject]@{Caption="Duis convallis egestas sem sit amet efficitur."; Value=2},

[pscustomobject]@{Caption="Vivamus ut odio dignissim, sollicitudin odio fermentum, sollicitudin purus."; Value=4}

[pscustomobject]@{Caption="Vivamus vitae lectus eleifend quam condimentum commodo eget quis arcu."; Value=8}

[pscustomobject]@{Caption="Nullam pulvinar, massa at consequat varius, nisi nibh euismod ante, nec vestibulum ligula nunc sed velit."; Value=16}

)

Example of Group-Object using a calculated property

Write-Host "Group-Object" -ForegroundColor Green
$obj | Group-Object -Property {$_.Caption.IndexOf("q") -ge 0} | ft -auto

This is what Measure-Object should be capable of, but fails

write-host "Measure-Object - Fail" -ForegroundColor Green
$obj | Measure-Object -Property { $_.Caption.Length } -Sum -Average -Maximum -Minimum

Expected Results:

This command, which fails...

$obj | Measure-Object -Property { $_.Caption.Length } -Sum -Average -Maximum -Minimum

Should have the same output as this work-around, but with the property displayed as "{ $_.Caption.Length }" instead of the

property that was created by the select-object command.

$obj | Select-Object @{N="Length"; E={$_.Caption.Length} } | Measure-Object -Property Length -Minimum -Maximum -Sum -Average

Internal BugId: 13107

Votes from Connect: 3

Original Date Submitted: 11/15/2014 1:29:53 AM

Description:
Contact Information
Handle: Gantcho Radoslavov
Site Name: PowerShell
Feedback ID: 1029839

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

Problem Description:
Invoke-webrequest is proving quite helpful. It would be nice however to be able to control the bandwidth used by the cmdlet. Is it possible to add the feature to throttle the bandwidth used by the command?

Thank you

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

Repro Steps:
using invoke-webrequest to fetch files from uri sources will use all the available bandwidth it can get

Expected Results:
Have an ability to control used bandwidth

Internal BugId: 13101

Votes from Connect: 3

Original Date Submitted: 9/16/2014 12:15:09 AM

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

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

Problem Description:
When you catch exceptions, those exception still appear in the global $Error list. I expect that caught exceptions shouldn't appear there because I'm catching and handling them. We have build pipelines that fail builds if there are any errors in the global $Error variable, and this causes false failures in situations where we are handling the exceptions.

$Error.Clear()
try
{

 throw 'Blarg!'

}
catch
{

# Caught and handled, Captain!

}

$Error

Note that $Error contains the caught Blarg exception.

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

Repro Steps:
$Error.Clear()
try
{

 throw 'Blarg!'

}
catch
{
}

$Error

Note that $Error contains the Blarg exception that I caught.

Expected Results:
I would expect the $Error variable to be empty, since I caught and handled the error.

Internal BugId: 11002

Votes from Connect: 22

Original Date Submitted: 12/27/2013 7:41:19 AM

Description:
Contact Information
Handle: Mark Michaelis
Site Name: PowerShell
Feedback ID: 812361

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

Problem Description:
Hi,

I have created several providers that work for files (e.g. Skydrive, Dropbox, photo sights, etc.). I would like to be able to copy files from the file system up to these providers and vice-versa. Please provide some means so that the provider copy-item and move-item operations will work across providers. Without this feature the following error is returned:

 "Source and destination did not resolve to the same provider."

Currently there doesn't seem to be any work around while still using the Copy-Item/Move-Item pattern.

Thanks,
Mark

Mark Michaelis | Chief Technical Architect, Microsoft Regional Director & MVP
Author of Essential C# 5.0

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

Repro Steps:
Expected Results:

Internal BugId: 7564

Votes from Connect: 10

Original Date Submitted: 12/6/2012 12:15:54 AM

Description:

Contact Information
Handle: Trevor Sullivan
Site Name: PowerShell
Feedback ID: 773554

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

Problem Description:
When writing a PowerShell function, script, or ScriptBlock that accepts named parameters, it is sometimes desirable to have the end user prompted for input. PowerShell input prompts work great for strings and integers, but fails with other data types (eg. bool, object).

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

Repro Steps:
function Test-Parameter {

[CmdletBinding()]

param (

    [Parameter(Mandatory = $true, HelpMessage = "Please input a Process object")]

    [System.Diagnostics.Process] $input

)


Write-Host -Object $input.Description;

}

$Process = (Get-Process)[10]; # Get a System.Diagnostics.Process object
Write-Host -Object $proc.GetType().FullName; # Make sure we actually have a System.Diagnostics.Process object

Test-Parameter; # Call the Test-Parameter function. When prompted for input

                                           # plug in $Process.

#

function Test-Parameter {

[CmdletBinding()]

param (

    [Parameter(Mandatory = $true, HelpMessage = "Please input a Process object")]

    [bool] $TrueOrFalse

)


Write-Host -Object $TrueOrFalse;

}

Test-Parameter; # When prompted, type $false. The function returns $true, because the inputs is evaluated as a string.

Expected Results:
You should be able to specify variable input when prompted to input parameter values. For boolean values, you should be able to input $true or $false when prompted. For arbitrary objects, you should be able to specify a variable that contains the object you want to use as input.

Internal BugId: 3995

Votes from Connect: 10

Original Date Submitted: 5/9/2012 10:46:55 PM

Description:
Contact Information
Handle: Kirk Munro
Site Name: PowerShell
Feedback ID: 741367

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

Problem Description:
This is a request for v.Next (post v3). More and more admins have been asking how they can store modules in a central repository so that they can centrally manage them while making them available to all systems where they use PowerShell. This is easy to do, however they need to be careful because some modules are designed to store configuration/state information in their own module folder. That won't work if the end user doesn't have rights to the location where the module is stored. It's also not a good practice to follow because there are specific locations where application data should be stored (Isolated Storage, for example).

I would like to see an enhancement made such that modules either have access to a new automatic variable ($PSModuleLocalStorage) with methods that facilitate writing/reading module configuration data to/from disk in the right location for each user of that module, or a small set of cmdlets specific to modules that are designed to facilitate the same thing. This feature should use the module GUID as part of the path automatically so that changes in module names don't affect the location where configuration/state information is stored.

There are other possibilities for this feature that could be considered as well, such as:
1. Storing the version of the module with the data so that module authors can detect the version when reading from disk and then perform upgrades if the data being used has changed between versions.
2. Encrypting the data written to disk automatically so that only the current user can access it (could be a module-specific setting).
3. Providing easy reading/writing of a single data file (the most common/simple use case), with support for reading/writing of additional files to the same location (for more complex module needs).

This is just a request for the most basic functionality to start though.

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

Repro Steps:
Try to store module configuration/state data for the current user in the module folder when the module is on a file share that the user doesn't have access to. You can't do that. Now try to easily identify where you should store that data and store it there so that it is easily accessible to the module even if the name changes and so that the folder is automatically created if it does not exist without writing a lot of script to handle that. You can't, it takes a fair amount of script to do this right.

Expected Results:
This should be easier, and it should promote best practices automatically, so that module authors do this consistently and correctly every time.

Internal BugId: 3569

Votes from Connect: 40

Original Date Submitted: 3/10/2012 1:56:58 PM

Description:

Contact Information
Handle: ramseyg [MVP]
Site Name: PowerShell
Feedback ID: 730195

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

Problem Description:
We have a user-authenticated proxy server on our corporate network. All systems/users must authenticate to access the internet. It is seamless from an internet browser perspective. We have an autoconfiguration script, or we can just enter the proxy information into internet explorer settings, and can browse to the web without any challenge/password.

I can even run commands like get-help get-command -online successfully. But I consistently receive an error when I attempt to run save-help from a corporate network connection. See attached image for more information.

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

Repro Steps:
see description. Just configure internet access to require proxy auth, and then attempt to run 'save-help'

Expected Results:
as long as I can access the internet, I should be able to run the 'save-help' command without issue.

Internal BugId: 3426

Votes from Connect: 10

Original Date Submitted: 3/8/2012 8:34:09 AM

Description:
Contact Information
Handle: Nektar
Site Name: PowerShell
Feedback ID: 729570

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

Problem Description:
In other scripting languages such as Python and MatLab, you can create say a list of all numbers from 0 to 100 stepping by 5 each time by typing something like 0:5:100. Also, you can splice an array from a point to the end by typing 0:end or in Python the last item is -1. In Powershell the .. operator can only accept a starting and an ending value but from what I know not a stepping value and not a keyword to tell it to find the end of ann array but you have to use the more wordy .length notation instead. So, for example I can't get all the even lines from a file by typing $l = cat file.txt; $f[0..2..end]; for example. I have to write a for loop instead. Please, since you have the .. operator, do not let it stand there without being used. Just add these two little things to it and it could eliminate the usage of so many loops. Otherwise, the .. operator is very limited unlike most other scripting languages.

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

Repro Steps:
Type 1..2..9; notice that you get an error.

Expected Results:
A) When I type 0..5..100 I want to get an array of all the numbers from 0 to 100 stepping by 5 each time, i.e. 0, 5, 10, 15, ..., 90, 95, 100.
B) When I type $arr[5..2..end] I want to be able to get all the even elements of the array $arr from element 5 to ($arr.length - 1).

Internal BugId: 3419

Votes from Connect: 13

Original Date Submitted: 9/21/2011 11:21:52 AM

Description:
Contact Information
Handle: Matthew Reynolds [MSFT]
Site Name: PowerShell
Feedback ID: 689864

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

Problem Description:
Remote registry is a core feature of Windows since before I can remember. IT Pros shouldn't have to resort to external exes, WMI, WinRM or .Net methods to use remote regsitry from powershell. They should be able to script naturally against remote registry.

Providers/cmdlets which interact with registry (e.g., set-item, get-item, etc) should be updated to use remote registry just like they can use remote files via SMB. The underlying .Net classes support it, Windows supports it.

Something like Get-Item \remotemachine\HKLM:\System\Blah

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

Repro Steps:
Expected Results:

Internal BugId: 3027

Votes from Connect: 14

Original Date Submitted: 6/14/2011 7:44:51 PM

Description:
Contact Information
Handle: Vadims Podans
Site Name: PowerShell
Feedback ID: 675309

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

Problem Description:
'-Filter' parameter tries to bind filter pattern to a both general name and a name in the 8.3 notation (MS-DOS format). This causes that in the 'Get-ChildItem -Filter' output appears unexpected items. For details see repro section.

Also this may cause catstrophic results if Get-ChildItem output is passed to Remove-Item cmdlet. Administrator will not expect that Program Files folders will match this pattern. Also PowerShell haven't native ways to determine certain object (file or folder) short name in 8.3 notation and returned object doesn't contain related property. This can be done dy running 'dir.exe' with /x switch.

Also documentation has no mention about this behavior.

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

Repro Steps:
[↓] [vPodans] dir c:\ -Filter *1

Directory: C:\

Mode LastWriteTime Length Name

d-r-- 08.04.2011. 1:08 Program Files

[↓] [vPodans] dir c:\ -Filter *2

Directory: C:\

Mode LastWriteTime Length Name

d-r-- 24.02.2011. 8:30 Program Files (x86)

[↓] [vPodans]

Expected Results:
Since neither of outputed objects matches this pattern nothing should be returned unless any object name ends with '1'.

Internal BugId: 2944

Votes from Connect: 15

Original Date Submitted: 10/21/2010 7:25:53 AM

Description:
Contact Information
Handle: rkeithhill
Site Name: PowerShell
Feedback ID: 615447

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

Problem Description:
It would be nice if you could decorate an advanced function parameter with an “AcceptsWildcard” attribute like this and have the parameter parsing code actually do the wildcard expansion for you. Of course the doc comment help should use the presence of this attribute to indicate correctly whether or not the parameter accepts wildcards. Perhaps the attribute would take an option to specify simple ([ ], *, ?), regex or custom (let me do it) wildcard expansion. That would be one less thing you would have to do in your cmdlet and as a result, one less thing folks would screw-up.

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

Repro Steps:
Currently in order to support globbing, each cmdlet developer has to known to do this and get the incantation right. This is error prone and results in inconsistencies with 3rd party cmdlets in terms of globbing behavior. Also, advanced functions doc comment help could use the attribute to properly document parameter that "accept wildcards".

Expected Results:
I expect the PowerShell parameter parsing engine to do the globbing work for me. :-)

Internal BugId: 2720

Votes from Connect: 4

Original Date Submitted: 8/24/2015 10:15:01 PM

Description:
Contact Information
Handle: herzbube
Site Name: PowerShell
Feedback ID: 1707779

Frequency: PowerShell
Regression: 1. Create a folder C:[foo]
2. Add a file "bar" to the folder
3. Run the following commands in PowerShell:

$path = 'C:\[foo]'

get-childitem -literalpath $path -recurse

Problem Description:
Let's say I have this file:

C:\[foo]\bar

I then run these PowerShell commands:

$path = 'C:\[foo]'

get-childitem -literalpath $path

Everything works fine, get-childitem shows me the file bar, then returns immediately.

Now I add the -recurse option:

$path = 'C:\[foo]'

get-childitem -literalpath $path -recurse

get-childitem no longer displays the file bar. In addition, the cmdlet runs a long time and displays various "permission denied" error messages for folders underneath C:\Windows, apparently because it scans the entire C: drive.

The problem is tied to the fact that the folder [bar] has brackets in the name. If I rename the folder to bar, i.e. without brackets, the result with recursion works as expected.

Environment: Windows 8.1, PowerShell 4.0.

Additional notes:

• I verified that in PowerShell 2.0 (on a Windows 7 machine) get-childitem returns the same result with or without -recurse. It appears that the behaviour has changed either in version 3.0 or 4.0.


• This post on technet.microsoft.com seems to describe the same problem. The poster uses PowerShell 3.0, so it would seem that the behaviour changed between versions 2.0 and 3.0: https://social.technet.microsoft.com/Forums/windowsserver/en-US/0fa34fab-cb35-4369-baad-a320ca610e24/getchilditem-file-recurse-literalpath-ctest-1-does-not-return-any-information?forum=winserverpowershell
  


• The post above also has a workaround: Use -path instead of -literalpath, then escape the square bracket characters.

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

Repro Steps:
1. Create a folder C:[foo]
2. Add a file "bar" to the folder
3. Run the following commands in PowerShell:

$path = 'C:\[foo]'

get-childitem -literalpath $path -recurse

Expected Results:
get-childitem displays the file "bar" and returns immediately.

Internal BugId: 15754