PowerShell Genie

Locate the layer that breaks a remote session

A remote command fails. Re-running Enable-PSRemoting everywhere is a change, not a diagnosis. Find the failing layer first: transport, name resolution, network reachability, listener, authentication or endpoint authorization.

Interactive guide 11 min practice Windows PowerShell 5.1 and PowerShell 7

Diagnostic scenario · recorded fictional outcomes · Microsoft documentation

The task

Windows WSMan remoting and SSH remoting use different transports. For a WSMan endpoint, name resolution and TCP reachability are earlier checks than session authorization. Test-WSMan can identify a responding WinRM endpoint; its response does not prove that the current user may create a PowerShell session.

  • Choose checks for the actual transport.
  • Distinguish listener reachability from session authorization.
  • Use recorded evidence to avoid unrelated configuration changes.

Genie tip: Choose checks for the actual transport.

Inspect this example’s structure

Read the command and its supplied arguments. This example requires real PowerShell or its module; this diagram does not execute it.

Resolve-DnsName app01.example.test
  1. Stage 1Resolve-DnsNamePositional values or no named parameters

    Build the reasoning

    Confirm the target

    1PS> Resolve-DnsName app01.example.test

    Verify the name resolves to the intended host before diagnosing credentials against it.

    Test the intended listener

    1PS> Test-NetConnection app01.example.test -Port 5985

    5985 is the usual HTTP WSMan port; 5986 is the usual HTTPS port. Test the port actually configured for this endpoint.

    Separate response from permission

    1PS> Test-WSMan app01.example.test

    A WinRM identification response and a successfully authorized PowerShell session are separate observations.

    Predict → Check → Explain

    Choose a case, predict the next useful check and run that diagnostic choice. Outputs below are fictional recordings, not network results.

    Predict the next useful check

    0 of 3 cases solved

    Find the mistake

    Changing before locating the failure

    1PS> Enable-PSRemoting -Force

    This changes local remoting configuration. Establish the target, transport and failed check before using it in an approved environment.

    Treating a listener response as full access

    1PS> Test-WSMan app01.example.test

    Identification success does not establish endpoint authorization, remote command rights or the health of the script you intend to run.

    For each case, name the evidence that rules out the other choices. A successful earlier check narrows the next question; it does not prove the whole operation works.

    Prove it: write it alone

    Solve all three recorded cases before this final decision opens.

    Prove it: use the right transport

    The runbook uses: Enter-PSSession -HostName linux01.example.test -UserName trainee
    The SSH listener is configured on port 22.
    A teammate proposes testing WinRM on 5985.
    Choose the next safe check

    Take it to a real environment

    Write down the host, transport, port, account and exact failing operation in the incident record. For server-side checks, use an authorized administrator and the configured endpoint. The lab supplies recorded results; it makes no DNS, network or server changes.

    Verify the details

    Final challenge not completedChoose another guide
    Genie guideLocate the layer that breaks a remote session

    A remote command fails. Re-running Enable-PSRemoting everywhere is a change, not a diagnosis. Find the failing layer first: transport, name resolution, network reachability, listener, authentication or endpoint authorization.