Exchange 2013 CU18 Released


Exchange 2013 CU18 has been released to the Microsoft download centre!  Exchange 2013 has a different servicing strategy than Exchange 2007/2010 and utilises Cumulative Updates (CUs) rather than the Rollup Updates (RU/UR) which were used previously.    CUs are a complete installation of Exchange 2013 and can be used to install a fresh server or to update a previously installed one.  Exchange 2013 SP1 was in effect CU4, and CU18 is the fourteenth post SP1 release.

Exchange 2018 CU18 Download

This is build 15.00.1347.002  of Exchange 2013 and the update is helpfully named Exchange2013-x64-cu18.exe.  Which is a great improvement over the initial CUs that all had the same file name!  Details for the release are contained in KB 4022631.

Whether or not your AD Schema needs to be updated depends upon your initial Exchange 2013 version.  This will dictate if the AD Schema needs to be modified.  Check the values as noted in this post.  There may be additional RBAC definitions, so PrepareAD should be executed prior to installing CU18.  If setup detects that PrepareAD is required it should be automatically executed if the account running setup has the necessary permissions.  This was an issue first discussed in the MessageCopyForSentAsEnabled  post and in Unexpected Exchange AD Object Values.

No Exchange 2010 updates were released today since Exchange 2010 is in extended support.  Updates will be released as per the extended support lifecycle policy.

Exchange 2007 is no longer supported, updates are not provided once a product has exited out of extended support.

Updates Of Particular Note

CU18 contains the latest time zone updates.

.NET Framework 4.7 is not supported at the time of writing.  Note that the focus will be placed upon supporting .NET Framework 4.7.1 with the next Exchange CU released for Exchange 2013 and Exchange 2016.

Advanced notification is provided so that administrators can proactively plan to update .NET between the release next Exchange CU and the subsequent CU.  This is similar to the approach with .NET 4.6.2 - Please see Exchange 2013 CU16 and Exchange 2016 CU5 .NET Framework Requirement for more details.

Issues Resolved

040755 New health monitoring mailbox for databases is created when Health Manager Service is restarted in Exchange Server 2013

KB4040121 You receive a corrupted attachment if email is sent from Outlook that connects to Exchange Server in cache mode

KB4040120 Synchronization may fail when you use the OAuth protocol for authorization through EAS in Exchange Server 2013

Some Items For Consideration

As with previous CUs, this one also follows the new servicing paradigm which was previously discussed on the blog.  The CU package can be used to perform a new installation, or to upgrade an existing Exchange Server 2013 installation.  You do not need to install Cumulative Update 4 or 5 for Exchange Server 2013 when you are installing the latest CU.  Cumulative Updates are well, cumulative.  What else can I say…

For customers with a hybrid Exchange deployment, must keep their on-premises Exchange servers updated to the latest update or the one immediately prior ( N or N-1).

After you install this cumulative update package, you cannot uninstall the cumulative update package to revert to an earlier version of Exchange 2013. If you uninstall this cumulative update package, Exchange 2013 is removed from the server.

  • Test the CU in a lab which is representative of your environment

  • Review this post to also factor in AD preparation which is to be done ahead of installing the CU onto the first Exchange server

  • Follow your organisation’s change management process, and factor the approval time into your change request

  • Provide appropriate notifications as per your process.  This may be to IT teams, or to end users.

  • Place the server into SCOM maintenance mode prior to installing, confirm the install then take the server out of maintenance mode

  • Place the server into Exchange maintenance mode prior to installing, confirm the install then take the server out of maintenance mode

  • I personally like to restart prior to installing CU.  This helps identifies if an issue was due to the CU or happened in this prior restart, and also completes any pending file rename operations.  3rd party AV products are often guilty of this

  • Restart the server after installing the CU

  • Ensure that all the relevant services are running

  • Ensure that event logs are clean, with no errors

  • Ensure that you consult with all 3rd party vendors which exist as part of your messaging environment.  This includes archive, backup, mobility and management services

  • Ensure that you do not forget to install this update on management servers, jump servers/workstations and application servers where the management tools were installed for an application.  FIM and 3rd party user provisioning solutions are examples of the latter

  • Ensure that the Windows PowerShell Script Execution Policy is set to “Unrestricted” on the server being upgraded or installed.  See KB981474

  • Disable file system antivirus prior to installing.  Do this through the appropriate console.  Typically this will be a central admin console, not the local machine

  • Verify file system antivirus is actually disabled

  • Once server has been restarted, re-enable file system antivirus

  • Note that customised configuration files are overwritten on installation.  Make sure you have any changes fully documented!

  • While CU18 does not add any new AD Schema changes.  If you are on an out-dated CU currently, then deploying CU18 may contain AD Schema updates for your organisation – please test and plan accordingly!  Whether or not your AD Schema needs to be updated depends upon your initial Exchange 2013 version.  This will dictate if the AD Schema needs to be modified.  Check the values as noted in this post.  Additional RBAC definitions may also be required.

 

