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

Original Date Submitted: 12/7/2011 8:49:03 AM

Description:
Contact Information
Handle: MMarcolini
Site Name: PowerShell
Feedback ID: 712014

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

Problem Description:
The Output pane is gone and the command pane has been transformed into the frankly clunky blue powershell command prompt. Why? This is like taking 3 steps backwards.

I use the ISE to interactively manage my windows systems in much the same way that I use an xterm to manage my unix systems. I typically have many local and remote command tabs open separated by task with snippets of code in the "Untitled#" Script Pane that eventually make their way into my OneNote script repository. I periodically snapshot my history and output pane to capture workflow.

I prefer the ISE over powerGUI and other editors because it's faster and because I MUCH prefer the way it manages the Command Pane and the Output Pane. The separation is both visually and functionally appealing. If I want to run something in a non-gui command prompt, I just click on the handy "Start Powershell.exe" provided.

Please restore the Output pane! This is such a big deal that I've actually rolled back to the older CTP.

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

Repro Steps:
Expected Results:

Internal BugId: 3175

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

Original Date Submitted: 12/20/2010 5:55:34 AM

Description:
Contact Information
Handle: Bartek Bielawski
Site Name: PowerShell
Feedback ID: 632464

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

Problem Description:
Currently I see no easy way to get type of registry values. Info presented by Get-ItemProperty is not very helpful. I found workaround for that (sample):
$key = Get-Item 'HKLM:\software\Microsoft\windows\CurrentVersion\policies\Explorer'
$Property = @{Name = 'Property'; Expression = {$}}
$Value = @{Name = 'Value'; Expression = {$key.GetValue($) }}
$ValueType = @{Name = 'Value Type'; Expression = {$key.GetValueKind($_)}}
$key.Property | select $Property, $Value, $ValueType
I think it would be better if Get-ItemProperty would return type too.

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

Repro Steps:
Expected Results:

Internal BugId: 2773

Votes from Connect: 18

Original Date Submitted: 12/13/2010 7:55:24 PM

Description:
Contact Information
Handle: HPH2
Site Name: PowerShell
Feedback ID: 630828

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

Problem Description:
From: http://social.technet.microsoft.com/Forums/en-US/ITCG/thread/7d2a0b0e-254f-4725-9c02-20744cd3cdd5/

Powershell version 2.0

Background:
I have a script successfully assembling information about servers in our primary domain.
Now i am trying to use PowerShell Remoting to include information about servers in our DMZ zones.
This works great.

Except when i try to query the Active Directory.

Following runs fine in a powershell window on the server dzms01 in a remote desktop session:

PS C:> $DomainRootPath='LDAP://DC=beodmz,DC=beo,DC=dk'
PS C:> $servername='dzms01'
PS C:> $searcher = new-object DirectoryServices.DirectorySearcher([ADSI] $DomainRootPath)
PS C:> $searcher.filter = "(&(objectClass=computer)(Name=$servername))"
PS C:> $searcher.CacheResults = $true
PS C:> $searcher.SearchScope = 'Subtree'
PS C:> $searcher.PageSize = 1000
PS C:> $ad=$searcher.FindOne()
PS C:> $ad

Path Properties

LDAP://CN=DZMS01,OU=ProductionServers,OU=Servers,DC=beod... {operatingsystem, countrycode, cn, lastlogoff...}

PS C:> $searcher

CacheResults : True
ClientTimeout : -00:00:01
PropertyNamesOnly : False
Filter : (&(objectClass=computer)(Name=dzms01))
PageSize : 1000
PropertiesToLoad : {}
ReferralChasing : External
SearchScope : Subtree
ServerPageTimeLimit : -00:00:01
ServerTimeLimit : -00:00:01
SizeLimit : 0
SearchRoot : System.DirectoryServices.DirectoryEntry
Sort : System.DirectoryServices.SortOption
Asynchronous : False
Tombstone : False
AttributeScopeQuery :
DerefAlias : Never
SecurityMasks : None
ExtendedDN : None
DirectorySynchronization :
VirtualListView :
Site :
Container :

PS C:> $searcher.SearchRoot

distinguishedName : {DC=beodmz,DC=beo,DC=dk}
Path : LDAP://DC=beodmz,DC=beo,DC=dk

PS C:> $searcher.SearchRoot.path
LDAP://DC=beodmz,DC=beo,DC=dk
PS C:>

Trying to do the same thing from my PC using powershell remote, and using the same login credentials, i get this:

