Take a look at the following configuration:
$configurationData =
@{

AllNodes =

@(

    @{

        NodeName = 'S16-01'

        PsDscAllowPlainTextPassword = $true

        PSDscAllowDomainUser = $true                        

    }

)

}

Configuration DSCRunDemo
{

param (

    [pscredential] $Credential

)

Import-DscResource -ModuleName PSDesiredStateConfiguration


Node $AllNodes.NodeName

{

    Script DSCRunDemo1

    {

        SetScript = 

        { 

            Write-Verbose -Message $(whoami)

        }            

        TestScript = 

        {    

            return $false

        }        

        GetScript =

        {

            return @{}

        }

        PsDscRunAsCredential = $Credential

    }

    Script DSCRunDemo2

    {

        SetScript = 

        { 

            Write-Verbose -Message $(whoami)

        }            

        TestScript = 

        {    

            return $false

        }        

        GetScript =

        {

            return @{}

        }

    }                 

}

}

DSCRunDemo -ConfigurationData $configurationData -Credential (Get-Credential)

One instance of the script resource has PSDscRunAsCredential while the other does not. This compiles fine and then MOF looks good.

/
@TargetNode='S16-01'
@GeneratedBy=Administrator
@GenerationDate=08/22/2017 13:36:38
@GenerationHost=S16-JB
/

instance of MSFTCredential as $MSFTCredential1ref
{
Password = "Dell1234";
UserName = "psdsc\administrator";

};

instance of MSFTScriptResource as $MSFTScriptResource1ref
{
ResourceID = "[Script]DSCRunDemo1";
PsDscRunAsCredential = $MSFT_Credential1ref;
GetScript = "\n return @{}\n ";
TestScript = " \n return $false\n ";
SourceInfo = "::22::9::Script";
SetScript = " \n Write-Verbose -Message $(whoami)\n ";
ModuleName = "PSDesiredStateConfiguration";

ModuleVersion = "0.0";

ConfigurationName = "DSCRunDemo";

};
instance of MSFTScriptResource as $MSFTScriptResource2ref
{
ResourceID = "[Script]DSCRunDemo2";
GetScript = "\n return @{}\n ";
TestScript = " \n return $false\n ";
SourceInfo = "::39::9::Script";
SetScript = " \n Write-Verbose -Message $(whoami)\n ";
ModuleName = "PSDesiredStateConfiguration";

ModuleVersion = "0.0";

ConfigurationName = "DSCRunDemo";

};
instance of OMI_ConfigurationDocument

                {

Version="2.0.0";

                    MinimumCompatibleVersion = "2.0.0";


                    CompatibleVersionAdditionalProperties= {"Omi_BaseResource:ConfigurationName"};

                    Author="Administrator";

                    GenerationDate="08/22/2017 13:36:38";

                    GenerationHost="S16-JB";

                    Name="DSCRunDemo";

                };

However, when we enact this configuration, it fails with the following message:

PS C:> Start-DscConfiguration -Path .\DSCRunDemo -Verbose -Wait -Force
VERBOSE: Perform operation 'Invoke CimMethod' with following parameters, ''methodName' = SendConfigurationApply,'className' = MSFT_DSCLocalConfigurationManager,'namespaceName' = root/Microsoft/Windows/DesiredStateConfiguration'.
VERBOSE: An LCM method call arrived from computer S16-JB with user sid S-1-5-21-689661094-3032901192-2251061677-500.
VERBOSE: [S16-01]: LCM: [ Start Set ]
VERBOSE: [S16-01]: LCM: [ End Set ]
The resources ('[Script]DSCRunDemo1' and '[Script]DSCRunDemo2') have conflicting values of the following properties: 'PsDscRunAsCredential'. Ensure that their values match.

+ CategoryInfo          : ResourceExists: (root/Microsoft/...gurationManager:String) [], CimException

+ FullyQualifiedErrorId : MI RESULT 11

+ PSComputerName        : S16-01

VERBOSE: Operation 'Invoke CimMethod' complete.
VERBOSE: Time taken for configuration job to complete is 3.761 seconds

If this is by design, it is a wrong design. Think of adding registry configuration for multiple users on the same system using the same configuration document.

