PowerShell置备程序中Restart-Computer致Packer流水线失败如何解决

Packer 执行 PowerShell Provisioner 时全程依赖与目标虚拟机的 WinRM 持久连接，若直接在脚本内调用Restart-Computer，会瞬间中断WinRM会话，Packer默认将这种非预期的连接中断判定为Provisioner执行失败，直接终止整个构建流水线，不会主动等待虚拟机重启完成后重连。

方案1：使用Packer官方Windows重启Provisioner（优先推荐） #

不要在自定义PowerShell补丁脚本中写入重启逻辑，将补丁安装、重启动作拆分为独立的Provisioner步骤，用官方原生能力处理重启重连，稳定性最高：

• 第一个PowerShell Provisioner只负责触发SCCM补丁安装，脚本内要加循环检测逻辑，确认所有待安装补丁的安装流程全部执行完成后再退出，不要触发重启。
• 紧接补丁安装步骤后添加windows-restart Provisioner，该组件会主动向虚拟机发送重启指令，之后按配置的间隔持续轮询WinRM端口，等虚拟机完成重启、WinRM服务恢复可用后，再继续执行后续构建步骤，不会触发连接中断报错。

参考配置片段：

# 执行SCCM补丁安装
provisioner "powershell" {
  inline = [
    "C:\\build\\Trigger-SCCMPatchInstall.ps1 -WaitForInstallFinish"
  ]
  execution_policy = "Bypass"
}

# 处理虚拟机重启
provisioner "windows-restart" {
  restart_timeout = "20m" # 根据VM规格、补丁配置耗时调整，建议留30%以上冗余
  restart_check_interval = "30s"
}

# 重启后执行后续操作：验证补丁状态、执行Sysprep通用化等
provisioner "powershell" {
  inline = [
    "C:\\build\\Validate-PatchResult.ps1"
  ]
}

方案2：标记文件适配多轮重启场景 #

如果SCCM补丁部署需要多轮重启才能完成（比如部分补丁安装重启后才能检测到后续依赖补丁），可以用系统标记文件配合退出码配置实现自动循环安装重启：

• 编写补丁安装脚本：每次执行时先检测固定路径的标记文件（如C:\build\reboot_after_patch.tag），如果存在则先删除标记，再扫描剩余待安装补丁；如果存在待装补丁则触发安装，安装完成后写入标记文件，调用shutdown /r /t 10触发延迟重启，给WinRM会话留足时间返回执行成功状态，避免Packer直接判定连接中断。
• 给PowerShell Provisioner配置合法退出码列表，将补丁安装常见的重启相关成功退出码（0、3010、1077）加入校验范围，避免脚本正常触发重启时被误判为执行失败。

参考配置片段：

provisioner "powershell" {
  inline = [
    "C:\\build\\Install-PatchesWithMultiReboot.ps1"
  ]
  valid_exit_codes = [0, 3010, 1077]
  execution_policy = "Bypass"
}

# 每轮执行完补丁脚本后加重启Provisioner，配合脚本内的标记判断是否需要终止补丁安装流程
provisioner "windows-restart" {
  restart_timeout = "20m"
}

• 严禁在PowerShell脚本中直接执行Restart-Computer -Force，该命令会立刻终止所有网络连接，WinRM会话无法向Packer返回任何执行状态，必然触发构建失败。
• 重启超时时间不要设置过短，SCCM补丁安装后首次重启可能伴随系统补丁预配置、更新回滚检测等流程，2核4G规格的Azure VM可能需要10分钟以上才能完成重启并正常启动WinRM服务，超时时间不足会导致Packer提前判定失败。
• 使用Azure Compute Builder构建镜像时，记得确认WinRM配置开启winrm_use_ntlm = true，避免虚拟机重启后出现WinRM认证失败导致无法重连。

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