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!

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

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.

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

when wmf4 initially launched, you could place meta.mof files into the pull server along side the default mof and both would be downloaded by the node and applied. This was rather ideal, as it meant I could create standard LCM configurations, and easily update/enforce them.

For some reason, this seems to no longer work in WMF5.0. This should be returned. Anyone who's had to edit the settings of hundreds (thousands?) of agents should understand it's way easier to tweak one property.

Real world example: ask anyone who's ever had to reconfigure the the SCCM agent cache. It's a needlessly complex process because the setting doesn't exist in the client profile.

I should not have to write custom module just to update the LCM of an agent when everything else is inplace

I'm trying to create a function that returns the bindinginfo for a website. This is intended to reduce the complexity of my dsc resource file that will have 20/30 websites with similar bindinginfo based on the node name. Anyway, it seems like the dsc compiler doesn't support cim instances. Doing the same thing with credentials actually works, so I wonder why this is the case for binding infos.

This is an example to reproduce the problem

configuration DscTest
{
Import-DscResource -ModuleName xWebAdministration;

Node localhost
{

xWebsite TestWebSite

{

    Ensure = "Present"

    Name = "TestWebSite"

    PhysicalPath = "C:\inetpub\test"

    BindingInfo = (Get-TestBindingInformation $Node)

}

}
}

function Get-TestBindingInformation
{
[OutputType([Microsoft.Management.Infrastructure.CimInstance[]])]
param(
[System.Collections.Hashtable] $node
)

return @(

New-CimInstance -ClassName MSFT_xWebBindingInformation -Namespace root/microsoft/Windows/DesiredStateConfiguration -Property @{

    Port                  = 80

    Protocol              = "HTTP"

    HostName              = "test1"

} -ClientOnly


New-CimInstance -ClassName MSFT_xWebBindingInformation -Namespace root/microsoft/Windows/DesiredStateConfiguration -Property @{

    Port                  = 80

    Protocol              = "HTTP"

    HostName              = "test2"

} -ClientOnly

)
}

DscTest

And this is the error I get:

Write-NodeMOFFile : Invalid MOF definition for node 'localhost': Exception calling "ValidateInstanceText" with "1" argument(s):
"Convert property 'BindingInfo' value from type 'STRING[]' to type 'INSTANCE[]' failed

At line:22, char:2

Buffer:

onName = "DscTest";

};^

insta

"

At C:\windows\system32\windowspowershell\v1.0\Modules\PSDesiredStateConfiguration\PSDesiredStateConfiguration.psm1:2193 char:21

... Write-NodeMOFFile $Name $mofNode $Script:NodeInstanceAlia ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CategoryInfo : InvalidOperation: (:) [Write-Error], InvalidOperationException
FullyQualifiedErrorId : InvalidMOFDefinition,Write-NodeMOFFile

You can find more details on the problem in this github issue:
https://github.com/PowerShell/xWebAdministration/issues/113

I can successfully create a disabled local user account on a non-domain joined server which has a password policy enforced.

If I try to create the disabled account with out a password, or one in violation of the policy, the configuration fails. This is expected.

If I create a disabled local user account with a password that meets the requirements, the configuration applies. When I run Test-DSCConfiguration the test fails with:
PowerShell DSC resource MSFT_UserResource failed to execute Test-TargetResource functionality with error message:
There could be a possible connection error while trying to use the System.DirectoryServices API's.Exception calling
"ValidateCredentials" with "2" argument(s): "This user can't sign in because this account is currently disabled.
"

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

+ FullyQualifiedErrorId : ProviderOperationExecutionFailure

+ PSComputerName        : localhost

Wouldn't this lead to the configuration constantly running every cycle?

Testing out WMF 5.0 and when I tried one of our existing configurations, which has a good amount of resources in it, the following error is logged in the event log after each consistency check:

Job {%JobID%} :
Http Client {%AgentID%} failed for WebReportManager for configuration The attempt to send status report to the server https://johntestx02/PSDSCPullServer.svc/Nodes(AgentId={%AgentID%}')/SendReport returned unexpected response code RequestEntityTooLarge..

I assume this is because of the amount of resources the node is trying to report on back to the report server. Has anyone else run into this? Can the Report Server configuration be adjusted to accept lager amounts of data?