Let me explain. I have a script that is collecting data, and I send it to StdOut by simply piping it into Select (but problem also happens if I add a ForEach loop and simply make [PSCustomObject] objects). Then my script loops to the next server. That output is not displaying on the screen. All is not lost though, when the script loops to the second server and displays both the first and second will now display. When the third server finishes it displays OK, as does the 4th.

So it looks like it's just the first one. Normally I would be OK with this, except that if the name of the second server is inputted wrong, my script will abort and the data from the first server disappears forever.

Has anyone else noted this behavior? I don't remember this happening before 5.1 and I have had multiple people able to reproduce this issue.

Votes from Connect: 17

Original Date Submitted: 8/13/2015 12:17:49 AM

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

Problem Description:
Suggestion one:

Add maintenance window awareness to the Local Configuration Manager. Edited via metaconfig, it specifies times when configuration changes are acceptable, when automated reboots are acceptable. Further automates configuration maintenance especially when you're implementing changes vs. correcting drift.

Suggestion two:

Add universal "DoNotImplementBefore" and "ImplementBy" settings to DSC resources. Just as "Present=" specifies to add/remove something, these would indicate a date/time for the setting to become valid (e.g., "we want to implement a bunch of changes, but not before x date") and a deadline by which the setting just be implemented (e.g., "this has to happen by x date"). The latter might play into the LCM configuration: For example, when set to ApplyAndAutoCorrect, even if AutoReboot=$false, an auto reboot may occur once a setting passes its "ImplementBy" date/time without previously being implemented.

These suggestions reflect some of the realities of managing a production environment.

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

Repro Steps:

Internal BugId: 15730

PS C:\Windows\system32> Get-PSRepository

Name InstallationPolicy SourceLocation

PSGallery Untrusted https://www.powershellgallery.com/api/v2/

TestRepo Trusted \NugetServer\BMNNuGet\packages

PS C:\Windows\system32> Find-Module * -Repository TestRepo

Version Name Repository Description

1.0.1 cConfigNode TestRepo Provides a way to manipulate nodes of the xml configu...
1.3.0 cNtfsAccessControl TestRepo The cNtfsAccessControl module contains DSC resources ...
3.2.0 xNetworking TestRepo Module with DSC Resources for Networking area

1.0.0 xReleaseManagement TestRepo Host a custom DSC Resource to transform files based o...
1.17.0 xWebAdministration TestRepo Module with DSC Resources for Web Administration

PS C:\Windows\system32> Find-Module xNetworking -Repository TestRepo
PackageManagement\Find-Package : No match was found for the specified search criteria and module name 'xNetworking'. Try
Get-PSRepository to see all available registered module repositories.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1360 char:3
+ PackageManagement\Find-Package @PSBoundParameters | Microsoft ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : ObjectNotFound: (Microsoft.Power...ets.FindPackage:FindPackage) [Find-Package], Exception

+ FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.FindPackage

PS C:\Windows\system32> Install-Module xNetworking -Repository TestRepo
PackageManagement\Install-Package : No match was found for the specified search criteria and module name 'xNetworking'. Try
Get-PSRepository to see all available registered module repositories.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1772 char:21
+ ... $null = PackageManagement\Install-Package @PSBoundParameters
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : ObjectNotFound: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Package], Excepti 

on

+ FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackage

PS C:\Windows\system32> $Credential

PS C:\Windows\system32> Find-Module xNetworking -Repository TestRepo -Credential (Get-Credential)
cmdlet Get-Credential at command pipeline position 1
Supply values for the following parameters:
PackageManagement\Find-Package : No match was found for the specified search criteria and module name 'xNetworking'. Try
Get-PSRepository to see all available registered module repositories.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1360 char:3
+ PackageManagement\Find-Package @PSBoundParameters | Microsoft ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : ObjectNotFound: (Microsoft.Power...ets.FindPackage:FindPackage) [Find-Package], Exception

+ FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.FindPackage

PS C:\Windows\system32> Find-Module * -Repository TestRepo | Install-Module
PackageManagement\Install-Package : No match was found for the specified search criteria and module name 'xNetworking'. Try
Get-PSRepository to see all available registered module repositories.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1875 char:34
+ ... $null = PackageManagement\Install-Package @PSBoundParameters
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : ObjectNotFound: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Package], Excepti 

