编译配置和 Start-DscConfiguration 分别做了什么？

编译把配置和资源声明转换成 MOF，不改系统；Start-DscConfiguration 读取 MOF，调用资源的 Test/Set 把目标机收敛到声明状态。

为什么含凭据的 MOF 需要额外保护？

MOF 可能包含可还原的密码或凭据材料，读取该文件的人可能据此提权；要用证书加密、限制目录 ACL，或改用无需写密码的身份。

从 5.1 迁移到 7.x 时，哪些 DSC 能力不能直接沿用？

5.1 的 Configuration 关键字、LCM、拉取服务和 Start-DscConfiguration 工作流不能直接用在 7.x 的 DSC v2 上；要改用资源调用或独立的 DSC v3 配置。

系统学习 学习路径总入口：先选领域，再建立模型，最后用故障演练验证

版本信息最后核对：2026-10-25

用声明式配置描述目标状态，让系统自动检查并收敛到该状态

适用场景

需要把服务器角色、文件、注册表、服务、功能安装等状态写成可审查、可重复的配置时使用。它适合批量初始化、环境一致性检查和配置漂移检测，不适合临时改一台机器上的单个设置。

DSC 是“声明目标状态”，不是“执行一串命令”。同一份配置重复应用应当得到相同结果；如果操作本身不可重入，应先改造成资源或脚本资源。

核心概念

资源与状态：DSC 资源实现 Get、Test、Set 三个动作，分别读取现状、判断是否符合、执行收敛；常见资源有 File、Service、WindowsFeature、Registry、Script。
配置与 MOF：Configuration 块描述节点和资源，编译后生成 MOF；编译本身不改系统，Start-DscConfiguration 才应用。
LCM 与刷新：Windows PowerShell 5.1 的 Local Configuration Manager 管理刷新模式、配置模式、重启和拉取频率；拉取服务需要安装 DSC-Service 功能，不是默认就在运行。
推送与拉取：推送由管理端把 MOF 推到目标机；拉取由目标机按配置 ID 从拉取服务获取。两者都依赖 LCM 的状态和凭据配置。
漂移检测与凭据：Test-DscConfiguration 只检查不修改，Get-DscConfiguration 读取已应用值。配置含 PSCredential 时，MOF 可能保存可还原的凭据，需要证书加密或托管身份。

5.1 与 7.x 差异

5.1 内置完整 DSC：Configuration 关键字、LCM、推送和拉取服务、Start-DscConfiguration 都在系统里；拉取服务要额外安装角色功能。
PowerShell 7.x 的 DSC 能力由 PSDesiredStateConfiguration 2.x 模块提供，从 PowerShell Gallery 单独安装；它没有 5.1 的 LCM 和拉取服务，主要供 Azure Machine Configuration 使用，File 等内置资源已被移除。
DSC v3 是独立的 dsc 命令行工具，使用 YAML/JSON 配置，不依赖 5.1 的 LCM；不要把 5.1 的 Configuration 脚本直接当成 DSC v3 配置。

常用操作

# 1. 查看本机可用的 DSC 资源
PS C:\> Get-DscResource | Sort-Object Name | Select-Object Name, Module, Version

# 2. 配置定义 WebServer.ps1；编译只生成 MOF，不改系统
Configuration WebServer {
    Import-DscResource -ModuleName PSDesiredStateConfiguration
    Node 'localhost' {
        WindowsFeature IIS { Name = 'Web-Server'; Ensure = 'Present' }
        File Site { DestinationPath = 'C:\inetpub\wwwroot\index.html'; Contents = 'ok'; Ensure = 'Present' }
    }
}
PS C:\> . .\WebServer.ps1
PS C:\> WebServer -OutputPath C:\DSC\WebServer

# 3. 先测试再应用；应用会真实修改目标机
PS C:\> Test-DscConfiguration -Path C:\DSC\WebServer -Detailed
PS C:\> Start-DscConfiguration -Path C:\DSC\WebServer -Wait -Verbose
PS C:\> Get-DscConfiguration

# 4. 日常检查配置漂移和 LCM 设置
PS C:\> Test-DscConfiguration -Detailed
PS C:\> Get-DscLocalConfigurationManager

# 5. 远程推送需要 WinRM 和管理员权限
PS C:\> Start-DscConfiguration -Path C:\DSC\WebServer -ComputerName SRV01 -Credential (Get-Credential) -Wait

# 6. PowerShell 7.x 安装 DSC 2.x 和资源模块，再调用单个资源
PS C:\> Install-Module PSDesiredStateConfiguration -MaximumVersion 2.99 -Scope CurrentUser; Install-Module PSDscResources -Scope CurrentUser
PS C:\> Invoke-DscResource -ModuleName PSDscResources -Name Service -Method Test -Property @{ Name = 'Spooler'; State = 'Running' }

易错点

把编译当应用：WebServer -OutputPath 只生成 MOF；不执行 Start-DscConfiguration，系统不会有任何变化。
应用前不测试：DSC 会真实修改服务、功能和文件，可能触发重启。先在一次性虚拟机验证，至少先跑 Test-DscConfiguration。
修改了配置却仍应用旧 MOF，是最常见的“怎么没生效”。重新编译并确认输出目录时间戳，再检查 LCM 指向的路径。
含凭据的 MOF 默认可能以可还原形式保存密码。不要把输出目录放在共享盘；使用证书加密，或改用服务账户、gMSA 等不需要写密码的方式。
资源顺序不能靠书写顺序猜测，跨资源依赖要用 DependsOn；涉及重启时更要明确先后和等待行为。
拉取模式不是“自动持续修复”：刷新频率、配置 ID、校验和、LCM 状态任一不对都会停在旧配置；先看事件日志和 LCM 输出。
5.1 的 Configuration 关键字和 LCM 在 7.x 的 DSC v2 中不可用；照抄旧脚本会直接解析失败，先确认目标端是哪套 DSC。

参考链接

读完自测

合上页面，先回答，再展开对照。

编译配置和 Start-DscConfiguration 分别做了什么？
为什么含凭据的 MOF 需要额外保护？
从 5.1 迁移到 7.x 时，哪些 DSC 能力不能直接沿用？

答案

编译把配置和资源声明转换成 MOF，不改系统；Start-DscConfiguration 读取 MOF，调用资源的 Test/Set 把目标机收敛到声明状态。
MOF 可能包含可还原的密码或凭据材料，读取该文件的人可能据此提权；要用证书加密、限制目录 ACL，或改用无需写密码的身份。
5.1 的 Configuration 关键字、LCM、拉取服务和 Start-DscConfiguration 工作流不能直接用在 7.x 的 DSC v2 上；要改用资源调用或独立的 DSC v3 配置。