Azure Policy 的常规评估机制只读取资源在 Azure Resource Manager 层面暴露的属性，例如虚拟机的 SKU、磁盘加密状态、网络接口配置。一旦审核目标深入到操作系统内部，比如某个注册表键值是否符合基线、Telnet 服务是否被禁用、SSH 是否关闭了密码登录，传统的策略定义就无能为力了。来宾配置正是为填补这个空白而设计的机制，它把 Azure Policy 的合规评估能力从资源平面延伸到操作系统内部，让管理员用同一套策略框架同时管理云端虚拟机与本地混合服务器的内部配置。
一、来宾配置审核的运行原理
来宾配置的核心思路是在目标机器内部安装一个轻量代理，由代理执行实际的检查动作。当你在管理平面分配一条来宾配置类型的策略后，Azure Policy 首先通过 DeployIfNotExists 效果向虚拟机推送两个组件：来宾配置扩展和系统分配的托管标识。扩展落地之后，代理会定期从策略服务拉取配置包，配置包本质上是一个经过签名的 zip 压缩文件，里面封装了 DSC 期望状态配置文档以及执行检查所需的全部依赖资源。
代理在机器内部执行检查后，把结果写入本地状态文件，并通过来宾配置服务上报到 Azure Policy 的评估管道。整个链路对网络有一定要求，虚拟机必须能够访问来宾配置服务的区域终结点，否则状态无法回传，合规记录会停留在未就绪状态。评估周期默认为二十四小时一次，机器重启或代理服务重启时也会触发一次即时评估，这个特性在排查问题时非常实用。另外，新版本服务目录中该功能已经演进为机器配置服务，但策略定义里的类别名称仍然叫来宾配置，两者指的是同一套机制。
需要特别说明的是，来宾配置审核默认只读不写，也就是只报告不合规项而不修改机器内部设置。如果希望策略自动修复问题，需要使用带有 Set 参数的配置包，并配合同时包含部署与审核两条定义的完整计划，这种模式对应来宾配置的 ApplyAndMonitor 机制，适合对配置漂移零容忍的环境。
二、启用来宾配置的前置条件与部署计划
直接分配一条来宾配置审核策略，往往会发现机器状态显示为未就绪，原因在于前置组件尚未安装。正确做法是先分配名为部署来宾配置策略前置条件的内置计划，它会为作用域内的虚拟机批量完成三件事：安装来宾配置扩展、启用系统托管标识、赋予托管标识读取配置包所需的权限。计划内部包含针对 Windows 与 Linux 的多个定义，分配一次即可覆盖两类平台。
托管标识是整个机制的安全基石。来宾配置代理需要用它访问存储配置包的存储账户、向策略服务上报状态，全程不需要在虚拟机内部保存任何长期凭证。因此在网络层面，除了放行来宾配置服务的终结点，还要确保托管标识的认证流量没有被防火墙拦截。对于启用了 Azure Arc 的本地服务器，接入方式完全一致，Arc 代理会把来宾配置扩展桥接到非 Azure 机器上，让本地机房的服务器也纳入同一套合规体系。
下面的示例演示了如何用 Azure PowerShell 为资源组分配前置计划并指定系统托管标识：
# 获取内置的前置条件部署计划
$SetDef = Get-AzPolicySetDefinition | Where-Object {
$_.Properties.DisplayName -like 'Deploy prerequisites to enable Guest Configuration*'
}
# 为资源组分配计划，并创建系统托管标识
$Assignment = New-AzPolicyAssignment -Name 'deploy-gc-prereqs' `
-DisplayName '部署来宾配置前置条件' `
-PolicySetDefinition $SetDef `
-Scope '/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/audit-rg' `
-IdentityType 'SystemAssigned'
# 为托管标识分配角色，使其具备推送扩展的权限
New-AzRoleAssignment -ObjectId $Assignment.Identity.PrincipalId `
-RoleDefinitionName 'Contributor' `
-Scope '/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/audit-rg'
分配完成后，可以在目标虚拟机的扩展页面看到 ConfigurationforWindows 或 ConfigurationforLinux 扩展出现在已安装列表中，这标志着前置条件部署成功，机器已经准备好接收具体的审核策略。
三、使用内置来宾配置策略进行审核
前置条件就绪后，就可以挑选具体的审核定义了。在门户的策略定义页面搜索来宾配置关键词，会出现上百条内置定义，覆盖操作系统基线、安全设置、应用程序配置等多个类别。常见的例子包括审核未设置密码过期时间的 Windows 机器、审核允许空密码登录的 Linux 机器、审核未安装指定监视代理的机器等。这些定义的效果都是 AuditIfNotExists，也就是在机器内部状态与期望不符时标记为不合规。
分配内置定义时要注意作用域与排除项的搭配。来宾配置的评估发生在单机层面，把策略分配到管理组可以一次性覆盖大量虚拟机，而对不适用该操作系统的机器，策略会自动跳过，不会产生误报。评估结果通常在三十分钟内开始陆续回传，完整覆盖一个大规模环境可能需要等待一个完整周期。
如果希望立即查看某台机器的合规状态而不等待周期触发，可以调用 REST 接口发起按需评估：
# 触发单台虚拟机的来宾配置按需评估 az rest --method POST \ --url "https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/audit-rg/providers/Microsoft.Compute/virtualMachines/webvm01/providers/Microsoft.GuestConfiguration/guestConfigurationAssignments/AuditWindowsPasswordExpiry?api-version=2020-06-25"
返回结果中的 complianceStatus 字段会给出 Compliant 或 NonCompliant 的结论，配合 resources 数组还能看到具体哪一项检查失败，便于把问题定位到确切的配置偏差。
四、自定义来宾配置包的制作流程
内置定义虽然丰富，但企业内部往往有个性化的基线要求，例如要求所有业务虚拟机安装自研监控客户端、禁止特定端口的服务运行。这时就需要制作自定义来宾配置包。整个流程分为四步：编写 DSC 配置文档、打包、签名、上传存储并创建自定义策略定义。
打包使用 PowerShell 库中的 GuestConfiguration 模块，下面的示例演示了从配置文档生成审核包并完成签名的完整过程：
# 安装来宾配置打包模块
Install-Module GuestConfiguration -Force
# 编译生成 MOF 配置文档
. ./AuditServiceBaseline.ps1
AuditServiceBaseline -OutputPath ./Output
# 将 MOF 与依赖打包为来宾配置包
$Package = New-GuestConfigurationPackage `
-Name 'AuditTelnetService' `
-Configuration './Output/AuditServiceBaseline.mof' `
-Type 'Audit'
# 使用代码签名证书对包进行签名
$Cert = Get-ChildItem -Path Cert:\CurrentUser\My |
Where-Object { $_.Subject -eq 'CN=GuestConfigCodeSigning' }
Protect-GuestConfigurationPackage -Path $Package.Path -Certificate $Cert
签名是强制的安全要求，未签名的包会被代理拒绝执行，目的是防止配置包在传输或存储过程中被篡改。签名证书的公钥需要导出并写入策略定义的配置参数，代理在解压执行前会用公钥校验签名。打包完成后把 zip 文件上传到虚拟机可访问的存储账户，记录文件的哈希值，再基于内置的来宾配置模板创建策略定义，把存储地址与哈希填入参数即可生效。
值得注意的是，自定义包中的 DSC 资源必须兼容期望状态配置的执行环境，Windows 机器使用 PowerShell DSC，Linux 机器则通过 PowerShell 的跨平台实现执行，编写配置时要留意两个平台在资源名称与参数上的差异，必要时分别为两类平台制作独立的配置包。
五、常见问题与排查思路
来宾配置链路涉及管理平面与机器内部两个层面，排障时建议先分层定位。第一步检查虚拟机扩展状态，如果 ConfigurationforWindows 或 ConfigurationforLinux 扩展显示创建失败，问题多半出在托管标识缺失或权限不足，重新分配前置计划通常可以解决。第二步查看代理日志，Windows 机器的日志位于 C:\ProgramData\GuestConfig 目录，Linux 机器位于 /var/lib/GuestConfig 目录，日志中记录了配置包下载、签名校验、执行结果的完整过程。
下表汇总了几个高频故障及其处理方式，可以作为快速排查的索引：
| 故障现象 | 常见原因 | 处理方式 |
|---|---|---|
| 扩展创建失败 | 托管标识缺失或角色未授予 | 重新分配前置条件部署计划 |
| 合规状态长期未就绪 | 网络拦截服务终结点或存储账户防火墙限制 | 放行来宾配置终结点与存储访问 |
| 配置包执行被拒绝 | 签名校验失败或哈希不匹配 | 重新签名并更新策略定义中的哈希值 |
| 结果回传延迟 | 评估周期尚未到达 | 调用按需评估接口或重启代理服务 |
合规数据时效性也是容易踩坑的点。来宾配置的评估周期为二十四小时，机器内部配置被人为改动后，管理平面最长需要一天才能反映出来。对时效敏感的场景可以结合 Azure Monitor 的资源日志监控来宾配置状态变更事件，做到分钟级的偏差告警，把静态审核升级为动态监控，进一步压实操作系统的合规底线。
Azure Policy来宾配置合规审核修改时间：2026-10-03 15:34:56