Votes from Connect: 11

Original Date Submitted: 11/5/2012 5:15:07 AM

Description:
Contact Information
Handle: Sean Kearney
Site Name: PowerShell
Feedback ID: 770035

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

Problem Description:
When Executing a PS-Remoting Session from a Microsoft Surface Device with Windows RT using Powershell 3.0 to Powershell 2.0 on a remote server (with defined trusts in WinRM) Implicit remoting fails

An interactive session on the x64 Remote server works fine, but using an IMPORT-PSSESSION with -prefix parameter fails to produce any available cmdlets.

EXPORT-PSSESSION will produce a module on the local Windows RT device but the module will not load and execute

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

Repro Steps:
Add Client system as "Trusted" I WinRM on remote host
Add remote Host as "Trusted" on WinRM in Windows RT device

execute
$s=NEW-PSSESSION -computer Netbios1 -credential (GET-CREDENTIAL)
(enter credentials for WinRM remoting on Remote system Netbios1)
IMPORT-PSSESSION $S -prefix XX
(To produce new verbs with an "XX" prefix from the remote system)

Expected Results:
If you would like to run something like GET-CHILDITEM C:\THISFOLDER (as an example on the remote system) and store the results in $X

$X=GET-XXCHILDITEM C:\THISFOLDER

It should execute "GET-CHILDITEM C:\THISFOLDER" on remote System NETBIOS1

It fails as the cmdlets do not appear as available cmdlets on the local system

BUT

ENTER-PSSESSION $S
GET-CHILDITEM C:\THISFOLDER

Works fine

Internal BugId: 3937

Votes from Connect: 25

Original Date Submitted: 10/4/2012 10:09:17 PM

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

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

Problem Description:
When you invoke Get-ChildItem in PowerShell 3.0 with a path that does not exist, it searches for all files instead (wtf?). If you combine that with -Recurse and -ErrorAction SilentlyContinue in a script, you're facing a huge performance degradation that won't be easy to spot. Consider the two transcripts below. They show that a single Get-ChildItem call using a path that does not exist on my system takes 1302 times longer on v3 than it does on v2! I intentionally left -ErrorAction off of the command so that errors showing the scope of the search actually being performed by Get-ChildItem could be seen by the errors that identify the paths it is hitting when the command is run.

PowerShell 2 Transcript:

PS C:> Measure-Command {gci -li C:\MyFolder -Recurse -Force}
gci : Cannot find path 'C:\MyFolder' because it does not exist.
At line:1 char:21
+ Measure-Command {gci <<<< -li C:\MyFolder -Recurse -Force}

+ CategoryInfo          : ObjectNotFound: (C:\MyFolder:String) [Get-ChildItem], ItemNotFoundException

+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

Days : 0
Hours : 0
Minutes : 0
Seconds : 0
Milliseconds : 29
Ticks : 292580
TotalDays : 3.38634259259259E-07
TotalHours : 8.12722222222222E-06
TotalMinutes : 0.000487633333333333
TotalSeconds : 0.029258
TotalMilliseconds : 29.258

PowerShell 3 Transcript:

PS C:&gt; Measure-Command {gci -li C:\MyFolder -Recurse -Force}
gci : Access to the path 'C:\Documents and Settings' is denied.
At line:1 char:18
+ Measure-Command {gci -li C:\MyFolder -Recurse -Force}
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : PermissionDenied: (C:\Documents and Settings:String) [Get-ChildItem], UnauthorizedAccess

Exception

+ FullyQualifiedErrorId : DirUnauthorizedAccessError,Microsoft.PowerShell.Commands.GetChildItemCommand

<snip>

gci : Access to the path 'C:\Users\Public\Documents\My Videos' is denied.
At line:1 char:18
+ Measure-Command {gci -li C:\MyFolder -Recurse -Force}
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : PermissionDenied: (C:\Users\Public\Documents\My Videos:String) [Get-ChildItem], Unauthor

izedAccessException

+ FullyQualifiedErrorId : DirUnauthorizedAccessError,Microsoft.PowerShell.Commands.GetChildItemCommand

gci : Access to the path 'C:\Windows\System32\LogFiles\WMI\RtBackup' is denied.
At line:1 char:18
+ Measure-Command {gci -li C:\MyFolder -Recurse -Force}
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : PermissionDenied: (C:\Windows\Syst...es\WMI\RtBackup:String) [Get-ChildItem], Unauthoriz