Please enjoy the update responsibly!

What do I mean by that?  Well, you need to ensure that you are fully informed about the caveats with the CU  and are aware of all of the changes that it will make within your environment.  Additionally you will need to test the CU your lab which is representative of your production environment.

Cheers,

Rhoderick

Comments (10)

  1. trkmany says:

    Hello, Rhoderick,
    exchange server 2013 on CU15, and .net Release: 460805,
    can I do CU18 or need prerequisites for this?
    Thanks in advance…

      1. trkmany says:

        Hi
        last question, is it ok to start the CU18 if The .net version is 4.7 on the exchanger servers?
        Thanks in advance…

        1. Unfortunately that is not a supported version of .NET. Some people have reported issues with it, others have not.

          Cheers,
          Rhoderick

  2. Josue Ogando says:

    Hello Rhoderick, Thanks again for keeping us updated and always informing us about many technical details.

    Are there any news for the organizations willing to disable TLS 1.0 and/or 1.1. The ones willing to operate only with TLS 1.2?

    I know that during the previous six months the Exchange team has been working with the .Net team expecting it to be ready soon. Many people has been waiting for this on the last quarterly updates.

    1. Hi Josue,

      Nothing more than is in the previous posts at this time – sorry!

      Cheers,
      Rhoderick

  3. Jon says:

    Any update on the CU15 .net hop before later CU? CU15 is not available for download anymore. Less risk jumping to latest vs multi upgrades in my view.

    1. Jon – CU15 should still be available – I can get to if from this post (click the image to hit the download)

      Cheers,
      Rhoderick

  4. David Reade says:

    I installed the .NET 4.7 update on to our Exchange 2013 server when it was released, before you advised people not to! I was going to reluctantly roll it back when I decided to risk it and see if it broke Exchange 2013 in any way. About 6 months later, Exchange 2013 and .NET 4.7 are still installed on the same server; no loss of functionality, no errors in the Event Log; everything is still working.

    I don’t know about anyone else, but from my point of view, .NET 4.7 and Exchange 2013 is a clear winner. Therefore is there really any further need to waste time getting .NET 4.7 “supported”?

    From my perspective, there are more pressing issues that need addressing, such as TLS 1.2. In the last update, you advised users not to solely use TLS 1.2. Why not? There’s no mention of any further progress with TLS 1.2 in this update.

    What are the implications (if any) of running Exchange 2013 with TLS 1.2 only?

    1. Hi David,

      This is still the best reference on the TLS aspect:
      https://blogs.technet.microsoft.com/exchange/2015/07/27/exchange-tls-ssl-best-practices/

      It has been updated since the initial publication date.

      .NET 4.7 should not have been installed as it has not be tested or validated. In fact it will not be. The December updates will introduce 4.7.1 support due to the release cadence of .NET.

      Cheers,
      Rhoderick

Skip to main content