对目标电脑进行配置以使用DSC Pull服务器是一个非常简单的过程，但是如果是第一次接触这些概念，有可能会有一些困惑。在这篇文章中，我将展示如何在目标客户端上配置Pull服务器，然后进行简单的配置。希望你能特别注意目标客户端的Pull配置，以及其和存储在Pull服务器上的配置之间的关系。许多IT专家甚至都不熟悉这个概念，在使用过程中容易犯错。

如果你看过这个系列文章之前的部分，可以使用自己的测试虚拟机进行实验。

在目标客户端上配置Pull服务器

理想状态配置（DSC）能够完成比你想象中更多的事情。虽然我关注的领域是Windows服务器，但是我想要指出的是在Linux服务器、Windows客户端和兼容的交换机或者其他设备上也可以轻松完成这些设置。这意味着DSC客户端可能不是活动目录域中的对象。这表明我们不能通过应用组策略来通知客户端使用哪个Pull服务器，以及获取哪个配置文件来完成本地理想状态设定。

我们通过确保每个客户端都拥有一个单独的、能够理解DSC的客户端软件来解决这个问题。在这个实例当中，我们使用Windows Management Framework 4（WMF 4）。每种客户端都有本地配置管理器（LCM），能够从指定的Pull服务器获取其配置文件。

你可以使用Get-DSCLocalConfigurationManager命令来查看当前的LCM配置。

上面的脚本中需要关注的一些属性：

• 配置ID：这一项现在是空的，但是将会被Pull服务器上相匹配的配置ID所取代。这也是客户端申请和应用正确的配置的方式。
• 配置模式：默认为ApplyandMonitor，应用配置。但是，它会允许一些偏差，或者其他人修改配置。通常需要将这一项改为ApplyAndAutoCorrect以防止其他管理员进行修改。
• 刷新模式：当前设定为PUSH，目标客户端正在等待我们下发配置，而不是尝试主动从Pull服务器获取配置。我们将会下发一个新的LCM配置，将配置调整为主动获取指定Pull服务器的URL。

还有一些其他的重要配置，但是了解这些配置已经足够进行我们下面的实验。

我需要下发一个LCM配置来更改当前属性，以便客户端开始从Pull服务器获取配置。

从第3到第11行定义了两个非常重要的、保证配置能够正常运行的强制参数。第一个是$ComputerName，指定了需要使用这个脚本进行LCM配置的客户端。第二个是$guid，这个参数将会在第20行分配给theConfigurationID ，其定义了从Pull服务器中获取哪个配置文件。Pull服务器上的Microsoft Operations Framework （MOF）文件必须和全局唯一标示符（GUID）名称一致。我知道这个规定听起来有些奇怪，但是下面我将会解释为什么需要这样做。

脚本中的结点定义部分有很多重要信息，但是需要重点关注以下部分：

• 第6行将ConfigurationMode设定为ApplyAndAutoCorrect。正如我之前所说的那样，这可以防止其他管理员对配置进行更改。
• 第21行将RefreshMode 设定为Pull，这样LCM将会开始连接Pull服务器进行后续配置。
• 第22行限定了客户端应该使用的获取模式类型。在这个实例中，将HTTP(S) Pull服务器设定为WebDownloadManager 。
• 第23到25行设定了Pull服务器的URL位置。

为了运行上面的配置，我还在这个脚本中添加了一些额外的配置。这些将会出现在强制参数当中，将LCM连接到Pull服务器。

• 第31行规定了接收新LCM配置的客户端列表。在这个例子中，我使用了一台名为S1的测试虚拟机，但是其同时也能够作为一个客户端列表。
• 第34行为ConfigurationID生成了一个GUID。需要注意的是这个数字需要是Pull服务器上配置文件的名字。
• 第40行为客户端的LCM执行了Set cmdlet。所有的客户端都会使用特定GUID来访问Pull服务器。

在运行脚本之后，检查客户端电脑中的Get-DSCLocalConfigurationManager来查看相关变化。

在第二部分《图文教程：如何在目标客户端上配置Pull服务器（下）》中，我将为大家介绍更多的客户端配置。