edAccessException

+ FullyQualifiedErrorId : DirUnauthorizedAccessError,Microsoft.PowerShell.Commands.GetChildItemCommand

Days : 0
Hours : 0
Minutes : 0
Seconds : 38
Milliseconds : 109
Ticks : 381091208
TotalDays : 0.000441077787037037
TotalHours : 0.0105858668888889
TotalMinutes : 0.635152013333333
TotalSeconds : 38.1091208
TotalMilliseconds : 38109.1208

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

Repro Steps:
gci -li C:\DoesNotExist -Recurse

Expected Results:
This should return immediately with an error indicating that C:\DoesNotExist does not exist, just like it did in PowerShell 2.0.

Internal BugId: 3858

Votes from Connect: 12

Original Date Submitted: 9/19/2012 5:52:24 AM

Description:
Contact Information
Handle: TobiasWeltner
Site Name: PowerShell
Feedback ID: 763406

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

Problem Description:
when you press F1 in ISE 3.0, the word the cursor is in is used as a keyword, and ISE executes this code:

Get-Help "keyword" -ShowWindow

The problem here are the double-quotes. The keyword should be placed into single quotes. With double quotes, unexpected behavior and accidental code execution is possible.

See details section below for steps to repro.

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

Repro Steps:
Run this code in ISE:
$test = 'Get-Service'

Place the cursor anywhere into $test and press F1.
Help for Get-Service opens. There should have been help for variables instead or no help at all BUT NOT help based on the content of the variable.

Type this into ISE:
$test = '$(Restart-Computer -whatif)'
Select the text inside the quotes and press F1.
Help opens, and at the same time the selected code executes.

Expected Results:
ISE should place the keyword into single quotes to ensure that it is taken literally and not converted or invoking code execution.

Internal BugId: 3828

Votes from Connect: 78

Original Date Submitted: 9/18/2012 6:29:36 PM

Description:
Contact Information
Handle: Peter Kriegel
Site Name: PowerShell
Feedback ID: 763246

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

Problem Description:
In PowerShell 3.0 there are no help files available in German language. But I would consider missing help as top priority here. Most of the the east German peoples are never learned English (they learned Russia). Even for Peoples who can read English, there is a big danger to misunderstood something. Reading documentation in a foreign language can be very challenging.

Calling the -online Help every time, i need verbose English Help, is no solution. Because i am sitting in a corporate Network with Proxy and no Internet Access!

I have downloaded the English verbose HelpFiles with Save-Help -UICulture 'en-US' but i cant acces this Helpfiles. Because the Help depends on the UI Culture of my current Windows setting.
I cant display them without changind my UI Culture in Windows!
Should i switch my Windows setting allways if i need verbose English help?

I Like to display choose the German AND EVEN the English help without changing my UI Culture in Windows or PowerShell!

Get-Help Get-Comand -Culture "en-US" -Full # should display the Englisch verbose Help
Get-Help Get-Comand -Culture "de-DE" -Full # should display the German verbose Help

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

Repro Steps:
Get-Help = consise crippeld German help

Expected Results:
Get-Help = Verbose (-full) German help OR verbose (-full) English Help without dependency of the UI Culture!

Internal BugId: 3818

Votes from Connect: 23

Original Date Submitted: 9/18/2012 3:37:35 AM

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

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

Problem Description:
There is no help available in Polish both in previous versions and in current version of PowerShell. Actually - nothing is really localized to Polish (including menus in ISE, most of error messages). But I would consider missing help as top priority here: it's not big issue for people who are fluent in English, but reading documentation in foreign language can be challenging.

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

Repro Steps:
Just run Get-Help on pl-PL machine and watch English text showing up. If you prefer other language than English - you may try to use Update-Help -UICulture <other-supported-culture>, but pl-PL is not supported at all...

