VSTS AzureVMFileCopy任务连接目标机器时权限被拒求助

看起来你在配置VSTS（现在的Azure DevOps）发布流程里的AzureVMFileCopy任务时碰到了权限拒绝的问题，我之前也踩过类似的坑，结合你已经完成的操作，给你几个针对性的排查和解决方向：

• 确认目标VM用户的权限等级
  一定要确保你用来连接的账号是目标VM的本地管理员组成员——WinRM远程执行操作需要较高的权限支撑。你可以在目标VM上打开PowerShell，运行net localgroup administrators查看管理员组的成员列表，确认你的账号在其中。如果是域账号，还要确保该域账号被赋予了目标VM的管理员权限。

• 验证WinRM HTTPS连接的有效性
  先在能访问目标VM的机器上手动测试WinRM连接，排除基础配置问题：

  1. 运行Test-WSMan -ComputerName <VM_IP> -Port 5986 -UseSSL，如果能返回WinRM的版本、协议等信息，说明HTTPS监听器配置正常；
  2. 如果上面的命令报错，试试跳过证书验证测试会话：

     $sessionOptions = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck
     Enter-PSSession -ComputerName <VM_IP> -Port 5986 -UseSSL -Credential (Get-Credential) -SessionOption $sessionOptions
     

     如果这个能成功建立远程会话，说明VSTS任务里需要开启跳过证书验证的选项（在任务的高级设置里找这个选项并勾选）。

• 检查VSTS代理的运行身份

  • 如果你用的是自托管代理：默认情况下代理可能用本地系统账户运行，这个账户跨机器访问时会有权限限制。建议把代理服务的运行账号改成拥有目标VM管理员权限的本地/域账号。
  • 如果你用的是微软托管代理：别忘了检查目标VM的NSG（网络安全组），确保它允许微软托管代理的IP段访问5986端口——虽然你开了VM本地防火墙，但NSG的规则优先级更高。

• 优化用户名格式的使用

  • 本地账号优先用.\username或者<VM主机名>\username的格式，避免系统对账号归属产生歧义；
  • 域账号必须用完整域名\用户名的格式，比如CONTOSO.COM\john_doe，不要用短域名缩写。

• 查看复制先决条件的安装日志
  你已经启用了“复制先决条件”选项，这个功能会自动在目标VM上安装必要组件，但如果权限不足，安装可能会静默失败。你可以去目标VM的C:\Windows\Temp目录下找AzureVMCopy.log之类的日志文件，里面会记录安装过程中的错误，能帮你定位具体的权限问题。

• 检查WinRM服务的权限配置
  在目标VM上运行winrm get winrm/config/service/auth，确认Basic和Negotiate这两个认证方式是启用的。如果没有启用，用下面的命令开启：

  winrm set winrm/config/service/auth @{Basic="true"}
  winrm set winrm/config/service/auth @{Negotiate="true"}
  

  注意：Basic认证在HTTPS下是安全的，Negotiate则更适配域账号的认证场景。

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