Windows Server 2025 / How to Use PowerShell Remoting with WinRM

PowerShell remoting sends commands to another server or opens an interactive shell there. For Windows Server 2025, check the Windows Remote Management (WinRM) endpoint and authentication before using Enter-PSSession or Invoke-Command.

Separate target setup from client connection commands

Run listener setup on the FS1 console and connection commands on the management PC. Reversing those locations can expose unnecessary listeners or query the wrong computer. This exercise uses Windows PowerShell remoting over WinRM, not PowerShell 7 remoting over SSH.

• Identify FS1 and a valid administrator account.
• Use the intended isolated management network.
• Keep the target console available for recovery.

Check the current target state in elevated Windows PowerShell; remoting may already be configured:

Get-Service WinRM
Get-PSSessionConfiguration
Test-WSMan localhost

Configure the target only when needed

If it is not configured, run the following on FS1. The command can affect listeners, session configuration, and firewall settings, so verify the computer name first.

hostname
Enable-PSRemoting -Force
Test-WSMan localhost

Restrict access to the required management PC or subnet. For profile-related failures, inspect the actual network context rather than disabling the firewall. Default WinRM ports are TCP 5985 for HTTP and 5986 for HTTPS.

An HTTP listener name does not by itself establish that authenticated message traffic is unprotected. Review WinRM authentication and message security when designing identity verification and credential protection.

Use server names in a working domain

This example assumes the PC and FS1 have joined the same domain, DNS and time work, and the account has permission. Do not expect it to succeed before the domain exists.

Test-WSMan -ComputerName 'fs1.ad.example.test'
Enter-PSSession -ComputerName 'fs1.ad.example.test'
hostname
whoami
Exit-PSSession

Commands after Enter-PSSession execute on the target. Exit-PSSession returns to the management PC. An IP address changes the authentication conditions compared with a domain name using Kerberos; prefer the FQDN when domain DNS is available.

Keep workgroup trust narrowly scoped

Workgroup or IP-based connections require additional conditions, such as HTTPS or a specific TrustedHosts entry. See remote troubleshooting guidance. TrustedHosts does not authenticate a server’s identity; consider trusted-certificate HTTPS for operational use.

For this isolated lab, verify FS1’s IP at its console. On the management PC, retain the original value and add only that target. Replace the account with the actual intended server administrator; do not use a wildcard for every host.

$previousHosts = (Get-Item WSMan:\localhost\Client\TrustedHosts).Value
$labTargets = (@($previousHosts -split ',') + '172.24.50.20' | Where-Object { $_ } | Sort-Object -Unique) -join ','
Set-Item WSMan:\localhost\Client\TrustedHosts -Value $labTargets
$labCredential = Get-Credential -UserName 'FS1\Administrator'
Enter-PSSession -ComputerName '172.24.50.20' -Credential $labCredential
hostname
Exit-PSSession

Custom local administrator accounts can encounter remote User Account Control restrictions. Revisit the authentication design instead of broadly disabling those protections. In the same management-PC session, restore the previous value after the lab:

if ([string]::IsNullOrEmpty($previousHosts)) {
    Clear-Item WSMan:\localhost\Client\TrustedHosts
} else {
    Set-Item WSMan:\localhost\Client\TrustedHosts -Value $previousHosts
}

Run a single query and close the session

Once domain prerequisites are satisfied, collect the target’s OS information in one operation:

Invoke-Command -ComputerName 'fs1.ad.example.test' -ScriptBlock {
    Get-CimInstance Win32_OperatingSystem | Select-Object Caption,Version,LastBootUpTime
}

Check PSComputerName and the returned OS so a local result is not mistaken for a remote one. Troubleshoot DNS, port reachability, WinRM response, authentication, and session authorization separately. A Test-WSMan response alone does not establish command execution rights. Before reversing listener changes, check whether other management tools depend on WinRM and compare with the original settings.