This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(96, 27%, 19%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
Hello, we have a single Exchange 2016 server running as a VM allocated with 6vCPU and 28Gb RAM. 2 databases and about 1000 mailboxes. We have a smart host appliance provided by Barracuda at the perimeter responsible for handline all inbound/outbound mail. Yesterday one of our vendors sent a mass email to all employees and the CPU of our mail server spiked to 100%. This caused some Outlook clients to drop offline intermittently and the smart host started spooling mail. I saw two different SMTP responses in the smart host for deferred messages that could not be delivered to our Exchange server at this time..
Anyway, this all eventually worked out. The messages spooled on the appliance and as Exchange CPU usage reduced all messages were eventually delivered successfully.
Question is, what can be done to prevent this scenario in the future. This mass email from our vendor resulted in a mini DDoS attack essentially. I am very surprised there is no mechanism in our Barracuda smart host or Exchange to deal with something like this. Some kind of sending domain rate limit mechanism maybe? Is there any feature of Exchange that could help here?
@Anonymous
I am writing here to confirm with you any update about this thread now?
If the suggestion below helps, please be free to mark it as an answer for helping more people.
Well, actually there was. Exchange backed off the connection (421 4.3.2) and forced the barracuda to essentially slow down.
The bigger issue is the mail delivery on Exchange itself caused issues. Was this server sized with the mailbox calculator?
6 vCPU and 28GB RAM seems really undersized to handle spikes.
Lol, I cannot make any sense of that awful spreadsheet. I've looked at sizing RAM for Exchange multiple times and the server will take just as much as you give it. If you have problems, "add more" has been the approach so far. Not exactly proactive. I'll take another look at the sheet, but it has never been helpful in the past.
You mention that 6vCPU and 28Gb RAM seems low. What should it be and why? Aside from this instance of a mass email to all employees, Exchange seems to operate normally for all users. Some kind of mechanism that prevented a particular sending domain from spamming unlimited messages into the environment while allowing others to flow inbound would be cool. Throttling per domain...
Regards,
Adam Tyler
well, the proof is in the pudding :)
You have seen that it cant handle the spike when it happened. All I'm saying is that if 99% of the time Exchange is running fine, then not sure I would worry about the specs, however if you want to be ready for the next time this happens, then you have to either scale up or out. So either add more resources to the existing server or add more servers ( And build a DAG) and spread the load across multiple servers.
I've actually seen a few people complain about this same issue. I personally have never seen it because when I always scale out and try to have more than I need server/resource-wise.
However, I get there are costs with either solution, but that is really what is needed.
As for preventing unlimited messages , there is throttling in Exchange that prevents that backs off connections by IP and time etc...
The defaults are set in the receive connectors and transport service.
https://learn.microsoft.com/en-us/powershell/module/exchange/set-receiveconnector?view=exchange-ps
The MaxInboundConnectionPerSource parameter specifies the maximum number of connections that this Receive connector serves at the same time from a single IP address.
A valid value is from 1 to 10000, or the value unlimited. The default value is 20.
To disable the inbound connection per source limit on a Receive connector, enter a value of unlimited.
But based on your description, that wasnt the issue you faced, since you saw this error "421 4.3.2 The maximum number of concurrent server connections has exceeded a per-source limit, closing transmission channel"
it sounds to me like Exchange throttled the connection, but what it couldnt handle was actually processing all those messages once they were received.
Hmmm. In our case all email appears to come from the same place because we are using a smart host at the perimeter I am thinking. It's not like the Exchange is smart enough to look at the details of the header and flag the original sending mail server source IP right?
In regard to scaling out, say we had multiple Exchange boxes, it would require some kind of a load balancer to deliver mail to multiple internal servers. Or is that not the typical approach? doesn't appear that our perimeter smart host device has the ability to deliver to more than one internal mail server IP.
Regards,
Adam Tyler
Correct, it doesnt look at the original sending IP, just the server connecting directly to it.
Yes, Load Balancer is recommended. To deliver you can have the smart host deliver to the load balanced IP or FQDN if it cant handle multiple IPs
Okay, thanks for the input. We're a VMware shop, so adding a few more CPU cores to the existing VM seems like an easier path forward for now. I'm sure we will end up on M365 before too long, so putting effort into reengineering on prem exchange seems a little silly.
Do you have a favorite load balancer solution for Exchange? Just in case I press forward..
Regards,
Adam Tyler
f5 has always been a good choice, but its pricey.
Kemp is a good solution:
https://kemptechnologies.com/microsoft-load-balancing/load-balancing-microsoft-exchange/
However, if you are planning to move to 365, I'd just beef up that existing server until you do.