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.

1. „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: 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: 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

Votes from Connect: 4

Original Date Submitted: 7/18/2014 5:22:57 AM

Description:
Contact Information
Handle: R Jason Morgan
Site Name: PowerShell
Feedback ID: 922914

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

Problem Description:
When you install the WMF 5 May preview on Windows 8.1 enterprise with update x64, KB2894868-x64, the nuget.exe file that gets placed at %winddir%\System32\config\systemprofile\AppData\Local\Microsoft\Windows\PowerShell\PowerShellGet\nuget.exe doesn't work. This issue is noticeable when you try and run the find and install *-Module cmdlets as SYSTEM. Specifically you notice it when trying to use them in DSC, like with cPSGet.

I've added a link to the PowerShell.org repository where you can find the resource. Additionally, you can just try executing that particular nuget.exe file. It looks like it's just a bad file.

https://github.com/PowerShellOrg/DSC

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

Repro Steps:
Try running the cPSGet resource, or using PowerShellGet when running as SYSTEM, or just try running the nuget.exe file @ %winddir%\System32\config\systemprofile\AppData\Local\Microsoft\Windows\PowerShell\PowerShellGet\nuget.exe

Expected Results:

Internal BugId: 8903

Votes from Connect: 4

Original Date Submitted: 7/16/2014 11:54:14 PM

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

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

Problem Description:
When I invoke:

PS> Get-Help .\foo.ps1

I get something like:

NAME

c:\users\sto\somedir\somesubdir\more\foo.ps1

SYNOPSIS

Some useful script

SYNTAX

c:\users\sto\somedir\somesubdir\more\foo.ps1 -logdir <String> -outputdir <String> [-debugmode]

[<CommonParameters>]


c:\users\sto\somedir\somesubdir\more\foo.ps1 -zipfile <String> -outputdir <String>  [-debugmode]

[<CommonParameters>]

There should be a means to remove the (most often useless) "c:\users\sto\somedir\somesubdir\more&quot; paths, for instance when using the help text in documentation, or sharing it over email, the reader most likely won't have the script stored at the same location!

This is discussed at length at http://social.technet.microsoft.com/Forums/scriptcenter/en-US/5a14e963-90ea-4ca1-9ab7-42c28515b427/how-can-i-avoid-path-when-referencing-script-name-in-help?forum=winserverpowershell

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

Repro Steps:
Invoke Get-Help with a scriptname as the argument.

Expected Results:
Only the scriptname (or the exact string passed to Get-Help) should be included in the resulting help text.

Internal BugId: 8900

Votes from Connect: 3

Original Date Submitted: 6/24/2014 2:27:32 AM

Description:
Contact Information
Handle: 8246jd
Site Name: PowerShell
Feedback ID: 903885

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

Problem Description:
The help file contains the following example:

PS C:&gt; Get-ADComputer -Identity "Fabrikam-SRV1" -Properties *

When done in my environment with a Identity name in my AD I receive the following error:

Get-ADComputer : One or more properties are invalid.
Parameter name: msDS-AssignedAuthNPolicy
At line:1 char:1
+ Get-ADComputer -Identity "Fabrikam-SRV1" -Properties *
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : InvalidArgument: (Fabrikam-SRV1:ADComputer) [Get-ADComputer], ArgumentException

+ FullyQualifiedErrorId : ActiveDirectoryCmdlet:System.ArgumentExcept

ion,Microsoft.ActiveDirectory.Management.Commands.GetADComputer

After looking further into it -Properties only accepts strings and does not accept wildcards. This example is misleading as it makes it appear that one may use the wildcard to gather all of the properties that are not default to this cmdlet. Please either add the ability to use wildcards with -Properties or update Example 1.

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

Repro Steps:
Open Shell and run Get-ADComputer -Identity "Fabrikam-SRV1" -Properties *

Expected Results:
Get-ADComputer : One or more properties are invalid.
Parameter name: msDS-AssignedAuthNPolicy
At line:1 char:1
+ Get-ADComputer -Identity "Fabrikam-SRV1" -Properties *
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : InvalidArgument: (Fabrikam-SRV1:ADComputer) [Get-ADComputer], ArgumentException

+ FullyQualifiedErrorId : ActiveDirectoryCmdlet:System.ArgumentExcept

ion,Microsoft.ActiveDirectory.Management.Commands.GetADComputer

Internal BugId: 8851

Votes from Connect: 3

Original Date Submitted: 6/23/2014 5:09:33 PM

Description:
Contact Information
Handle: Ivan Akcheurov
Site Name: PowerShell
Feedback ID: 903486

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

Problem Description:
"Fancy string - Hor""ray"

outputs correctly (only one double quote): Fancy string - Hor"ray

'Hor"ray'.Replace('"', '""')

outputs correctly (two double quotes): Hor""ray

"Fancy string - $('Hor"ray'.Replace('"', '"'+'"'))"

outputs correctly (two double quotes): Hor""ray

"Fancy string - $('Hor"ray'.Replace('"', '""'))"

outputs INCORRECTLY (only one double quote): Fancy string - Hor"ray

In my opinion, developers would intuitively expect, that within "$(inline expressions)" Powershell would treat text as statements and won't interfere with the last argument of Replace('"', '""') converting it into '"' (unless the statement interpreter decides to do so).

