xPDT – Remoting Tasks and Validation

In “xPDT – the next generation of deployment automation”, I outlined the requirements and challenges of automating distributed deployment. This post will examine the challenges associated with remoting tasks and validation.

By definition, a distributed deployment is spread across multiple servers, which means there is a need to initiate a deployment from one location to multiple machines. Windows Server has a number of ways to execute a task against a remote server – the preferred way is using WinRM, but there are also tools such as PSExec, and even WMI methods to start a process on a remote machine. For reasons that I will explain in a later post on execution, the original PDT did not use any of these approaches. Instead, it effectively used the Windows Task Scheduler as a remote agent. The original PDT was a distributed deployment controller, and for each task that it needed to execute on a remote server it would register that as a task in Task Scheduler on that remote server without a trigger, then start that task, then wait for that task to complete. Wrapped around each task, it would first check to see if what it was about to do was needed using one of a number of validation tests, and then would only execute where necessary and run the same validation after the task was complete to ensure it did what it was intended to do.

DSC makes this almost trivially easy. The DSC Local Configuration Manager (LCM) runs on each server, so effectively provides the agent. When a DSC configuration is provided to a server – either through a push which sends the configuration to the machine using WSMan, or through a pull where LCM retrieves a configuration from a pull server using either SMB or HTTPS/HTTP – the LCM executes that configuration locally. Each DSC resource that is included in the configuration defines a test to determine whether the item defined by that resource is in the desired state or not, and then only executes a set if test returns false.

So, the builtin capabilities of DSC easily replace the remoting tasks and validation components of the original PDT. xPDT and DSC also has the benefit that a re-run completes in a significantly shorter time than the original PDT. All validation checks in the original PDT are run from the central “controller” – the machine running Installer.ps1 – using remoting to the remote server, which takes time due to having to traverse a network and other remoting delays. If a DSC configuration is re-run – either because it is set to “ApplyAndAutocorrect” or the same configuration is pushed again – all of the validation checks are run locally in LCM. In some sample configurations I’ve run through both the original PDT and xPDT, a re-run in PDT can take 10 minutes or more while the same re-run in xPDT takes under a minute.

In my next post, I’ll discuss credentials requirements and how I solved those in xPDT.