Powershell DSC in coexistence with group policy.


Does any one have any experience with DSC in coexistence with group policy ?
We are looking at way to introduce DSC in our customers domain.
But our responsebility is mainly OS, file, print, DCHP and som AD on about 150 customers.
We would like to start using Powershell DSC, but we also see that we have to coexist with group policy.
This due to applications etc.

And we would not like a situation where we stop the service, and policy start it again.
Og other configurations, where policy and DSC start changing eachothers settings.

Any sugestions on howe I can get control on this ?
would not like to create a loop here… :slight_smile:

The process that seems to work well for a graceful transition:

  • Introduce DSC for “baseline” configuration as part of your server build/deployment process to eliminate any steps that are completed manually today. Use this phase to stabilize a DSC strategy and the supporting environment.
  • Transition policies that apply across all servers. During this phase, build a skillset for operational validation so your automation platform can verify the health state of your environment on demand. Use this as an opportunity to show value.
  • Define server roles in DSC and transition the special/unique GP settings. This phase could take a long time if you have hundreds of server roles. You might find yourself aligning this work with new releases of each server role.

To quote Jeffrey Snover, “How do GPO and DSC get along? They don’t: they’ll fight like two raccoons in a bag.”

So you have to be very careful that whatever is being configured, is being done by one, or the other, but not by both. That can be hard, especially with complex GPOs, but otherwise you will indeed create a loop. Michael’s suggestions are good ones, but it starts with a really solid inventory of what your GPOs are all doing.

Thanks for the feedback.
I see we have some challenges here…

And our thoughts is to configure a “baseline” for new servers, and keep them like that.
But in some environment there are sevral contributors, and administrators.
Those environment could be a challenge to have full controll of.
The best would be to lock them down in a way.

Maybe create a new OU for the servers using PS DSC, and restrict the use of policy there.
It would also be possible to remove rights in part of registry to prevent policy conserning computer part to be applied.

But guess we just have to work it out some how.

I think of DSC as the Computer part of GPO, not the User part.
Its unlikely youll have a User based GPO that shuts down a service, though I have seen a case like that before. For which I wouldn’t use DSC in the first place.

The good part about DSC - you dont need a domain active to set state (similar to local GPO on the node)

The bad part, in this relation, is that you cant use the GPO filtering with WMI to set which objects inside the OU get the policy
applied but for that you can work with multiple DSC scripts thus multiple mof files and then use the ConfigurationNames option in the LCM to give the nodes the right MOF files.

As for multiple admins, multiple contributors, you can work with partial configurations:

This will allow you to give some teams more freedom and control but still maintain one mof. This requires work and discipline
but if you set an environment for them with CS Cod, connected to a source control where all they do is check-in changes to templates and you do the behind-the-scene Build and Tests before creating a new partial mof for them, you can get a good pipeline implemented

@Jan you are on the right track. The end goal would be an environment where no changes are made without first passing automated validation, but you will first need to prove the value of the approach before you can drive organizational acceptance.

You might be able to use our whitepaper to help with the convincing.