In this second post about the new features in Exchange 2019, we'll look at the two big-ticket improvements in Exchange 2019, both taken directly from Office 365: MetaCache Database (MCDB) and BigFunnel.

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.

Exchange Server database management

Exchange Server database management

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.

BigFunnel ^

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.

Enhancements ^

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.

Creating a rule to block PowerShell

Creating a rule to block PowerShell

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.

Subscribe to 4sysops newsletter!

Summary ^

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.

  1. Ardian Anggara 3 years ago

    We are moving by upgrading the exchange server to 2019. But the Outlook search or OWA search is not working anymore. this really pains us. not sure how to check on BigFunnel. do you have any idea?

  2. Author
    Paul Schnackenburg 3 years ago

    Hi Ardian,


    I don't really know exactly how to check on BigFunnel – here are the docs from MS, not sure if that's useful. 



  3. JAG 2 years ago

    Hi Paul,


    Great article!

    Just curious, for a standalone physical server with 3 X 1.6 Terabyte Mailbox Databases, could just 1 800GB NVME drive suffice? or would this require qty 3 SSDs?


    Thank You

    • Author
      Paul Schnackenburg 2 years ago

      Hi Jack,

      Glad you liked the article.
      It depends, not so much on the size of the databases, but on the number of physical HDDs that underlies them. How many drives do you have? Are they just plain drives (not RAID) as the Preferred Architecture specifies?
      The recommendation is one SSD per three HDDs so that’ll be your design point.
      Having said that, I don’t know whether you’d get better performance if you just introduced a single SSD, I don’t have a system of your size to test that.
      Let us know about the number of drives,


  4. Jack Golightly 2 years ago


    System sits on Raid 1 (2 x 800GB Samsung PM1645a 800GB Mainstream SAS 12Gb SSD)

    Mailbox Database Drives are 3 x Raid 1 (2 x Samsung PM1645a 1.6TB Mainstream SAS 12Gb SSD)

    All NTFS with Database whoa! Realtime surprise – Computer Management -> Disk Management says NTFS but DiskPart -> Select Vol -> Filesystems says all three are formatted REFS!!! 64kb stripe size is what I formatted but what I saw was NTFS when I pulled the trigger.


    Anyways my point is that I do not have any HDDs but they 'are' limited to 12Gbit/sec so the NVME disk(s) would be faster still.


    What I do not get is the tie to Database Availability Groups?

    There is no DAG in this configuration.


    Thank You

  5. Author
    Paul Schnackenburg 2 years ago

    Hi Jack,

    There's no tie in to DAGs specifically BUT the Preferred Architecture assumes that you're using clusters and DAGs (after all, you don't want a single failed server to bring down your entire Exchange environment). 

    I'm not really sure what the NVMe disk will give you in this scenario, as mentioned, Microsoft assumes individual (non-RAID) HDDs for storage of your mailbox databases and the SSD for caching is "icing on the cake". 

    Or put another way – are you or your users seeing degraded performance today? You've got some sweet SSDs there – they'll be LOT faster than HDDs. 

    Hope that helps,


  6. Jack Golightly 2 years ago


    Yes, I think you  are correct – that perhaps this won't really offer that much of a gain.

    Comparing the technical specs, yes the NVME drives are faster BUT it is hard to say whether performance gains would be realized.

    Thank You!

  7. Clive 12 months ago

    Nice article, but a shame that Microshaft broke search functionality in Exchange 2019.

    We have numerous users who can’t find emails via search and no way to rebuild the search index. Microsoft’s command does nothing and despite their assurance that it’s fixed in the latest CU it still doesn’t work.
    I’m tempted to roll back to 2016 as that worked much better.

    Given that we pay for Exchange on Prem, you’d think that Microshaft would be more willing to fix the issue.

    • Author
      Paul Schnackenburg 12 months ago

      Hi Clive,
      I hear your frustration and I’m sorry that you’re caught up in Microsoft’s focus on the cloud and neglect of on-premises products. I didn’t know about the rebuilding of the search index not working, very poor showing from Microsoft.

Leave a reply

Your email address will not be published.


© 4sysops 2006 - 2022


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account