Votes from Connect: 17

Original Date Submitted: 11/23/2010 4:09:27 PM

Description:
Contact Information
Handle: Aleksandar Nikolic
Site Name: PowerShell
Feedback ID: 623892

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

Problem Description:
I would like to see Enable-PSRemoting support for ComputerName parameter to enable remoting on a remote machine.

If you are in a domain environment then the ComputerName parameter would not mean much because you could use GPO to enable PowerShell remoting wherever you like. However, in a workgroup environment it could be quite useful.

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

Repro Steps:
Expected Results:

Internal BugId: 2755

When configuring IIS using Powershell, the cmdlets that read or write to configuration do not work when the application pool is 32-bit.

There is no way of specifying the "bitness" of the application therefore by default the configuration is written to the web.config file in the Framework64 folder which is ignored for 32-bit applications.

This is also the case for IIS manager when using "Configuration Editor". You can choose the location of "Root Web.Config <location path="my website"> however this ignores whether the application is 32 or 64 bit and always writes to the 64 bit location in the Framework64 folder.

On many cmdlets it is possible to specify the clr version however this does not help when the application is 32-bit.

Votes from Connect: 5

Original Date Submitted: 10/30/2014 6:04:29 AM

Description:
Contact Information
Handle: Peter M10
Site Name: PowerShell
Feedback ID: 1014939

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

Problem Description:
I would like to access the pipeline object with Where-Object without curly brackets like so:

1..10 | Where-Object $_ % 2 -eq 1

to get only uneven numbers.

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

Repro Steps:
1..10 | Where-Object $_ % 2 -eq 1

Expected Results:
Gives an "Cannot validate argument on parameter 'Property'." error.

Internal BugId: 13075

Votes from Connect: 3

Original Date Submitted: 8/22/2014 2:01:53 AM

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

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

Problem Description:
Write-Error isn't supposed to take both a message and an exception (see help Write-Error), but you can pass both without getting the "Parameter set cannot be resolved using the specified named parameters." error message.

Also, when you use Write-Error in a catch block, and use both parameters, the original exception bubbles up instead of what gets written with Write-Error.

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

Repro Steps:

I expect this to fail with a "Parameter set cannot be resolved using the specified named parameters." error. Instead, I see an error written.

Write-Error -Message 'Blarg!' -Exception (New-Object 'Exception')


# If you do the above in a catch block, the Write-Error message never shows, instead the exception bubbles up.

# I'd like to get a 'Parameter set cannot be resolved using the specified named parameters.' error instead so I can fix my authoring error.

try

{

    throw 'Blarg!'

}

catch

{

    Write-Error -Message 'my custom message' -Exception $_.Exception

}

$Error[0] | fl -Force

$Error.Clear()

# This is the code I *should* have written, but PowerShell doesn't help me write it!

try

{

    throw 'Blarg!'

}

catch

{

    Write-Error -Message 'my custom message' 

}

$Error[0] | fl -Force

Expected Results:

Internal BugId: 8965

Votes from Connect: 20

Original Date Submitted: 2/27/2009 5:16:35 PM

Description:
Contact Information
Handle: Itanium2
Site Name: PowerShell
Feedback ID: 418906

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

Problem Description:
For example, we have a folder and Administrator or Administrators group is object owner and doesn't have explicit (or inherited from parent) ACE with TakeOwnership right. Running code (see reprodiction steps) we get an error.

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

Repro Steps:
here is code that adds Everyone group to existing ACL:
$acl = Get-Acl C:\test
$accessRule = New-Object System.Security.AccessControl.FileSystemAccessRule("everyone", "FullControl", "Allow")
$acl.AddAccessRule($accessRule)
$acl | Set-Acl C:\test

while current user has TakeOwnership right - all works as expected. However if we remove this right for current user we get error:

Set-Acl : Attempted to perform an unauthorized operation.
At line:1 char:15
+ $acl | Set-Acl <<<< C:\test

+ CategoryInfo          : PermissionDenied: (C:\test:String) [Set-Acl], UnauthorizedAccessException

+ FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft.PowerShell.Commands.SetAclCommand

Expected Results:
here is no neccessary to have TakeOwnership right if user is objects owner.

Internal BugId: 1949