Home » Blog » September 2016 Updates for Exchange Server 2016/2013

September 2016 Updates for Exchange Server 2016/2013

Microsoft has released new cumulative updates for Exchange Server 2016 and 2013 this month, announcing:

  • Exchange Server 2016 Cumulative Update 3 (download)
  • Exchange Server 2013 Cumulative Update 14 (download)

These releases follow last week’s release of critical security updates for Exchange. The cumulative updates announced for Exchange 2016 and 2013 today include those critical updates. For Exchange 2010 and 2007 the update releases last week were packaged as update rollups instead.

The new CUs for Exchange 2016 and 2013 deliver some significant changes:

  • Exchange Server support for Windows Server 2016 has been announced. Make sure you read the guidance carefully, it is not simply a case of all Exchange versions supporting installation on Windows Server 2016 or use with Windows Server 2016 domain controllers. For customers that have been waiting to deploy Exchange 2016 until Windows Server 2016 support is available this is good news, however we still need to wait for the general availability of Windows Server 2016, which will likely be announced at Ignite 2016 this month.
  • .NET 4.6.2 support is included for Exchange 2016 CU3 (or later) running on Windows Server 2016. At this time no other versions of Exchange are supported with .NET 4.6.2, so be careful not to allow it to install on your Exchange servers, until the planned December 2016 update releases. However, Microsoft has announced that .NET 4.6.2 will be required for Exchange 2016 and 2013 on all supported operating systems from March 2017 (which will be when another round of cumulative updates are released).
  • One of the features of Exchange 2016 announced before RTM, but that was not included in RTM, is “Read from Passive” which is an improvement in the database content indexing that allows database availability group members to build their index from a passive database copy, instead of copying the index data from the server hosting the active database copy (except for lagged database copies). Microsoft estimates that in some environments this will save as much as 40%, and has updated the Exchange Server Role Requirements Calculator to reflect this change.
  • Exchange setup will no longer set server component states to an inactive/offline status during pre-requisite checks. This is a significant improvement in the update installation experience for customers, because it means that a pre-requisite check failure will not leave the server in a non-functioning state.

Additional Information

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Blog

18 comments

  1. Peter Cooney says:

    Great to finally see the context indexing change! Been a problem since 2010 as you know.

    Also great to see the CU check changes it is a common problem.

    As always thanks Paul for the support you give the Exchange community.

  2. sajid says:

    Hey, i already updated to my production exchange with cu3 of exchange 2016.
    only issue was high cpu which was due to context indexing. i rebuild my context indexing and give some time for rebuilding and the issue is solved.
    Regards

  3. Matt says:

    Hi
    Thanks for this post. I just installed the CU3 in our test environement. This is the first CU I installed on a 2016 Exchange. Everything went fine (but took loads of time). Just one little “problem”. We have 2 edge servers. In the ECP, both show the old Build Version 225.42. Is this normal? Do you have the same?
    Would be very thankful if somebody with a edge server would report, how it looks in his environement.
    Thanks and greetings,
    Matt

  4. Oleg Gritsun says:

    This CU3 update break the search in public folders. We have faced this issue after update then two days ago MS Exchange support engineer confirmed that their developers know about this problem and working towards a resolution.

  5. Alan says:

    I’ve added a new server to our network running CU3 (the others are all still CU1). We have a DAG across all 4 servers. We now get a strange error for some (only some) mails being delivered to mailboxes on any database that’s active on the CU3 server: some mails randomly get stalled in the queue on the other servers saying “Last Error: 421 4.4.0 failed to parse smtp response from Mailbox Transport Delivery: string did not match smtp response suffix regex <250 2.0.0 OK[resubmit=False"
    I can't find anything on Google on this error. We can only clear it by activating the database back on any of the CU1 servers. I am reluctant to update any of the other servers to CU3 until we resolve the issue. Any ideas what this might be?
    cheers

    • Maurice says:

      Hi Alan,

      We have exactly the same issue.
      Running in mixed environment with two Exchange 2013(CU12) and two Exchange 2016 CU3 servers (without any DAG configuration).
      When we implemented the Exchange 2016 CU3 servers random mail gets queued and status ‘retry’.

      We found out when “user A” is sending e-mail to ‘distribution group A’ !and! to himself,
      (Where “User A” is also member of “Distribtion group A) e-mail will be deliverd but gets stuck in queue with error:

      “Last Error: 421 4.4.0 failed to parse smtp response from Mailbox Transport Delivery: string did not match smtp response suffix regex <250 2.0.0 OK[resubmit=False]"

      Did not found any solution yet!

      Regards, Maurice

  6. Alan says:

    Haven’t logged with MS yet as I can’t keep the databases active in our production environment for long as mails back up. But I have verified that mails sent to distro groups where any of the recipients are on a CU3 server get stuck on a CU1 queue. So it seems CU1 servers have issues sending to CU3 ones but not vice versa. Ordinary mails are not affected.

    • Unless there’s some other element of your environment that is causing it (e.g. a third party product installed on the Exchange servers, like antivirus, antispam, host-based intrusion, a load balancer, WAN optimizer, firewall, etc) I think you should raise a support case. I can’t repro in my environment, but if you can reliably repro it in yours then perhaps it is a bug.

  7. David says:

    I have the same error as Maurice is having;
    We found out when “user A” is sending e-mail to ‘distribution group A’ !and! to himself,
    (Where “User A” is also member of “Distribtion group A) e-mail will be deliverd but gets stuck in queue with error:

    “Last Error: 421 4.4.0 failed to parse smtp response from Mailbox Transport Delivery: string did not match smtp response suffix regex <250 2.0.0 OK[resubmit=False]"

    I have two 2013 CU13 servers with some stuck emails trying to send to three 2016 CU3 servers.

    is there any way to change the smtp response suffix regex on exchange 2016 to make them unstuck?

    • I still can’t repro this in my environment. See my comment to Alan above. Unless you’ve got some other element in your environment that you can look into further, then I think the best thing to do is get a support case open for troubleshooting.

    • Adrian says:

      Hi Guys
      Having the same problem too, I’m running mixed like Maurice, 2 servers 2013 (CU13) and 2016 (CU3). I did the upgrade to CU3 on our 2016 exchange server and CU13 for the 2013 server on the weekend and we have started getting the same problem. Some, not all emails getting stuck in the shadow redundancy queue when users send emails to distribution groups. Some group members receive the mail but some hang in the queue.

      All the users mailboxes in question are on our 2016 server but the queue that holding the emails is on the 2013 server all reporting the same error “421 4.4.0 failed to parse smtp response from Mailbox Transport Delivery: string did not match smtp response suffix regex <250 2.0.0 OK[resubmit=False]"

      I haven't been able to consistently replicate the problem…yet

      Adrian.V

        • Maurice says:

          Hi all,

          The migration to Exchange 2016 CU3 is finished and we have uninstalled both Exchange 2013 servers.
          I can’t reproduce the issue anymore. All seems to be working normal now!
          No more e-mails in ‘retry’ state with error “421 4.4.0 failed to parse smtp …..” when trying to reproduce the problem!

          In my case, the ‘retry’ state was because the e-mail was processed by the Exchange 2013 HUB transport queues in a mixed Exchange 2013 / 2016 environment.

          For now my problem is solved by uninstalling the Exchange 2013 servers.

          Regards, Maurice

Leave a Reply

Your email address will not be published. Required fields are marked *