Votes from Connect: 8

Original Date Submitted: 3/3/2015 5:52:55 AM

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

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

Problem Description:
Currently, there is no way to detect whether a command parameter has a default value or what the default value is. It's important to help authoring and to command parsing.

I can use the AST to get the default value, but that works only for functions and scripts; not for cmdlets.

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

Repro Steps:
(gcm <command>).ParameterSets.Parameters | gm

Expected Results:
TypeName: System.Management.Automation.CommandParameterInfo

Name MemberType Definition
---- ---------- ----------
Equals Method bool Equals(System.Object obj)
GetHashCode Method int GetHashCode()
GetType Method type GetType()
ToString Method string ToString()
Aliases Property System.Collections.ObjectModel.ReadOnlyCollection[string] Aliases {get;}
Attributes Property System.Collections.ObjectModel.ReadOnlyCollection[System.Attribute] Attributes {get;}
DefaultValue Property string DefaultValue {get;}
HelpMessage Property string HelpMessage {get;}
IsDynamic Property bool IsDynamic {get;}
IsMandatory Property bool IsMandatory {get;}
Name Property string Name {get;}
ParameterType Property type ParameterType {get;}
Position Property int Position {get;}
ValueFromPipeline Property bool ValueFromPipeline {get;}
ValueFromPipelineByPropertyName Property bool ValueFromPipelineByPropertyName {get;}
ValueFromRemainingArguments Property bool ValueFromRemainingArguments {get;}

Internal BugId: 14277

Votes from Connect: 5

Original Date Submitted: 3/2/2015 8:58:03 PM

Description:
********Contact Information********
Handle: Trond Hindenes
Site Name: PowerShell
Feedback ID: 1156994
***************************************

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

Problem Description:
If a workflow uses deep nesting (at least 3 levels of nesting), erroraction does not work. This is reproducable in both the V4 and V5 feb preview of the WMF.

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

Repro Steps:
Consider the following 3 workflows
workflow one
{
Write-Output "one"
}

workflow two
{
one

}

workflow three
{
two -ErrorAction Stop
}

this code does not compile. If removing the "ErrorAction" parameter in workflow three, it works.

Expected Results:
workflow should compile.

Internal BugId: 14275

Votes from Connect: 3

Original Date Submitted: 2/19/2015 11:08:09 PM

Description:

********Contact Information********
Handle: Rohn Edwards
Site Name: PowerShell
Feedback ID: 1138469
***************************************

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

Problem Description:
In the December 2014 and February 2015 WMF 5.0 previews, flags enumerations that have byte, sbyte, short, or ushort underlying types have to be cast or coerced to a numeric type before -band, -bor, or -bxor bitwise operations will work.

int, uint, long, and ulong underlying types still work as expected.

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

Repro Steps:
First, ensure $PSVersionTable.PSVersion is 5.0.10018.0

To see the error, run this command:
PS> [System.Windows.Input.KeyStates]::Down -band [System.Windows.Input.KeyStates]::Down

KeyStates has an underlying type of 'Byte'. The command works if you modify it like this:
PS> [System.Windows.Input.KeyStates]::Down.value__ -band [System.Windows.Input.KeyStates]::Down

Expected Results:
No errors are expected, like running this command:
[System.Windows.Forms.ButtonState]::Pushed -band [System.Windows.Forms.ButtonState]::Pushed

It appears that version 5 returns an instance of the enumeration instead of a numeric value (which it looks like previous versions return).

Internal BugId: 13250

Votes from Connect: 5

Original Date Submitted: 2/6/2015 3:54:49 PM

Description:
********Contact Information********
Handle: edi89
Site Name: PowerShell
Feedback ID: 1117495
***************************************

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

Problem Description:
Using paramter validation in functions works just find - something like this:
function test{
Param (
[ValidateRange(3,8)]
[Int] $mytest )

write-host $mytest
}
test 4
test 9
The problem is, that it seems, that parameter validation is in fact just a special case of variable validation which leads to the circumstance, that the variable used (in this case $mytest) is beeing validated every time you use it. Try this:
function test{
Param (
[ValidateRange(3,8)]
[Int] $mytest)

$mytest = $mytest+5
write-host $mytest
}

test 4

It seems to be by design, but the documentation about parameter validation is misleading if not completly wrong, because it says something like:"parameters are validated when you call the function/cmdlet", which simply is not the way it works - the variable is validated everytime you use it.

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

