我之前也碰到过类似的坑，本地PowerShell跑起来一切正常，到Jenkins Pipeline里就掉链子，核心原因还是Jenkins的运行上下文和mstsc的启动机制在服务环境下有特殊差异，给你拆解下可能的原因和解决办法：

可能的问题根源 #

• Jenkins服务账户的权限限制：默认Jenkins作为Windows服务运行时用的是Local System账户，这个账户没有交互式桌面权限。当你启动mstsc时，系统会在非交互式会话（通常是会话0）里创建进程，而mstsc在这种环境下大概率会启动一个子进程来处理连接，导致Start-Process返回的是父进程ID，可父进程很快就退出了，你拿到的自然是无效的PID。
• mstsc的特殊启动逻辑：mstsc本身有进程复用或代理启动的机制，比如检测到已有合适实例时会复用进程，或者在非交互式环境下会通过另一个进程实例加载rdp配置，这就直接导致返回的PID和实际运行的进程不匹配。

可行的解决办法 #

1. 调整Jenkins服务的运行账户（推荐方案） #

把Jenkins服务的运行账户改成有交互式权限的本地管理员或域账户：

• 打开Windows服务管理器，找到Jenkins服务右键选「属性」
• 切换到「登录」标签页，选择「此账户」，输入有权限的账户信息
• 勾选「允许服务与桌面交互」（Windows Server 2012及以后版本可能需要额外配置远程桌面权限，但这个选项能让服务账户访问桌面会话）
• 重启Jenkins服务后再测试

2. 通过命令行参数筛选正确进程（无需改动服务配置） #

如果不想调整服务账户，可以放弃依赖Start-Process返回的PID，转而通过查询进程的命令行参数精准定位目标mstsc进程：

# 启动mstsc连接
Start-Process "$env:windir\system32\mstsc.exe" -ArgumentList "C:\Users\AzureUser\Desktop\MyRDP.rdp /h:900 /w:1600" -WindowStyle Minimized

# 等待几秒让进程完全启动（时间可根据实际情况调整）
Start-Sleep -Seconds 2

# 查询带有目标rdp文件路径的mstsc进程
$targetProcess = Get-CimInstance Win32_Process | Where-Object {
    $_.Name -eq 'mstsc.exe' -and $_.CommandLine -like '*MyRDP.rdp*'
}

if ($targetProcess) {
    Write-Host "实际运行的进程ID: $($targetProcess.ProcessId)"
} else {
    Write-Host "未找到匹配的mstsc进程"
}

这个方法的核心是通过Win32_Process类获取进程的命令行参数，精准定位到加载了你指定rdp文件的mstsc进程，彻底避开PID不匹配的问题。

3. 确认64位PowerShell环境 #

虽然你提到试过Invoke-Command，但可以再验证下Jenkins里的PowerShell是否是64位：

Write-Host "PowerShell架构: $([Environment]::Is64BitProcess)"

如果返回False，可以在Jenkins Pipeline里直接指定64位PowerShell路径：

pipeline {
    agent any
    stages {
        stage('Test RDP') {
            steps {
                powershell '''
                    & "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe" -Command {
                        # 这里放入你的RDP启动脚本
                    }
                '''
            }
        }
    }
}

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