PS C:> $ses = New-PSSession -ComputerName 'dzms01' -Credential $cred
PS C:> Invoke-Command {$DomainRootPath='LDAP://DC=beodmz,DC=beo,DC=dk'} -session $ses
PS C:> Invoke-Command {$DomainRootPath} -session $ses
LDAP://DC=beodmz,DC=beo,DC=dk
PS C:> Invoke-Command {$servername='dzms01'} -session $ses
PS C:> Invoke-Command {$searcher = new-object DirectoryServices.DirectorySearcher([ADSI] $DomainRootPath)} -session $ses
PS C:> Invoke-Command {$searcher.filter = "(&(objectClass=computer)(Name=$servername))"} -session $ses
PS C:> Invoke-Command {$searcher.CacheResults = $true} -session $ses
PS C:> Invoke-Command {$searcher.SearchScope = 'Subtree'} -session $ses
PS C:> Invoke-Command {$searcher.PageSize = 1000} -session $ses
PS C:> Invoke-Command {$ad=$searcher.FindOne()} -session $ses
Exception calling "FindOne" with "0" argument(s): "An operations error occurred.
"

+ CategoryInfo          : NotSpecified: (:) [], MethodInvocationException

+ FullyQualifiedErrorId : DotNetMethodException

PS C:> Invoke-Command {$searcher} -session $ses

PSComputerName : dzms01
RunspaceId : 19248cc5-e3b2-422d-9f16-62b6419cc0f8
PSShowComputerName : True
CacheResults : True
ClientTimeout : -00:00:01
PropertyNamesOnly : False
Filter : (&(objectClass=computer)(Name=dzms01))
PageSize : 1000
PropertiesToLoad : {}
ReferralChasing : External
SearchScope : Subtree
ServerPageTimeLimit : -00:00:01
ServerTimeLimit : -00:00:01
SizeLimit : 0

The following exception occurred while retrieving member "StringSerializationSource": "An operations error occurred.
"

+ CategoryInfo          : NotSpecified: (:) [], ExtendedTypeSystemException

+ FullyQualifiedErrorId : CatchFromBaseGetMember

PS C:> Invoke-Command {$searcher.SearchRoot} -session $ses
System.DirectoryServices.DirectoryEntry
PS C:> Invoke-Command {$searcher.SearchRoot.path} -session $ses
PS C:> Invoke-Command {$searcher.filter} -session $ses
(&(objectClass=computer)(Name=dzms01))
PS C:>

It seems as the DirectoryServices.DirectorySearcher object is somehow garbled.
Can anyone help me in the right direction?

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

Repro Steps:
Se description above.

Expected Results:
Se description above.

Internal BugId: 2770

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

Original Date Submitted: 8/11/2010 2:47:58 AM

Description:
Contact Information
Handle: Kirk Munro (Quest Software)
Site Name: PowerShell
Feedback ID: 585227

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

Problem Description:
Invoke-Command should handle top-level progress reporting (for example: throttling 5 active operations, 9 complete, 123 machines/sessons to go) and have nested progress bars for individual machines that originate from remote machines so that Write-Progress calls from inside the script block continue to work as expected.

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

Repro Steps:
Call Invoke-Command with 1000 computer names and try to monitor the progress. You can't.

Expected Results:
You should be able to see the progress for a remote command that you are running against many machines.

Internal BugId: 2653

Votes from Connect: 16

Original Date Submitted: 6/16/2010 11:13:55 PM

Description:
Contact Information
Handle: cmille19
Site Name: PowerShell
Feedback ID: 568074

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

Problem Description:
The normal PowerShell host supports startup parameters which facilitate building custom shells (i.e. SCOM, Exchange, Admin Tools etc.) callable from the Windows Start Menu. These custom shells either call a startup script that then load modules or import a console files with customizations.

Unfortunately, PowerShellISE does not support any startup parameters. For the module developer creating solutions which specifically target PowerShellISE.exe and NOT PowerShell.exe, this becomes an issue. Yes, there are workarounds of using/mis-using profiles but this is not ideal.

Please include the -Command and -File startup parameters in a future release of PowerShell_ISE

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

Repro Steps:
N/A

Expected Results:
PowerShell_ISE -Command "C:\LoadMyPowerShellISEModule.ps1"

Internal BugId: 2573

Votes from Connect: 33

Original Date Submitted: 3/12/2010 7:45:29 PM

Description:
Contact Information
Handle: Kirk Munro (Quest Software)
Site Name: PowerShell
Feedback ID: 541500

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

Problem Description:
If you use the preference variables or the -WarningAction common parameter to control how warnings are handled in PowerShell, or if you use the preference variables to control how verbose or debug messages are handled in PowerShell, your control efforts are ignored because the warning, verbose or debug messages are displayed every time anyway.

This differs from how preference variables and the -ErrorAction common parameter affect errors, where you can decide what to do with the error before it is sent to the error stream, including controlling whether or not it is sent to the error stream.

Each of these message streams should be handled consistently, allowing you to control what is sent to the stream and what is simply processed internally by your script.

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

