The Exchange Server settings you must get right
For many of these entities, on-premises Exchange Server is a messaging must. Microsoft continues to update the software with the assurance that any improvements made to its cloud-based stack will eventually trickle down. Increasingly, these features are adding layers of complexity to the already daunting task of running an enterprise-grade messaging system. It's easy to get lost when going through hardware capacity planning, setting up DAGs (database availability groups) and site resiliency, configuring mail routing, and making sure your users can actually connect to the system.
With that in mind, here are a few details you absolutely must get right before opening the doors to your new messaging environment.
Before you even download Exchange Server, you should have a good idea of how many users your system will need to support, any service-level agreements you may have in place, and how long a disaster recovery window your organization will require. These are very deep topics that are far beyond the scope of this article, but Microsoft provides some tools to help you plan this out.
First up is the Exchange 2013 Sizing and Configuration Recommendations article on TechNet. It will take you through the basics such as Active Directory CPU core to mailbox server CPU core ratios, networking configuration, required Windows Server hotfixes, and pagefile configuration. If you are familiar with Exchange Server 2010, you'll notice a few changes highlighted in this article for configuring Exchange 2013, such as no longer recommending a separate network for replication.
Once you've familiarized yourself with the core recommendations, it's time to dive into capacity planning. The Exchange Team Blog is a great source of information for this, and the group has published a comprehensive look at how to correctly size your environment. Don’t be discouraged by the mathematical formulae -- a sizing calculator is available for download to help ease you through the process.
A few TL;DR tips:
You have everything installed. Your databases are replicating. Your loads are balanced. Performance is being monitored. Now it's time to move on to actually getting mail into and out of your system.
Make sure all of your domains are listed with the proper domain type under Mail Flow > Accepted Domains, and your default domain is correct. If you intend on using email address policies, now is a good time to review them to make sure you have the right domains and username format selected. You can do so under Mail Flow > Email Address Policies.
As with Office 365, you need to get your DNS entries set up correctly before mail can route to your system or clients can autodiscover their settings. This is a bit more difficult for on-premises solutions because you will need to configure firewall rules to allow port 25 inbound to either your front-end or edge transport servers depending on your specific configuration.
You will need to first create an A record for the IP address of your MTA (Message Transfer Agent). For instance, we are using mail.exampleagency.com in our lab. Once the A record is in place, create an MX record that points to it. Your DNS hosting provider should have adequate documentation to cover the creation of these records.
For autodiscover, you will need to create either an A record to the IP address of your client access server or, if it is the same as your MTA, a CNAME record pointing to it. Again, for our lab we use a CNAME record of autodiscover.exampleagency.com pointing to mail.exampleagency.com since they are both using the same IP address. It is required that this record be autodiscover.yourdomain.tld since that is how Outlook Autodiscover will look for it.
Unlike Office 365, which we covered in a previous article, on-premises Exchange does not automatically create a send connector for you. To do so, open EAC (Exchange Admin Center) and navigate to Mail Flow > Send Connectors. A basic connector will merely send out to the Internet via DNS resolution.
If you are using a third-party messaging gateway such as Mimecast, you will configure that as a custom connector. This is also where you will set up any enforced TLS connections to other MTAs. For instance, Bank of America requires enforced TLS connections for its vendors. For this, you will need to use a Partner connector.
This is also a good opportunity to review your receive connectors. Here you can set maximum incoming message size (default is 35MB -- remember to account for the roughly 33 percent MIME encoding overhead), whether to enable connection logging, security settings such as enforced TLS, and IP restrictions.
You have the basic mail routing configured and you can send and receive email. Now you need to get clients connected to your system so that they can actually use it.
With Office 365, Microsoft uses its own namespace for Outlook Autodiscover, Outlook Web App, and SMTP connectivity over TLS. As such, Microsoft use its own certificates. For on-premises Exchange, you will need to purchase new certificates from a trusted CA to allow trusted secure connectivity to your systems.
Fortunately, Microsoft has made the process easy to complete. To start, open EAC and navigate to Servers > Certificates. Add a new certificate and choose to generate a request. A wizard will open and walk you through the process. You will be given the opportunity to choose your domain for each access type. In this example, I've mainly used webmail.exampleagency.com for everything.
Once you finish the wizard, take your certificate request file and upload it to your preferred certificate authority (we used GoDaddy). You will then receive the certificate in the form of a CER file. Simply click on Complete and import the CER file to have the certificate be imported and enabled for use in your environment.
Now that you have your certificate installed, it's time to tell Exchange what domains to use for what services. Navigate to Servers > Virtual Directories. From here, you should configure external access for each one. In this example, we have configured the OWA virtual directory to use webmail.exampleagency.com.
There are more complex topics to discuss such as client access arrays and load balancing, but those are best left for a more in-depth exploration than this article. For more information, see Microsoft's Exchange Server documentation on TechNet.
Even though your data isn't in a public cloud, you still need to carefully consider security. For starters, make sure you're applying regular updates to both Windows Server and Exchange Server. The same advice for administrator accounts applies, as well; always use separate administrator accounts from regular accounts.
You absolutely must keep access to administrative tasks restricted to internal networks or VPNs unless you intend to enable some form of multifactor authentication via third-party products such as RSA SecurID.
Make sure you have a sensible password policy in place. Guidance on this keeps changing, but we’re partial to the newer idea of using longer passwords rather than more complex passwords. In our lab, we require users to have 14-character passwords -- minus any complexity requirements -- that expire every 90 days.
You should also consider whether you need to restrict sending sensitive information via email such as Social Security numbers and credit card numbers. You can configure these restrictions under Compliance Management > Data Loss Prevention. Microsoft provides a number of templates that can be used to help you get up and running quickly. In this example, I'm using the US FTC template to restrict sending credit card numbers.
If you've followed through this far, you hopefully have a working on-premises Exchange system. Now you need to protect it, back it up, and generally make sure it stays online.
For antivirus solutions, you will want both a system-wide, real-time antivirus package as well as a package that scans messages in transit. Microsoft provides a list of required exclusions for both Active Directory domain controllers and Exchange Server systems. Make sure to follow Microsoft’s recommendations and not rely on your antivirus vendor to automatically implement these for you. I've seen too many antivirus packages trample mailbox database log files out-of-the-box to trust them to do it for you.
You also need to consider the type of backup and restore methods you want to support. Are you backing up to disk or tape Do you need granular restore (which is far more resource intensive than it's usually worth) How far back do your backups need to go There are lots of questions you'll need to ask yourself, your team, and upper management.
Other product considerations include data loss prevention, antispam software, and email archiving. In some cases, this could all be included in a single package. But make sure it's certified to work with Exchange Server 2013 and has adequate vendor support. You don't want to buy a product only to find out it was built for Exchange Server 2007 and has email-only support.
Lastly, make sure to do your homework. Check to make sure your organization doesn't need to follow any specific laws for data retention, data loss prevention, or data access. Do test backups and restores on a regular basis. Use the EICAR test file to make sure your antivirus software is running correctly. Routinely check your performance monitors to make sure you don't need to rebalance a DAG or add a domain controller. Oh, and one more thing: learn to love PowerShell.
Running an on-premises Exchange Server is far more complicated than simply signing up for Office 365, but you have much more control and get a far more rewarding experience as an IT professional. This article hopefully gave you at least a good overview of your options and what you absolutely must get right when configuring on-premises Exchange Server. Each organization is different, and this guidance may be off the mark for your scenario. It should, however, be sufficient for the majority of small-business IT administrators looking to get set up quickly.
Related articles