SCOM - The Ehlo options for the client proxy target did not match

The full error is this one:

Alert: Exchange Health Set
Source: sr-XXXXX - HubTransport
Path: sr-XXXXX.domain.lan;sr-XXXXX.domain.lan
Last modified by: System
Last modified time: 12/15/2016 9:43:40 AM Alert description: The Ehlo options for the client proxy target 1.1.0.1 did not match while setting up proxy for user  on inbound session 08D41FF9C251F8DD. The critical non-matching options were <maxSize>. The non-critical non-matching options were <NONE>. Client proxying will continue.
Probe Exception: ''
Failure Context: ''
Execution Context: ''
Probe Result Name: 'Transport/SmtpProxyEhloOptionsDoNotMatchContinueProxying'
Probe Result Type: 'Failed'
Monitor Total Value: '0'
Monitor Total Sample Count: '1'
Monitor Total Failed Count: '1'
Monitor Poisoned Count: '0'
Monitor First Alert Observed Time: '15-12-2016 08:43:37'

The error itself doesn't tell you al lot at first glance.
But if you look at "client proxy target 1.1.0.1" it shows you in the direction of the receive connector on the server the error originated from.

So what's happening here?
Let's say the MaxMessageSize for the organisation is set to 50MB.
An email arrives at the Client Frontend receive connector which has a size of  50MB.
If the MaxMessageSize is set at 50MB it gets passed on to the Client Proxy receive connector which usually has a MaxMessageSize setting of 50MB as well.
Then it will be passed on to the Outbound Frontend Proxy receive connector which has a setting of 50MB as well.

Every time the message gets proxied/passed on to the next receive connector some header info gets added to the message making it a little bit bigger.
So in other words your receive connector needs to accept a bigger MaxMessageSize for every step along the way.

How do we do this?

First check your Current settings:

get-ReceiveConnector *\* | fl identity,role*,maxm*size,bind* Then check the settings for the individual receive connector on all the servers: Get-ReceiveConnector "*\client proxy servername" | fl identity,role*,maxm*size,bind* Get-ReceiveConnector "*\client frontend servername" | fl identity,role*,maxm*size,bind* Get-ReceiveConnector "*\outbound proxy frontend servername" | fl identity,role*,maxm*size,bind* Get-ReceiveConnector "*\client frontend servername" | fl identity,role*,maxm*size,bind* After that set the MaxMessageSize for the Client Frontend connector on each server: Set-ReceiveConnector "servername\client frontend servername" -MaxMessageSize 50MB Then set the MaxMessageSize for the Client Proxy connector on each server, and add 1MB: Set-ReceiveConnector "servername\client proxy servername" -MaxMessageSize 51MB Then set the MaxMessageSize for the Outbound Proxy Frontend connector on each server, and add 1MB: Set-ReceiveConnector "servername\outbound proxy frontend servername" -MaxMessageSize 52MB Now you can check your settings with the same commandlet as you started with: Get-ReceiveConnector "*\client proxy servername" | fl identity,role*,maxm*size,bind* Get-ReceiveConnector "*\client frontend servername" | fl identity,role*,maxm*size,bind* Get-ReceiveConnector "*\outbound proxy frontend servername" | fl identity,role*,maxm*size,bind* Get-ReceiveConnector "*\client frontend servername" | fl identity,role*,maxm*size,bind* Then restart the MSExchangeTransport Service on each server to activate the settings: Get-Service -ComputerName servername -Name MSExchangeTransport | Restart-Service

Remote PowerShell session - the request needs to be sent to a different machine

Well this is a nice one as well….NOT. I keep losing hair like this.
After trying to setup a remote PowerShell session the following error occurs.

The WinRM service cannot process the request because the request needs to be sent to a different machine.
Use the redirect information to send the request to a new machine.  Redirect location reported: https://mail.mydomain.com/powershell.
To automatically connect to the redirected URI, verify "MaximumConnectionRedirectionCount" property of session preference variable
"PSSessionOption" and use "AllowRedirection" parameter on the cmdlet.
+ CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportRedirectException
+ FullyQualifiedErrorId : PSSessionOpenFailed

Let me tell you what is not the cause so you can skip checking all those things:

• An URL redirect in IIS
• Reinstall of WinRM
• adding “–AllowRedirect” after your connection command let
• "MaximumConnectionRedirectionCount" property setting
• Misconfigured certificate
• PowerShell version
• Invalid credentials

The list could go on and on, but the solution is quite simple as it is not logic at the same time.
The error doesn't say a lot about the actual cause.
So remember when was the last CU you installed? Bingo, after every CU your IIS settings can get garbled and that’s exactly what happened here.
Changes are your authentication settings in IIS on the PowerShell virtual directory for the frontend website are gone/missing/set incorrectly.
In my case they were gone, no authentication option was set. After setting it al back the way it should be (see this post, you need to make note of this stuff for a working Exchange environment in cases like this) I could create a remote PowerShell session instantly.

After renewing Exchange certificates IMAP stops working

The strangest things happen as an Exchange admin.
Recently i renewed the certificates for our Exchange servers, and while everything went fine the next day we got several calls that a few IMAP mailboxes stopped working.

No this is particularly strange because it's an IMAP mailbox that uses plain text logon on port 143, the default imap port so it doesn't even use a certificate.
After ripping my hairs out, calling everybody who came to close a #$%^ and a &!@#*& i came across this post by Jetze Mellema.

Strangely enough it worked, well at least for 2 of the 3 mailboxes.
The day after we were getting calls that there was still one mailbox that couldn't connect.

Same error in the IMAP protocol log:

2016-12-13T09:11:57.785Z,000000000000003F,8,x.x.x.151:143,x.x.x.202:54194,imapmailbox,63,43,55,login,imapmailbox@domain.com *****,"R=""2yc2 NO LOGIN failed.\r\n* BYE Connection is closed. 14"";Msg=Proxy:servername.domain.lan:1993:SSL;ErrMsg=ProxyNotAuthenticated"

The error message suggests that there is something going on with authentication or a firewall issue possibly blocking a port or using a certificate that is expired or has wrong name in it.

But no, to solve this we moved the mailbox to another mailbox database.
After the move we created an Outlook profile with the correct credentials and were able to login immediately. 

Now if you're reading this and you know why this happend please let me know, because i was baffled and totally don't understand any logic behind this stuff.