Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Dig into the Exchange 2016 hardware requirements

A move to Exchange 2016 may mean increased costs to hardware that can support the latest Microsoft messaging platform.

Exchange Server 2016 runs much leaner than previous versions and requires less RAM to operate its various roles....

But Exchange Server 2016 hardware requirements are complicated and still up for debate among users.

Microsoft claims that companies can install Exchange Server 2016 on a 30 GB system partition, but that won't support the OS alone, especially if you plan to update it over the years. In practice, admins should have at least 100 GB for the system partition running an Exchange application. Otherwise the databases will end up on a separate disk.

Much like previous versions of Exchange Server, Microsoft still does not recommend virtualization.

Exchange Server 2016 also requires 8 GB of RAM for the mailbox role and 4 GB for the Edge Transport role; it must run on Windows Server 2012 or later. Microsoft has some guidance available on sizing CPU. Users are probably looking at a bare minimum of two cores running at least 2 GHz each.

Despite these guidelines, many system administrators will run Exchange on some flavor of unsupported hardware.

Exchange 2016 hardware requirements and design

Much like previous versions of Exchange Server, Microsoft still does not recommend virtualization. In practice, there's no real issue with running Exchange in a virtualized environment where the storage runs on top of Network File System.  A rather large number of systems administrators have been doing this for years without issue. However, Microsoft does not certify or support this.

If official support is required, look to the Microsoft Server Virtualization Validation Program. You should also check out Microsoft's Exchange 2016 system requirements page. And check that your hardware or hypervisor vendor will support your environment, so you don't have to rely on Microsoft.

An upgrade from Exchange Server 2010 or 2013 to Exchange 2016 features some architectural changes that reduce the stress on the storage subsystem but come with increased CPU requirements. Improved multithreading support balances this out. Also, thanks to the replacement of  the Information Store process with the Managed Store process -- a change introduced in Exchange 2013 -- Exchange 2016 ends up being faster in multi-database scenarios on high-core count servers.

Exchange is no longer an application that will consume the resources of an entire physical server. It can run alongside hundreds of applications on a virtualization cluster. Because of this, Microsoft cut the number of roles that Exchange Server 2016 supports. It no longer breaks all the different functions of Exchange into individual systems -- each with their own redundancies and complexities.

Next Steps

Is cloud or on premises cheaper for Exchange?

Upgrade considerations for Exchange 2016

Why admins should consider an Exchange Server 2016 update

This was last published in January 2017

Dig Deeper on Microsoft Exchange Server 2016

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

3 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What infrastructure changes must you make to upgrade to Exchange Server 2016?
Cancel
This article is full of errors:
* Exchange 2016 requires at least WS2012 R2, not WS2012
* Downplaying the risk of running on NFS by stating "there is no real issue", just don't. Period. Also, JBOD is more cheap, less complex and thus less chance of performance or other issues.
* The author makes some false claims that Exchange 2016 would run faster compared to Exchange 2010 or Exchange 2013 on the same multi-core hardware. Hardware is utilized differently, yes.
* Author claims Exchange is more "virtualization friendly", and that is the reason the number of roles were cut down. Nonsense.
* No word on using the Server Role Calculator. Use this to calculate or verify your (planned) deployment.
Cancel

Hi there.  First off, I'd like to say that I respect you and your opinions a great deal and in no way wish to be adversarial.  That said, I must disagree with some of your points.

 

1) Exchange 2016 requires at least WS2012 R2, not WS2012

 

With apologies, that’s not what Microsoft says here: https://technet.microsoft.com/en-us/library/aa996719(v= exchg.160).aspx

 

2) Downplaying the risk of running on NFS by stating "there is no real issue", just don't. Period. Also, JBOD is more cheap, less complex and thus less chance of performance or other issues.

 

This is a matter of opinion and something very much debated within the industry.  Microsoft's Exchange team is, of course, of the “don’t use NFS ever” viewpoint.  It is important to note that their viewpoint is not remotely the only one.  More importantly, perhaps, many highly qualified and very experienced people disagree with the Microsoft Exchange team on this (and several other issues).  These disagreements extend even to the point that some vendors are willing to take ownership of Exchange support issues when run on their NFS storage.  This is no different than VMware taking ownership of Oracle's support issues when running Oracle's databases in VMware's hypervisor.

 

