When executing Get-Process -ComputerName against Windows Server 2012 R2 systems, many administrators encounter the frustrating "Couldn't connect to remote machine" error. Interestingly, Invoke-Command works while the direct Get-Process approach fails, indicating a specific protocol-level issue rather than general connectivity problems.

For Get-Process -ComputerName to function properly, several infrastructure components must be correctly configured:

• Windows Remote Management (WinRM) service running and properly configured
• Appropriate firewall rules for ports 5985 (HTTP) and 5986 (HTTPS)
• Proper authentication mechanisms
• Component Object Model (COM) network access enabled

Here's the complete step-by-step resolution:

1. Verify WinRM Configuration

First, check the WinRM service status on both machines:

# On both local and remote machines
Get-Service WinRM
Enable-PSRemoting -Force
Test-WSMan -ComputerName Win2012r2

2. Firewall Configuration

Create precise firewall rules (note this differs from standard RDP ports):

# On the remote server
New-NetFirewallRule -DisplayName "Windows Remote Management (HTTP-In)" 
    -Name "WinRM-HTTP-In-TCP" 
    -LocalPort 5985 
    -Protocol TCP 
    -Direction Inbound
    
New-NetFirewallRule -DisplayName "Windows Remote Management (HTTPS-In)" 
    -Name "WinRM-HTTPS-In-TCP" 
    -LocalPort 5986 
    -Protocol TCP 
    -Direction Inbound

3. Authentication and Credential Delegation

Configure proper authentication using either of these methods:

# Option 1: Explicit credentials
$cred = Get-Credential
Get-Process -ComputerName Win2012r2 -Credential $cred

# Option 2: Enable CredSSP (for double-hop scenarios)
Enable-WSManCredSSP -Role Client -DelegateComputer Win2012r2
Enable-WSManCredSSP -Role Server

If direct connectivity still fails, consider these workarounds:

Using CIM Sessions

$session = New-CimSession -ComputerName Win2012r2
Get-Process -CimSession $session

Wrapper Function Solution

For scripts where you can't modify the call structure but need reliability:

function Get-RemoteProcess {
    param(
        [string]$ComputerName,
        [pscredential]$Credential
    )
    
    try {
        Get-Process -ComputerName $ComputerName -Credential $Credential -ErrorAction Stop
    }
    catch {
        Invoke-Command -ComputerName $ComputerName -Credential $Credential -ScriptBlock {
            Get-Process | Select-Object Name, Id, CPU, Handles, WorkingSet
        }
    }
}

• Verify DNS resolution works properly (Test-Connection Win2012r2)
• Check for network-level restrictions (VLANs, ACLs)
• Validate group policy isn't overriding your settings
• Examine Windows Event Logs for related errors

---

When attempting to retrieve process information from remote Windows servers using Get-Process -ComputerName, many administrators encounter the frustrating "Couldn't connect to remote machine" error. The puzzling aspect is that while Invoke-Command works flawlessly, the native Get-Process remote functionality fails.

The Get-Process -ComputerName command relies on different protocols than PowerShell Remoting (WinRM). It primarily uses:

• Remote Procedure Calls (RPC)
• Windows Management Instrumentation (WMI)
• DCOM (Distributed Component Object Model)

Before diving into solutions, let's verify all required components:

# Check if the remote server is reachable
Test-NetConnection -ComputerName Win2012r2 -Port 135

# Verify RPC services
Get-Service -ComputerName Win2012r2 -Name RemoteRegistry, RpcSs | Select-Object MachineName, Name, Status

# Test WMI connectivity
Get-WmiObject -ComputerName Win2012r2 -Class Win32_OperatingSystem | Select-Object Caption

Here are the most effective fixes based on real-world troubleshooting:

1. Firewall Configuration

The Windows Firewall must allow specific ports:

# Create firewall rules for RPC/WMI
$ruleParams = @{
    DisplayName = 'Allow RPC/WMI for Get-Process'
    Direction = 'Inbound'
    Protocol = 'TCP'
    LocalPort = 135,445,49152-65535
    Action = 'Allow'
    Enabled = 'True'
}
New-NetFirewallRule @ruleParams

2. Service Configuration

Ensure these services are running on both machines:

$requiredServices = @(
    'RemoteRegistry',
    'RpcSs',
    'Winmgmt',
    'DcomLaunch'
)

foreach ($service in $requiredServices) {
    Get-Service -Name $service | Set-Service -StartupType Automatic -Status Running
}

3. Alternative Approaches

When direct Get-Process fails, consider these workarounds:

# Method 1: Using WMI directly
Get-WmiObject -ComputerName Win2012r2 -Class Win32_Process | 
    Select-Object ProcessName, ProcessId, WorkingSetSize

# Method 2: Wrapped Invoke-Command
function Get-RemoteProcess {
    param([string]$ComputerName)
    Invoke-Command -ComputerName $ComputerName -ScriptBlock { Get-Process } |
        Select-Object ProcessName, Id, CPU, WS -Unique
}

In domain environments, additional factors may affect connectivity:

• Network security policies blocking RPC traffic
• Kerberos authentication issues
• Group Policy restrictions
• Port exhaustion on the remote host

These commands help identify the root cause:

# Check WMI health
Test-WSMan -ComputerName Win2012r2

# Enable detailed logging
& wevtutil sl Microsoft-Windows-WinRM/Operational /e:true
& wevtutil sl Microsoft-Windows-WMI-Activity/Operational /e:true

# Test RPC connectivity
Test-NetConnection -ComputerName Win2012r2 -Port 135