WinRM remoting fails
Documentation: Microsoft Learn
Work the problem
The listener responds
Fictional case: DNS returns the expected address, the configured WinRM port is reachable and Test-WSMan responds. Creating a PowerShell session returns Access is denied.
Reasoning notebook
Record the evidence that supports your answer and the check you would run next. Your notes stay in this browser — nothing is uploaded.
Why it happens
A remoting session needs the name to resolve, the port to accept a connection, a listener running behind that port, and authentication acceptable to both ends. Any one of those failing produces similarly worded text, which is why the message alone rarely identifies the layer at fault. Kerberos adds a further requirement that the name you typed matches an SPN registered for the target.
Check this first
What to look for
Listener response does not prove this account can create a session. Inspect authentication details and endpoint authorization.
Working through it
Confirm the name resolves to the intended target and test the configured port. Then use Test-WSMan for the WSMan listener and inspect session creation separately. On the target, check the intended endpoint and who may use it.
Connecting by IP changes the authentication conditions and can require additional configuration; failure or success by IP is not a clean proof that Kerberos alone is the cause. Use the actual authentication error and the environment’s approved configuration.
Avoiding it next time
Verify the repair: Create a session with the intended account and endpoint, then run a read-only identity check on the target.