…the DSC fires successfully, it triggers the download / install of the patches (e.g. the latest 1GB CU for Windows 2016) - but then the Start-DscConfiguration immediately returns - leaving the patch to download/install in the background.
The issue being that my build then assumes that the process is complete, the node is compliant and continues to shut the machine down for templating.
Question is - is there an amendment I can make to the logic of the script to not exit until the patches are installed, or if not, is there a reliable way to continually check for compliance, and not move on until compliance is met?
Huh. See, the thing about DSC is “eventual compliance.” It’s not designed to be part of a synchronous process, per se. You’re meant to kind of let it alone to do its thing. I suppose you could create a custom resource that keeps returning non-compliant every time it’s checked, until the patch process is complete. You’d need to find some service or registry key or process or something it could “ping” to determine that. And the custom resource’s “Set” wouldn’t actually do anything, just its “Test” and “Get.”
I get that what i’m doing isn’t exactly the best use case for DSC - but i’ve DSC’d everything else in the build, and it seems a shame to jump back into a ‘basic’ PowerShell task for this one step!
In any case - the DSC Windows Update script is great once the machine is out in the wild, in an environment without SCCM.
I use a similar script to do what you need here. It is doing a lot more as well, so it would not make sense to post it here. But the short of it is:
I use the module PSWindowsUpdate on the LCM side to do the actual patching. (Invoked from an xScript). That will block the running of the LCM until it is finished.