通过psexec强制启用Winrm管理
在 wmic 被砍、WinRM 默认未启用、且 psexec 遭遇远程登录策略死锁 的极端安全策略下，我们手中还剩最后一张王牌：远程修改目标机注册表，强行激活 WinRM（Windows 远程管理）服务，然后再用 PowerShell 瞬间触发脚本。
Windows 的远程注册表服务（Remote Registry）或通过最基础的 IPC$ SMB 管道修改注册表通常是默认允许管理员操作的。我们可以利用这一点，“隔空”为目标机接通 WinRM 的任督二脉。
请在你的控制端计算机（CMD 窗口）中，依次复制并执行以下这组命令，即可彻底打破僵局：
🛠️ 终极三步走：远程强启 WinRM 并触发升级
第一步：建立最基础的管道连接（获取写入注册表权限）
net use \\F202000903\ipc$ "管理员密码" /user:.\administrator
请谨慎使用此类代码。
第二步：远程写入注册表，强制开启并配置 WinRM（完全静默）
保持上面的 CMD 窗口别关，直接把下面这 4 行命令一行行粘贴进去执行：
:: 1. 允许本地账户远程管理（解开 Token 限制）
reg add "\\F202000903\HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
:: 2. 强制将 WinRM 服务启动类型改为“自动”
reg add "\\F202000903\HKLM\SYSTEM\CurrentControlSet\Services\WinRM" /v Start /t REG_DWORD /d 2 /f
:: 3. 快速开启 WinRM 基础监听（允许 HTTP 5985 端口通信）
reg add "\\F202000903\HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Service" /v AllowUnencrypted /t REG_DWORD /d 1 /f
:: 4. 远程命令目标机立即启动 WinRM 服务（利用 sc 绕过 wmic/winrm 限制）
sc \\F202000903 start WinRM
第三步：在控制端打开 PowerShell 触发脚本
此时目标机的 WinRM 已经强行在后台复活了。请立刻在控制端打开 PowerShell，执行触发命令：
powershell
# 1. 创建凭据
$password = ConvertTo-SecureString "Cmpw2026#chg$08" -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential(".\localroot", $password)
# 2. 绕过连接限制，直接用 CIM（WMI Over WinRM）隐形触发本地脚本
$opt = New-CimSessionOption -Protocol Dcom
$session = New-CimSession -ComputerName F202000903 -Credential $cred -SessionOption $opt
Invoke-CimMethod -CimSession $session -ClassName Win32_Process -MethodName Create -Arguments @{ CommandLine = "cmd.exe /c D:\Temp\local_upgrade.bat" }
这样操作会对正常登录的用户产生影响吗？
完全没有影响。
- 远程写入注册表、通过
sc启动服务全部在底层进行，当前正在办公的用户看不起任何弹窗和提示。 - WinRM 启动后占用的系统资源极小（几 MB 内存），用户绝无卡顿感。
- PowerShell 触发
local_upgrade.bat后，升级进程将在独立的Session 0（系统隔离会话）中隐形起跑。
请在控制端 CMD 中尝试执行 第二步的注册表和服务启动命令。只要 reg add 提示“操作成功完成”且 sc 提示服务进入 START_PENDING 或 RUNNING 状态，请立刻去第三步用 PowerShell 轰出最后一击！
提示 “错误: 不支持该请求”（Request not supported），通常是因为目标计算机上的 Task Scheduler（计划任务服务）禁止了通过网络进行远程创建，或者某些安全组策略彻底锁死了远程 schtasks 的调用。
既然如此，我们不需要再死磕计划任务和 WinRM 了。由于你已经在目标机的同一目录下放好了脚本，我们可以利用最基础、兼容性最强的 sc 命令（Windows 服务控制管理器） 来完成“隔空”触发！
sc 是 Windows 极其底层的核心工具，由于它走的是基础的 RPC 管道，几乎永远不会被禁用，且没有 schtasks 或 wmic 的各种复杂限制。
请在你的控制端 PowerShell 中，直接运行以下三行命令：
powershell
# 1. 远程把你的升级脚本注册为一个临时系统服务 (名称为 WinUpgrade)
sc.exe \\F202000903 create WinUpgrade binPath= "cmd.exe /c D:\Temp\local_upgrade.bat" start= demand type= own
# 2. 远程启动这个服务（这会在目标机本地瞬间以 SYSTEM 最高权限触发你的脚本）
sc.exe \\F202000903 start WinUpgrade
# 3. 触发成功后，远程删除这个临时服务名（不影响已经在后台运行的升级进程）
sc.exe \\F202000903 delete WinUpgrade
请谨慎使用此类代码。
关键注意事项（必看）
binPath=和start=后面必须有一个空格（例如binPath= "..."），这是sc命令的固有语法格式，缺少空格会报错。- 当你运行第二步
sc start时，控制端屏幕可能会弹出一个 “错误 1053: 服务没有及时响应启动或控制请求”。不用慌，这代表成功了！- 原因：因为你的批处理脚本是一个普通的脚本，不是标准的 Windows 服务程序。当它在后台拉起
setup.exe后，它不会向 Windows 回传“服务已启动”的信号。但这完全不影响你的local_upgrade.bat已经在目标机本地完美隐形起跑！
- 原因：因为你的批处理脚本是一个普通的脚本，不是标准的 Windows 服务程序。当它在后台拉起
请尝试在控制端连着执行这三行命令。如果第二步顺利把命令轰了出去，说明单机更新已经彻底打响！
如果执行完后，你想确认目标机后台的 setup.exe 到底有没有在疯狂跑进度（复制文件），我可以用原生的底层网络连接（如注册表网络检查或文件体积变化）帮你写一个监控指令。需要我提供吗？