Repro Steps:
function test{
Param (
[ValidateRange(3,8)]
[Int] $mytest)

$mytest = $mytest+5
write-host $mytest
}

test 4

Expected Results:
test 4
The variable cannot be validated because the value 9 is not a valid value for the mytest variable.
At line:6 char:5
+ $mytest = $mytest+5
+ ~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : MetadataError: (:) [], ValidationMetadataException
+ FullyQualifiedErrorId : ValidateSetFailure

4

Internal BugId: 13225

Votes from Connect: 3

Original Date Submitted: 1/30/2015 5:06:50 AM

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

Frequency: Always Happens
Regression: I don

Problem Description:
Now that I've gotten used to ISE-Snippets, I love them and I have a huge selection of them to help me with calculated properties, custom objects, and things like that. I'd love to be able to use ISE-Snippets in the PowerShell console as well.

We can already hit F7 to see a list of the last 40 or so commands in our window. How about adding a similar window for ISE style snippets for our coding reference while in the console?

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

Repro Steps:
Expected Results:

Internal BugId: 13210

Votes from Connect: 3

Original Date Submitted: 1/29/2015 7:34:02 AM

Description:
********Contact Information********
Handle: aL3891
Site Name: PowerShell
Feedback ID: 1106345
***************************************

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

Problem Description:
i've investigated DSC but found it to be almost unusable on any kind of scale since it seems every variable is stored in some global scope, not even quantified with step names.

This makes it impossible to so something as simple as stopping and starting a service to update it, surely a common scenario. (Because the "Name" has to be unique)

Even worse, trying to work around this limitation using script resources since the script blocks are not allowed to be the same on a single node, meaning that parameterization is impossible (variable names are not expanded before this check)

This essentially makes DSC unusable for any kind of system that has more than one service running on it, atleast if some degree of code duplication is going to be avoided.

it is possible that this can be solved by writing completley custom resources yourself, but then what is the point of DSC?

i really hope i missed some fundamental part of DSC because right now some very basic resources doesnt seem to working for any kind of realistic scenario out of the box

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

Repro Steps:
-

Expected Results:
-

Internal BugId: 13208

Votes from Connect: 3

Original Date Submitted: 1/3/2015 6:07:28 AM

Description:
********Contact Information********
Handle: The Deeds
Site Name: PowerShell
Feedback ID: 1074131
***************************************

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

Problem Description:
Part 1:

In bash, we say:

rm -f

In Powershell, the equivalent is:

rm -Force

Please add an alias -f, so to make it compatible with unix-like shells. It helps a lot in C/C++ CMAKE and other scripting scenarios like Nodejs etc.

Part 2:

We desperately need mkdir -p (or --parents) switch of Unix in Windows. Going by the man (manual); http://www.computerhope.com/unix/umkdir.htm, it says:

"Create parent directories as necessary. When this option is used, no error is reported if a specified DIRECTORY already exists."

The emphasis on "no error is reported". This is EXTREMEMLY important in C/C++ make recipes.

Hope it will buzz into the ears at Redmond and will arrive in posh vNext.

Thanks in anticipation!

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

Repro Steps:
mkdir /temp; rm -rf /temp

-f is not a switch, instead use rm -r /temp -Force! Which is yuck!

mkdir -p /temp/and/then/some/non/existent/path

-p is unrecognized.

Expected Results:
Introduce -f switch to rm and -p to mkdir in vNext of powershell.

Internal BugId: 13174

Votes from Connect: 3

Original Date Submitted: 1/3/2015 3:54:37 AM

Description:
********Contact Information********
Handle: rpseekell
Site Name: PowerShell
Feedback ID: 1074018
***************************************

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

Problem Description:
I use this script to connect to Office 365 via PowerShell, which I think is pretty standard:
$cred = Get-Credential
$sess = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $cred -Authentication basic -AllowRedirection
Import-PSSession -Session $sess

However, since updating to the November preview of PowerShell (WMF) 5, the new-PSSession command hangs and never finishes. I get a message like,
WARNING: Your connection has been redirected to the following URI: "https://podXXXXXXXX.outlook.com/powershell-liveid?PSVersion=5.0.9883.0 "
and minutes later, nothing else has happened.
Uninstalling the November update and going back to the May update or PS/WMF4 will cause it to work again.

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

Repro Steps:
$cred = Get-Credential
$sess = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $cred -Authentication basic -AllowRedirection
Import-PSSession -Session $sess

