PowerShell / WinRM error while trying to kill a process remotely

I want to kill a process remotely in powershell using

invoke-command -cn computername -script { stop-process name }

I made sure the network at the destination computer wasn't set to public, and I managed to run enable-psremoting on the destination.

Now trying to run Invoke-Command ... at the source

but i'm getting some errors
PS C:\Users\username> invoke-command -cn sag35 -script { stop-process name } [sag35] Connecting to remote server failed with the following error message : The WinRM client cannot process the request. If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the TrustedHosts configuration setting. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. You can get more information about that by running the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic. + CategoryInfo : OpenError: (:) [], PSRemotingTransportException + FullyQualifiedErrorId : PSSessionStateBroken PS C:\Users\username>

I looked up about winrm.cmd and adding a trusted host

I was then honored with this rather repetitive error message

`PS C:\Users\username> winrm set winrm/config/client '@{TrustedHosts="sag35"}'

WSManFault
Message = The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig".

Error number: -2144108526 0x80338012
The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig".
PS C:\Users\username>`

ADDED Further to what Trondh wrote about needing winrm at the source.. I did winrm qc, mentioned in this article I now have winrm at source and dest, I can do winrm id(which I understand is a local ping). I also managed to get the trustedhosts line to work for each comp e.g. winrm set winrm/config/client '@{TrustedHosts="compA"}'

Though an error.. when I do win id -r:compA(from compB) or win id -r:compB(from compA). I get the same error whichever comp, and it is an administrative PowerShell prompt.

I ran: reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f as mentioned here and here but no need because that value was already in the registry, and port 5985 for http is open and through the Windows 7 firewall on those computers within my LAN. Port 5986 (for HTTPS) is closed, but I probably only need 5985/http. I understand that this port was set up automatically, and I can see is accessible.

this technet article suggested some tests like winrm id to ping, and with -r for a remote ping.

PS C:\Windows\system32> winrm id -r:compB  
WSManFault  
    Message = Access is denied.  

Error number:  -2147024891 0x80070005  
Access is denied.  

You may need to specify alternate credentials, since both systems are workgroup member (not domain members).

$Cred = Get-Credential;
Invoke-Command -ComputerName PC01 -Credential $Cred -ScriptBlock { Get-Process; };

Here are some general troubleshooting tips for WinRM:

1. Ensure WinRM service is running on client and target systems: Get-Service -Name winrm;
2. Ensure appropriate TCP port(s) are listening on target system (HTTP = 5985; HTTPS = 5986) (use netstat -aon;
3. Ensure client can access port(s) on target system (http://www.nmap.org): nmap -p5985,5986 server01.contoso.com
4. Ensure default PowerShell session configurations exist on target: Get-PSSessionConfiguration
5. Ensure that your user account has administrative access to the target system
6. Ensure that DNS is resolving correctly to the target system's IP address: Resolve-DnsName -Name server01.contoso.com