The PowerShell DSC sequence I’m using to deploy my Windows machines primarily uses script elements although a multitude of other elements (such as WindowsFeature shown below) could be used. The Pull Server has PowerShell DSC installed as a feature.
With this example, I’m using Server 2016 in Azure against other Azure provisioned systems.
For a basic primer into PowerShell DSC, have a look at this blog first.
As I have installed Chocolatey (actually Klondike as you can tell from the “api/odata” URI element of the Package Repo string), using Windows Management Framework 5.1 allows me to retrieve a package for install directly from my build server.
All PowerShell DSC script items begin by testing a machine and validating if an install is required. The mandatory TestScript section must return a true or a false – in regard to the existence of an element that shows the component has run correctly. I use a standardised launcher with packages that will create a signature file after a successful install. You can see in the TestScript section the signature file is being looked for prior to initiating the SetScript function.
SetScript will actually install the package.
GetScript wont be used at all with a Pull server but would allow the machine to be remotely queried over a CIM session.
Creating the Sequence Management Object File
Management Object Files (MOF) are the text files used to transfer sequence instructions from the Pull Server to the clients. The DSC sequence shown doesn’t explicitly name any clients, instead I’ll use a Configuration Data object. I’m doing this to future-proof my project as it allows me to assign custom properties to my machines. At some later stage, this can be used to dynamically install packages based on the properties chosen.
Also note that I’m using ‘localhost’ as my machine name. This will allow me to produce a sequence that can be accepted during deployment by all machines.
With the example shown above, I titled my configuration SOEInstall. At the bottom of that script, I will create the MOF by calling SOEInstall like a function.
As I’m running this script on my DSC Pull Server, I can copy the newly created MOF to the server Configuration directory. Once copied, I must copy a new checksum to accompany the file.
The GUID used with this sequence will be embedded in bootstrap scripts used by clients during provisioning to retrieve this file.
Note that there is practically no difference between the management of sequences designated for Windows and Linux systems.
The Local Configuration Manager (on Linux) is designed to be able to manage reboots through $Global variables. With every example I could find, the way to set the variable is to use PowerShell... which isn't possible through bash. That doesnt stop a machine being forced to reboot by directly calling shutdown. I use a flag file (called 'rebootme') which can be checked for within a shutdown script.
- Log in to post comments