Exchange Center

ENow Software's Exchange blog built by Microsoft MVPs for IT/Sys Admins.

business man touching cyber padlock

Securing Exchange Servers

Image of Nathan O'Bryan MCSM
Nathan O'Bryan MCSM

Securing Exchange Servers

Securing Exchange servers is hard. I mean it can be a giant pain sometimes. There are what, hundreds of millions or maybe billions of lines of code running on your Exchange servers, right? It doesn’t take much for a typo to get through and open a vulnerability that can then be exploited opening the most important and valuable data within your organization to all kinds of bad actors.

Read More
activated online archive mailboxes

Floating Mailbox Databases in Exchange 2019: Pros & Cons

Image of Thomas Stensitzki
Thomas Stensitzki

Since the early days of Exchange Server, the limits of user mailboxes were strictly regulated. In many Exchange organizations, these quota limits were configured on a mailbox database level and were therefore consistent for all mailboxes stored in the same database. This approach was selected because the existing hard disk space was scarce and expensive in the past.

The following example shows two databases (DB-USER-1 / -2) for standard users and one database with larger mailboxes for executives (DB-C level).

The approach to configuring quotas at a database level was never questioned when transitioning to modern versions of Exchange Server. The old operating patterns were merely taken over.


With modern Exchange Server versions and the Preferred Architecture recommendations this type of servicing of mailboxes no longer makes sense. One of the essential non-technical recommendations is to standardize and simplify the daily operation of the entire Exchange Server platform. Especially with a hybrid setup, which is the parallel operation of a local Exchange organization a and Exchange Online, it is recommended to simplify the service model.

You can standardize and simplify Exchange Server operations by configuring mailbox quotas at the mailbox level. This standardization eliminates the need for dedicated mailbox databases for different user groups. You can move mailboxes between any database, allowing you to respond to on-premises IT infrastructure challenges more flexible.

The following example illustrates this standardization with three mailbox databases (DB-1 / -2 / -3) which store a different number of mailboxes with varying quotas of mailbox.

The simplification becomes even more apparent when we look at the distribution of varying user mailboxes (MBX, blue/yellow) and activated online archive mailboxes (ARC, green).

In addition to user mailboxes and online archive mailboxes, there are other types of mailboxes:

  • Room and resource mailboxes (RES, gray)
  • Public folder mailboxes (PF, orange)

For simplified and standardized operation, these additional mailbox types provide the following example with mailboxes distributed across five mailbox databases.

With a modern implementation of Exchange Server utilizing a Database Availability Group (DAG), you do not need a traditional backup solution. All required functions to protect mailboxes and mailbox content are integrated into the Exchange Server product. Therefore, it does not matter in which database a particular mailbox is stored. This type of operation is the same as the operating model in Exchange Online. In Exchange Online a user mailbox is stored in "a" mailbox database on “some” Exchange Servers.


Are there any disadvantages for such a simplified and standardized operation of mailbox databases in an on-premises Exchange organization?

There is one disadvantage to a standardized operation in an on-premises Exchange organization, at least if you continue to rely on traditional backup methodology and regularly restore mailbox content from a classic (or legacy) backup. In this case, you need to know in which database a mailbox was stored at the time of backup to restore exactly that single database explicitly. The Active Directory object of a mailbox owner has no history of the previous locations of a mailbox. The object stores the current mailbox database location only.

There are no restrictions regarding security for the service operation and administration of Exchange mailboxes. With Exchange Server Role Based Access Control (RBAC) you have all the options to allow management of dedicated mailboxes, e.g., executive mailboxes, to only specific support personnel.  You should refrain from restricting the access to Active Directory objects by adjusting object permissions directly. Modifying the object security settings is much more insecure compared to controlling access using RBAC.


Modern operation of an Exchange organization with database-independent control of mailbox quotas provides flexibility and standardization. In a hybrid setup with Exchange Online, you operate mailboxes in the local Exchange organization in the same way as in Exchange Online. Therefore, you have a consistent mode of operation. The only differences are the different mailbox quotas compared to Exchange Online. Ideally, you also adjust the mailbox quotas in the on-premises Exchange organization to match those in Exchange Online.

If your on-premises IT infrastructure does not provide the necessary operational parameters for secure and stable operation of Exchange Server, but mailbox availability is essential to your business, then Exchange Online is the better alternative.


Enjoy Exchange Server.

Read More
Exchange tile icon

Exchange 2019 CU4 and Exchange 2016 CU15 Explained

Image of Jaap Wesselius
Jaap Wesselius

On December 17, 2019 Microsoft released Exchange 2019 CU4 and Exchange 2016 CU15 as part of their quarterly release cycle. As expected, no new features in these Cumulative Updates. According to the Microsoft vision, if you want the latest and greatest you need Exchange Online, if you’re satisfied with a rock solid on-premises deployment you’re good with these versions. And since Exchange 2013 is out of support, no Cumulative Update for Exchange 2013 is released.

