Maintaining your Exchange Servers with the latest updates is the best practice. Staying up to date with the new builds of any software product is a good idea, because it means you’re receiving the latest bug fixes, security updates, and feature compatibility with any integrated components.
For Exchange Server in particular there are clear reasons to stay up to date:
- Exchange Server 2013 and 2016 use a servicing model of “Cumulative Updates”, and Microsoft will support the latest CU. Support for the N-1 CU runs out 3 months after the release of the latest one. Cumulative updates ship every quarter, which aligns with the 3 month support period. If you’re running N-2 or earlier, you are not running a supported environment. There is an exception for Exchange 2013 CU4, which is also known as Exchange 2013 Service Pack 1, and continues to receive security updates. However, it is well out of date in terms of bug fixes, and you should not deploy that build.
- Exchange Server 2010 Service Pack 3 is the only service pack still supported, under extended support, until 14th January 2020.
- Exchange Server 2007 Service Pack 3 is the only service pack still supported, under extended support until 11th April, 2017.
Besides the supported status of those Exchange versions, Office 365 Hybrid configurations require you to maintain your on-premises servers to at least N-1.
The word “supported” can mean different things in different scenarios, but for this article it means:
- If you call Microsoft with a problem, they will ask you to reproduce the problem on a supported version of the product before they do much else for you. This makes sense as you may see a bug that does not exist in the supported versions.
- Security updates are released only for supported versions of the product. Running unsupported versions puts you at risk due to unpatched security vulnerabilities.
Deploying updates carries risk. Microsoft has released updates in the past that introduced new bugs, but there is also the risk that something unique to your environment will cause an unexpected issue.
Your organization needs to balance the risks of updates with the risks of doing nothing. My view is that you should update, and mitigate the risks through a thorough process of testing, or by using highly available deployments that will not suffer an outage due to an update to a single server. If the pace and risks of updates are too much for you, then you can also consider Office 365.
For more information about keeping your Exchange Servers updated:
- FAQ: In What Order Should You Install Service Packs, Update Rollups, and Cumulative Updates?
- Updated Guidance for Solving Outdated Exchange Server and .NET Framework Versions
- Installing Cumulative Updates for Exchange Server 2016
- Installing Cumulative Updates for Exchange Server 2013
- Servicing Exchange 2013 (Microsoft Exchange Team blog)
- Exchange Server Updates: build numbers and release dates (TechNet)
- How to Install Updates on Exchange Server 2010 Database Availability Groups
- How to Install Updates on Exchange Server 2010 CAS Arrays
- Exchange Server 2013 support lifecycle
- Exchange Server 2010 support lifecycle
- Exchange Server 2007 support lifecycle
Question: You write that “Microsoft will support the latest CU. Support for the N-1 CU runs out 3 months after the release of the latest one. ”
Does this mean that if I run CU4 right now, my Exchange 2016 CU4 enviroment is not supported by Microsoft?
Do you have a link at Microsoft website were this is written??
Hope to hear from you 🙂
That question is already answered in my article above, and the links I included at the end.
Always the best!
Question… I have just taken over a new role where I was horrified to discover they are running Exchange 14.3 (123.4), basically Exchange 2010 was installed and never touched… 4 years ago.
I am going to upgrade to Exchange 2016, however need to update my Exchange server first before I can do that migration…
Can I just install Update Rollup 16 or do I need to install 1 through to 16.
Here you go:
I always shutdown, snapshot (they are VM’s), start up and let stabilize, and then update. Then watch the logs….
Why are you taking snapshots?
I believe he would use that for roll back purposes. – He’d better make sure he’s LUN’s have enough space!
*his* not he’s
Which is not supported.
What do you mean? I do the same with my Exchange servers.
Using a VM snapshot to roll back an Exchange server to a previous state is not a supported recovery method.
A very good article. Despite the fact that I have never had any issues with installing service packs or CU, I still get nervous about doing this in single server deployments. Email is so critical these days with many senior management expecting 24/7 email availability, that should any issues occur extreme pressure can be placed on the Exchange Admin to resolve ASAP.
When ever I see single server deployments I try to introduce high availability and load balancing in order to minimize downtime to email systems. Even with this in place however, I’ve come across many companies who leave systems unpatched as they are terrified of breaking the email system.
I anticipate that this will drive many companies to move their data to Office 365 and escape the patching and updating of Exchange!