Expected Results:
At least some documents (about_* topics for starter) could be localized to help administrators in Poland understand major PowerShell concepts, even if they are not fluent in English (most of them are, but that's not the point).

Internal BugId: 3816

Votes from Connect: 11

Original Date Submitted: 7/13/2012 3:45:58 AM

Description:
Contact Information
Handle: RichardMcKenzie
Site Name: PowerShell
Feedback ID: 753494

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

Problem Description:
A new bug has been introduced in powershell v3.0 - RC that does not exist in v3.0 CTP2.

It appears that .ps1 scripts fail to execute and throw the runtime error "Executable script code found in signature block" if the following line appears in the script:

organizational unit filter

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

Repro Steps:
enter the following line into any powershell v3.0-RC script and it will fail

organizational unit filter

ISE will highlight all subsequent code with red underline and show the mouse-hover message "Executable script code found in signature block" and attempts to execute the script will fail with the same runtime exception.

I have tried a few variations, and it appears that only that very specific string causes a failure ... adding any other non-whitespace character to that string removes the error.

What are the chances anyone else would come across that obscure bug ??? heh heh ... oh well ... keep up the good work - loving powershell

Richard McKenzie
richard@rmck.com

Notes:
- execution policy is set to bypass
- works from v3 CTP2 machine on same network & domain, running same OS

Richard McKenzie

Expected Results:

Internal BugId: 3709

Votes from Connect: 10

Original Date Submitted: 7/12/2012 9:58:36 PM

Description:
Contact Information
Handle: sba
Site Name: PowerShell
Feedback ID: 753454

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

Problem Description:
Given that PS3 will not be available for legacy operating systems, and that PS3 will not be deployed everywhere overnight, it is currently required to write scripts that are backwards-compatible with PS2.

This can be achieved by:
- using 'Set-StrictMode-version 2.0'
- testing in a host created by running 'powershell -version 2.0'

But it's not possible to develop using the ISE in PS2 mode.

IMVHO this makes migration to PS3 more difficult and time-consuming than it has to be.

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

Repro Steps:
powershell_ise -version 2.0

fails

Expected Results:
This should start an ISE that uses version 2 of the language

Internal BugId: 3706

Votes from Connect: 18

Original Date Submitted: 6/28/2012 2:16:48 AM

Description:

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

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

Problem Description:
The PowerShell ISE v3 Release Preview does not show the parameter name in the Intellisense window, for a parameter that already has a value define (based on its position).

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

Repro Steps:
1. Open ISE v3 Release Preview
2. In a new script window, type a cmdlet and a value for its first positional parameter (eg. gci *.txt)
3. Place cursor directly after cmdlet name
4. Type [Space] + '-' to invoke Intellisense for parameter names
5. Notice that the parameter at position 0 is not listed

Expected Results:
The parameter name should be listed in Intellisense, if it has not already been explicitly used elsewhere in the command.

Internal BugId: 3676

Votes from Connect: 56

Original Date Submitted: 1/13/2011 12:03:33 AM

Description:
Contact Information
Handle: Oisin Grehan
Site Name: PowerShell
Feedback ID: 635713

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

Problem Description:
From Vista onwards, Windows supports both a transacted registry (TxR) and transacted filesystem (TxF). With powershell v2, we got TxR support. For v3 or beyond, it would be great to have TxF support. A good example taking Pscx's archive cmdlets into account would be the following pipeline:

PS> dir c:\logs\ -rec -inc *.log -usetx | write-zip -removeoriginal -usetx | move-item c:\archived_logs\ -usetx

This will recursively search C:\logs for *.log files, compress them with maximum compression, move them to c:\archived_logs and then delete the original. Transaction support ensures that a failed zip operation (or some other unknown/expected failure) will not result in one of the source files being removed with a corresponding zip backup.

Yes, it's possible to write careful code that will verify written zips etc but even that code may fail in certain circumstances. Tx support keeps it clean and reliable.

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

Repro Steps:
n/a

Expected Results:
n/a

Internal BugId: 2784

Votes from Connect: 21

Original Date Submitted: 10/8/2010 4:46:21 PM

Description:
Contact Information
Handle: TobiasWeltner
Site Name: PowerShell
Feedback ID: 611703

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

Problem Description:
Start-Transcript logs input and output. This creates huge log files.
There should be a switch that enables Start-Transcript to only log the inputs and omit the outputs. Optionally, there could be an indicator whether a command completed successfully, was aborted or raised an exception.

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

Repro Steps:
currently default behavior

Expected Results:
new switch like -small that omits transcribing command results

Internal BugId: 2710

Votes from Connect: 16

Original Date Submitted: 8/9/2010 1:34:16 AM

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

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

Problem Description:
I would like that Get-Member cmdlet supports Online parameter in V3 (similar to Get-Help in V2):

Get-Process | Get-Member -Online

That command would open the .NET Framework page in MSDN (http://msdn.microsoft.com/en-us/library/system.diagnostics.process.aspx).

dir | Get-Member -Online

That command would open the .NET Framework pages in MSDN (http://msdn.microsoft.com/en-us/library/system.io.fileinfo.aspx and http://msdn.microsoft.com/en-us/library/system.io.directoryinfo.aspx).

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

Repro Steps:
Expected Results:

Internal BugId: 2649

Votes from Connect: 15

Original Date Submitted: 7/21/2010 11:36:19 AM

Description:
Contact Information
Handle: bigjimslade80465
Site Name: PowerShell
Feedback ID: 576911

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

Problem Description:
Currently, I need to do this:

if(! ($bar)) { & foo}

I would like to be able to do this:

unless($bar) { & foo}

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

Repro Steps:
Currently, I need to do this:

if(! ($bar)) { & foo}

I would like to be able to do this:

unless($bar) { & foo}

Expected Results:

Internal BugId: 2618

Votes from Connect: 15

Original Date Submitted: 5/29/2010 12:09:48 AM

Description:
Contact Information
Handle: Clint B.
Site Name: PowerShell
Feedback ID: 563695

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

Problem Description:
The -ArgumentList parameter is described as passing arguments 'for the script that is specified by the FilePath parameter', which is true. But it also specifies the arguments to a scriptblock specified by the ScriptBlock parameter.

Additionally the help says that "Because all of the values that follow the ArgumentList parameter name are interpreted as being values of ArgumentList, the ArgumentList parameter should be the last parameter in the command.", which doesn't appear to be true at all. For example:

PS $ start-job -ArgumentList "one","two" -ScriptBlock { write-host $args }
PS $ receive-job 2
one two

PS $ start-job -ArgumentList "one","two" -FilePath C:\temp\Test.ps1
PS $ receive-job 4
one two

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

Repro Steps:
PS $ gh start-job -parameter argumentlist

-ArgumentList <Object[]>

Specifies the arguments (parameter values) for the script that is specified by the FilePath parameter. 


Because all of the values that follow the ArgumentList parameter name are interpreted as being values of ArgumentList, the ArgumentList parameter should be the last parameter in the command.

Required?                    false

Position?                    named

Default value                

Accept pipeline input?       false

Accept wildcard characters?  false

Expected Results:

Internal BugId: 2556

Votes from Connect: 10

Original Date Submitted: 5/22/2010 3:29:42 AM

Description:
Contact Information
Handle: x0n
Site Name: PowerShell
Feedback ID: 560761

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

Problem Description:
Calling test-path " " returns $true. I would expect $false unless a file named " " really did exist.

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

Repro Steps:
given there is no file or folder named " " in the root of C:\

ps c:&gt; test-path " "
True

Expected Results:
ps> test-path " "
False

Internal BugId: 2549

Votes from Connect: 12

Original Date Submitted: 4/30/2010 9:13:05 PM

Description:
Contact Information
Handle: Roman Kuzmin
Site Name: PowerShell
Feedback ID: 556004

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

Problem Description:
The more detailed question and investigation is in here:
http://stackoverflow.com/questions/2744047/mysterious-different-conversion-to-string-of-seemingly-same-input-data

Items returned by (Get-ChildItem <path>) and (Get-ChildItem <path> -Include *) are converted to strings differently. Different results of the two commands below, IMHO, do not make any practical sense and only lead to confusion and bugs:

This command gets just file names

string[]

This command gets full file paths

string[]

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

Repro Steps:
(see the description)
Output:
File1.txt
File2.txt
C:\TEMP\Test\File1.txt
C:\TEMP\Test\File2.txt

Expected Results:
Output:
C:\TEMP\Test\File1.txt
C:\TEMP\Test\File2.txt
C:\TEMP\Test\File1.txt
C:\TEMP\Test\File2.txt

Internal BugId: 2530

Votes from Connect: 15

Original Date Submitted: 3/31/2010 2:02:45 PM

Description:
Contact Information
Handle: Martin Zugec
Site Name: PowerShell
Feedback ID: 546066

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

Problem Description:
Please re-consider default behavior of Import-Module. Current issue is that if you want to use namespaces (module\verb-noun), you still need to pay attention to name of your functions, because last one always wins.

This forces us to use SCCM\Get-SccmObject always simply because of the fact that we never know which function we will overwrite. SCCM\Get-Object would overwrite Get-Object in this case. This makes modules less useful.

Default behavior should be that current functions are not overwriten - if there is conflict, new functions should be available by Namespace only.

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

Repro Steps:
1.) Create module SCCM.psm1
2.) Create function Get-Object and export it from module
3.) You can access this function using SCCM\Get-Object (perfect), however it will overwrite built-in Get-Object