Expected Results:
Commands above finish and return a PSModuleInfo object like this:
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Script 1.0 tmp_na0ljv0x.dmw {Add-DistributionGroupMember, Add-MailboxFolderPermi

And then I can run commands against Office 365.

Internal BugId: 13171

Votes from Connect: 3

Original Date Submitted: 1/2/2015 7:28:29 AM

Description:
********Contact Information********
Handle: Roland Illig 2
Site Name: PowerShell
Feedback ID: 1073011
***************************************

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

Problem Description:
The German version of the installer for Microsoft Security Essentials has two wrong translations:

1. „Falls keine Firewall aktiviert ist, aktivieren Sie die Windows-Firewall (empfohlen).“

This text should not even be in the installer in this form. Either the firewall is already activated, then the checkbox is useless and must not be shown at all. Or the firewall is not already activated, then the ”If no firewall is activated“ is redundant and should therefore be removed. Don’t confuse the user with unnecessary decisions.

2. „Aktivieren Sie die automatische Beispielübermittlung.”

This must be in a passive voice. “Automatische Beispielübermittlung aktivieren.”
Additionally, the word ”Beispiel” is not understandable for an average user. There is a long explanatory text above, but that doesn’t even mention the word “Beispiel“.

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

Repro Steps:
Expected Results:

Internal BugId: 13169

Votes from Connect: 3

Original Date Submitted: 12/11/2014 7:11:16 AM

Description:
********Contact Information********
Handle: Clint Stotesbery
Site Name: PowerShell
Feedback ID: 1051712
***************************************

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

Problem Description:
I've run into a rare case. I can't use New-Object on a class whose GetEnumerator method throws NotSupportedException. System.Security.Cryptography.Xml.SignedInfo's GetEnumerator method throws a NotSupportedException: http://msdn.microsoft.com/en-us/library/system.security.cryptography.xml.signedinfo.getenumerator(v=vs.110).aspx

The stack trace shows TypicalEnumerable as this method catches Exception and then rethrows it as an ExtendedTypeSystemException. I followed the complete stacktrace (hint: there are delegates involved not in the stack trace) and I can't figure out a way to prevent this case from happening.

One workaround is to sub class SignedInfo and implement GetEnumerator so it doesn't throw an exception. Then use Add-Type and use the sub class. This works with New-Object so it doesn't throw an exception. The problem is that when I try to return my sub class from inside a function, the return keyword and Write-Output end up "losing" the object which results in it returning null to the calling function.

This may be a bug in SignedInfo (why implement IEnumerable and then have GetEnumerator throw a NotSupportedException??!!!) but New-Object shouldn't be calling GetEnumerator... it should only be calling the type's constructor.

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

Repro Steps:
PS C:\>Add-Type -AssemblyName System.Security
PS C:\> New-Object System.Security.Cryptography.Xml.SignedInfo
New-Object : The following exception occurred while trying to enumerate the collection: "Specified method is not
supported.".
At line:1 char:1
+ New-Object System.Security.Cryptography.Xml.SignedInfo
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [New-Object], ExtendedTypeSystemException
+ FullyQualifiedErrorId : ExceptionInGetEnumerator,Microsoft.PowerShell.Commands.NewObjectCommand

PS C:\> try { New-Object System.Security.Cryptography.Xml.SignedInfo } catch [Exception] { Write-Host $_.Exception | Format-List -Force }
System.Management.Automation.ExtendedTypeSystemException: The following exception occurred while trying to enumerate the
collection: "Specified method is not supported.". ---> System.NotSupportedException: Specified method is not supported.

at System.Security.Cryptography.Xml.SignedInfo.GetEnumerator()
at System.Management.Automation.LanguagePrimitives.TypicalEnumerable(Object obj)

Expected Results:
I should be able to run New-Object on a type without its GetEnumerator method being invoked. That seems like strange behavior.

Internal BugId: 13142

Votes from Connect: 3

Original Date Submitted: 12/4/2014 3:29:25 AM

Description:

********Contact Information********
Handle: Josef Nemec
Site Name: PowerShell
Feedback ID: 1045858
***************************************

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

Problem Description:
When calling Add-Member over an object all ScriptProperty members are being invoked (script blocks from those properties are invoked). I found it during testing on PowerShell 5 preview (from Windows 10 preview build), but it also occurs in PS 4 (tested on Windows 8.1). It seems like it occurs only with System.Management.Automation.dll 6.3.9600.17400 and newer since it works for me on 8.1 machines with version 6.3.9600.17090.

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

Repro Steps:
Execute following commands:

$global:BaseObject = New-Object PSObject
$global:BaseObject | Add-Member ScriptProperty "Test" { Write-Host "testing message" }
$global:BaseObject | Add-Member NoteProperty "Test2" 2

"testing message" will be displayed after second Add-Member call, which indicates that property code was executed even when not called directly.

Expected Results:
ScriptProperty members shoudn't be executed during Add-Member call, but only when explicitly called, i.e. by running $BaseObject.Test in provided example.

Internal BugId: 13130

Votes from Connect: 3

Original Date Submitted: 11/7/2014 10:07:44 PM

Description:

********Contact Information********
Handle: sba
Site Name: PowerShell
Feedback ID: 1023770
***************************************

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

Problem Description:
I have a script that contains the following code:

--------------8<----------------
function Get-ScriptDirectory{

$Invocation = (Get-Variable MyInvocation -Scope 1).Value
try {
Split-Path $Invocation.MyCommand.Path -ea 0
}
catch {
Write-Warning 'You need to call this function from within a saved script.'
}
}

$scriptdir = Get-ScriptDirectory

Set-Location $scriptdir -ErrorAction Stop
--------------8<----------------

(this originates from PS2.0 days)

The script runs fine, except if it's run from MSBuild using:

<Target Name="AfterClean">
<Message Text="Cleaning old generated files" Importance="normal" />
<Exec Command="powershell -noprofile -executionpolicy unrestricted -file $(ProjectDir)RemoveOldGeneratedFiles.ps1 ... />
</Target>

When run this way, I get:

Cleaning old generated files
powershell -noprofile -executionpolicy unrestricted -file ...\RemoveOldGeneratedFiles.ps1 ...
The property 'Value' cannot be found on this object. Verify that the property exists.At ....\RemoveOldGeneratedFiles.ps1:34 char:2
+ $Invocation = (Get-Variable MyInvocation -Scope 1).Value
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], PropertyNotFoundException
+ FullyQualifiedErrorId : PropertyNotFoundStrict

