使用PowerShell脚本部署MSI包时SQL连接失败问题排查

以下是导致该问题的常见原因和对应的排查/解决方法：

1. Kerberos双跳限制（最可能原因） #

如果你的PowerShell脚本通过**远程会话（如Invoke-Command）**在目标虚拟机上执行，会触发Kerberos的双跳限制：

• 手动登录虚拟机操作时，用户身份直接在VM本地运行进程，属于单跳，身份可正常传递到SQL服务器；
• 远程脚本执行时，PowerShell会话的身份默认无法二次传递（从VM跳转至SQL服务器），MSI进程会以NT AUTHORITY\ANONYMOUS LOGON身份访问SQL，导致登录失败。

解决方法：启用CredSSP身份验证支持双跳：

1. 在本地执行脚本的机器上运行：

   Enable-WSManCredSSP -Role Client -DelegateComputer "目标虚拟机的FQDN或IP"
   

2. 在目标虚拟机上运行：

   Enable-WSManCredSSP -Role Server
   

3. 执行远程命令时指定CredSSP认证：

   Invoke-Command -ComputerName "目标VM" -Authentication CredSSP -Credential $yourCred -ScriptBlock {
       msiexec.exe /i "C:\path\to\your.msi" /qn YOUR_PARAMS=VALUE
   }
   

2. MSI自定义动作的执行上下文问题 #

部分MSI包的自定义动作会强制以SYSTEM账户执行（而非当前用户），即便你用有权限的用户启动MSI，连接SQL的动作仍会使用SYSTEM账户。若SYSTEM账户无SQL登录权限，就会触发匿名登录错误。

排查与解决：

• 用Orca工具打开MSI包，查看CustomAction表的Type列：若值包含32（表示以SYSTEM运行），需修改该配置；
• 将自定义动作的执行上下文改为“交互式用户”（去掉Type值中的32），或给NT AUTHORITY\SYSTEM账户授予SQL服务器的登录权限。

3. 非交互式会话的身份传递限制 #

若脚本在非交互式会话（如任务计划、自动化工具）中执行，即便本地运行，Windows也会限制身份的网络传递，导致MSI无法用当前用户身份连接SQL。

解决方法：

• 确保脚本在交互式会话中执行；
• 改用本地SQL账户（在安装参数中指定SQL_AUTH而非Windows认证）绕开Windows身份传递问题。

4. PowerShell执行MSI的方式问题 #

若脚本用Start-Process启动msiexec时未正确保留用户上下文，也可能导致身份丢失：

• 避免不必要的-RunAs参数；
• 添加-Wait参数确保MSI在当前会话上下文完成：

  Start-Process msiexec.exe -ArgumentList "/i C:\path\to\app.msi /qn PARAM=VALUE" -Wait -NoNewWindow
  

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