I personally do not believe that it is my job as a writer to merely parrot the party line of the Microsoft Exchange Team.  Where differing opinions exist, I feel it's worth discussing the fact of the debate, especially where there is strong evidence to dispute the official take on things.  I understand if you feel otherwise.

 

3) The author makes some false claims that Exchange 2016 would run faster compared to Exchange 2010 or Exchange 2013 on the same multi-core hardware. Hardware is utilized differently, yes.

 

Here you have a valid point.  You are right and I am wrong.  In fact, I was wrong twice.  First in that I misremembered something about changes to the storage model as having being limited to 2016 only, and second that I shouldn't have stated that so broadly that the changes made Exchange 2016 better at handling multiple cores.

 

To be clear, what I was thinking about here was the removal of the Store.exe process as discussed here: https://technet.microsoft.com/en-us/library/dn789066(v=exchg.160).aspx.  The new Managed Store process (introduced in Exchange 2013) is way better at handling multiple stores, especially on systems with lots of cores.

 

In practice, this has meant that deployments to high core count servers can handle more messages than Exchange 2010, even with the role consolidation, but it doesn't apply to all scenarios.  I have asked my editor to update the article.

 

4) Author claims Exchange is more "virtualization friendly", and that is the reason the number of roles were cut down. Nonsense.

 

If you have an official Microsoft source willing to go on record saying this wasn’t part of the reason, by all means point me to it and I'll ask the editor to add that to the article.  My sources have told me that one major impetus behind the shift to the “combined role” design was the increased adoption of Exchange under Hyper-V, combined with the fact that servers are now more than powerful enough to handle multiple roles on a single box. 

 

I understand that this is a highly contentious issue within Microsoft as the Exchange team are massively conservative and very tightly wedded to their “physical boxes using JBOD storage” design.  Something that not only frustrates the fnord out of their clients, but many other fiefdoms within Microsoft as well. 

 

5) No word on using the Server Role Calculator. Use this to calculate or verify your (planned) deployment.

 

There are reasons for this.  http://windowsitpro.com/blog/vmware-tells-microsoft-they-dont-know-anything-about-exchange-2013-performance is an example.  Yes, I understand that Microsoft’s Server Role Calculator is critical to tickbox admins who believe rigidly adhering to whitepapers is important for regulatory compliance.  That said, the official guidance is demonstrably disconnected from actual real world requirements.  I didn't include it for the simple reason that I don't believe it is accurate for many use cases, especially smaller ones.

 

Some Additional thoughts:

 

If it were up to the Exchange team, nobody would be running Exchange in a virtualized environment, ever.  Despite this, running Exchange in virtualized environments, most of them on VMware, and many of those on NFS, is quite popular.  I myself have many such deployments.  The universe hasn't ended.  My clients haven't suffered data loss in the decade or so that I've been running these.  No dark geek deity has slipped its skeletal fingers across my keyboard and demanded I atone for sins against the vendor.

 

I am not here to say that the Microsoft Exchange Team are dumb, or that they are deliberately attempting to mislead anyone.  Far from it.  They're smart people doing what they think is right.  What they believe is right, however, has proven to be at odds with what many organizations need for some time.

 

I don't wish to get into a drawn out discussion on this, but do wish to say that I feel my job is to be something other than someone who rewrites technet articles, reprints press releases and parrots what vendor spokespeople have to say.  Part of that job is point out where hypothesis and practice are misaligned, and where a vendor viewpoint isn't covering all relevant customers or partners' needs.

 

TL;DR: I believe the customer dictates needs to the vendor, I don't believe the vendor dictates use cases and constraints to the customer.  This is, of course, one of the great debates of our industry, and I don't believe we'll solve it here.


Thank you very much for taking the time to comment on this article, and I hope you have a great 2017.

Cancel

-ADS BY GOOGLE

SearchWindowsServer

SearchEnterpriseDesktop

SearchCloudComputing

SearchSQLServer

Close