A quick blog on recently published security updates for Exchange Server 2013 up to Exchange Server 2019. These fixes address the following vulnerabilities:
- CVE-2019-1373: Microsoft Exchange Remote Code Execution Vulnerability
The CVE documents contain more details on the vulnerabilities. The exploits can be fixed by single security update, which you can find in the table below per current Exchange version.
|Exchange 2019 CU3||Download||15.2.464.7||KB4523171||KB4515832|
|Exchange 2019 CU2||Download||15.2.397.9||KB4523171||KB4515832|
|Exchange 2016 CU14||Download||15.1.1847.5||KB4523171||KB4515832|
|Exchange 2016 CU13||Download||15.1.1779.7||KB4523171||KB4515832|
|Exchange 2013 CU23||Download||15.0.1497.4||KB4523171||KB4509409|
Be advised that the Security Updates for Exchange 2013-2019 are Cumulative Update level specific. Unfortunately, the security update carries the same name for different CUs, and you cannot apply the update for Exchange 2016 CU14 to Exchange 2016 CU13. I would suggest tagging the Cumulative Update in the file name when you store it, e.g. Exchange2016-CU14-KB4523171-x64-en.msp.
As with any patch or update, I’d recommend to apply this in a acceptance environment first, prior to implementing it in production.
The Exchange 2013 CU23 version of this security update broke the eDiscovery PST Export Tool for us. When it would actually start exporting to a .pst file, it stops with the error message ‘FailedToLoadStatus’ instead.
The solution is this: if you search for the file called “microsoft.exchange.ediscovery.export.dll” under your user profile, under AppData, you will find several versions of it (assuming you used the PST Export Tool before this security update was installed on your Exchange Server). If you look at their properties, specifically their versions, the most recent one (included with this patch) will be 15.0.1497.4. What you need to do is find a copy of an earlier version of this dll under your AppData (for example 15.0.1497.0, which is the CU23 version), and replace/overwrite all instances of the 15.0.1497.4 version with it (still under AppData). Then you can just start the tool again, and it will work.
LikeLiked by 1 person
my problem was very similar, but had to open case with M$ – here is what we had to do
• This is a known issue in our product. After installing a security patch, the Microsoft.Exchange.Diagnostics.dll goes missing from the client machine.
• The fix for this issue is mentioned below:
o Navigate to C:\Program Files\Microsoft\Exchange Server\V15\Bin on any Exchange mailbox server. [In your case Server: ILDREX13-01]
o Copy the “Microsoft.Exchange.Diagnostics.dll” file.
o Paste it in the AppData folder (install location of PST Export tool) on the client machine. [Note: By client machine, we mean the machine from where you are trying to export to PST]
o To find the location on the client machine, to paste it to: Go to your client machine and open file explorer.
o In the file explorer, Navigate to: C:\Users\YOURUSER\AppData\Local\Apps\2.0
o Then, search for microsoft.exchange.ediscovery.exporttool.exe in the file explorer.
o Out of all the paths that you get, look for all the paths/location where you can find files with extension .dll
o When you find that path or paths, make sure to paste the Microsoft.Exchange.Diagnostics.dll in all these paths with .dll files, in your client machine.
o Close all browser windows and re-try to export to PST after the above step.
same issue with 2016 CU14, above Solution fixed our issue.
Thank you Robert
Having the same issue. Where are you finding the 15.0.1497.0 version to replace the 1497.4 version?
Extract the CU23 install files, and search for the file in there.
Robert, thank you so much for sharing this solution! Worked great on our Exchange 2016 CU15. Only difference is I changed out the DLL files in the Exchange “bin” folder on the server. I renamed the newer file, replaced it with the earlier version, and no more error.
Thank you Robert, I’ve been looking all day for a fix to this. It figures you never notice something like being broke after a CU until it’s an urgent request.
Still a problem with the latest CU for Exchange 2016 and this article is the only one I’ve seen that addresses this. Thank you. 🙂
But has anyone found a way to fix it server side? Sending a dll to our techies is at best a workaround.
And I meant the eDiscovery problem that was addressed by Robert. Sorry for being unclear.
I’d recommend to submit a ticket if possible to at least make the product group aware of any issues.
A failed KB4509409 on an Exchange 2013 CU23 build somehow removed the AD groups Exchange Domain Servers, and Exchange Enterprise Servers. Can’t start exchange services without them. Customers mail server is dead in the water. Can’t find much on how to repair this. Going for the tape now. Big time beware!
Security Updates don’t touch Active Directory.
Those groups are definitely missing at this moment. All exchange services fail to start (Microsoft Exchange Active Directory Topology service for instance). I had restarted the exchange server right before I applied the update and all the exchange services were running OK after the restart. I have no idea what else would have removed them if it wasn’t from the KB.
Oddly, these groups aren’t shown as a deleted object so i can’t recover them. But they are certainly gone.
Im very open to any and all ideas. Im sitting here wondering if i should restore the DC from backup, or the exchange server. I can’t find much online if those groups are recreatable.
Just an update. I guess these AD groups don’t exist on CU23. No idea. However, if someone else has this issue with KB4509409 failing, and the inability to start exchange services:
In C:\ExchangeSetupLogs\ServiceControl.log, i noticed the following entry: [Error] System.Management.Automation.CommandNotFoundException: The term ‘Stop-SetupService’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Steps i took to resolve the downed server and to bring all exchange services back online:
1. Created file ‘profile.ps1’ in C:\Windows\System32\WindowsPowerShell\v1.0 containing the following single line:
Set-Alias Stop-SetupService Stop-Service
2. Run Powershell as administrator. Get-ExecutionPolicy and note the return value. You may want to change this back when all steps are completed and Exchange is back up and running. Set-ExecutionPolicy Unrestricted and answer yes at the prompt.
3. Using this same powershell window along with the file path to the original KB4509409-x64-en.msp, run the installer with forced full logging: msiexec /p “C:\DownloadedPatchFromHell\Exchange2013-KB4509409-x64-en.msp” /L*V “C:\DownloadedPatchFromHell\update.log”
KB4509409 at this point finally ran for me without failing. Half way thru, it prompted it could not continue as services were in use. At this point i did the following:
4. Open IIS manager, expanded the exchange server\Sites, and stopped both ‘Default Web Site’ and ‘Exchange Back End’.
5. Opened cmd.exe as an administrator and: iisreset /force
6. Using Services.MSC, stopped the following services: ‘Microsoft Exchange Diagnostics service’, ‘Microsoft Exchange Search Host Controller’, ‘Microsoft Filtering Management Service’.
7. Continue with KB4509409 install. Process took long time to complete (maybe 30 to 40 minutes). Installer prompted that it completed successfully. All exchange services were still down after installation completed.
8. Restarted the Exchange server.
9. Using IIS manager, started both sites ‘Default Web Site’ and ‘Exchange Back End’.
10. Run powershell as an administrator and: Set-ExecutionPolicy RemoteSigned (or whatever you had recorded in step #2) and accepted Yes at the prompt.
I hope this helps save someone else from patch-fail pain, i lost 10 hours of my life to this nonsense.
– Eric Parr
11. Delete the file created in step #1: C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1
12. And restart the exchange server again for good measure.