Expected Results:
I would expect that new functions won't overwrite existing ones. From design perspective, modules can be easily used as dynamic libraries of functions - but if they are not loaded all at once, it can be extremely dangerous, because you never know what you will overwrite.

Internal BugId: 2493

Votes from Connect: 17

Original Date Submitted: 12/9/2009 12:06:32 AM

Description:
Contact Information
Handle: Xaegr
Site Name: PowerShell
Feedback ID: 518895

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

Problem Description:
When you need to send a array of objects to switch statement, you cannot just pipe it:
PS > Get-EventLog security -newest 100 | Switch ($.EventId) {672 {$Id672++} 680 {$Id680++} }
or
Get-EventLog security -newest 100 | Select -expandProperty eventid | Switch {672 {$Id672++} 680 {$Id_680++}}

You need to specify full expression as "argument" for a switch, like this:
Switch (Get-EventLog security -newest 100 | select -expandproperty eventid) {672 {$Id672++} 680 {$Id680++} }

It works, but the first variant is much more powershell like. People are expecting this to work. It also will make using switch in ad-hoc pipelines much easier.

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

Repro Steps:
Get-EventLog security -newest 100 | Switch ($.EventId) {672 {$Id672++} 680 {$Id_680++} }

Expected Results:

Internal BugId: 2294

