In Azure Automation DSC the whole MOF file gets encrypted without the need to manually issue certificates for every node and then to collect the public keys.

From Azure documentation:
"Keeping credentials secure in node configurations (MOF configuration documents) requires encrypting the credentials in the node configuration MOF file. Azure Automation takes this one step further and encrypts the entire MOF file."

This extremely useful feature sould also be implemented in the on-premises DSC pull server. Especially because the needed functionality must alread be in the WMF 5 as nothing more than WMF 5 is needed to use the Azure Automation DSC service.

This would be huge improvment for the DSC pull server.

Thx!

At some point in the 5.0 time period, Update-Help installed About topic files in the en-US directory for the PSWorkflow module with .txt (not .help.txt) file name extensions.

e.g. about_Foreach-Parallel.txt

Later, this was fixed and Update-Help installed the same help files in the same directory with the (correct) ".help.txt" file name extension.

e.g. about_Foreach-Parallel.help.txt

Now, the PSWorkflow\en-US directory has 9 pairs of files that are identical except for the file name extension.

about_ActivityCommonParameters.help.txt
about_ActivityCommonParameters.txt
about_Checkpoint-Workflow.help.txt
about_Checkpoint-Workflow.txt
about_Foreach-Parallel.help.txt
about_Foreach-Parallel.txt
about_InlineScript.help.txt
about_InlineScript.txt
about_Parallel.help.txt
about_Parallel.txt
about_Sequence.help.txt
about_Sequence.txt
about_Suspend-Workflow.help.txt
about_Suspend-Workflow.txt
about_WorkflowCommonParameters.help.txt
about_WorkflowCommonParameters.txt
about_Workflows.help.txt
about_Workflows.txt

Get-Help should ignore the .txt files (must have changed in 4.0), but it does not. Instead, it finds both .txt and .help.txt. So, when you run Get-Help, instead of displaying help for the topic, it lists the duplicate base names.

PS C:\ps-test> Get-Help about_Foreach-Parallel

Name Category Module Synopsis
---- -------- ------ --------
about_ForEach-Parallel HelpFile Describes the ForEach
about_Foreach-Parallel HelpFile Describes the ForEach

I'm not sure why Get-Help is recognizing About.txt files.

But, we had a similar problem in a module when we shipped a file with corrected capitalization in the base name.

about_FileName.help.txt
about_filename.help.txt

We might want to tweak Get-Help so that when it detects an exact duplicate base name, it displays the content in the newest file.

Also, in modules, Get-Help should display the help only for the version of the module that it's processing. That would allow module authors to update help topic names without causing unintended duplicates.

For some reason DSC errors out with a credential object contains a null password. Unfortunately that is the mechanism use to set group managed service accounts.
Here is a link to a relevant bug in xWebAdministration: https://github.com/PowerShell/xWebAdministration/issues/80#issuecomment-171364644

And here is an example of the output your recieve when you attempt to use a managed service account:

"VERBOSE: [COMPUTERNAME]: LCM: [ End Test ] [[xWebAppPool]testpool] in 0.0070 seconds.
The password supplied to the Desired State Configuration resource MSFT_xWebAppPool is not valid. The password cannot be null or empty.
+ CategoryInfo : InvalidResult: (:) [], CimException
+ FullyQualifiedErrorId : InvalidPassword
+ PSComputerName : localhost

Votes from Connect: 391

Original Date Submitted: 5/21/2015 12:20:32 AM

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

Problem Description:
PowerShell users often read .NET reference pages in MSDN. It's all but required, because Get-Help doesn't describe object members. However, in the Examples section of .NET reference pages, there are no PowerShell examples; not even a PowerShell tab.

MSDN says they cannot demonstrate a demand for PowerShell examples. I'd like to use this feature request to demonstrate the demand.

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

Repro Steps:

Internal BugId: 14500

Advances to the current PullServer are, quite frankly, slow and moving in a direction questionable to most MVPs. Microsoft should follow their own lead they took with the DSC modules: opensource it and place it on GitHub so that the community can invest in making a tool that we'd actually like to use.

Example of features still missing that everyone wants:
1. certificate management (use self-signed or pki)
2. web interface for compliance reporting

