通过Pull服务器部署Resource

  有两种把新的Resource部署到各个节点上去的方式：手动的，或者通过一个pull服务器。手动的方式明显在针对很多台节点机器是十分耗时的，尽管你也可能使用像系统中心配置管理器（System Center Configuration Manager）来自动化这个过程。你不能真正的用DSC本身来实现部署Resource。虽然File这个Resource可以处理这一点，但是你却不能够在你确认它们存在目标节点之前使用这个新的Resource。因此你不能写一个拷贝Resource并且尝试使用它的配置脚本，即使你让它分离开来。

  微软一开始是期望你使用pull模式的，因为节点可以找出它们差那些Resource然后从pull服务器那边把它们拷贝过来。

  当你创建一个pull服务器的时候，你制定Resource（module）将会放在哪儿的路径。比如，在我们创建基于HTTP（S）的pull服务器时，我们使用这个路径：

ModulePath   = "$env:PROGRAMFILES\WindowsPowerShell\DscService\Modules"

  这里针对部署到pull服务器上的模块需要有个特定的命名约定。首先，这整个模块必须被zip压缩。它的文件名必须以ModuleNamevesion.zip这样的格式。你还必须要使用_New-Checksum来创建一个对应的名为ModuleName_version.zip.checksum的校验文件。这两个文件都必须放在pull 服务器的模块路径(ModulePath)下。

  当你创建一个要使用到pull服务器上的模块的配置脚本时，你必须确认这个MOF文件包含这个模块的名字和版本号码。比如说，这个MOF文件摘录清楚的显示了PSDesiredStateConfiguration模块下版本为1.0的WindowsFeature这个Resource：

Instance of MSFT_RoleResource as $MSFT_RoleResource1ref
{
  ResourceID = "[WindowsFeature]Backup";
  ModuleName = "PSDesiredStateConfiguration";
  ModuleVersion = "1.0";
};

  注意，有一些关于在使用DSC时ZIP文件不工作的记录（见 http://connect.microsoft.com/PowerShell/feedback/details/804230/lcm-fails-to-extract-module-zipped-with-system-io-compression-zipfile），这是因为它们没有使用.NET框架的System.IO.Compression.ZipFile.CreateFromDirectory() 方法。要小心哦！

  DSC将会尝试去使用Resource的最新版本（特定情况下，在Resource所以在的module里只有一个版本；一个模块下的每个Resource被认为和模块拥有同样的版本号）。因此，当DSC拉回一个配置的时候，它会检查这个pull服务器上被这个配置使用了的任何Resource的新的版本。如果你想，你也可以配置LCM不去下载更新版本的模块。在配置的时候，你也可以在使用Import-DscResource时制定一个版本号；如果你这么做的话，那DSC就会寻找，并且只使用这个特定的版本。