Azure自定义DSC策略分配报错NoComplianceReport求解决方案

一、先搞定GuestAssignment未自动创建的核心问题 #

• 检查策略定义的properties.policyRule，必须将Microsoft.Compute/virtualMachines/guestAssignments设为目标资源类型，效果需指定为DeployIfNotExists或AuditIfNotExists，否则无法触发自动创建。参考示例片段：

  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Compute/virtualMachines"
        },
        {
          "field": "Microsoft.Compute/virtualMachines/osProfile.osType",
          "equals": "Windows"
        }
      ]
    },
    "then": {
      "effect": "DeployIfNotExists",
      "details": {
        "type": "Microsoft.Compute/virtualMachines/guestAssignments",
        "roleDefinitionIds": [
          "/providers/Microsoft.Authorization/roleDefinitions/...（填入来宾配置所需权限角色ID）"
        ],
        "deployment": {
          ... // 此处需指向包含DSC配置的来宾分配模板
        }
      }
    }
  }
  

• 查看VM的扩展管理页，确认Azure Policy for Windows扩展处于运行成功状态，若异常则卸载后重新安装最新版本。
• 验证Azure Monitor Windows Agent（AMA）配置：确保AMA已正确关联Log Analytics工作区，且来宾配置的日志收集规则已启用，保证策略分配时附带的日志配置生效。

二、修复"NoComplianceReport"错误 #

• 手动触发合规扫描：进入VM的来宾配置标签页，点击"立即评估"（Windows），等待15-30分钟后查看合规状态。
• 检查策略分配权限：分配策略的主体（用户或服务主体）必须拥有Microsoft.GuestConfiguration/guestConfigurationAssignments/write权限，否则无法自动创建GuestAssignment。
• 排查日志定位问题：在Log Analytics工作区中查询GuestConfiguration表，过滤关键词NoComplianceReport，找出具体的配置错误或扫描失败原因。

三、跨Windows/Linux的通用非退役解决方案 #

放弃依赖传统DSC .mof文件的旧流程，改用来宾配置自定义策略（Azure官方推荐，支持双系统）：

• 编写合规检测脚本：Windows用PowerShell，Linux用Bash，将脚本与元数据打包成.zip格式的来宾配置包。
• 将配置包上传至Azure存储账户，生成SAS URL，在策略定义中引用该URL。
• 创建跨OS统一策略：通过osProfile.osType字段区分Windows/Linux系统，分别调用对应检测脚本，效果设置为Audit或DeployIfNotExists。

四、应急手动修复（自动分配仍失败时） #

手动创建GuestAssignment：

1. 导出策略定义中包含的来宾配置模板。
2. 使用Azure CLI命令手动部署：

   az guestconfiguration assignment create --name <分配名称> --resource-group <资源组名> --vm-name <VM名称> --guest-configuration-name <配置名称> --content-uri <配置包SAS URL> --content-hash <配置包哈希值>
   

3. 部署完成后触发合规扫描，验证状态。

内容的提问来源于stack exchange，提问作者Sonny