Example of features added that are questionable/actually bad ideas:
1. partial configurations (multiple pull server sources, mofs, and reports all being _managed_ by the node? who thought this was a good idea when we could do this with composite configurations more elegantly?)
2. specific LCMConfiguration class (why should I _have_ to now maintain two configuration files when 1 used to be just fine? Is it so i can use a feature #1?)

The pullserver is a critical component when it comes to the success of DSC but it's evolving too slowly. Open it up and let the few who are dedicated to DSC succeeding develop an ecosystem that will allow that to happen.

The New-LocalUser cmdlet available in Windows 10 Anniversary Update cannot perform a function described in the documentation.

Local user accounts may be connected with existing Microsoft accounts. New-LocalUser should support this by accepting a -Name parameter of the form "MicrosoftAccount\<user>@outlook.com". This is described in the detailed help.

However this fails because the parameter fails validation as it is over 20 characters in length (already true with "MicrosoftAccount\" and "@outlook.com" let alone the "actual" user name). The 20 character limit is valid for a regular local account name, but shouldn't be valid for an MS account name.

There appears no other way I can find to create a local user account with an existing MS account; so this is rather major.

Note that also the error message from the "problematic" call is also of spurious grammar (where it inserts the length of the name parameter provided):

PS C:\WINDOWS\system32> New-LocalUser -name 'MicrosoftAccount\me@outlook.com'
New-LocalUser : Cannot validate argument on parameter 'Name'. The character length of the 31 argument is too long. Shor
ten the character length of the argument so it is fewer than or equal to "20" characters, and then try the command agai
n.
At line:1 char:21
+ New-LocalUser -name 'MicrosoftAccount\me@outlook.com'
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidData: (:) [New-LocalUser], ParameterBindingValidationException
+ FullyQualifiedErrorId : ParameterArgumentValidationError,Microsoft.PowerShell.Commands.NewLocalUserCommand

Renamed from "Provide additional resource control methods in DSC" for clarity
Votes from Connect: 13

Original Date Submitted: 5/28/2015 12:15:20 AM

Description:
********Contact Information********
Handle: Ben Gelens
Site Name: PowerShell
Feedback ID: 1373894
***************************************

Problem Description:
Scenario:
A MOF file is compiled for a node serving a website. The service resource is used to declare the W3SVC service to be started and the file resource is used to copy in the web content.
Next an update is deployed to the website by compiling a new MOF file and for the new content to become active, the W3SVC service needs to be restarted.

Right now we need to do this in stages as we need to compile an intermediate MOF file to stop the W3SVC service.
When dealing with continues deployment / integration utilizing DSC Push or Pull, it would be greatly beneficial if DSC could leverage additional functionality so a resource could actually trigger a restart of a service by calling the service resource governing the status of that service and allowing this action to take place.

Of course this should not be implemented only for the service resource but would apply to others as well.

Chef has implemented this concept in all its resources where they can specify a Notify on one resource and an Action on another. For example: when a file mutation has taken place, it could notify the service resource to handle the restart action.

Suggestion:
Enrich DSC with additional native functionality to allow us to signal resources to take actions as the desired state of another resource is re-implemented / restored.

Code Example using registry:
configuration MyWebSite {

WindowsFeature SNMP-Service {
Name = 'SNMP-Service'
Ensure = 'Present'
}

service SNMP {
Name = 'SNMP'
StartupType = 'Automatic'
State = 'Running'
Action = 'Restart','Start','Stop'
DependsOn = '[WindowsFeature]SNMP-Service'
}

Registry Community {
Key = 'HKLM:\System\CurrentControlSet\Services\SNMP\Parameters\ValidCommunities'
ValueName = 'MyCommunity'
ValueData = '10'
ValueType = 'Dword'
Ensure = 'Present'
Force = $true
Notify = '[Service]SNMP:Action:Restart'
}
}
In this example we make sure SNMP service is installed, the service has the desired state of started and a registry key is set to configure the SNMP service with a valid community setting.
The registry setting will only be activated once the SNMP service is restarted so we setup a notify on the registry resource and allow it to trigger the Action of restart on the resource governing the SNMP service.

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

Repro Steps:

Internal BugId: 14519

I have created an internal NuGet Gallery to act as a module repository for internal modules and am trying to automate the registration of it as a trusted internal repository for all users in my organisation that use Windows Powershell and/or perhaps are starting to use DSC.

As all of the users in my organisation who use Powershell are in an AD group, I went looking for a Group Policy setting to register the internal repsitory. There isn't one, so I created a GPO and set it to run the following script, in the user context at login.

#Requires -version 5.0
Register-PSRepository -Name DomianRepo -InstallationPolicy Trusted `
-PackageManagementProvider NuGet `
-PublishLocation 'https://ps.my.addomain.com/gallery/api/v2/package/'; `
-SourceLocation 'https://ps.my.addomain.com/gallery/api/v2/'; `
-ErrorAction SilentlyContinue

In most cases the NuGet library (NuGet-anycpu.exe) is missing from either of the required locations and when the script is run interactively 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\ThisUser\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"):

This of course means that the script which is run by Group Policy upon logon and thus is not in an 'interactive' session fails to complete. This is a similar issue to that linked below:
https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/12491361--bug-install-module-force-prompts-for-user-input

My suggestions as a means around this issue are:

1). Remove the dependency on NuGet-anycpu.exe on the repository registration process completely meaning that the user can choose to install those binaries as appropriate only when they actually come to trying to use a registered repository (probably interactively)

2). Provide a -Force parameter for 'Register-PSRepository' allowing it to successfully register a repository in either the User or System context as appropriate to the rights of the installing user account without generating an interactive prompt

3). Provide a Group Policy Administrative template to register repositories as appropriate for users.

Powershell jobs (eg, Start-Job, Wait-Job, Receive-Job) fail when Powershell's codepage is set to UTF8.

Simple reproduction on Server 2012R2 w/ PS5:
from cmd.exe, set the parent process codepage and start powershell with:

chcp 65001
powershell

from the powershell that just started:
$job = Start-Job -ScriptBlock { Write-Output yo }
Receive-Job $job -Wait

The Receive-Job call will fail with: "
[localhost] The background process reported an error with the following message: Cannot process an element with node type "Text". Only Element and EndElement node types are supported. at
System.Management.Automation.Remoting.OutOfProcessUtils.ProcesData(String data, DataProcessingDelegates callbacks).
+ CategoryInfo : OpenError: (localhost:String) [], PSRemotingTransportException
+ FullyQualifiedErrorId : 2100,PSSessionStateBroken
"

This is problematic for things like Ansible that want to use Powershell with arbitrary non-ASCII character sets (where setting region-specific codepages are kind of a non-starter).