EXEC : warning : You need to call this function from within a saved script. [...foo.csproj]

If I add a Write-Host command to the Get-ScriptDirectory function before the "$Invocation = ..." line, the problem very mysteriously disappears.

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

Repro Steps:
Run a script with the aforementioned code via MSBuild

Expected Results:
No exception raised by Get-Variable MyInvocation -Scope 1).Value

Internal BugId: 13091

Votes from Connect: 5

Original Date Submitted: 10/29/2014 11:53:04 PM

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

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

Problem Description:
Currently there is no easy method to determine which version of PowerShell a particular cmdlet will work within.

Take the example of New-PSDrive. This command was introduced in PowerShell version 2.0, but the current Version property displayed when I run 'Get-Command New-PSDrive | Format-List' displays the value of 3.1.

While this cmdlet was included in 3.0 and 4.0, it is misleading that the version of 3.1 is displayed, when the cmdlet will function perfectly within PowerShell version 2.0.

In a lively discussion on the matter today on Twitter with a number of PowerShell MVPs, we were unable to find a conclusive command or one-liner to run to obtain the base version of a cmdlet, or the version in which it was introduced.

While adding this data to all existing cmdlets would be quite a workload, I think this is valuable information which helps provide teachable moments and added information to the PowerShell Command Line Interface experience.

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

Repro Steps:
Get-Command New-PSDrive | Select Version

>Version
----------
3.1.0.0

Expected Results:
Get-Command New-PSDrive | Select Version,IntroducedIn

>Version IntroducedIn
---------------------------
3.1.0.0 2.0

Internal BugId: 13074

Votes from Connect: 3

Original Date Submitted: 10/24/2014 11:54:58 PM

Description:
********Contact Information********
Handle: FZB
Site Name: PowerShell
Feedback ID: 1010203
***************************************

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

Problem Description:
I am not sure if it's a Powershell issue or better suited for Windows Server, though without access to Windows Server connect, I'll try my luck here...
Windows supports vhd/vhdx files, without the need of a hyper-v role. This in my point of view is a nice feature, which let's you for example create containers to nicely separate customer data per project, so if a project is done, you can delete a single container file (vhd/x) and are cleanly done with it (the containers are mounted for example in drive:\projects, so you have a clean structure in your file system).
As vhd and vhdx are basic windows features, I don't see why to convert them with powershell (Convert-VHD - http://technet.microsoft.com/en-us/library/hh848454.aspx ), you have to have the hyper-v role installed (which is not possible in a vm). Installing the management powershell modules for hyper-v doesn't make the cmdlet available, so it might be a windows issue and not so much a powershell problem, but I certainly would like to see those commands available without the hyper-v role installed, as vhd/vhdx aren't bound to hyper-v.

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