on

+ FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackage

PackageManagement\Install-Package : No match was found for the specified search criteria and module name
'xReleaseManagement'. Try Get-PSRepository to see all available registered module repositories.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1875 char:34
+ ... $null = PackageManagement\Install-Package @PSBoundParameters
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : ObjectNotFound: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Package], Excepti 

on

+ FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackage

Votes from Connect: 5

Original Date Submitted: 2/20/2015 2:01:32 PM

Description:

Contact Information
Handle: john.s2011n
Site Name: PowerShell
Feedback ID: 1139497

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

Problem Description:
in PS 4.0 and also previous versions, there is no option to easily convert multiple selected lines to comment block. so when we have selected multiple lines & we want to make them as comment, we have to insert comment block in another location on the pane, and then cut these multiple lines and paste them inside comment block which is a bit cumbersome.
but in other products like VBA2013, this option exist & there is a button on edit toolbar which converts multiple lines into comment, in place.

hope this be added in PS 5.0
thanks

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

Repro Steps:
Expected Results:

Internal BugId: 13253

NuGet feeds allow security around both listing/retrieving packages as well as pushing packages. NuGet.exe and other clients further allow you to persist credentials for listing/retrieving packages using the "nuget sources" command. (https://docs.nuget.org/consume/command-line-reference#sources-command)

This persistence is important for two reasons:

1) When you push a package to a secured NuGet feed, NuGet clients generally do a list/read operation first. That list/read operation doesn't contain any API key that you pass along in the push operation. In order for a push to succeed with an API key, you also need to have credentials set for the read operation. You can read about some folks who have been affected by that here: http://inedo.com/support/questions/2319

2) In an unattended/build server scenario, you need the ability to provide credentials for list/read and push in a non-interactive way. If the only way to provide credentials is interactive (e.g., Get-Credential) then there's no way to, say, enable a build server agent to automatically install required scripts to execute a build.

This may somewhat overlap with this other note about Register-PSRepository failing against authenticated endpoints: http://windowsserver.uservoice.com/forums/301869-powershell/suggestions/11678499-register-psrepository-fails-against-authenticated

Steps to reproduce:

1. Install WMF5 RTM on a fresh Windows 2012 R2 system


2. Open an Administrator PS prompt and run "Install-Module Pester -Force"

Expected result: The -Force parameter causes the NuGet client to be installed without user intervention.

Actual result: The following message is displayed:

NuGet-anycpu.exe is required to continue.
PowerShellGet requires NuGet-anycpu.exe to interact with NuGet based galleries. NuGet-anycpu.exe must be available in
'C:\Program Files\PackageManagement\ProviderAssemblies' or
'C:\Users\Administrator\AppData\Local\PackageManagement\ProviderAssemblies'. For more information about NuGet provider,
see http://OneGet.org/NuGet.html. Do you want PowerShellGet to download NuGet-anycpu.exe now?
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"):

