Last week our AFN (Azure Freak Night) got cancelled which is kind of good for me because I haven’t written yet about the previous one. On this night we reviewed Azure DSC so read along if you want to know more about it!
We have been looking at the automation options in Azure for a while and we decided it was time to test out the “Desired State Configuration”. The basic concept of DSC lies at the core of our work as IT professionals but for those who don’t know the concept I’ll give a brief explanation/example. If you already know you can just skip to the MSFreaks blog here for the technical details on how to configure this step-by-step.
If you’re a user of computers you’ve probably experienced that sometimes it just won’t work all of a sudden. So you walk up to your tech guy and tell him that your computer doesn’t work anymore. Usually the first thing that the tech guy will say is: “What did you do?” And of course you reply with: “Nothing it just stopped working all of a sudden while I was working”. What your tech guy is actually asking is if anything has changed while you were working. This can be a change initiated by yourself or a change that the computer made automatically (think automatic updates e.g.).
As tech guys this really is the core of what we have to find out because probably around 90% (just a guess btw don’t shoot me for it) of the problems are because of changes, be it small or big. So when we ask this question it’s not about blaming someone or something being able to tell what changes helps us reduce the solving time. It’s kind of like giving the police a statement of the suspect, we need to know every little detail. Your tech guy doesn’t care if you pressed the wrong button, did something you find stupid or just smashed your keyboard in frustration pressing all sorts of buttons. He is there for your convenience and just wants to solve your problem as quickly and effortlessly as possible.
We do however understand that you might not recall everything you did or that there are processes in the background (group policies, automatic updates etc.) you might not be aware of. So that is why Azure leverages DSC. With DSC it doesn’t really matter what you did or what might have happened as we can just reload the configuration that we saved earlier in order to restore everything to the way it was.
Keep in mind though that this is in no way a back-up so if you deleted a file your DSC probably won’t bring this back!
The part that we can save however are configuration settings like domain joins, registry settings etc. With DSC you can easily set this up and restore settings based on your choice of automatically every XX minutes or just alerting that the settings are no longer compliant.
This of course not only helps our users but also our fellow colleagues when they’re troubleshooting some other issue. During troubleshooting many things are usually changed in order to find the solution and with the DSC we can always go back to our configured start situation to apply just the fix that we found and recapture it and reset all the other things we changed.
So there you have it! DSC is a really powerful tool in our toolkit which makes troubleshooting easier and sometimes even unnecessary. We all know that when doing this manually you forget that 1 checkbox or make a typo in your registry string that goes unnoticed. So it’s also the perfect way to copy configurations as you’re always sure that you have the same state on every server in your landscape.
Now that we’ve covered the concept you can check out our step-by-step blog about setting this up in Azure on the MSFreaks blog here.
Zommy