Repro Steps:
open powerhsell
run Convert-VHD C:\temp\yourvhd.vhd c:\temp\yourvhdx.vhdx
--> cmdlet not known
install Remote management Hpyer-v powershell module
run Convert-VHD C:\temp\yourvhd.vhd c:\temp\yourvhdx.vhdx
--> error that cmdlet needs hyper-v role

Expected Results:
as vhd and vhdx are windows features, not hyper-v specific features, I would have hoped to be able to actually convert them

Internal BugId: 11064

Votes from Connect: 4

Original Date Submitted: 10/6/2014 9:54:44 PM

Description:
********Contact Information********
Handle: Trevor Sullivan [MVP]
Site Name: PowerShell
Feedback ID: 993661
***************************************

Frequency: Always Happens
Regression: I don

Problem Description:
When writing a simple example to debug a PowerShell Background Job, the Background Job does not have enough time to initialize, before the Debug-Job command is invoked. Examine the following example:

$ScriptBlock = {
$Foo = 1;
Wait-Debugger;
$Foo++;
};

$Job = Start-Job -ScriptBlock $ScriptBlock;
Debug-Job -Job $Job;

When I run the above code in the PowerShell ISE, I receive an error message from Debug-Job, stating:

"Debug-Job : The provided job and all child jobs were examined but no jobs were found that could be debugged. In order to debug a job or child job the job must support debugging and also be in a running state."

Solution
---------------------------
To solve for this, I would suggest adding optional parameters: -Wait and -Timeout. The purpose of these parameters would be to cause the Debug-Job command to "wait" (a specified amount of time) for the specified Background Job to be in a "Running" state, so that the debugger can be invoked. The -Timeout parameter would be the number of milliseconds that Debug-Job should wait for the Background Job to be in a valid (Running) state for debugging. I would suggest a default of 1000 milliseconds, just to provide enough time for the Background Job to initialize.

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

Repro Steps:
Expected Results:

Internal BugId: 11034

Votes from Connect: 28

Original Date Submitted: 9/29/2014 7:28:00 PM

Description:
********Contact Information********
Handle: Axel B. Andersen
Site Name: PowerShell
Feedback ID: 984532
***************************************

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

Problem Description:
When running Powershell Logon or Logoff Scrips in GPO's the -NoProfile switch is not included in the command. This results in very long logon/logoff times, if users have filled their Powershell Profile with a lot of modules. It can take up to 10 minutes, if the profile needs user input to load.

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

Repro Steps:
Create a powershell profile with just this one line:
read-host "Please type something"

Create a logon script with this content:
start-transcript c:\temp\test.txt # Make sure the folder exists before running the script.
gps
stop-transcript

Create a GPO and configure the User Logon Powershell Script above.

Link the GPO to the OU where the testuser with the profile resides.

Log on with the test user.

Expected Results:
The logon process will wait for the Powershell Script to time out. It will halt at Read-Host, which can be seen in the c:\temp\test.txt file after logon.

Internal BugId: 11025

Votes from Connect: 4

Original Date Submitted: 9/15/2014 7:04:41 AM

Description:
********Contact Information********
Handle: Derp McDerp
Site Name: PowerShell
Feedback ID: 972024
***************************************

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

Problem Description:
Specifically:

1. it should auto-complete the xml based on their doctypes
2. it should recognize the interior of <ScriptBlock>s as PowerShell scripts rather than as text blobs and format and auto-complete those correctly.
3. it should provide better outlining of the xml (e.g. if you put the caret on an end tag or start tag it should highlight the entire interior of that xml node)

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

Repro Steps:
Expected Results:

Internal BugId: 11001

Votes from Connect: 4

Original Date Submitted: 9/14/2014 4:22:48 PM

Description:
********Contact Information********
Handle: sba
Site Name: PowerShell
Feedback ID: 971502
***************************************

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

Problem Description:
When 'Get-ChildItem -Recurse -LiteralPath' is run against a directory whose name contains square brackets, no output is produced.

Take a directory with the following contents:

PS> cmd /c dir /s d:\tmp\dir[1]
Volume in drive D is DATA
Volume Serial Number is 0454-9DBF

