PowerShell DSC locally: basic example

If you are new to the principle of Desired State Configuration (DSC), its Big Idea is to take a set of declarative instructions (basically configuration as code), and if the requested thing is not in the required state, “make it so”. If it is in the required state, do nothing. This article uses the simple example of folder creation to demonstrate that. Everything happens locally, which is not a typical use-case, but is useful for focussing on learning and basic syntax, rather than also getting your head around remoting.

Sometimes rather than struggle with remote authentication, I am happy just to push a bunch of scripts to a new VM, and do everything locally. You still need WinRM running.

For the example, I am creating a folder. (Of course it is very easy to create a folder in “normal” PowerShell or from the command line or any number of ways. But this is precisely about using the very simplest example to illustrate a point.) The push server and the receiving client are the same thing. This example can be executed on a Windows 7 client (providing it has the right level of PowerShell for DSC*) or Windows 10 client, or Windows 2012 R2 server and up. *The minimum version of PowerShell is 4.0. You can check this by running $psversiontable in Powershell.

On the first execution, the folder does not exist, so you get this…

The system cannot find the file specified.
The related file/directory is: c:\temp\TheDemo01.

On the second execution, the folder does exist, so you get this…

The destination object was found and no action is required.

Both of these were expected, as you might hope with something called Desired State Configuration.







PowerShellDSC and Azure: more notes

This is starting to feel a little more robust in my mind… I created a pair of VMs on Azure, on the same subnet, with 1 implicitly a push server, and 1 a “client” server, or “pushee”. Each have public IPs… although thinking about it could I just have opened the RDP ports without that? Don’t know, don’t think so. But regardless they talk DSC to each other through their respective private ports. In fact I couldn’t actually get them to talk DSC/PowerShell/WsMan to each other through their public ports/DNS names. Authentication is done through runtime credentials… which are the same on both servers, FWIW. I don’t have a domain (uksouth.cloudapp.azure.com not really a domain… and if it was that would worry me from a security point of view.

The test here was to create a folder from one to the other, being the very simplest proof that had value… and it worked.

Advice: after each failed run, delete the created Dsc configuration folder. Avoids confusion.


PowerShell DSC: Using a Push Server

Driven from a Push Server, this creates an empty folder on the remote server (PS V5, Windows Server 2016, both), which is in the same domain:

It amused me to do a cartoony representation – I like pictures, diagrams:

The single code file and the history is in a Gist here.