Install Patches for Exchange 2010, 2013, 2016, and 2019 ASAP
Updated March 16
On March 2, the Microsoft Threat Intelligence Center (MSTIC) issued details of multiple day-zero exploits in active use against on-premises Exchange servers. As described in their blog, attackers “used these vulnerabilities to access on-premises Exchange servers which enabled access to email accounts, and allowed installation of additional malware to facilitate long-term access to victim environments.” The attack is attributed to HAFNIUM, a group believed by Microsoft to be state-sponsored and operating out of China. While this attack is against on-premises servers, MSTC say that they have observed HAFNIUM “interacting with victim Office 365 tenants.”
Amongst other issues, the identified vulnerabilities allow attackers to dump the LSASS process memory, use PowerShell to export mailbox data, download the OAB. Microsoft recommends that on-premises customers follow their published guidance to protect Exchange servers.
The Microsoft Security Response Center (MSRC) noted that “These vulnerabilities are used as part of an attack chain. The initial attack requires the ability to make an untrusted connection to Exchange server port 443. This can be protected against by restricting untrusted connections, or by setting up a VPN to separate the Exchange server from external access. Using this mitigation will only protect against the initial portion of the attack; other portions of the chain can be triggered if an attacker already has access or can convince an administrator to run a malicious file.”
To explain how the Hafnium attack works, John Hammond has posted a video on YouTube.
Here how the experts combat HAFNIUM attacks and security flaws within Exchange Server
Closing Off the Vulnerabilities
To close off the four reported vulnerabilities, the Exchange development group has issued security updates for the following versions of Exchange server:
- Exchange Server 2010 (RU 31 for Service Pack 3). This is an out-of-band update for an unsupported server to ensure that organizations have defense in depth.
- Exchange Server 2013 (CU 23).
- Exchange Server 2016 (CU 19, CU 18).
- Exchange Server 2019 (CU 8, CU 7).
It’s recommended that you disable anti-virus products before attempting to install these updates. Remember to install the updates using an account with administrator permissions (will prevent problems with OWA and ECP virtual directories) and always reboot servers once they’re updated.
More detail about the patching process is available in the Exchange team blog and this presentation from Microsoft EMEA support.
March 7 Update: Microsoft published an article describing issues encountered when applying security updates to Exchange Server.
March 8 Update: Microsoft made an update available for selected versions of Exchange 2016 and Exchange 2019. The update applies only the security patches and no other fixes. It is very much a short-term method to allow customers with servers that cannot be updated to Exchange 2016 CU20 or Exchange 2019 CU9, perhaps because of a dependency on some other application, to secure their servers. However, as Microsoft points out, applying another update to these servers will expose them again to the exploit if the update doesn’t include the security patches. See KB5000871 to download the updates.
March 15: Microsoft has released the Exchange On-Premises Mitigation Tool (EOMT), a one-click mitigation tool for Exchange 2013, 2016, and 2019. This is the fastest way to check an on-premises Exchange server for problems and mitigate the risk. The EOMT tool is downloadable from GitHub. The important point is that EOMT is intended as a quick fix. It does not protect against future attacks and servers need to be secured as per Microsoft’s recommendations.
March 17: Microsoft released Exchange 2019 CU9 and Exchange 2016 CU20. These are the regular quarterly cumulative updates for the supported versions of Exchange Server. The updates include the security patches.
March 18: Microsoft issued a set of YouTube videos to guide people through the remediation process.
March 19: Security company F-Secure says that there are still many Exchange Servers which remain unpatched, noting that “assume that there has been at least a digital knock at the door for every business with Exchange Outlook Web Access installed in the world. Because access is so easy, you can assume that [the] majority of these environments have been breached.”
March 24: ZDnet reports Microsoft saying that 92% of vulnerable Exchange servers have been patched.
Checking the Updates Have Been Applied
A reader asked how to check that the security update is in place. Two methods exist. First, use the Exchange Server Health Checker script (written by Marc Nevins, an Exchange escalation engineer). You’ll see something like Figure 1 to show the installed updates. Like any PowerShell or other code downloaded from the internet, run the script on a test server before putting it anywhere near a production system.
Second, check the file version of ExSetup.exe
Get-Command Exsetup.exe | ForEach {$_.FileVersionInfo}
Now check the returned value against Table 1 to validate that you’ve got the right file version.
| Patched systems file versions | |
| Exchange Server 2019 | For CU7: 15.02.0721.013 For CU8: 15.02.0792.010 |
| Exchange Server 2016 | For CU18: 15.01.2106.013 For CU19: 15.01.2176.009 |
| Exchange Server 2013 | For CU23: 15.00.1497.012 |
Script to Check for Exploits
Test-ProxyLogon.ps1 is a PowerShell script written by Microsoft (downloadable from GitHub – updated March 5) to check servers for signs of exploits from the vulnerabilities reported in CVE-2021-26855, 26858, 26857, and 27065. If you’re worried that your servers might have been compromised, you can run the script and work with Microsoft support if anything untoward is detected.
Microsoft Safety Scanner Tool
March 6 Update: Microsoft has updated the latest version of the Microsoft Safety Scanner (MSERT.EXE) to detect and remediate the latest threats known to abuse the Exchange vulnerabilities disclosed on March 2, 2021. Administrators can use this tool for servers to scan for “known indicators from adversaries.” See the MSRC blog for more information.
Install Those Updates!
Although hundreds of millions of Exchange mailboxes now run in Exchange Online, a substantial number remain on-premises. Many large organizations run hybrid deployments and keep some mailboxes on-premises. No matter whether you’re a pure on-premises organization or a hybrid organization, this is a call to action that you can’t afford to ignore. Download and install the security updates now. And then think about if you really should be running on-premises Exchange servers.
Successfully installed RU32 on both our Ex2010 Servers along with Visual C++ Redistributable.
Having intermittent issues with OWA and the EMC failing… stuck at ‘Adding snap-in console’ basically times out and won’t launch successfully. I’m not seeing any relevant event logs info.
I’ve done several uninstalls/re-installs of the update and reboots with no luck.
Any ideas on what could be causing the issue?
Hi
I ask about opening OWA from outside after we install update its secure to open it??
so user can access Email over internet
If you are confident that your server is fully patched, you can allow OWA access.
Hi Tony,
I have a coexistence scenario between exchange 2010 SP3 and Exchange 2016, i’ve installed Rollup 32 in Exchange 2010 FE, and CU20 in the Exchange 2016, i’m getting an “invalid canary ” error when try to access to /ecp in the 2010 mailboxes, did anyone experienced the same?
Kind Regards,
Hello, After running the all in one mitigation script and patching the servers (CU19). Should I roll back the mitigations?
Why would you roll back the mitigations?
Thanks for your response and advice
Upgraded fron Exchange 2016 CU17 to CU19 in a DAG environment took 5 hours from start to end
HAFNIUM patch took 45 mintues in DAG
Main point, it’s slow and cumbersome but paitence and lots of coffee.
Hi there,
We are running Exchange 2016 hybrid. Our on-premise Exchange server doesn’t host any mailboxes and is now fully patched. We’ve also temporarily blocked inbound access through 443 whilst the patching was being carried out and have confirmed that no malicious access or files have occurred.
Is there any reason why we need to unblock port 443? I’ve read that it’s needed for OWA, which we don’t use as all email is accessed via Exchange Online and also for Autodiscovery but I’m not sure if that’s something that we need if all our users access Office 365 Online.
Any advice greatly appreciated!
Thanks!
https://docs.microsoft.com/en-us/exchange/plan-and-deploy/deployment-ref/network-ports?view=exchserver-2019 says that 443 is used for:
Encrypted web connections are used by the following clients and services:
• Autodiscover service
• Exchange ActiveSync
• Exchange Web Services (EWS)
• Offline address book (OAB) distribution
• Outlook Anywhere (RPC over HTTP)
• Outlook MAPI over HTTP
• Outlook on the web (formerly known as Outlook Web App)
If you don’t use those features, you can keep 443 off. EWS is used in hybrid deployments to access on-premises mailboxes for calendar data, but as you say, all mailboxes are in the cloud, so….
Thanks Tony, that’s really helpful!
Great article by the way!
Hey Tony,
Great Article as always. Question for you… and apologies if I missed it in your write up.
1) Would a reverse proxy like a Kemp Load balancer (with exchange add on) – have prevented this?
2) Would any type of reverse proxy (with or without load balancing) have prevented this attack?
3) What about if a company/client had Hybrid Modern Auth enabled, using the set-authserver cmdlet so there on-premise mailboxes could use azure for Modern Auth
4) Would having ADFS configured and enable for on-premise mailboxes have prevented this? 3rd party auth providers like OKTA?
Thanks,
At this point, I am loathe to make any sweeping statements that using a load balancer or any other technique would have helped. It all depends on the implementation (settings) and execution, plus the management discipline. What’s important is patching the servers to resist further attack and making sure that any files planted on servers by attackers are removed. We can debate the finer points of prevention afterwards.
Fair enough. I get it. I was just hoping there may be some way to determine if other security layers would have prevented it.
but I suspect not, at least with the methods I described as all URL requests would have been valid and allowed, any type of preauth would probably have broken autodiscover anyways.
Thanks for your input.
Tony, quick question, did microsoft determine that the folks that were using 2016 cu x that upgraded to 2016 c18 on March 2, exposed themselves to the vulnerability. We are seeing that all of the activity “shelling” comes post the initial upgrade. The file stamps show that well. We pulled packet capture and do not see activity and we are unable to see if the w3wp actually spawned this process. Looks like to us that the activity started post the first patch on March 2. Are you seeing this elsewhere? We didnt go to cu19 till friday’s release and then cu 19 again on saturday. Like the other individual the same results, micorosft scan says 1 file removed. We pulled the physical exchange logs and grep’d thru them looking for aspnnet_client/.x etc…. we see those in the logs with 404 or 303 but no activity beyond that. They are attempts to in my opinion call home that are blocked….. The other problem is we run qualys at the same time so some of the data can be convoluted in the logs….. Any thoughts on the statement above….Post, we have investigated down to the Kernal level, we have looked at all the hashes and find them unfound. We have loaded our CW agent and Qualys agents…..We have built rules around the box. We never saw any user creation through UEBA or the logs….. Any ideas if we simply could have upgraded into this?
The patches are included in Exchange 2016 CU19, so any server running a previous release is or was vulnerable. What you might be seeing is the activity which happened when attackers discovered that the vulnerabilities were there to be probed (see the notes about activity in https://practical365.com/blog/attack-exchange-impetus-move-cloud/).
There appears to be a lot of probing activity going on by different groups, so it’s hard to give a definitive answer. I’d say that any unexplainable activity you see in logs or in files that you don’t recognize is evidence of a probe or attack unless proved otherwise.
Hi guys
We investigated and concluded in logs that the attacker placed a webshell file, but was not successfull in executing it.
BUT i noticed the WhenChanged property whas updated on all our accounts in Active Directory most likely all of those with Organization Management rights.
The change is not logged in our windows Active Directory servers security event logs.
We updated the Exchange servers and applied the security in the same period of time these accounts got “something” updated. Is it common Exchange knowledge that Organization Management admins are changed during Exchange CU updates or security updates?
I cant find any details about this, lets say in the SchemaUpdates included in the lates CU updates.
/Simon
Loads of broken links, PLS FIX?
I just checked the links and didn’t find an issue with any. Which link are you having difficulty with?
In general, if you complain about something, be precise about the problem you have encountered. It makes it a lot easier to fix the problem, if one exists.
We patched as soon as the MS notifications came out, however after running the Test-ProxyLogon.ps1 it revealed suspicious activity under CVE-2021-26855 and CVE-2021-27065
We have ran the mitigations and the Microsoft Safety scanner which detected and removed 1 aspx file, the box is just a management box, all emails in 365, no further logs of suspicious activity but considering whether to revert back to a previous backup and re-patch, Microsoft support are not responding back to our queries unfortunately
If the security scanner removed a suspicious aspx file and no further signs of bad activity exists, the box is probably OK. But I would confirm this with Microsoft support because they have the latest information about problems that have been found on Exchange servers around the world.
Hi, I have EX2016 RTM installed, but have .net 4.8 installed too, which is not on the supported matrix. Should I go straight to CU19 from RTM?
Yes. RTM is vulnerable. Go to a supported and secure CU as quickly as you can.
Thanks, the question was more to do with will I have any problems with applying the CU19 as .net 4.8 is already installed somehow, but RTM is not listed as supported with .net4.8.
The Exchange 2010 SP3 CU is CU32 and not CU31 as listed in the article.
Right. You patch RU31. to get it to RU32. The article says “the Exchange development group has issued security updates for the following versions of Exchange server”
“And then think about if you really should be running on-premises Exchange servers.”
Eliminating on-premises servers isn’t going to solve anything. It just pushes onto others the problem of updating defective software that should have been properly written in the first place. Beyond that, it will allow Microsoft and the other software giants to erect a wall of secrecy that will prevent people from even knowing about these defects and the fact that they may have been compromised. The existence of on-premises software is what forces Microsoft et al to acknowledge the defects at all– because people will find out when independent forensics auditors and network administrators uncover the defects in servers not controlled by the software vendors. The convenience of secrecy and the “recurring revenue” issue are what are driving the march to the cloud– not anything inherently better about off-premises software. What no one wants to discuss right now is that Exchange Online was just as vulnerable and its users may have been breached just as much as anyone else; patching it was just easier. It was still Exchange. Eliminating on-premises software will be a huge step backward.
It’s hard to critize software written years ago when the threat horizon was very different to what it is today. Calling something defective is setting an expectation that the developers should have anticipated nation-state attacks on servers running old software that, in many cases, was not patched and kept current.
Exchange Online might have been as vulnerable (I don’t know) as its on-premises counterparts. But it’s protected by security barriers which stop attackers getting in to test any potential vulnerability. So we shall never know. Exchange Online runs different code in a different environment under a different management regime. It’s an apples to oranges comparison.
I have installed patch CU18: 15.01.2106.013 on my exchange server 2016 , is it enough to avoid recent attacks ?
Or should i also install CU19: 15.01.2176.009 ?
Install the latest update.
Hi,
anyone a script/command to check if Exch 2010 was compromised? Test-Proxylogon.ps1 only works for 2013 and newer. Commands in https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/ don’t work either.
__Leo
I’m having an issue that after i install the latest patch for Exchange 2016 CU 18
my server will still show the older Build number, I tried this on 2 separated servers and having the same issue. Any ideas?
Log a call with Microsoft and get their opinion.
Hi Tony, thank you for taking the time to put this article together, super useful/helpful/practical as always.
Would just like to point out that the version number mentioned for Exchange 2013 CU23 is one digit wrong, it should be 15.00.1497.002, not 15.00.1497.012.
Thanks again!
Thanks. I got this data from Microsoft support. I wonder why they think it’s 012?
I just installed the latest version in exchange 2013 CU 23 and the version number is 012
I have tons of respect for you guy but this comment really hurt…
“And then think about if you really should be running on-premises Exchange servers.And then think about if you really should be running on-premises Exchange servers”
Hi Tony,
There are two fixes detected in the terminal screenshot in your article. KB5000871 and KB4602269.
I updated my Exchange 2019 to CU8 and applied the KB5000871 patch. The script HealthChecker.ps1 currently displays:
Version: Exchange 2019 CU8
Build Number: 15.2.792.3
Exchange IU or Security Hotfix Detected.
Security Update for Exchange Server 2019 Cumulative Update 8 (KB5000871)
I`ts all right or should I still install KB4602269?
KB4602269 is an older security patch. You should be OK with the newer because these are cumulative fixes, but I would check with Microsoft.
Is anyone having outlook client disconnections after these updates? We have two 2019 exchange servers and after the updates it started causing these issues. We completely rebuilt two new exchange servers but did not solve the clients from still disconnecting. Seems to only happen in the morning two instances. We are using MS support to help isolate and find the root cause but still nothing and has been going on for week now.
We have been days for 2 days & have a case open with MS. They are NO help
Would check the config files. Alot of people including my customer have had it where the paths in these files have been set to either none existent drives or just %exchange. As such its caused back pressure and ma issues .
I am actually surprised there isn’t a single update to fix all the issues by now, considering how critical a problem this is.
Yes, technically, these are individual bugs needing individual updates but has Microsoft forgotten the concept of Service pack or even Cumulative Update?
I understand the priority would be to rush individual updates out first since they would probably be quicker and that’s all fine.
But they should better be working on a single update or should now start working on it.
As good as you have to be to be still managing onprem exchange, anyone can miss out on all updates to reduce the possibility of it by just releasing one update, make it part of Windows Update.
It was a disaster when they ran Exchange service packs and updates through Windows Updates which they used to do with Exchange 2010. Lots of people could not get the updates installed because Windows Updates provides no way to feed back even simple errors such as “you don’t have net 4.8 installed only net 4.7 stop and install net 4.8 then restart the update” it would just fail out and the user would be left scratching their heads.
As for Exchange 2013-2019 ALL of the updates for Exchange are CU’s and in fact this latest security patch is the first time they have released a Patch to a CU through Windows Updates. The CU is not through Windows Updates, the Patch to the CU is. However with 4 of my 2016 Exchange servers 1 properly discovered the Patch after rebooting from the CU19 update, the remaining 3 did not and I manually downloaded the Patch after putting them to CU19. Of the 3 remaining 1 of them had it’s own WSUS server – in order for WSUS to pull down the Patch I would have had to wait 24 hours for WSUS to sync, then approve the update then wait another 4 hours for the Windows Updates on the server to sync to the WSUS server before it would have listed the patch.
Ok this helps. I thought that CU were their own separate updates, but then today I saw Windows Update downloading it. I was very confused.
We have Exchange 2016 cu17 do we still need patch ? if so where are the file location please.
You need to update. Did you read the article to findthe references to the Microsoft material?
Hi,
If we take a snapshot and revert if something goes wrong?
Yes you need to update to the latest VC2013 redistributable, to Net 4.8, then install CU 19 then install the patch.
Does this affect older versions of exchange 2013? We are on ex2013 cu21.
Yes. It does. You need to apply the patch for Exchange 2013.
hello,
Thanks for the article.
When trying to run Test-ProxyLogon.ps1 i have an access denied (AccessDenied,PSSessionStateBroken).
Any idea
Are you running with admin permissions?
yes i am running the script with admin permissions.
Then you should contact Microsoft support to find out what’s going on. This is too important a problem to mess around guessing what could be happening.
its possible that your “admin” acc doesn’t have “Exchange admin rights”. I think you need to be part of “Exchange organization” security group. Remember that not always, domain admin = exchange admin.
I have the same problem. Not all of my exchange boxes are showing access denied to childitem Even though access is denied the script moves on and shows my server as compliant
So after dissecting the script they are looking for log paths recursively . So some of you your servers may not have those directory paths present like oabgeneratorlog, and the script will kick out access denied. This could have been written better, however I appreciate that something was provided.
Did you run the Exchange Management Shell explicit as “Run as Administrator”? this did the trick for me.
If your ECP/OWA vDirs are broken, here’s the fix : https://aka.ms/FixOWAECP.
Not running the update using an elevated cmd prompt can cause this problem.
Good luck!
Hi
Have run the update on a couple of Ex2013 servers and OWA is broken on both.
After signing into OWA, get “Bad Request”.
Have rebuilt OWA virtual directory but still no luck.
HELP!!!!
It is likely your admin userID did not have correct permissions. See
https://docs.microsoft.com/en-us/exchange/troubleshoot/client-connectivity/exchange-security-update-issues?WT.mc_id=twitter
Hi Tony,
I got the info that updates can install without fixing the vulnerabilities, if UAC is enabled and not running the update as an administrator.
Do you think that these two methods of checking afterwards would catch this?
Thanks!
I think they should. But you must run the updates with a privileged account. That’s always been the way to install Exchange updates.
OWA and ECP sites are broken after installing the patch ex2013 cu23 … tried bodybuilding the directories with no luck .
Sorry to hear that. Have you contacted Microsoft support?
I’ve got the same problem. Please keep this thread updated if you find a solution and I will do the same.
We installed our’s last week as well, issues encountered is that the OWA/ECP broke in our environment.
We followed instructions on KB article but did not mention of the .NET 4.8 being installed first before the security update.
I’m wondering if that’s causing our OWA issue in our case.
We followed the KB suggested by Microsoft about OWA/ECP being broken after CU security update but issue still persists:
https://docs.microsoft.com/en-us/exchange/troubleshoot/client-connectivity/owa-stops-working-after-update
I’ll install 4.8 and re-apply the CU23 security update tonight I’ll see if this resolves our issues.
Also, I noticed that there’s a new release for the Security Update but only applied to 2016/2019 Exchange servers. Wondering if Microsoft discovered bugs on the initial release.
The new releases for Exchange 2016 and 2019 are to help customers get servers to a protected state ASAP. Microsoft focused on the servers under current support. As to your issue, a reinstallation following .NET 4.8 can’t hurt.
I was already on WS exchange 2016 CU 19, so I’ve applied the security update. How can I prove the update applied? It said it was successful and I requested a reboot afterwards which was done, but I can’t see it in a list of applied hot fixes, the only thing I do see is in program and features, ms exchange server 2016 CU 19 was installed at the time of installing the sec update.
Dates on files? I’ll ask Microsoft for a firm answer. It’s a good question…
Run Get-Command Exsetup.exe | ForEach {$_.FileVersionInfo}
Patched systems file versions:
Exchange Server 2019 For CU7: 15.02.0721.013
For CU8: 15.02.0792.010
Exchange Server 2016 For CU18: 15.01.2106.013
For CU19: 15.01.2176.009
Exchange Server 2013 For CU23: 15.00.1497.012
I also updated the text with information about using a Microsoft script to return details.
I’ve been tasked to overlook the impact of theese vilnerabilities on a couple of exchange servers. I found that they are running on CU14, there is no patch for CU14. Should I update to latest CU and then do a Windows Update to receive the latest patches? I have to assume that we are vulnerable at CU14 too, right?
Did you have a look at the Microsoft presentation I reference in the post? That has the answer to your question. A cumulative update is superseded by another CU. If you’re running an older CU which is patched by a newer, then the patched vulnerability exists in the older CU.
Sorry, no I had not. I don’t want to come off as lazy, I just got lost in all the tabs digging for more information. It’s closing in on 11pm in Sweden so I’m starting to loose the edge. I’ll grab another cup, read your references and power through this.
Thanks for helping me understand this!
Don’t worry. It’s a difficult time for lots of people.
Anyone else having this update break 2019 CU8?
Break in what way? It’s kind of hard to look for help when you don’t have details.
Sorry for the ambiguity. I found where the OWA and ECP sites were breaking for several people after posting this and this was my result. I ended up having to install it via Windows Updates and things installed fine. I even tried installing as admin, but this seemed to be the only solution.
No worries. I’m glad that you got things sorted.
It’s a while since I installed a roll-up update for Exchange 2010. The good news is that you’re at least at SP3. The bad news is that I don’t know if you can go straight to RU32. I will ask.
https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2010-service-pack-3-march-2-2021-kb5000978-894f27bf-281e-44f8-b9ba-dad705534459
Thanks Tony. I have searched everywhere for this info and can’t find anything.
My Microsoft contacts say: Yes, they can. However, there will be C++ and .NET updates in their future (aka.ms/exmatrix)
great news… well, still a risk moving up so many Roll up’s wouldn’t you say?
can you also please clarify what you mean with “there will be C++ and .NET updates in their future (aka.ms/exmatrix)”
I read it as meaning that because the servers run Exchange 2010 SP3 RTM, they won’t have been updated with the C++ and .NET updates required to move forward with the roll-up updates that they should have received, which means that you can expect to have to apply those updates now.
I’ve personally done this on Exchange 2010 recently, and its not a huge deal as long as the server is healthy.
From SP3 RTM….
Install Update Rollup 21
Install the Visual C++ Redistributable
Install Update Rollup 22 (probably not entirely necessary, but it validates that Visual C++ is installed)
Install Update Rollup 30 (For me, updates 31 and 32 were installed via Microsoft Update, but you should be able to just go straight to 32)
Good luck!
I guess the critical phrase there was “as long as the server is healthy…”
Thanks Jonboy.
Yes well exactly, how do I check the server is healthy? I’m not being funny here. It is working and has for some time but I am still a bit nervous as we don’t have any test/dev nor do we have a robust rollback plan. i.e our backups are at the data level, not like with veeam etc.
Since our 365 migration is halfway through and we have completely blocked access to port 443 (yes we don’t use OWA) would it be completely crazy to just power on with the migration and not run this update. Heck we are only like 3 weeks away!
love the website btw
You don’t need to install UR21 or 22 or 30 you can go direct from SP3 RTM to rollup 32. I did. In fact rollup 32 even gives you the download locations for VC redistributable if you don’t have it installed.
Hi all,
great timing 🙂 not….
We are halfway through our migration to 365 running a hybrid Exchange 2010 setup. We have blocked all 443 traffic, however the Business is very nervous and have requested the patch to be installed.
Running SP3 RTM installed. Can we go from that straight to CU32?
It’s a massive jump and I am concerned of the risks. We don’t have any test environments either.
Hmmm why the hell are you still running Exchange 2010 SP3 RTM and not any CU? In CU 31 there were also some security issues fixed….
I would see what Windows Update offers you in Exchange 2010 Cumulative Updates….
I’ve found that all issue regarding patching Exchange 2010 comes from OS patch level. I had a WinServ 2008 (none R2 !) with Exchange 2010 SP1 when I joined the current place I work at. After doing a backup for the VM I upgraded to R2 and patched it to SP1 along with the post SP1 packs provided by MS. After that I upgraded Exchange to SP3 and started applying the CU’s. Besides a few glitches in the prehistoric Exchange Management Console everything is working smoothly. I applied the latest urgent CU32 and everyone is okay.