The MSDN documentation for $PSCmdlet.ShouldContinue (https://msdn.microsoft.com/en-us/library/ms568259%28v=vs.85%29.aspx) states "Cmdlets calling ShouldContinue should also implement a Force parameter that allows the cmdlet to bypass these calls. If this is not done, it will be difficult to use the cmdlet from scripts and noninteractive hosts." I'm trying to use Install-Module from an automated setup script on a fresh machine, and this prompt causes the script to hang.

Workaround: Before using Install-Module for the first time, run the following command to fetch NuGet-anycpu.exe (this is what Install-Module is doing internally):

PackageManagement\Get-PackageProvider -Name NuGet -Force

In PowerShell ISE, if you invoke the exit command, it closes the entire application regardless of how many tabs you have open. It would be better if the exit command simply closed the current tab (if you have multiple tabs open) or the entire application if you only have one runspace open. This would prevent accidentally closing runspaces that you wanted to go back to just because you used the all-too-familiar exit command.

Also, making this change would address this issue within PowerShell ISE: when you invoke exit, the Runspace.StateChanged event is only fired for the current/active runspace (tab), even if you have multiple tabs open, so all tabs other than the current one that want to do cleanup of some resource when the runspace is closed cannot do so.

Votes from Connect: 3

Original Date Submitted: 6/8/2015 2:40:45 PM

Description:
Contact Information
Handle: aL3891
Site Name: PowerShell
Feedback ID: 1411231

Problem Description:
At the moment all dsc resources are executed serially. given that dependencies are allready specified, it would in theory be safe to execute steps in parallel.

I'm guessing this is planned at some point but i could really use a way to enable parallel execution because I'm using dsc to spin up test environments with a bunch of services and having those being set up in parallel would speed things up considerably.

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

Repro Steps:

Internal BugId: 14550

Votes from Connect: 42

Original Date Submitted: 4/10/2015 11:19:28 PM

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

Problem Description:
The Out-GridView command displays all of the properties of each object that is fed into it. Consequently, in order to make the tool more usable, the Select-Object command can be used to inclusively filter the key properties of each object, to display to the end user. Unfortunately, this process results in a modified object, that cannot be used for all intended purposes.

Instead of using Select-Object, a -DisplayProperty parameter should be added to Out-GridView, so that unmodified objects can be piped into it, while only the specified properties are displayed. The pipeline output from Out-GridView should emit the unmodified objects.

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

Repro Steps:

Internal BugId: 14376

Votes from Connect: 12

Original Date Submitted: 4/4/2015 8:50:49 AM

Description:
Contact Information
Handle: Arnoud Jansveld
Site Name: PowerShell
Feedback ID: 1224213

Frequency: PowerShell ISE
Regression: function Show-Form
{

[reflection.assembly]::LoadWithPartialName("System.Windows.Forms") >$null

$form = New-Object System.Windows.Forms.Form

$label = New-Object System.Windows.Forms.Label

$label.Text = "Please close this form"

$label.AutoSize = $true

$form.Controls.Add($label)

$form.ShowDialog()

}

$result = Show-Form

Workaround (slow):

$result = Start-Job ${function:Show-Form} | Receive-Job -Wait -AutoRemoveJob

"Form result: " + $result.ToString()

Write-Warning "The following step may hang PowerShell ISE, save your work!"
Read-Host -Prompt "Hit Enter or Ctrl-C to abort"

This generates a WM_SETTINGCHANGE broadcast message

Problem Description:
After using ShowDialog() to display a Windows Forms dialog, the ISE will hang when it receives a WM_SETTINGCHANGE broadcast message (e.g. when changing display resolution, switching from a laptop screen to an external monitor or connecting to the current session from another machine via RDP).

This was reproduced on PowerShell ISE version 4 and 5 (Feb preview). Sadly it affects many useful scripts, including Lee Holmes' (awesome) Show-Object.

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

Repro Steps:
function Show-Form
{

[reflection.assembly]::LoadWithPartialName("System.Windows.Forms") >$null

$form = New-Object System.Windows.Forms.Form

$label = New-Object System.Windows.Forms.Label

$label.Text = "Please close this form"

$label.AutoSize = $true

$form.Controls.Add($label)

$form.ShowDialog()

}

$result = Show-Form

Workaround (slow):

$result = Start-Job ${function:Show-Form} | Receive-Job -Wait -AutoRemoveJob

"Form result: " + $result.ToString()

Write-Warning "The following step may hang PowerShell ISE, save your work!"
Read-Host -Prompt "Hit Enter or Ctrl-C to abort"

This generates a WM_SETTINGCHANGE broadcast message

Expected Results:
The script should show an empty dialog; after closing it and hitting Enter at the prompt the ISE should remain responsive (on some occasions the script has to be run more than once for the problem to occur).

This works fine in the regular PowerShell console.

Internal BugId: 14363

I think it's time for an overhaul of Group Policy and GP Preferences. You can still keep the GUI to allow everyone to have something familiar, but I would love to see if Group Policy can be converted to start using PowerShell DSC under the hood. I think this would make things much simpler in terms of deployment and wouldn't require logon/logoff or restarts anymore (unless you wanted a script to run at those times). For everything else like IE/Edge settings, registry settings, mapped drives/printers, desktop backgrounds and such I think having everything exposed in PowerShell would both make it more secure (as we've recently seen with the SMB signing problems) and easier to troubleshoot. It might even make it easier to deploy a Linux version of Group Policy since DSC can work against Linux...