Read More
Group of business people assembling jigsaw puzzle and represent team support and help concept

LDAP Policies & Exchange Deployment

Image of Ingo Gegenwarth
Ingo Gegenwarth

The Exchange Team provides you the Exchange Role Requirements Calculator now for a long time. This tool is still maintained and the preferred one for correct sizing. You can find information on how to use it on this EHLO blog post.

Although the calculator takes several  scenarios into account, it cannot cover everything. One of these are LDAP Policies, which exist since Windows 2000. These policies are your friends as they help to safeguard your Active Directory Domain Controllers. When Exchange 2010 throttling policies were introduced, which have the same purpose: Manage performance and heath of your Exchange servers. If you are not familiar with, I recommend reading this(old) Docs article as the new one doesn’t contains much details.

Why should I care?

There is a recommendation about the ratio of CPU cores of Active Directory global catalog cores for every mailbox server core of 1:8, but nothing related to LDAP client connections.

When you look at LDAP policies, you will see there is a property MaxConnections with a value of 5000. This limit is for per Domain Controller for ALL clients. You might think this is quite a high number, but here is an example of a DAG with preferred architecture:

  • 1 DAG with 4 servers
  • 72 databases
  • Each database has 4 copies (3 high available and 1 lagged)
  • Evenly distributed across all servers

In a normal situation, where every server is in a healthy state, each server holds 18 activate and 54 passive databases.

Since Exchange 2010 every database has its own Microsoft.Exchange.Store.Worker process, which is an improvement in terms of availability and performance, but this process also establish a connection to a domain controller. And this is not the only process, which is doing this. Every Exchange related process (e.g.: MSExchangeHMWorker, MSExchangeFrontendTransport) will do and some of them even more than one like w3wp.exe. You can check easily check the number of connections your Exchange server has established to a domain controller with PowerShell:

Open an elevated PowerShell and run the following commands:

  1. $DCConnections=Get-NetTCPConnection -RemoteAddress  
  2. $DCConnections | group OwningProcess | sort count | select count,@{l="Process";e={(Get-Process -Id $_.Name).ProcessName}},@{l="ProcessID";e={$_.Name}} | ft -a  
  3. $DCConnections | group OwningProcess | measure -Sum -Property count  

In this example you see that the IIS worker for Exchange Active Sync established 4 connections to one of the domain controllers.

This server established in total 98 connections to one domain controller and Exchange will do the same to any other domain controller. Now you have to do the math and keep in mind that Exchange might not be the only client. Here an example:

Assuming you have 4 DC with 40 CPU cores in an AD-Site:

4*40 = 160 CPU cores (AD) è 160*8 = 1280 CPU cores (Exchange)

Furthermore, you have in this AD site 40 Exchange servers with each 24 CPU cores, which gives you a total of 960 CPU cores. From ratio perspective you are below the required ratio, but from LDAP connection perspective you have already approx. 3920 per domain controller, which is 78,4% of the allowed.

What happens when the connection limit is reached?

By design a domain controller is looking into idle connections and will drop them as needed. Idle connection doesn’t seem to sound too bad, right? From Exchange perspective it is as Exchange has a pool with active domain controllers and checks them periodically. If a domain controller is not responsive, it will be removed from the pool and re-added after successful check. It can be that after a successful check, the domain controller terminated the connection. When this happens, Exchange assumes that the server is healthy and will send requests to. These requests will fail, and as unforeseeable things can happen e.g.: unexpected prompts for credentials, database failovers, server performance decreasing. This is what I have seen in an environment running into this issue.

What is the fix?

Even though the KB article is old it’s still valid: How to view and set LDAP policy in Active Directory by using Ntdsutil.exe

The good thing about this is that you can configure the policy either per domain controller or per AD site. Thus, it gives you the ability for carefully testing, which should be always done.

After you applied the new policy you can verify that the increase was successfully implemented:

There are several servers above the 5000 LDAP Client Sessions limit.


This scenario cannot be found in any environment. It also doesn’t apply only to large environment as it’s depending on many aspects like ratio, installed application and number of clients. But something you should check and monitor. The impact for the domain controller should be marginal on newer hardware. In this environment the value for MaxConnections was increased to 15.000 without any negative impact.

Read More
Email security listing image

Email Security - How to Protect Against CFO Fraud

Image of Jaap Wesselius
Jaap Wesselius

Everybody receives spam and phishing email. Most of the time they are easy to recognize and just annoying, but sometimes there’s phishing email that’s harder to detect by eye. Imagine you’re the CFO of a company and you receive an email from your CEO where he asks to transfer $ 50,000 to an account. And you cannot talk about it, because it is for an unannounced acquisition.

Read More