Download that new Cumulative Update for Exchange…While you can.

No the messaging world is not ending, but things have changed tremendously in the last few years around the Exchange upgrade cadence. The expectation is that you are keeping your servers up to date – applying the latest CU every quarter.  There are obviously good reasons to do so – namely new features and security fixes.  Having said that, you may be surprised to learn that unless you are in hybrid mode, you will still be supported running an out-of-date CU – with some caveats.

But here’s the rub: Exchange relies heavily on the .Net Framework and deep down in places you don’t talk about at parties; you want those .Net updates, you *need* those .Net updates. It’s here where the lack of keeping current will bite you in the rear.

When a new CU is released, the third previous CU from 9 month ago will be removed from public download.  If that update was required to support an upgrade of .Net, then you are in a pickle.

As you can see from the Exchange Supportability Matrix, and Michel’s blog post, there have been a number of these “Bridge” CUs that are required as you make the leap to the next .Net version.  There are a few moving pieces here, but typically you will be given at least 6 months notice that a future CU will require a specific .Net version that is optional now and can be installed on the current CU.

So for example, Exchange 2013 CU 19 supports .Net Framework 4.7.1. You want to upgrade to that version after you apply CU19. Now you are well positioned for the future CU that requires 4.7.1.

Expect this to be the new norm:

  1. Advance notice of new .Net requirement in a future CU.
  2. Support for that .Net version in a CU when it’s released.
  3. Optional upgrade to that .Net version after applying the newly released CU.
  4. Required upgrade to that .Net version before you can apply the CU that was part of the original notice.

If you aren’t convinced by now that keeping up with the Exchange Cumulative Updates is in your best interest, I would offer that you at least download them as they are released – even if you never plan to actually install it. That way you can easily access that “Bridge” CU and avoid a call to Microsoft Support, since that will be the only way to get them once they are pulled from the public download.

 

 

 

This message wasn’t delivered to anyone because there are too many recipients. The limit is 100. More hybrid fun!

If you are living the Exchange Online Hybrid dream like so many, you often run into oddities around message flow.  One encountered recently was a nagging NDR an Exchange Online user would get when sending to an old-school Distribution List.

Specifically:

This message wasn’t delivered to anyone because there are too many recipients. The limit is 100. This message has 198 recipients.

Details:

Action: failed
Status: 5.5.3
X-Supplementary-Info: < #5.5.3 smtp;550 5.5.3 RESOLVER.ADR.RecipLimit; too
many recipients>

Now the first thought is some Exchange Online limitation, but the NDR was actually generated by an on-premises server and, as we all know, DLs count as one recipient right? Besides, I wasn’t aware of any limit anywhere in Exchange of 100 – except the pickup directory for the transport service.

Regardless, due diligence required some checking and the sender ( who was part of the list) had the standard recipient limits in place:

And if you didn’t already know, 500 is the default in Exchange Online and that can not be modified.

The other members of the group were all on-prem, so I checked their recipient limits and, as expected, those were set to the default of “unlimited”.

Hmm, Did someone mess with the on-prem org limits? Didn’t make sense since this was the only user reporting this. But being the good scout, I checked anyway and that value was set much higher than 100.

So where the heck was that coming from?

Checked receive connector limits, looked through SMTP protocol logs. No smoking gun.

Then it occurred to me, was it possible that the remote mailbox for the 365 sender was the culprit?

Sure enough, there it was:

Set-Remotemailbox doesn’t let you change that attribute, so I cleared it with ADUC and the birds sang once again.

Reconstructing this, I can only assume that the on-prem mailbox had this value set for some reason and during the move to Exchange Online, it was preserved for the remote mailbox.

The interesting piece to remember is that the DL was expanded in Exchange Online and because majority of the list members were still on-prem, the recipient limits came into play on the on-prem object.

Good times!