Also in PHP $code = '&quot;'; echo "(&quot;) vs ($code)"; gives (") vs (&quot;) which means that there is only one evaluation of $code. Otherwise it would output (") vs (")

http://stackoverflow.com/questions/24242338/powershell-doubled-double-quotes-in-inline-expressions/24346886#24346886
(there is one answer that also suggests that this is a bug)

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

Repro Steps:
1. Open Powershell
2. Type the following command:
PS> "$('""')"
3. Press Enter

Expected Results:
Output should be:
""
Actual result is (please see description for justification):
"

Internal BugId: 8848

Votes from Connect: 11

Original Date Submitted: 6/5/2014 4:37:24 AM

Description:
Contact Information
Handle: keseph
Site Name: PowerShell
Feedback ID: 888873

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

Problem Description:

Using the latest versions of the Azure PowerShell module from the Web Platform Installer on an otherwise-clean image of Windows Server 2012 R2 Datacenter from the Azure Gallery, you cannot import the Storage module after importing the Azure module. You receive a long string of errors starting with:

PS C:&gt; Import-Module Storage
Import-Module : Cannot process Cmdlet Definition XML for the following file:

C:\Windows\system32\WindowsPowerShell\v1.0\Modules\Storage\Disk.cdxml. At line:339 char:13

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

Repro Steps:
Import-Module Azure, Storage

Expected Results:
No errors.
Importing the Storage module before the Azure module causes both to succeed and the cmdlets for both work fine.

Internal BugId: 8810

Votes from Connect: 13

Original Date Submitted: 5/14/2014 10:32:59 PM

Description:
Contact Information
Handle: Мухаметшин Наиль
Site Name: PowerShell
Feedback ID: 873348

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

Problem Description:
Good day everyone!

Very strange issue: when i try to load together Virtual Machine Manager 2012 and Data Protection Manager 2012 modules - script fails:

PS C:\Windows\system32> ipmo virtualmachinemanager
PS C:\Windows\system32> ipmo DataProtectionManager
Import-Module : Could not load type 'Microsoft.Internal.EnterpriseStorage.Dls.Utils.AlertTypes.AlertEnum' from assembly
'Utils, Version=1.0.523.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
At C:\Program Files\Microsoft System Center 2012 R2\DPM\DPM\bin\Modules\DataProtectionManager\DataProtectionManager.psm
1:2 char:1
+ Import-Module (Join-Path $cmdletDllPath ObjectModelCmdlet.dll)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : NotSpecified: (:) [Import-Module], TypeLoadException

+ FullyQualifiedErrorId : System.TypeLoadException,Microsoft.PowerShell.Commands.ImportModuleCommand

in other order:

PS C:\Windows\system32> ipmo DataProtectionManager
PS C:\Windows\system32> ipmo virtualmachinemanager
ipmo : Could not load type 'Microsoft.VirtualManager.Utils.IRunOnBehalfOf' from assembly 'Utils, Version=1.0.523.0, Cul
ture=neutral, PublicKeyToken=31bf3856ad364e35'.
At line:1 char:1
+ ipmo virtualmachinemanager
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : NotSpecified: (:) [Import-Module], TypeLoadException

+ FullyQualifiedErrorId : System.TypeLoadException,Microsoft.PowerShell.Commands.ImportModuleCommand

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

Repro Steps:
Installed Windows Server R2 Std U1
Installed SCDPM R2 Server + Console
Installed SCVMM R2 Console

Opening powershell prompt
PS C:\Windows\system32> ipmo virtualmachinemanager
PS C:\Windows\system32> ipmo DataProtectionManager
or
PS C:\Windows\system32> ipmo DataProtectionManager
PS C:\Windows\system32> ipmo virtualmachinemanager

Expected Results:
Modules loaded normally without error and their cmdlets active.

Internal BugId: 7765

Votes from Connect: 12

Original Date Submitted: 3/12/2014 7:14:43 PM

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

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

Problem Description:
Hi all,

I think that it is a constant annoyance having to update-help on new servers or workstations. In my opinion, there is really no reason that Update-help should require me to relaunch Help as an admin user, as that requires launching a separate instance of the console.

THanks,

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

Repro Steps:
PowerShell v4 no longer bundles help files along with the program binaries. This results in needing to run Update-Help in order to pull down the content.

Expected Results:
Would be nice to not have to run this command as administrator, in order to comply with 'Running with Least Privilege', as most users will then keep the console open with elevated permissions.

Internal BugId: 7673

Votes from Connect: 28

Original Date Submitted: 1/4/2014 6:13:19 AM

Description:
Contact Information
Handle: PowerShellDon
Site Name: PowerShell
Feedback ID: 812950

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

Problem Description:
Install-WindowsFeature is missing important instructions and caveats with regard to the -Source parameter.

First, it does not provide examples of the correct path syntax when pointing to a WIM image (e.g., "wim:/c:/sources/install.wim:3", including an explanation of the numeric index). The help does suggest pointing to a WIM image, but without the right path syntax, it's hard to get it to actually work. The numeric index is especially important. For example, if you use 4 (full GUI Datacenter Edition) on a Server Core box, you'll end up with GUI components installed even if you didn't ask for them.

Second, it also does not describe that -Source will not work on servers that have been configured to use a WSUS server for updates. See post at http://powershell.org/wp/2014/01/01/using-install-windowsfeature-with-offline-source/ including comments.

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

Repro Steps:
Expected Results:

Internal BugId: 7585