What is different/better about DSC vs "regular" scripting?

I watched a video on ITPro.tv about PowerShell Desired State Configuration DSC. They introduce it, and effectively run a script. However, this was their first (real) introduction of scripting too, so I didn't pick up the difference between DSC and regular scripting. I've done some regular scripting before, and maybe they just didn't have that great of an example; it seemed like a regular script could install a role/feature and copy some files just fine. I didn't see the benefit to DSC compared to just a script. Aside from a machine being able to poll for some kind of changes, which they didn't cover in practice, just in theory.

What are the benefit(s) of DSC over traditional scripts; for example "install role, copy file"?

• With PowerShell, you can connect to remote machines and tell them to do stuff, so that's not exclusive to DSC.
• With DSC it seems like you're doing some sort of compilation to make a mof file, and then you run it from the shell after the script, which seems like an unnecessary step.
• The MSDN overview reads like an overview of PowerShell, and I don't see the differentiating characteristics.

As you have said, you can do pretty much everything you would do with DSC, with straight powershell code.

But, DSC is all about configuration management.

Configuration management is about patterns and practices of using code and various systems to ensure a system is in a specific state. Ref 1 2

One important thing about Configuration management is idempotence. Meaning the code describing your system in the configuration management system will be checked and ran against your system periodically. Lots of basic scripts are not well designed, and will do the correct thing the first time you use it to configure a system, but the next time they will error, duplicate things and so on. Configuration management systems ideally will abstract away a large portion of the testing and state checking code you have to manually add in a script, to make your script idempotent.

Another important thing about DSC and many other configuration management systems is about making re-usable resources that actually do the work that can be shared with anyone and everyone in the world. In this way your actually 'configuration' should be just the few specific details that are specific to your environment. This also means you should need to write a lot less code, since you can re-use things that has been used and vetted by many other people.

I have included a few links above, but there are many good web sites you can find on the Internet about the theory of configuration management systems. The general theory applies to all configuration management systems (puppet, chef, dsc, ansible, etc) it is certainly worth learning, and worth using in most environments.

I suggest you take a look at https://docs.microsoft.com/en-us/powershell/dsc/dscforengineers#i-have-powershell-why-do-i-need-desired-state-configuration.

I've been doing devops as a C# project lead since way before it was called that. I've written dozens of these "setup a share", and "create an app in IIS", and "check if IIS Rewrite is installed" type of scripts. I'm usually asked to do it by someone who thinks "It's just one line of code to do X." But what if the thing already exists? What if steps 1,3 already exist but 2,4 don't, or step 2 (lets say an IIS app pool) is not configured exactly the same as last time?

Yes, DSC requires you to name every "part" of the script. Which seems tedious at first. But if you don't name it then DSC engine and providers can't tell you what part of the script it taking too long, or what part of the script is failing.

If you're doing folders, IIS, app deployment, or Windows Features I highly recommend you invest a few days in learning DSC.