Updated April 12th: Notice on KB4487563
Today, as part of patch Tuesday, supported Exchange versions received security updates to remediate the following issues:
- CVE-2019-0817: Microsoft Exchange Spoofing Vulnerability
- CVE-2019-0858: Microsoft Exchange Spoofing Vulnerability
Security updates are available for the following product levels, and fix the vulnerability mentioned:
Build | KB | Download | CVE-2019-0817 | CVE-2019-0858 | |
Exchange 2019 CU1 | 15.2.330.7 | KB4487563 | Download | Yes | Yes |
Exchange 2019 | 15.2.221.16 | KB4487563 | Download | Yes | Yes |
Exchange 2016 CU12 | 15.1.1713.6 | KB4487563 | Download | Yes | Yes |
Exchange 2016 CU11 | 15.1.1591.16 | KB487563 | Download | Yes | Yes |
Exchange 2013 CU22 | 15.0.1473.4 | KB487563 | Download | Yes | Yes |
Exchange 2010 SP3 RU27 | 14.3.452.0 | KB4491413 | Download | Yes | No |
Notes:
- CVS-2019-0858 does not apply to Exchange 2010.
- Exchange 2010 is currently in Extended Support. Extended support for Exchange 2010 ends January 14, 2020.
- Don’t forget to put the Exchange server in maintenance mode prior to updating.
- If you want to speed up the update process for systems without internet access, you can follow the procedure described here to disable publisher’s certificate revocation checking.
- The order of installation shouldn’t matter with the “every server is an island” concept, yet recommended is to upgrade internet-facing first, followed by non-internet-facing servers, and finally Edge Transports.
Notice on KB4487563:
Apart from the known issues mentioned in KB4487563, there are reports the fix terminates while stopping services, and the following error is being logged:
[Error] System.Management.Automation.CommandNotFoundException: The term ‘Stop-SetupService’ is not recognized as the name of a cmdlet, function, script file, or operable program.
This Stop-SetupService isn’t a regular cmdlet, and I assume is an alias created by the update. However, there are reports this operation fails. In those circumstances, next to retrying installation of the update, a workaround might be opening up a PowerShell session and adding the alias yourself using New-Alias Stop-SetupService Stop-Service, followed by running the update. The alias isn’t persistent, so will be gone after you close your session.
Caution:
As for any update, I recommend to thoroughly test updates in a test environment prior to implementing them in production. When you lack such facilities, hold out a few days and monitor the comments on the original publication or forums for any issues.
thnx voor de update 🙂
LikeLike
I didn’t have any real issues installing this update in my lab. What I noticed though was that it rolled back the “Display name” reg fix for Exchange 2013 CU22 so it once again stated “Cumulative Update 20”.
Furthermore – under “Installed Updates” the name of the patch is correct but the “Program”-column shows “Microsoft Exchange Server 2013 Cumulative Update 20 – Software Updates”.
LikeLike