Updated deploying-resources-via-pull-servers.txt

mattypenny authored
revision 3e8f835e6a90f9c1798068358ee2e061c5ce2337
deploying-resources-via-pull-servers
# Deploying Resources via Pull Servers

Write here...
There are two ways to deploy new resources to your nodes: manually, or via a pull server. Manually is obviously time-consuming across a large number of nodes, although you could potentially use software like System Center Configuration Manager to automate that process. You can't really use DSC itself to deploy resources. While the **File** resource could handle it, you couldn't actually _use_ the new resources in a configuration until you were sure they existed on the target nodes. So you couldn't write a configuration that copied a resource _and_ tried to use it - even if you set dependencies.

Microsoft basically expects you to use pull mode, since nodes can figure out what resources they're missing and copy them from the pull server.

When you create a pull server, you specify the path where resources (modules) will be located. In our example of creating an HTTP(S) pull server, for example, we used this path:
````
ModulePath = "$env:PROGRAMFILES\WindowsPowerShell\DscService\Modules"
````
There's a specific naming convention required for modules deployed to a pull server. First, the entire module must be zipped. The filename must be in the form _ModuleName\_version_.zip. You must use **New-DscChecksum** to create a corresponding checksum file named _ModuleName\_version_.zip.checksum. Both files must be located in the pull server's **ModulePath**.

When you create a configuration that uses a module from the pull server, you have to ensure that the MOF contains the module's name and version number. For example, this MOF excerpt clearly indicates that the **WindowsFeature** resource lives in version 1.0 of the PSDesiredStateConfiguration module:
````
Instance of MSFT\_RoleResource as $MSFT\_RoleResource1ref

{
ResourceID = "[WindowsFeature]Backup";
ModuleName = "PSDesiredStateConfiguration";
ModuleVersion = "1.0";
};
````
Note that there are reports (see [http://connect.microsoft.com/PowerShell/feedback/details/804230/lcm-fails-to-extract-module-zipped-with-system-io-compression-zipfile](http://connect.microsoft.com/PowerShell/feedback/details/804230/lcm-fails-to-extract-module-zipped-with-system-io-compression-zipfile)) of ZIP files not working with DSC if they were created by using the .NET Framework's System.IO.Compression.ZipFile.CreateFromDirectory() method. Be aware.


Note that DSC will always try to use the newest version of a resource (technically, only the module in which a resource lives has a version; every resource in that module is considered to be the same version number as the module itself). So, when DSC pulls a configuration, it'll check the pull server for new versions of any resources used by that configuration. You can configure the LCM to _not_ download newer modules, if desired. In a configuration, you can also specify a version number when using **Import-DscResource** ; if you do so, then DSC will look for, and only use, the specified version.