As you might notice, the security fix is made available for the N-1 builds of Exchange 2013 and Exchange 2016. This could imply the issue was addressed in the latest builds of those products. I hope to receive official confirmation on this soon.
The issue is deemed Important, which means organizations are advised to apply these updates at the earliest opportunity. However, as with any update, it is recommended to thoroughly test updates and fixes prior to deploying them in a production environment.
You are reading it correctly: the later Cumulative Updates are not affected. Earlier builds will not receive a security fix, as support is provided up to N-2 generation builds. Reason for Exchange 2013 SP1 being in there is that Service Packs are on a different support scheme.
Note that this Rollup or security fix replaces MS16-108 (kb3184736) – you can install MS13-105 over installations containing this security fix (no need to uninstall it first).
Last Update: December 13th, 2016: The Windows team published an update for Windows Server 2016, which should fix the issue with DAG members crashing when restarted. The related article is KB3206632, and you can download it here. Be advised, the Windows Server 2016 update – which also fixes other issues – is nearly 1 GB!
About one month ago, Exchange Server 2016 Cumulative Update 3 was released which supported deployment on Windows Server 2016. However, recently issues are being reported on various communities as well in related blog comments, where Exchange 2016 became unstable, symptoms being randomly crashing IIS application pools (which says nothing about the root cause).
Microsoft acknowledged there is an issue with Exchange Server 2016 CU3 on Windows Server 2016:
If you attempt to run Microsoft Exchange 2016 CU3 on Windows Server 2016, you will experience errors in the IIS host process W3WP.exe. There is no workaround at this time. You should postpone deployment of Exchange 2016 CU3 on Windows Server 2016 until a supported fix is available.
So, be advised to hold off to deploying Exchange 2016 on Windows Server 2016 until further notice.
Update: The Exchange Team has also posted a notice that an update is in the works, and to delay further Exchange 2016 deployments on Windows Server 2016 until this delay has been made available. No ETA on the update yet.
Update: Made changes to reflect that IIS Request Filtering will not work.
This week, Microsoft released a security fix MS15-034 (KB3042553) for IIS which potentially allows for remote code execution on IIS, denial of service attacks (DOS) or bugchecking of servers. Since Exchange leverages IIS, Exchange servers are affected.
The vulnerability is easy to exploit, using an HTTP or HTTPS request and specifying a Range header with a value of 18446744073709551615 (maximum 64-bit unsigned integer). The Range header, introduced in the HTTP/1.1 specification, can be used by the requester to receive only a portion of data, for example the first few bytes of a JPG to determine its dimensions.The issue occurs when you specify out of bounds value. for example, when using cURL you can specify:
ISC SANS institute provided instructions for SNORT here.
Disable IIS kernel caching, but this is not recommended due to negative impact on performance.
Unfortunately, Request Filtering is not an option so you can not prevent the exploit using IIS’ built-in Request Filtering feature. The Request Filtering will occur after parsing of the Range header, and it is in this parsing causing the issue.
A short notice on an issue when you have deployed Exchange 2013 Cumulative Update 6 in coexistence in an Exchange 2007 environment. Exchange fellow Tony Redmond did a write-up on the issue here.
The issue prevents ActiveSync users whose mailbox reside on Exchange 2007 to authenticate properly when their requests are being proxied from Exchange 2013 CU6 to Exchange 2007. It has been identified in KB2997847. Alternatively, you direct Exchange 2007 EAS traffic directly to Exchange 2007 CAS servers when they are internet-facing and published.
Be advised that a previous known issue in this deployment scenario with delegates and dismounting stores has been identified in KB2997209.
Both articles provide links to request these hotfixes.
Another Exchange fellow, Jason Sherry, is keeping track of resolved and open Exchange 2013 CU6 issues here.
As mentioned earlier, when you have deployed Exchange Server 2013 Cumulative Update 6 in a Hybrid deployment, several Office 365-related mailbox functions will not show up in the Exchange Admin Center (EAC). The issue was identified by Microsoft in KB2997355 and a fix was published.
However, the script to fix the issue looks for the XAML file in the default Program Files folder, using the default Exchange installation folder. Better is to check the actual Exchange installation folder, which can easily be accomplished in Exchange Management Shell using the $exinstall environment variable, or by reading the folder from the registry.
To help those installing Exchange in a non-default installation folder, and I know there are quite a few of you out there, who are hesitant to correcting the installation path in the provided FixIt script, I have create an alternative version of the Exchange2013-KB2997355-FixIt script. This version will read the installation path from the registry. Not disturbing but changed as well is correcting the XAML file in one go, unlike the official script which performs 3 consecutive read/modify/write actions on the same file.
You can download the Exchange2013-KB2997355-FixIt-v2.ps1 script here.
After installing Exchange 2013 Service Pack 1, people reported issues with Transport Agents. Symptoms are that the Transport service doesn’t start or stops shortly after starting the service or you can’t install the 3rd party product.
Be advised that the script supplied in the KB article tries to locate and fix various alternate versions of those files. Something you might want to consider as well when fixing it manually, should you be unable to locate the specific files mentioned above.
After running the script you should be able to start the Transport service or install 3rd party containing transport agents..
Update (3/5): Updated blog after official KB article got published. The issue was also blogged on by fellows Jason Sherry, Paul Cunningham while Tony Redmond has additionanal background details here.
Microsoft published an important hotfix for .NET 4.5 earlier this year. It wasn’t picked up on by many, therefor a quick write up on the matter.
Since Exchange 2013 is built on top of .NET 4.5, it is recommended to install the hotfix on all Exchange 2013 Mailbox and Multi-Role servers. The hotfix will reduce the memory consumption of the store worker processes.
Today the rereleases of MS13-061 Security Fix for Exchange 2013 CU1 and Exchange 2013 CU2 saw daylight. This security update KB2874216 fixes the issue described in Microsoft Security Bulletin MS13-061 and supposedly fixes the issues found with the original release. After installing the v2 patch, the version will be upped 2 notches compared to the original patch.
As mentioned in an earlier article, security fixes are Cumulative Update level specific. In practice, this means there are two different versions of the security update patch file: one for CU1 and one for CU2.
Be advised both files carry the same file name, Exchange2013-KB2874216-v2-x64-en.msp. I suggest adding some form of Cumulative Update identification to the file name when you archive it, e.g. Exchange2013-KB2874216-v2-x64-en-CU2.msp.
As with any patch or update, I’d recommend to thoroughly test this in a test and acceptance environment first, prior to implementing it in production. If you don’t have the resources and risk management can agree, you might want to consider postponing implementation for a short period while monitoring for issues in the online.