This topic contains 7 replies, has 3 voices, and was last updated by
May 17, 2016 at 10:17 am #39203
Hey all, I'm very new to DSC as a whole, and I'm having a hard time wrapping my head around the approach. I'm trying to start small here, and essentially looking to create DSC configs to replace many of the GPOs we currently use.
When I build GPOs, I link them to OUs, and I make each GPO accomplish a single thing to keep it all modular. It allows me to re-use them in other places, and it makes it much easier to make changes and to troubleshoot.
I don't know how to approach this from a DSC perspective. For example, let's say that I hypothetically manage a Skype for Business infrastructure. I may want some settings applied to all servers, and some things only applied to Front Ends, Back Ends, Edge, etc...
It seems like I would want to use configuration data to outline all of the nodes and assign them roles, and then use the .Where statements to target the servers with the config stanzas.
I know how to do that, but it seems like a very poor approach. In the end, I'll end up with a gigantic monolithic config that I'll be terrified to touch (even though I have a test environment),
Is there a best practice approach to this? Should I have a different config with for each type of server role? Does that mean I don't even need to use configuration data?
Just looking for some friendly advice here....
May 17, 2016 at 11:46 am #39212
I'm not sure DSC is a good alternative to GPO. Have you read, "The DSC Book?" It's linked from our Resources/eBook menu and might provide some better insight. But DSC isn't designed for dynamic targeting, nor for a high level of modularity (albeit with some exceptions), nor for AD-based deployment. DSC isn't really designed with client workloads in mind, nor is it positioned as a GPO replacement. Not yet.
I'm in the middle of writing a DSC design book – I'd summarize it here, but honestly, you're hitting all the questions you should be asking and that I'm trying to put into book form ;). I'm sure others will chime in, but the short answer is, if you want to go this route, forget what you know about GPOs. DSC isn't equivalent in any way.
May 17, 2016 at 1:22 pm #39220
First of all, thank you for the response!
You mentioned "I'm not sure DSC is a good alternative to GPO." That's good to know, and honestly I have no idea why I made the assumption that it is.
You also mentioned a lot of things that it is not meant for, so now I'm having a hard time figuring out what it IS meant for.
I greatly appreciate the comment and look forward to reading the DSC design book (hurry up!). In the mean time, I'll check out "The DSC Book" that you mentioned.
May 17, 2016 at 9:14 pm #39223ParticipantTopics: 29Replies: 125Points: 0Rank: Member
Easiest way to look at it, IMO, is a declarative framework for _systems_. The reason it doesn't make a good GPO replacement is because GPOs involves user data, something basically out of scope. Final DSC configurations are also rigid ... as in the mof file that is generated doesn't contain variables.
DSC *is* ideal for server farms. Say you have a farm of SQL servers and need to make sure all of them are configured identically ... DSC is ideal for this. Ditto for web, exchange, anything where you need to reliably repeat and enforce configurations. But in general think "fixed system settings". Anything extremely dynamic isn't as ideal (by dynamic I mean settings that actively change in an environment ... not necessarily settings that will set different based on need).
One of the the most simple POCs/success cases I use for DSC with my clients are Hyper-V clusters. Amazingly enough, server templates in SCVMM don't control things like network cost and nic binding order under good control, but this is EXTREMELY simple to regulate in DSC. It also means I can mass change iSCSI settings, jumbo packet frame sizes ... any of those nice "best practice settings" that otherwise turn into a runbook of settings you have to remember to switch on into something that is easily and centrally controlled (and rapidly updated if new best practices emerge).
May 18, 2016 at 6:05 am #39231
Hi Justin, thanks for the response!
I am not looking to use DSC as a replacement for any workstation GPO settings — merely for settings that configure our server farms.
To be a little more specific, I'll explain what I want to configure for all servers and then give an example for one role of server. I want to use DSC for the following:
For all servers:
-Set the PS Execution Policy
-Configure baseline FW rules for all servers
-Ensure that some generic services are always in the running state
For Skype for Business Front End servers:
-Set the local administrators
-Create appropriate FW rules for Front End functions
-Ensure that the Front End specific services are always running
-Enable that some Front End specific features and roles are always installed
I know all of this can be done fairly easy with Group Policy or with DSC. However, with GP it's very intuitive as to how to make it happen. Link the GPOs at the Skype for Business OU level, and link the specifics at the Front End OU.
I'm wondering about that part of the DSC approach. Do I list all nodes on the configuration data, and assign roles as needed there and then apply the config using this config data? The targeting is built-in with the .Where functionality and what not.
However, that's where I really have the question: is that best practice? Because if I take this approach, then in the end we have our entire UC platform configuration within one gigantic Configuration and Configuration Data file...and it feels weird.
Does that make sense?
May 18, 2016 at 6:23 am #39232
Keep in mind that DSC was deliberately designed with no dependencies on AD, because almost all organizations have some number of servers that aren't in a domain.
So instead, you either push a DSC configuration to a machine (or push a bunch to a bunch of machines) as a manual operation.
Or, you drop all those configurations onto a DSC Pull Server. You then configure (one time operation) the machines to grab their configurations from that Pull Server. You do have to tell them which config to grab, since a Pull Server can have lots of configurations for many different servers.
Breaking a configuration down into modular pieces... that's more complex. It's not that you can't do it, it's just that there are about 5 different ways of doing so. None of them are wrong – they just all have pros and cons to consider.
But what you're asking is really "what's the best approach" and that's a HUGE question with a LOT of complex "it depends" type of answers. But seriously... give me a few days. I'm going to have a first draft of my design chapter done, it'll be a freebie, and I promise it'll help you understand the different approaches and their pros and cons.
May 18, 2016 at 1:14 pm #39251
OK. See if https://leanpub.com/the-dsc-book doesn't help at least a little (you can grab just the Free Sample; you don't need the full book and right now I have written beyond what's in the Sample).
"However, that's where I really have the question: is that best practice? Because if I take this approach, then in the end we have our entire UC platform configuration within one gigantic Configuration and Configuration Data file...and it feels weird."
Yes, you'd wind up potentially with one huge script. Whether that's a best practice or not depends entirely on you. Some people love it. Others hate it. It's more about what's going to work for you.
What you're probably secretly wanting without realizing it is some kind of tooling to help yo manage all your configuration artifacts, so you could sort of dynamically generate a MOF without having to have a ginormous script. Sadly, we do not have such toolking. I hope someday we do.
May 18, 2016 at 6:50 pm #39261
Hey Don. I just read the sample. I'm not entirely sure if it's coincidence, but it just happens to be exactly what I'm looking for 🙂 I'm super excited for it to be released and want to say thank you for the perfectly timed sample!
From the different options you list, the "Simple Includes" seems to be closer to what I am looking for in a design. That way I can modify the included configs and will only affect the stanzas where those configs are included — giving me some of the modularity that I felt was missing.
But as you mention, ultimately a node will read in a single mof. It may be a compilation of multiple mofs, but it will all be joined together in the end. So with both simple includes and with partial configs, the problem of accidentally duplicating something that needs to be unique is very likely to occur at some point. It would be nice if something could detect the duplicated values.
I'll start with the simple include method and just feel my way through it. The beauty of this is that everything is in source control — making playing around easy (and safe).
It seems like DSC is still finding itself and I'm excited to see how it evolves. I'm also looking forward to seeing the tooling that will start to evolve alongside it.
The topic ‘Best practices approach to DSC architecture’ is closed to new replies.