Repro Steps:
& {

$warningPreference = 'Stop'

trap {

    'Inside trap'

    continue

}

Write-Warning 'I''m warning you!'

Write-Host 'After Write-Warning call'

}
'Outside my script block'

Expected Results:
Inside trap
After Write-Warning call
Outside my script block

Note: the warning text should not be displayed, but at the moment it is displayed before the trap statement is even entered

Internal BugId: 2466

Votes from Connect: 20

Original Date Submitted: 6/4/2009 3:05:28 AM

Description:
Contact Information
Handle: reballard
Site Name: PowerShell
Feedback ID: 463828

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

Problem Description:
Add ability to remotely enumerate/query the Local Security Policy within Powershell without having to resort to leverage 3rd party utilities such as DumpSec, etc. output. This ability would be useful when needing to spot check Local Security Policy stuff within a Powershell Script.

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

Repro Steps:
It doesn't appear possible to natively query a Servers Local Security Policy from within Powershell and it doesn't appear that WMI support this. However numerous 3rd party utilities provide this capability by accessing the associated API's.

Expected Results:
Ability to query/enumerate a Server's Local Security Policy config within Powershell without leveraging any 3rd party utilities.

Internal BugId: 2050

Votes from Connect: 42

Original Date Submitted: 2/28/2009 10:20:55 PM

Description:

Contact Information
Handle: hrottenberg
Site Name: PowerShell
Feedback ID: 419466

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

Problem Description:
In a lab environment, or a low-budget situation, SSL certificates come last on the todo list. Currently, the New-WebServiceProxy cmdlet cannot be used with self-signed certificates. When you control the network, self-signed certs present little to no risk and are very commonly used. Please add a Force parameter (or similar) to this cmdlet to allow for ignoring acceptable SSL cert exceptions.

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

Repro Steps:
PS > $proxy = New-WebServiceProxy -Uri $Uri -Credential (Get-Credential)

cmdlet Get-Credential at command pipeline position 1
Supply values for the following parameters:
Credential
New-WebServiceProxy : The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

Expected Results:

Internal BugId: 1954

Votes from Connect: 11

Original Date Submitted: 12/26/2008 4:01:12 PM

Description:

Contact Information
Handle: n4cer
Site Name: PowerShell
Feedback ID: 389694

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

Problem Description:
The new cmdlets added for control of local and remote computers (stop-computer, restart-computer, etc.) are great, but I think they would be complemented by the addition of the following two cmdlets:

Get-Computer
Get-Computer would return objects representing all computers on the network (workgroup or domain) including the local machine. It would serve a similar purpose as CMD's net view, however, the returned computer objects would contain rich information beyond just the computer's name. The IP Address, MAC Address, Domain/Workgroup, possibly logged-in users, uptime, etc., are some things that come to mind. This cmdlet could feed others such as Get-Process, Restart-Computer, Get-Hotfix, etc., and serve as a frequently used cmdlet for systems administration.

Start-Computer
The Start-Computer cmdlet would serve as a Wake On LAN cmdlet, taking one or more MAC Addresses of network computers and sending magic packets to those machines. Support for other protocols could be offered as well, such as Intel's Active Management Technology via WS-Management.

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

Repro Steps:
Expected Results:

Internal BugId: 1834

When an attempt to run an EXE is made from within CMD, or from Windows Explorer, but this fails due to a missing DLL or missing export in a DLL (among other possible failures), a popup message is displayed that tells the interactive user the name of the missing DLL or information about the missing export.

This behavior is not desirable in scripts, so the PowerShell designers have decided not to implement it; instead the execution continues and $LASTEXITCODE is set to something like 0xC0000135.

This makes troubleshooting difficult, because from a PowerShell prompt there is (AFAIK) no way to get the information the popup would bring. There is not even an error message!

I'm a long-time user of MKS Toolkit, where this is configurable -- see the '-X' option at http://www.mkssoftware.com/docs/man1/set.1.asp -- and where the shell at least tells you that the child process could not start.

Couldn't this be implemented in PowerShell (both the console host and the ISE, of course)?

The PWD automatic variable is not set when the script block passed to InlineScript is executing within a workflow targetting a remote computer. Attempts to retrieve the variable (such as Get-Item Variable:\PWD) fail. The variable becomes present as soon as the first Set-Location statement is executed.

This differs from both powershell.exe and standard PS remoting behavior, where the variable is present from the start.

This issue breaks code which expects the PWD variable to always be available, such as IIS PowerShell Provider cmdlets (e.g. Get-WebApplication).

Client / workflow host: WMF 4.0 on Windows 7, also tested on 8.1
Workflow target: WMF 4.0 on Windows Server 2012 R2, also tested on 2008 R2