Votes from Connect: 12

Original Date Submitted: 10/31/2009 4:57:26 AM

Description:
Contact Information
Handle: x0n
Site Name: PowerShell
Feedback ID: 506808

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

Problem Description:
I see that trying to import a module where the module does not exist yields a non-terminating error. I think that really should be a full-blown terminating error; a failure to load a dependency like that really should stop the script. Having to use get-module -list available, or bump $erroractionpreference up to "stop" just to let try/catch work seems like a bit of a hack.

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

Repro Steps:
ps> try { import-module foo } catch { "caught" }
The specified module 'foo' was not loaded because no valid module file was found in any module directory.

+ CategoryInfo          : ResourceUnavailable: (foo:String) [Import-Module], FileNotFoundException

+ FullyQualifiedErrorId : Modules_ModuleNotFound,Microsoft.PowerShell.Commands.ImportModuleCommand

Expected Results:
ps> try { import-module nonexistant } catch { "caught" }
caught

Internal BugId: 2242

Votes from Connect: 14

Original Date Submitted: 7/23/2008 3:57:45 AM

Description:

Contact Information
Handle: Dmitry Sotnikov
Site Name: PowerShell
Feedback ID: 357352

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

Problem Description:
Some cmdlets accept scriptblocks for some parameters, while others don't. This is very inconsistent and confusing.

On the one hand you can use this syntax for these examples: http://blogs.msdn.com/powershell/archive/2008/04/21/mindwarpingpower-cmdlets-scriptblock-parameters.aspx

On the other, something like this would fail for no apparent reason:
Get-DistributionGroup | Set-DistributionGroup -DisplayName {$_.name}

This is actually (IMHO) a design flaw of PowerShell (unfortunately still present in v2 ) – you (if you are develkopping cmdlets) cannot just have scriptblock support for your parameters. To have your parameters accept scriptblocks you either need to declare their type as ScriptBlock (not an option for your example of setting TsProfilePath which is a string) or make it accept value from pipeline (and face the side effects).

A very bad decision someone made at some point, and – as your email demonstrates – leading to a confusing and inconsistent behavior of some cmdlets accepting scriptblocks for some parameters, while others do not.

This should be changed so that there is consistent experience across all cmdlets from all Microsoft teams and 3rd-parties.

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

Repro Steps:
Expected Results:

Internal BugId: 1696