Exchange Online PowerShell WinRM issue

I went into my PowerShell ISE today, as I always do, and tried to connect to Exchange Online. However, as you can see from the above error message:

Connecting to remote server outlook.office365.com failed with the following error message: The WinRM client cannot process the request.

I couldn’t connect! Why was this I wondered? It was working last time. I then proceeded to waste a good amount of time trying to troubleshoot WinRM errors to no avail. Only at the point of frustration did I actually read more of what the error message actually said:

Basic authentication is currently disabled in the client configuration. Change the client configuration and try the request again.

I then tried to connect to Exchange Online via PowerShell using another machine of mine and received the same error. I then tried a VM in Azure and that worked fine. It was at this point that I started to suspect it was something to do with my Intune policies as the Azure VM was stand alone.

I had just recently implemented the Security Baselines provided by Microsoft.

I was working my way through some of the reports of conflicts and misconfigurations by adjust my existing best practices policies to suit. I didn’t appreciate that these Security Baselines actually implement policies that get pushed out to devices! I thought they just compared your settings to what Microsoft recommended as best practice.

When I went to the affected workstations and ran the command:

winrm get winrm/config/client/auth

I got the above in which you can see that the Basic auth setting is indeed set to false but that it is set by a GPO. Ok, so where is this GPO I wondered? Given that all the affected machines were Azure AD joined without a local domain controller it meant that the GPO was going to be Intune, as that is where the policies are pushed from in my case.

When I repeated that winrm command on a machine that worked I saw the above, Basic = true and no Source=”GPO”.

I then tried in vain to change the GPO locally using PowerShell and the GP console to alter the setting but with no luck.

Suspecting Intune and my policy fiddling, I totally disabled all configuration policies for the device but the problem continued. I then deleted the Security Baseline policies I had created and BAM, everything worked!

Ok, so the problem was the Security Baseline policies, but how? Well, it turns out that these Security Baselines actually do apply an additional policy to your devices once you enable it. Now my question was, where exactly does it do this and can I alter the Security Baseline if desired?

Turns out, that the location for what affected me is in the Remote Management section of the MDM Security Baseline policy as shown above.

Unfortunately, I had breezed over these options when I first set up the policy using the wizard. You can expand each of the options there and make adjustments if you need! D’Oh!

The lessons here are, firstly that if your implement the MDM Security Baseline or the Microsoft Defender ATP baseline, these will create policies and apply these to your environment. Secondly, you can customise these baselines if you wish, both during the creation process and afterward if you wish. Thirdly, you need to be careful with these policies as they set a lot of settings that you may not seem to immediately come from Intune.

I’ll spend some more time looking at these in detail and reporting back. My own personal best practice policies are pretty close to the Microsoft ones, but it is great that I can do a comparison between them and improve my own.

A frustrating self inflicted issue to resolve but I have learned much in nutting it out and I hope if you have the same issues that this information saves you the time I had to invest to resolve it!