In recent years, the Exchange Product Team began recommending the "Preferred Architecture" for Exchange On-Premises. Inspired by what Microsoft found successful in their Office 365 datacenters, the Preferred Architecture (PA) was designed with several business requirements in mind:
- Include both high availability within the datacenter, and site resilience between datacenters
- Support multiple copies of each database, thereby allowing for quick activation
- Reduce the cost of the messaging infrastructure
- Increase availability by optimizing around failure domains and reducing complexity
Before any assumptions are made, I’m actually a big proponent of the PA for the correct type of customer. I often tell customers that not only can the PA reduce costs by utilizing physical servers on JBOD (wasting no disks to RAID), but also can reduce risk and therefore support costs. The fewer moving parts, fewer vendors involved, and fewer technologies at play ultimately lead to fewer calls to vendor support. Outside of Premier Support agreements, Microsoft has been said to lose money every time a customer calls their support organization. This means it makes financial sense for Microsoft to encourage customers to deploy less complex solutions which require them to engage Microsoft Support less frequently.
However, does this hold true for customers of all sizes? Does it always make financial and operational sense for a 1,000 mailbox company to implement the PA and deploy 4 Exchange servers across two datacenters? What about a 500 mailbox company? Or a 100 mailbox company? I think many Exchange Professionals would agree that in Microsoft’s eyes, customers not big enough to deploy the PA are better suited for Office 365. Though in actuality, Microsoft would be more than happy to sell Exchange Online seats to companies of every size.
I actually share Microsoft’s point of view in many regards. I would love to see every Small Business Server (SBS) customer move to an Office 365 solution. However, customers will ultimately have their reasons for straying from the PA; some founded in technical constraints and others founded in political or illogical reasoning. Maybe a customer is perfectly suited for the PA in terms of both size and operational maturity, but still chooses to virtualize on SAN. Exchange Professionals such as myself are then left with two possibilities: (1) stand firm and refuse the business of a customer who doesn’t want to align with Microsoft’s recommendations no matter how persuasive we are or (2) help them achieve the best possible solution given their decision. I choose the latter, as l can at least ensure the customer will be deploying in the best possible way to ensure the best possible availability and supportability given their decision to avoid the Preferred Architecture or Office 365. I’ve actually jokingly began calling this architecture the "If you insist Architecture," meaning that even after all attempts of me convincing you to avoid deviations from the Preferred Architecture or Office 365, you’ve "insisted" upon this route.
With that said, I’d like to present my architecture recommendations for environments of small and medium/large sizes who choose not to follow the Preferred Architecture. Having spent over a decade working with Exchange for a company that sold Small Business Server (SBS) en masse, deals heavily in storage solutions and virtualization, as well as Preferred Architecture, I feel I’ve learned some lessons with each architecture worth sharing. Let’s begin with the single Exchange Server environment, or the “Small Business Server” clientele.
Starting with BackOffice Server 4.0 (running Exchange 5.0) and progressing to Small Business Server 2011 (running Exchange 2010), SBS was targeted at small businesses consisting of 75 users or less. SBS was tailored both in price and function to meet the needs of these smaller businesses; factors which helped drive the popularity and use of SBS. However, from a supportability standpoint, it was a very problematic solution. You had a Domain Controller that was also running Remote Desktop Services, which were coupled with Exchange and SharePoint co-located within IIS. With each of these products/features tightly intertwined on the same server, the complexities involved in troubleshooting or recovering from failures strained Microsoft and their partner support organizations. It is partly these reasons which drove Microsoft 5 years ago to announce the end of SBS as we knew it. As some customers had become quite fond of SBS and Consultants had built their businesses around selling SBS to their customers, it came as a bit of a shock. So let’s first focus on the current options for these "SBS Customers."
I’d like to first make a desperate plea to "SBS Consultants" out there; please do not try to make your own "Homegrown SBS Server." If your goal is to make a Windows 2016 File Server/DC with Exchange, SharePoint, SQL, and Remote Desktop Services, you’ll be delivering a highly unstable and unreliable solution for your customers. When asked, Exchange Product Team members have stated that Exchange is designed to be the only application/role installed on the server, except for Anti-Virus or systems management agents. Microsoft does not test or validate Exchange being installed on the same server as SharePoint, SQL Server, or Skype for Business; meaning there’s no guarantee it will work properly and there exists no runbook for troubleshooting it during failures. I’ve seen several consultants attempt this as a solution to deliver to their customers and they often struggle with simply getting them installed, as IIS typically doesn’t know how to handle Exchange/Skype for Business/SharePoint coexistence.
Assuming we agree that do-it-yourself SBS should not be attempted, what are your options? Below are the two most prudent options we’ll discuss:
- Physical Windows 2016 Essentials Server: Office 365 Integration
- Hyper-V Host: Windows 2016 Essentials Server VM + Exchange Server VM
Physical Windows 2016 Essentials Server: Office 365 Integration
With Windows Server 2012 R2, The Essentials Experience was not only an edition that could be purchased, but also an installable Server Role. In addition to being a Domain Controller, running Remote Desktop Services, and having a simplistic management GUI, it also contained Office 365 Integration features which could be used to connect your on-premises Active Directory environment to an Office 365 tenant. Further enhancements were made for Windows Server 2016, such as Azure-integrated recovery services. Having supported SBS for a long time, by far the most complicated components to support were Exchange and SharePoint. Even when functioning properly, you still were tasked with backing up and updating each. The Windows Server Essentials Experience allows customers to still have a local directory and file storage solution in Windows Server, which is fairly simplistic to maintain (especially with Azure-integrated backup), while having the ability to integrate with an Office 365 tenant for Exchange/SharePoint/Skype for Business/OneDrive/Yammer/Teams/etc.
This is Microsoft’s strategic replacement for SBS as well as my preferred solution for any small business desiring the benefits of fast/local file storage as well as a low total cost of ownership via cloud-based line of business applications. The Essentials Experience also includes a method to keep local passwords in sync with Office 365, similar to PasswordSync within Azure AD Sync but instead using a web API to connect to the tenant and change a password to mimic any local changes. This solution also allows easy management of Exchange objects within the Office 365 tenant, as they will be cloud users instead of users being synced from an on-premises directory. There is no need for on-premises Exchange management tools, as the on-premises Active Directory environment is not considered the source of authority for the cloud objects. The design also makes merger and acquisition scenarios easier to navigate. As the Office 365 Integration provided in the Essentials Experience does not use Directory Synchronization, there are no complex identity challenges. Simply disable the integration and you’ll be left with “Cloud User” objects in the cloud which can easily be mapped to a new on-premises directory via Azure AD Sync. It should be noted that the supported limit for the Office 365 Integration features is 100 users. Please see the official Windows Server 2016 Essentials documentation for additional information.
Hyper-V Host: Windows 2016 Essentials Server VM + Exchange Server VM
For a small business wishing to remain entirely on-premises, Windows Server Essentials can still provide a local Domain Controller, file storage, and Remote Desktop Services. However, you cannot install Exchange or SharePoint on Essentials. I personally recommend buying a physical server to use as a Hyper-V host, and then virtualizing Essentials/Exchange/SharePoint/etc. on separate virtual machines. This solution will require more up-front licensing costs but will satisfy the desire to remain completely on-premises for all workloads. Microsoft offers several licensing and virtualization options for Essentials; some even partnering with OEMs. Of course you can certainly forego Essentials and purchase Windows Server Standard or Datacenter, as you can always install the Essentials Experience Server Role at a later time. The only difference in this option from purchasing the Essentials edition of Windows Server is the licenses which are included in Essentials (and price of course).
Note: You can also choose to not use Essentials at all, allowing you to instead collocate Exchange and your Domain Controller on the same VM; however I advise strongly against that path. While technically supported, I always try to discourage customers from collocating critical workloads on the same operating system, as it makes backup and recovery operations more complex.
This design is essentially an IT infrastructure starter kit so to speak. You can easily install additional Domain Controllers or Exchange servers and scale your business as needed. Should you choose to integrate with Office 365, you can easily add the Essentials Server Role if your environment consists of less than 100 objects, or you can install Azure AD Connect to implement full directory synchronization. This would be the preferred approach for small environments of more than 100 users.
While this solution introduces the complexity of virtualization, it also introduces the simplicity of virtual machine level backups. Third-party solutions which can back up a virtual machine while integrating with the applications running within them (Exchange, AD, etc.) via a supported VSS provider will allow simplified backup and restore operations.
As a good Consultant or Administrator, it’s your job to present these options to the decision makers (often those writing the checks) so they can make a decision about what’s best for the business. Choosing to design a small business environment utilizing authentication, file storage, email, and web which resides entirely on-premises will be more costly than the cloud alternative. I often tell people that even though I can setup and manage Exchange quite easily based on my technical skillset, if I were to start my own business I would simply use Office 365. Why am I going to pay for licensing, pay the electric bill to run the server, worry about regular offsite backups, and lose sleep over uptime when I can simply cut a check each month? However, that option will not be desirable for every customer and we should make every effort to guide customers down a supported, manageable, and scalable path.