We had many significant Exchange related announcements at Ignite this year, including many for Exchange Server 2019 and Exchange hybrid. However, to the dismay of many, there was still no announcement for eliminating the last Exchange server after migrating to Exchange Online while still running directory synchronization.
The focus of this post will be updated for Exchange Server 2019, with other posts being provided for further updates.
Exchange Server 2019
This was pretty major because there have been architectural changes in Exchange Server that are a significant shift from the long journey to “cloudifying” even the on-premises product.
Windows Server 2019
While the preview releases of Exchange Server 2019 have been running on Windows Server 2016, Exchange Server 2019 RTM will only run on Windows Server 2019. This is a great move. In the past, you could always tell that the latest version of Exchange was written to prefer the Windows release that would be coming out just a little after its own release. For instance, Exchange Server 2010 was just more polished on Windows Server 2008 R2, but if you were an early adopter, you were running in Windows Server 2008. Likewise with Exchange 2013 and 2016 with Windows Server 2012 R2 and 2016 being the preferred options, respectively.
Since Windows Server 2019 will not be available until October, Exchange Server 2019 preview runs on Windows Server 2016. Exchange Server 2019 will be released before the end of the calendar year.
No Unified Messaging
Unified Messaging has been eliminated from Exchange Server 2019. This reduces the total install size by about 20% when including the language packs. The UM capabilities were really something that spoke to the relationship between OCS/Lync/Skype for Business with the UC products handling the phone call and Exchange handling the voicemail. The Skype for Business/Teams product team is now responsible for voicemail in the form of Cloud Voicemail. The voicemail messages still end up in the Exchange mailbox, wherever it resides, but Exchange no longer needs to speak SIP, answer calls, and offer an interactive voice interface.
In addition, the removal of UM eliminates the dependency of Exchange on the Desktop Experience features in Windows Server, which means…
Windows Server Core is not only supported in Exchange Server 2019, it is the recommended way to run Exchange Server. Even when executing Exchange Management Shell on an Exchange Server, the process is still “remoting” to the server.
Volume Licensing Only
Exchange Server 2019 will only be available via volume licensing, including no longer having an option for the free hybrid co-existence license for customers that have migrated to Exchange Online. I would not be surprised if we see a change here to allow for the hybrid co-existence license as there was no announcement to end the requirement.
Hardware Requirements Recommendations
This is pretty significant on it own. If you do not recall, there has been a long evolution occurring with Exchange Server. Exchange Server 2003 was the last version of Exchange that really supported the legacy hardware strategy of building wild redundancy into each server and packing it with the fastest storage as possible. Exchange Server 2007 marked the use of the x64 platform which provided for significantly greatly addressable memory. Exchange took advantage of this for caching and reduced the disk I/O requirements for the same amount of data over each release through 2016. The Preferred Architecture said to implement cheap SATA HDDs in a JBOD configuration and rely on the full stack redundancy provided by having multiple servers in a database availability group.
Another thing to keep in mind is that Exchange Server 2013 was essentially a rewrite of Exchange Server in .NET managed code, while retaining a rather similar architecture as Exchange Server 2010. While Exchange had been requiring additional memory for two releases, Exchange Server 2013 had about a 50% increase in required memory due to the use of .NET. This is because of the means that .NET employs to allocate memory. Also, this aligns with modern hardware. CPU cores and sockets have more direct access to some memory in the system over other memory; it is just how the system bus works these days. .NET allocates more memory the more CPU cores are available in the system. This is why the recommendation had always been to limit the number of CPU cores to about 24 and the maximum memory to 96GB.
The new recommendations are still based on the preference for physical hosts rather than virtual machines.
New servers come with new processors that have ever an ever increasing CPU core count. The previous recommendation was for up to 24 CPU cores (ideally on two CPU sockets). The new recommendation if for 48 CPU cores.
With the increased support for CPUs, the minimum recommendation for memory is now 128GB, with a maximum of 256GB. Keep in mind that this is based on supporting a production mailbox load on an Exchange Server. Exchange Server is being targeted towards only the largest of enterprise customers and not organizations with a single Exchange server with a few hundred mailboxes. When the time comes that these organizations perhaps decide to migrate to Exchange Online, an Exchange Server 2019 system can be used as a hybrid coexistence server and use just 8GB of memory, like with Exchange Server 2013/2016.
The recommended memory for an Edge Transport server is 64GB.
Previous releases had standardized on matching the system memory plus 10MB, up to 32GB. Exchange Server 2019 recommends 25% of the system memory for the pagefile size. This aligns with fairly well with the previous recommendations since the recommended memory is 128GB, which would still be 32GB for the pagefile.
The architectural changes are with the storage. It is still recommended to use RAID 1 for the operating system, page file, and Exchange install bits and to have separate JBOD SATA HDDs for databases (which four database replicas between per disk). However, traditional storage hardware has continued to increase in capacity while remaining relatively flat in terms of performance. The hosting 10 rather large mailboxes on a 500GB mailbox database works with the previous versions. But with SATA HDDs supported about 4x the capacity with the same performance, that will just no longer work.
To combat the stagnate performance, Exchange Server is building its own tiered storage mechanism based on the Meta Cache Database (MCDB). Certain aspects of the mailbox will be cache on faster storage. The recommendation is is that the MCDB needs to storage between 5-6% of the mailbox database contents (up to 10% can be used, but beyond that does not create significant improvements). This is done by loading the MCDB on SSD. Rather than having one large SSD for all of the HDDs, it is recommended to have one SSD per three HDDs.
This is how Microsoft operates Exchange Online today. Best practices should be followed by keeping servers symmetrical (same number, sizes, and performance characteristics of disks).
M.2 form factor SSDs are recommended to not consume significant physical space within the server. Mixed-used SSDs are recommended. Write-intensive SSDs are expensive and do not provide significant value.
Meta Cache Database
As stated, the MCDB is a mechanism to cache certain mailbox content. This includes the indices and recent messages (not attachments). This results in 50% latency reduction for search in the new search capability (BigFunnel), and 50% reduction in logon. In addition, 20% more users can be loaded per server and 2-3x faster access to mail.
The Mailbox Table is essentially in the MCDB, which reduces I/O latency and improves the logon speed.
Manage-MCDB cmdlet establishes the behavior for using SSD. It becomes fully managed by Exchange. In fact, Exchange prefers to even format the volumes.
MCDB is opportunistic. So, of the MCDB is compromised, it will fall back to accessing the data on the HDD storage, just with decreased performance.
The MCDB is just another Exchange database and has a one-to-one mapping. For instance, each mailbox database will have one MCDB:
The DocId is used to sort and purge older data from the MCDB.
Dynamic DB Cache
In Exchange Server 2013/2016, RAM caching of databases were distributed between active and passive replicas. Dynamic DB Cache shifts the preference towards active replicas and reduces I/O by 3-7%.
BigFunnel is the new search mechanism in Exchange Server 2019 that is based on technology from Bing. Searching has traditionally been against the index in Exchange Server or within the OST file. Previously, the shift was to use the index on the Exchange Server to maintain consistency, even if utilizing Cached Exchange Mode (CEM). This has been maintained. However, to further improve consistency and to simplify the platform, the content index is now performed per mailbox and is storage with the mailbox, meaning it is replicated with the mailbox and eliminates one database replica from having inconsistency with another database replica.
Captions allow better summarized results and context for searches.
Get-MailboxStatistics has details for BigFunnel.
Windows Server 2012 R2 forest and domain functional levels are required. Exchange Server 2016 RTM required Windows Server 2008 and updated to Windows Server 2008 R2 with a later cumulative update.
The standard practice of supporting coexistence with the previous two releases has been maintained.
- Exchange Server 2016 CU11, or later
- Exchange Server 2013 CU21, or later
No support for coexistence with Exchange Server 2010, or earlier.
Code Forking Away From Exchange Online
Exchange Server is over 20 years old and has its root as the on-premises product. With Office 365, the development quickly shifted to “cloud first” with the features being released after they had been in Exchange Online for some time. However, there is a lot of code that is meant for Exchange Online only; this is apparent when you review documentation and you see parameters that are “Exchange Online only”. Not only does this code increase the footprint, but it also means that this code has to be tested for its potential impact to on-premises deployments.
Previous releases essentially forked away from the Exchange Online code with each cumulative update. Now, Exchange Server 2019 is forked and the plan is that the cumulative updates will no longer be new forks from Exchange Online. I would imagine that the next release of Exchange Server will be a new fork from the code.
Client Access Rules
CARs have been available for a while in Exchange Online and are coming to Exchange Server 2019. CARs allows for restricting access based on version, IP, etc. They are very similar to Conditional Access policies, but are Exchange specific and require no separate licensing.
Will This Be The Last Release of Exchange Server
Unless Exchange Server 2019 becomes an “evergreen” rollout, it is very unlikely that it will be the last release of Exchange Server. Keep a few things in mind and do not put too much stock into the “Exchange Server is dead” crowd. First and foremost, there is no other major messaging platform that has both an on-premises and online offering (please do not suggest that Lotus Notes is a major messaging platform, yes they have an online offering with hybrid… however, I only ever see moves from Notes to Exchange). This means that the offering is a strategic advantage for Microsoft over Google and Amazon.
Further, it is estimated that there are about 350M licensed users for Exchange, in one form or another. Of those, there are 135M users in Office 365. This means that over 60% of users are operating in Exchange on-premises, still.
While the definite trend is towards the cloud, we are only beginning to approach the peak in the curve.
As long as there is customer demand and Microsoft can remain profitable or justify it as a loss leader, Exchange Server will remain a thing. How many times did people say that public folders were dead (or even that they were in fact removed from some version of Exchange Server)?