Latest posts by Paul Schnackenburg (see all)
- Repair a corrupt EDB file with Stellar Repair for Exchange - Tue, Jan 14 2020
- Fixing WSUS issues with the SolarWinds Diagnostic tool for the WSUS agent - Tue, Nov 26 2019
- ManageEngine Desktop Central: Unified endpoint management for Windows, Linux, and Mac - Wed, Sep 18 2019
MetaCache Database (MCDB) ^
I often ask my students, "when it comes to HDD storage, what's the one thing that has changed and the one thing that hasn't?" Speed isn't really improving—15 years ago I could buy a 15,000 RPM drive, but it would have been a lot smaller than today's 8 or 10 TB drives (with 20 TB on the horizon).
To manage this abundant but slow storage, Exchange has been on a mission to reduce storage input/output operations per second (IOPS) ever since Exchange 2007's release. And indeed Microsoft runs Office 365's fleet of Exchange servers (all 175,000 of them) on ordinary, slow 10 TB HDDs (they're just about to upgrade to 12 TB HDDs). This is part of the preferred architecture (PA), a set of guidelines Microsoft provides for the "best practices" deployment of Exchange Server.
Note that this deploys Exchange on physical servers, not virtualized ones, and it relies on Exchange native data protection by having multiple copies of your mailbox databases on separate servers in a database availability group (DAG).
If you do deploy on physical servers and you have the option of adding some SSD drives to those servers, you can enable MCDB. This technology—which Microsoft is using in Office 365, so it's battle hardened—stores mailbox meta information such as folder structures, item meta data, or even small items. This speeds up mail access by 2 to 3 times, logon times by 50%, search times by 50%, and also means you can house up to 20% more users per server. Obviously, user density is a key point for a service as large as Office 365, but an enterprise that can buy 20% fewer servers for their new Exchange cluster should be happy as well.
It's important that you design with the same size and number of SSDs in each member server in your DAG. Microsoft recommends one SSD per three HDDs, with 5–6% of the capacity of your HDDs and preferably M.2 SSDs as they don't use up drive slots in your servers like 2.5" SSDs do. Leave the drives raw so that Exchange knows which ones to use. T
hree categories of SSDs are on the market today: consumer-grade ones on the lower cost end of the spectrum and write-intensive drives on the high end, with normal enterprise drives in the middle range. Microsoft uses the middle-of-the-range drives (the size of the SSD in writes per day) and recommends you do too.
Be aware MCDB stores two copies of the data: a smaller Exchange Database (EDB) file on the SSDs (one per database on the server) and the normal full database on the HDDs. If an SSD fails, there's no loss of data—the user experience will simply revert to pre-SSD speeds.
If you're in a DAG and other healthy SSDs on other servers have the cached information, it'll replicate it from those servers onto the replacement SSD, a process that takes 10–20 minutes. If that SSD was the last one, the cache will simply build up as it does when you first enable MCDB.
I know that many enterprises virtualize all of their workloads, including Exchange, departing from the PA. Some are even lucky enough to run on all-flash arrays (probably not with 100 GB per mailbox quotas though). MCDB will of course not apply for these deployments.
But if you're deploying according to the PA and looking to retire your existing Exchange 2013/2016 cluster and deploy on new hardware, MCDB is a no-brainer. For a small additional cost (remember you only need 5–6% "extra" SSD space), you will dramatically improve the end-user experience.
Building on the work in Exchange Online for storing search indexes, Exchange 2019 brings an entirely new search stack. Previous versions maintained the search index for each mailbox database outside of the database itself. This meant a separate high availability setup for index storage and having to manage resources for two separate parts of the server. There are also challenges around compliance as Exchange applies mailbox encryption separately to the index store.
Exchange 2019, like Exchange Online, moves index storage into the database itself. It has also moved index creation to when a message arrives rather than as a background task. It will scan large messages later, either within a few seconds or on a scheduled basis. Indexes for each item are per-object indexes (POIs), which Exchange stores with the item, in each mailbox. Previous versions also had to create indexes for each copy of a database in a DAG; the new process means it only has to index a message once.
In the actual user experience, not only is searching faster, particularly if you employ MCDB, but the search results are more relevant. Instead of showing the first sentence or two of a message that may have your search term further down in the message, it'll bubble up the particular sentences in those emails that contain the term. This comes from technology imported from Bing.
Dynamic Database Cache ^
Dynamic Database Cache (DDC) is another addition to Exchange 2019 that has to do with how much memory it uses in caching per database on a server in a DAG. In 2016, when you size the cache—say 500 MB per active database and 250 MB per passive, and you have a maximum of 10 active databases on the server (5 passive)—you'll be using 6.25 GB of memory.
When you balance the DAG, however, and now only have seven active databases, the memory allocations don't change, and you'll only be using 4.75 GB, wasting the additional 1.5 GB. DDC in Exchange 2019 will use the additional RAM when the server has a balanced number of active databases, increasing your cache hit ratio and improving the end-user experience.
As a meeting creator, you can now set it so that the people you invite can't forward the invitation to other people. Recurring events will now have a default end date rather than continuing "forever." New settings for Out of Office (OOF) allow you to block out the calendar for a set time, automatically declining any meeting requests for the OOF period.
You can now send and receive emails from Email Address Internationalization (EAI) email addresses (with Greek, Traditional Chinese, Japanese, or Cyrillic characters); however, you still can't add an email domain with these characters.
With the move to use layer 4 load balancing with Exchange some years ago, one downside was that once you publish your endpoints for management, there was no easy way to limit user access. Exchange 2019 introduces Client Access Rules, which let you limit access to the Exchange Admin Center (EAC) and PowerShell endpoints based on user or IP address ranges.
Note that the administrator's mailbox must be on an Exchange 2019 server for EAC restrictions to work. And while you're in a mixed-mode deployment, the PowerShell endpoint cross-version compatibility may mean that a connection through an Exchange 2019 to a 2013/2016 backend server may not be restricted as you'd expect.
Exchange Server 2019 is a solid release, but there aren't enough amazing features to call this a full release—perhaps 2016 R2 would have been a better name. Businesses that are still keen on running Exchange on premises today either have very strict regulations that prevent a move to the cloud or have decided to hold out for some other reason. For these customers, Exchange 2019 is a good way forward, particularly if you can delight your end users with the new performance enhancements in access and search.