Our example DSC configuration is pretty simple even though it worked well for showcasing how to push DSC configurations. When DSC configurations become more complex, there are things you must take into consideration.

Up until now, we have been configuring settings or enabling software with DSC Resources that were already present on the target host. What if we tried to use text files and MSIs that were not present on the target node? In all our examples, we haven't had to actually do any work to get the files we want onto our target nodes. And herein lies the main problem with pushing DSC configurations. Nothing is done for us; we have to copy everything and ensure everything is present and accessible on the target nodes. So, what do we have to do for ourselves when pushing DSC configurations?

When pushing DSC configurations, DSC does not copy DSC Resources for you. While you may be annoyed by this, it does make sense when you think about it. DSC Resources can be placed at several places, and there isn't a file transfer mechanism that can be used to put them there without involving the user in making a choice or providing credentials. You also might be wondering why we need to copy over the DSC modules if we already compiled the MOF locally. The MOF compilation process produces the manifest that DSC uses to list the things to do on the target node; the DSC Resource holds the code that implements the decisions and actions to bring the system to the desired state, so it has to be present on the target node for it to be executed.

The only way to solve this is to copy the DSC Resources over to the target nodes yourself when pushing DSC configurations. If you are thinking of using DSC to do this, that's good inventive thinking, but this is not so easy a problem to solve using DSC. It's a chicken-and-egg scenario. DSC can't do this for you because it uses the DSC Resources present on the machine to validate that it can execute the incoming DSC configuration you are pushing to it. It parses the MOF before it executes it and tries to find out if all the needed DSC Resources are present on the host. If they aren't present, then it exits with an error.

When copying DSC Resources, you will have to deal with the normal file copying problems of which transfer method to use (network or SMB shares, credentials, and so on). If you are copying new DSC Resources, then you may have to deal with different versions. Each DSC Resource comes with version information in its manifest file, but may include or remove files at its own discretion. A blind file copy will not know to remove files or deal with file renames, among other possible version scenarios. Using PackageManagement (as described in Chapter 4, DSC Resources) or a file-sync tool will help alleviate this issue somewhat, but at the same time introduces steps you have to perform on the remote target nodes before you can push DSC configurations to them. This means setup steps that you have to either script or manually follow, determine drift, and so on. Dealing with this via scripting (deleting if present, reading version files, and so on) adds more complexity to your deployments and makes you have to do the work of detecting drift, when you started out having DSC do this for you.

This is somewhat alleviated in DSC v5, where different DSC Resource versions can coexist side-by-side. Details of how this works are still considered experimental, so whether this will help in pushing DSC configurations or only help Pull Server scenarios remains to be seen.

The only way to cheat and accomplish this using DSC is to have two separate DSC configuration script files. One copies the DSC Resources, and the other contains the real manifest, but the same problems above apply here. In WMF 5, a potential solution to this problem exists. You can use a DSC Pull Server to distribute DSC Resources while still pushing DSC configurations directly to the target nodes.

With all these problems, it is evident that this is not meant to be a scalable long-term operation for you to perform yourself on many thousands of hosts, and that a pull server was meant to handle this for you.