Author Posts

April 28, 2014 at 12:21 pm

During development of a new machine configuration, I'd like to be able to completely remove the currently "Pushed" configuration from the test machine. It's not a VM, so I can't just turn it off and have all changes be remove. One idea I had is simply you to Push out a new more or less empty configuration, such as the following:

Configuration ClearConfig

Node $MachineName
Log Nothing
Message = "Clearing configuration"

ClearConfig -MachineName localhost

Is there a better way to accomplish this "clearing out"?

May 2, 2014 at 12:47 am


Depends on what you mean with remove. A node can only have one configuration. You can apply 2 configurations to a server, however only the last will be "active". The node will have both configurations applied, however if you run Test-DSCconfiguration/Get-DSCconfiguration, the last applied (pushed/pulled) configuration is used/returned.

If you want to reset the node's configuration, you will have to create an "inverse" of the applied configuration and apply that configuration to the node. I have been playing with the idea to create that functionality, however time constraints prevents me from doing so.

As a sidenote I currently use snapshots to reset my test nodes when I create configurations.

Let me know if this make any sense to you, if not post a new question 🙂



May 2, 2014 at 11:44 am

My question was about "resetting" a nodes configuration, so your reply makes sense. I intend to try and use "snapshots" during development, but if that wasn't available I was also looking for ideas on how "turn off" or "disable" configuration checking. Depending on what the configuration consists of, I am not sure if an "inverse" configuration would always be possible. Thanks for the reply.

May 2, 2014 at 4:47 pm

So... you've asked a few things, maybe :).

You can shut the LCM off so it stops checking, yes.

But you can't "remove" a config. It isn't like Group Policy; a config applies, and whatever it does is "sticky." You'd have to put in place a config that "undoes" everything to "reset" the state of the machine. So, "inverse," as you said.

But you can keep the LCM from checking its current config.

May 5, 2014 at 11:57 am

Don –

How do you shut the LCM off so it stops checking?

In you last sentence, did you mean to say you "can't" keep the LCM from checking its. If not is keeping it from checking the same thing as turning it off?


May 5, 2014 at 2:38 pm


A node can be configured in 2 modes: PULL and PUSH (default). Only a node with a PULL refreshMode will automatically check its configuration and may or may not apply it. You can check the setting with the Get-DscLocalConfigurationManager cmdlet.

See also this for settings that apply to LCM:



May 6, 2014 at 4:49 am

I ran a "Get-DscLocalConfiguration" on the Windows 7 machine I using to experiment with DSC, and here is how the LCM is configured:
AllowModuleOverwrite : False
CertificateID :
ConfigurationID :
ConfigurationMode : ApplyAndMonitor
ConfigurationModeFrequencyMins : 30
Credential :
DownloadManagerCustomData :
DownloadManagerName :
RebootNodeIfNeeded : False
RefreshFrequencyMins : 15
RefreshMode : PUSH
PSComputerName :
< << In reviewing the "Desired State Configuration" windows event log, the LCM is logging every 30 minutes. So even in "PUSH" mode the configuration is automatically being tested. It is currently logging a "Warning" level message because something about my current configuration must be wrong. The event message logged isn't very useful as far as what isn't configured correctly: >>>
Job {856F9B18-9523-4382-892F-EB7D4FAE86BB} :
From LCM, message is
Completed processing test operation. The operation returned False.
<<< So once again, how can I turn off the LCM from checking? Jeff

May 6, 2014 at 1:48 pm


Okay, now we are on the same page. That would be the Consistency engine talking to your eventlog.

Get-ScheduledTask -TaskName consistency

Or open up taskscheduler and browse to Microsoft\Windows\Desired State Configuration.

You may disable the task to prevent it from running and thus prevent it from creating the eventlog entry. An easier approach would probably be to delete/rename the current.mof file in the $env:systemroot\system32\configuration. Please note that I have not tested that, it may convert the warning message you receive now with an error message in the eventlog.