PowerShell cmdlet的-ComputerName参数采用何种远程技术？以Get-Service为例

一、Get-Service/ Get-EventLog的-ComputerName参数依赖的远程技术 #

Get-Service、Get-EventLog这类传统PowerShell cmdlet的-ComputerName参数，底层依赖远程过程调用（RPC），而非PowerShell Remoting（WinRM）：

• 对于Get-Service，具体调用的是服务控制管理器（SCM）的RPC接口，通过目标机器的RPC终结点映射器（默认端口135）建立连接，后续使用动态分配的端口通信。
• 对于Get-EventLog，则依赖事件日志服务的RPC接口，同样基于RPC机制。
  这类RPC调用不需要目标机器配置PowerShell Remoting，只要对应服务（SCM、Event Log）运行、RPC端口开放且调用者拥有足够权限即可生效。

二、Get-CimInstance/Get-WmiObject失效但Get-Service可用的原因 #

Get-CimInstance和Get-WmiObject默认依赖WMI（Windows Management Instrumentation），WMI底层虽也基于RPC，但有更严格的要求：

• 目标机器必须开启WMI服务（Winmgmt）；
• 需确保调用者对目标WMI命名空间（如root\cimv2）有访问权限；
• 若使用CIM会话（New-CimSession），还需目标机器开启WinRM服务并完成基础配置。
  而Get-Service依赖的SCM RPC与WMI的RPC在端口、权限校验逻辑上存在差异，因此会出现前者可用后者失效的情况。

三、验证Get-Service执行时的远程技术的方法 #

1. 用Process Monitor跟踪网络活动 #

• 启动Process Monitor，过滤本地PowerShell进程（powershell.exe或pwsh.exe）的网络操作；
• 执行Get-Service -ComputerName Bits，可观察到进程向目标机器发起RPC连接（目标端口初始为135，后续切换为动态端口）。

2. 在目标机器上查看连接与日志 #

• 执行netstat -ano，查找与本地PowerShell进程PID对应的远程连接，确认目标端口为135或动态RPC端口；
• 打开事件查看器，筛选安全日志中的RPC登录事件（事件ID通常为4624、5145），可看到来自本地机器的RPC连接记录。

3. 端口连通性测试 #

• 执行Test-NetConnection -ComputerName <目标机器名> -Port 135，验证RPC终结点映射器的端口是否开放，这是SCM RPC正常工作的前提。

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