On September 17, 2019 Microsoft released its quarterly updates for Exchange. This time, the updates contain Exchange 2019 Cumulative Update 3 and Exchange 2016 Cumulative Update 14. No updates are released for Exchange 2013 or Exchange 2010.
Over the past 20 years we’ve seen some dramatic changes in Microsoft Exchange Server. Exchange server 2000 was the first version that was using Active Directory, after switching from its own directory that was in Exchange server version 4.0 until version 5.5.
In an earlier blog post I wrote about Autodiscover changes, especially when using Outlook 2016 Click-to-Run.
The virtualized operation of Exchange Server has been a hot topic for discussion ever since the introduction of hypervisor platforms. Often these discussions are very emotional, and the valid arguments rarely heard.
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.
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:
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:
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.
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.
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.
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.
SSL Certificates in Exchange are widely used, both for encryption of traffic as well as server authentication. Despite the fact they are widely used, a lot of admins still think certificate management is difficult (and expensive). But it is not, let me explain.
The current version of Exchange can, and in most cases should, be installed on Windows Server Core. Windows Server Core is a version of the Windows Server operating system that does not have a Graphical User Interface (GUI). Since “windows” are well ingrained into the administrative habits of most of us Windows Server administrators, it’s reasonable to expect that most Exchange administrators are going to be a bit hesitant to go down this route.
Many companies use old-style public folders, known as legacy public folders, on Exchange Server 2010. Often, the public folder hierarchical structures have grown uncontrollably for years. And not only in terms of data volume but also in the number of folders and the folder depth in the public folder hierarchy. For these reasons, many companies fear legacy public folder migration to modern public folders.
On February 12, 2019, Microsoft released its quarterly updates for Exchange server, and in this case Microsoft has released Exchange 2019 CU1, Exchange 2016 CU12, Exchange 2013 CU22 and Exchange 2010 SP3 Update Rollup 26 (although the latter is not really a quarterly update).