Directory of d:\tmp\dir[1]

2014-09-14 09:23 <DIR> .
2014-09-14 09:23 <DIR> ..
2014-09-14 09:23 <DIR> subdir
0 File(s) 0 bytes

Directory of d:\tmp\dir[1]\subdir

2014-09-14 09:23 <DIR> .
2014-09-14 09:23 <DIR> ..
2014-09-14 09:23 <DIR> ssdir
0 File(s) 0 bytes

Directory of d:\tmp\dir[1]\subdir\ssdir

2014-09-14 09:23 <DIR> .
2014-09-14 09:23 <DIR> ..
2014-09-14 09:23 12 file.txt
1 File(s) 12 bytes

Total Files Listed:
1 File(s) 12 bytes
8 Dir(s) 463,074,471,936 bytes free

This doesn't produce any output:

PS> gci -Recurse -LiteralPath 'd:/tmp/dir[1]'

Whereas this works:

PS> gci -Recurse -Path 'd:/tmp/dir`[1`]'

Directory: D:\tmp\dir[1]

Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 2014-09-14 09:23 subdir

Directory: D:\tmp\dir[1]\subdir

Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 2014-09-14 09:23 ssdir

Directory: D:\tmp\dir[1]\subdir\ssdir

Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 2014-09-14 09:23 12 file.txt

This is discussed a.o. at https://connect.microsoft.com/PowerShell/feedback/CreateFeedbackForm.aspx?FeedbackFormConfigurationID=434&FeedbackType=1

P.S. There might already be a bug filed for that same issue, but it's currently not possible to *search* for existing bugs on Connect (browsing is available, but there are more than 2,400 bugs opened...)

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

Repro Steps:
gci -Recurse -LiteralPath 'd:/tmp/dir[1]'

no output is produced

Expected Results:
The contents of the directory d:/tmp/dir[1] should be returned

Internal BugId: 11000

Votes from Connect: 6

Original Date Submitted: 9/11/2014 4:15:39 AM

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

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

Problem Description:
Help documentation is more time consuming than it needs to be. My biggest pain point with help is that I like to include links to all other commands with the same noun to aid in discoverability. Sure, there is Get-Command -Noun ..., but it is useful in help documentation to include links to those commands as well. This also helps modern help tools link to those commands more easily.

As I create a module, adding additional commands, I really dislike having to circle back to the comment-based help and add the new commands to the links. Ditto when renaming a command.

I would like to see help automatically include any commands that have the same noun in the links of related items in the command help. With that in place, command authors would only have to worry about including links to online help, or links to other commands that may not be as obviously related but that you would want end users to be able to discover via help. The rest (links to commands with the same noun) would just be magic. As a plus, anyone extending a set of commands with additional verbs could have their commands automatically linked as well, without having to set up the links themselves.

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

Repro Steps:
New-Module -Name Test -ScriptBlock {
<#
.SYNOPSIS
Get something.
.DESCRIPTION
The Get-Something command gets something.
#>
function Get-Something {
[CmdletBinding()]
param()
}

<#
.SYNOPSIS
Set something.
.DESCRIPTION
The Set-Something command gets something.
#>
function Set-Something {
[CmdletBinding()]
param()
}
} | Import-Module
Get-Help Get-Something
Get-Help Set-Something

Expected Results:
You should see Set-Something in the RELATED LINKS section of Get-Something help and Get-Something in the RELATED LINKS section of Set-Something help because they share the same noun.

Internal BugId: 9994

Votes from Connect: 5

Original Date Submitted: 9/8/2014 11:00:11 PM

Description:
********Contact Information********
Handle: Oisín Grehan
Site Name: PowerShell
Feedback ID: 966940
***************************************

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

Problem Description:
As of v5, the call (&) operator cannot invoke .NET methods. With the implied deprecation of new-object in v5 by way of the "new(...)" synthetic static constructor method, this becomes a more obvious lack.

One thing new-object has that the new v5 static method "new" does not is splatting support. Syntactically, this seems to make most sense when combined with support for invoking .NET methods with the call (&) operator. Here is an example on how this might work:

PS> [string]::format
OverloadDefinitions
-------------------
static string Format(string format, System.Object arg0)
...

PS> $arguments = @{format="Hello, {0}.", arg0="world"}
PS> & ([string]::format) @arguments
Hello, world.

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

Repro Steps:
see description

Expected Results:
see description

Internal BugId: 9990