Intro
This particular Powershell error I came across yesterday is not well explained in other forums. I present the error and the explanation though not necessarily the solution.
The details
I recently received my new PC running Windows 8.1. On rare occasions I use Windows Powershell to do some light Exchange Online administration, but I am a complete Powershell novice. I have previously documented how to get Powershell to work through proxy, which is also poorly documented. To repeat it here these steps work for me:
> $credential = Get‐Credential
> $drj = New‐PSSessionOption ‐ProxyAccessType IEConfig
> $exchangeSession = New‐PSSession ‐ConfigurationName Microsoft.Exchange ‐ConnectionUri "https://outlook.office365.com/powershell‐liveid/" ‐Credential $credential ‐Authentication "Basic" ‐AllowRedirection ‐SessionOption $drj
> Import‐PSSession $exchangeSession
And that had always worked under Windows 7. Now this is what I get:
New-PSSession : [outlook.office365.com] Connecting to remote server outlook.office365.com failed with the following error message : The WinRM client cannot process the request. Basic authentication is currently disabled in the client configuration. Change the client configuration and try the request again. For more information, see the about_Remote_Troubleshooting Help topic. At line:1 char:20 + $exchangeSession = New-PSSession -ConfigurationName Microsoft.Exchange -Connecti ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin gTransportException + FullyQualifiedErrorId : -2144108321,PSSessionOpenFailed |
What’s up with that? I independently checked my account credentials – they were correct. Eventually I learned there is a winrm command which can shed some light on this. In particular this command show the problem quite clearly:
> winrm get winrm/config/client
Client NetworkDelayms = 5000 URLPrefix = wsman AllowUnencrypted = false [Source="GPO"] Auth Basic = false [Source="GPO"] Digest = false [Source="GPO"] Kerberos = true Negotiate = true Certificate = true CredSSP = false DefaultPorts HTTP = 5985 HTTPS = 5986 TrustedHosts |
So even though I have local admin rights, and I launch Powershell (found in C:\Windows\System32\WindowsPowerShell\v1.0) as administrator, still this rights restriction exists and cannot as far as I know be overridden. The specific issue is that a GPO (group policy) has been enabled that prevents use of Basic authentication.
New idea – try Kerberos authentication
More info about our command is available:
> get‐help new‐pssession ‐full|more
You see that another option for the Authentication switch is Kerberos. So I tried that:
> $exchangeSession = New‐PSSession ‐ConfigurationName Microsoft.Exchange ‐ConnectionUri "https://outlook.office365.com/powershell‐liveid/" ‐Credential $credential ‐Authentication "Kerberos" ‐AllowRedirection ‐SessionOption $drj
This produced the unhappy result:
New-PSSession : [outlook.office365.com] Connecting to remote server outlook.office365.com failed with the following error message : The WinRM client cannot process the request. Setting proxy information is not valid when the authentication mechanism with the remote machine is Kerberos. Remove the proxy information or change the authentication mechanism and try the request again. For more information, see the about_Remote_Troubleshooting Help topic. At line:1 char:20 + $exchangeSession = New-PSSession -ConfigurationName Microsoft.Exchange -Connecti ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ + CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:Re moteRunspace) [New-PSSession], PSRemotingTransportException + FullyQualifiedErrorId : -2144108110,PSSessionOpenFailed |
So it seems that because I use a proxy to connect Kerberos authentication is not an option. Drat. Digest? Disabled in my client.
Solution
Unless the security and AD folks can be convinced to make an exception for me to this policy I won’t be able to use this computer for Powershell access to Exchange Online. I guess my home PC would work however. It’s in the cloud after all.
So I tried my home PC. Initially I got an access denied. It was that time of the month when it was time to change the password yet again, sigh, which I learned only by doing a traditional login. With my new password thnigs proceeded further, but in response to the Import-PSSession $exchangeSession I got this new error:
Import-PSSession : Files cannot be loaded because running scripts is disabled on this system. Provide a valid certificate with which to sign the files. At line:1 char:2 + Import-PSSession $exchangeSession + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (:) [Import-PSSession], PSInvalidOperationException + FullyQualifiedErrorId : InvalidOperation,Microsoft.PowerShell.Commands.ImportPSSessionCommand |
A quick duckduckgo search shows that this command helps:
> Set-ExecutionPolicy RemoteSigned
And with that, voila, the import worked.
2nd solution
I finally found a Windows server which I have access to and isn’t locked down with that restrictive GPO. I was able to set up my environment on it and it is useable.
3rd solution
I see that as of August 2016 there is an alpha version of powershell that runs on CentOS 7.1. That could be pretty cool since I love Linux. But I’d have to spin up a CentOS 7.1 on Amazon since my server is a bit older (CentOS v 6.6) and (I tried it) it doesn’t run it correctly:
$ sudo powershell
powershell: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.18' not found (required by powershell) powershell: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.5' not found (required by powershell) powershell: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by powershell) powershell: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by powershell) |
The instructions for installation are here.
Conclusion
Not every problem has a simple solution, but here I’ve at least documented the issues more clearly than it is elsewhere on the Internet.
References and related
Powershell for Linux? Yes! Instructions here.
19 replies on “Powershell winrm client error explained”
I had this same issue on my new Win10 laptop (Win7 worked fine).
I couldn’t find a GPO forcing this so I changed the registry setting to force it to be allowed. This may revert when I reboot or the policy refreshes but it got me out of a hole.
Open regedit as admin and go to:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WinRM\Client
I had the same three lines disabled as you and each one had a DWORD associated with it.
Simply change the DWORD from 0 to 1 and then restart the PowerShell console
That’s great. This tip will help a lot of people, including me. Thanks.
thank for the tip!
Changing the Dword helped me.
Thanks for this article and Changing the WORD fixed it for me!
Is solved as well here
You saved me – Thank you soooooo much
Thanks! Finally I found a solution that worked out for me!
Changing the Registry key worked for me , Thanks.
This was very helpful for me as well.
great help, changing the registry value helped.
Excellent Brother
I see a lot of folk saying “Changing the registry key helped”, and I do want to make sure people are making an informed decision about this.
Using basic authentication sends your username and password in plain text, across the internet. You’ll be ok most of the time- but you are at risk of someone else intercepting it.
When you use basic authentication to an HTTPS site (which pretty much every site is) your credentials are encrypted by the SSL tunnel and there is no danger of interception in transit.
Maybe, but a lot of the “tutorials” also turn encryption off…
This helped me, thank you
THANK YOU
Thanks! Was bugging me and changing the registry key for AllowBasic worked.
It works. Thanks Thom