If you would like to read the other parts in this article series please go to:
In part 1 and 2 of this article series revolving around best practice recommendations including general tips and tricks from the field, when you as a large Enterprise organization face an upgrade to Exchange 2016, I provided you with a set of recommendations you should try to follow as closely as possible.
In this part 3, we will continue where we left off. More specifically, we will switch our focus to the sizing aspects of an Exchange server solution.
Let´s get going.
Historically, lots of Exchange Server deployments have suffered from performance issues over time. The Exchange Server product depends hugely on services and components like Active Directory, network, load balancer, virtualization, and storage to perform as expected. For this reason, negative Exchange Server performance impact can be caused by any of these services and components. If we do not have the appropriate number of domain controllers, bandwidth, load balancer SSL TPS or storage IOPS per database, the end user will have a poor experience. The same of course goes for the specs used to size the physical or virtual Exchange servers themselves.
So what can we do in order to ensure we put together an Exchange server solution that performs as expected? Fortunately, we have several tools as our disposal. We already talked about the JetStress tool in part 1, but there are several other tools that can help us.
The very first steps I recommend you take on your journey to putting together a properly size Exchange Server solution is to go ask the “Perf Guy” aka Jeff Mealiffe. Jeff has written a very detailed sizing and capacity focused blog post. He wrote that for Exchange 2013 specific deployments, but most of it can be used for Exchange Server 2016 as well. After all, Exchange Server 2016 is just a big service pack for Exchange Server 2013.
The blog post provides you with great insights into the “whats and whys” on how to put together an Exchange Server solution. This is optional reading as we do have magic tools that can do the sizing for us, but if you are a real Exchange server nerd, you want explanations and what happens behind the scene right?
You can find his blog post here. There’s also a short Exchange Server 2016 specific follow up blog post here. Finally, also bear in mind you can go too big when it comes to sizing and Exchange Server solution. For instance, did you know is isn’t recommended to size an Exchange Server with more than 24 CPU cores and 96GB of memory? More details on what you need to be aware revolving around sizing too big can be found here.
An easily forgotten detail when sizing an Exchange Server solution is the requirements from the Active Directory or more specifically the domain controllers. Since the Exchange 2007 days, the rule of thumb has been a ratio 4:1 cores for each Mailbox server role when running 32-bit based domain controllers, and a 8:1 ratio when you have 64-bit based domain controllers deployed.
Today pretty much all organizations use 64-bit based domain controllers (Global Catalog servers) and although all roles (except the Edge Transport server role) is installed on the same server instance with Exchange Server 2016, the ratio haven’t changed. You should still go with a 1:8 ratio processor cores.
Said in another way, you should base your solution on a ratio of 1 Active Directory global catalog processor core for every eight Exchange Server processor cores handling active load, assuming 64-bit global catalog servers are used.
So if you follow the preferred architecture and spec your servers with 24 processor cores, you would need three domain controllers (Global Catalog servers) processor cores per Exchange 2016 server.
This recommendation is based on domain controllers (Global Catalog servers) not used by other applications and services, so remember to account for current domain controller (Global Catalog servers) utilization.
Granted we often engage on Exchange migration or upgrade projects that run under a tight deadline set by the respective project manager. So instead of asking the perf guy and spending evenings and nights deep diving into the TechNet web, what can we do to march forward in a pace that matches the expectations of the project manager´s set deadlines? Say hello to the Exchange Server Role Requirements Calculator. The Exchange calculator was originally released back in the Exchange 2007 days (original announcement blog post can be found here) in order to assist customers in designing their storage layout for Exchange 2007. Back then the calculator focused on driving the storage requirements (I/O performance and capacity) and what the optimal LUN layout should be based on a set of input factors.
However, the calculator has evolved with each Exchange Server version released since then. Nowadays it’s much more than a simple storage requirement (I/O performance and capacity) calculator. Today, the calculator takes everything related to the Exchange servers into account and really is a piece of art.
I will not go into details on how it works here as it contains help notes and is pretty easy to understand once you have played around with for a while.
The input section of the Exchange Server Role Requirements Calculator
One thing the Exchange Server Role Requirements Calculator doesn’t account for is the requirements revolving around clients connecting to the Exchange server solution. For a long time, we had to do rough calculations, but back in 2012, the Exchange Client Network Bandwidth Calculator was announced and just like the Exchange Server Role Requirements Calculator, the Exchange Client Network Bandwidth Calculator has evolved over time. The calculator can help us predict the client network bandwidth requirements for a specific set of users. The prediction algorithms used within this calculator are entirely new and have been derived after significant testing and observation.
The input section of the Exchange Client Network Bandwidth Calculator
You can find a session on Channel9 here that covers the updated version.
To finish this article, I wanted to let you know of a critical hotfix you need to apply on your Exchange 2010 Client Access servers when upgrading to Exchange Server 2016 (or 2013). Nothing worse than identifying these things too late.
In a coexistence scenario, where the client access namespaces has been switched to the Exchange 2013 or 2016 servers (or more specifically the respective virtual services on the load balancer), while mailboxes are still located on the legacy Exchange 2007 or 2010 servers, it is crucial that the Exchange 2013 or Exchange 2016 servers can connect to the legacy client access servers.
An issue has been identified where Outlook Anywhere clients are prompted continually for their credentials. Additionally, their Outlook clients may remain in a disconnected state.
To fix this issue you should ensure the hotfix mentioned in this Microsoft KB article is installed on the legacy Exchange client access servers.
This concludes part 3 was the last in this multi-part article series. Hope you enjoyed it and find some of the stuff useful for your current or next Exchange Server 2016 deployment.
If you would like to read the other parts in this article series please go to:
Not being able to find project documentation is way too common. Use Azure DevOps’ built-in…
Samsung is again the first major company to roll out new smartphones in the new…
PhotoSquared has experienced a data leak, mainly because the popular U.S.-based photo app failed to…
Here’s an elegant and modern way to move data from your Azure virtual machine to…
The effects of the recent Facebook data breach are still being felt. In this new…
Are you finally ready to take the plunge into Exchange 2019? If you are building…