This segment shows how to manage expectations by creating a service level agreement (SLA) including performance and reliability for your Exchange 2016 servers.
- [Instructor] Every successful project begins with thoughtfully established expectations. If you're preparing to install an Exchange server organization or migrate from a previous version, you're going to want to start out by defining what users can expect from the messaging servers by creating a service-level agreement. As IT, we don't get to define these expectations on our own. Similarly, acceptable thresholds can't come exclusively from the company's email users.
Before designing a topology, establishing a budget or installing a single server, IT should sit down with the company leadership and create a service-level agreement. An SLA will give some definition of what is expected of the Exchange organization. There are a lot of blueprints and guides to creating a service-level agreement, but in terms of Exchange, it usually boils down to performance, reliability and resiliency.
Let's take a look at performance first because that is the most commonly misunderstood metric. Certainly, performance is about speed, and we all want the emails we send to be delivered by the time our finger leaves the mouse button, but this metric has a lot of variables if we try to measure the speed of not only our servers, but the entire internet. The measure of purely speed is hard to quantify, and it leaves out other very important aspects of performance. Many organizations intentionally place a delay on all outbound messages that allow a sender to retract a message before it's delivered.
This may seem like an unnecessary delay on all messages to benefit a very few, but for those very few, an oops button can save a relationship or even a job. Another consideration is the accuracy of filtering inbound messages to block spam, viruses and messages from unwanted senders from ever reaching the users' inboxes. This measure of performance is so important that some service-level agreements, like this one from Symantec, will cite this accuracy as their only performance metric.
The second part of a service-level agreement is reliability. The most common measure of reliability is uptime. You have no doubt seen service claims like 99% uptime. With a little math, we can see that 99% uptime means up to .1% or .001 downtime, which equals about a third of a day or roughly eight and 3/4 hours of downtime per year.
Now, so long as that eight hours isn't all in a row, that might not be too bad. As an Exchange administrator, you need to look at three different aspects of availability. Database availability groups allow you to replicate the mailbox databases across multiple Exchange servers to keep that service running through different types of outages. The fact that client access services are installed on all mailbox database services means connections can be maintained to all of those database copies through the same type of outages.
In this course, we're going to look at additional measures that can be taken to maintain access to your Exchange 2016 organization using an edge transport server or some failover concepts to provide for maximum uptime of the transport services or the ability for email to move in, out and around the organization. A goal of 100% uptime may not be reasonable, but if you have a plan for scheduled maintenance and fast recovery, then no more than two hours per quarter may become a realistic goal, and two hours per quarter adds up to eight hours per year, and that 99.9% measure that was mentioned before.
Now, the third part of a service-level agreement is resiliency. This is the part of the SLA that admits that occasionally, bad things will happen. Resiliency refers to what it takes to bounce back. Some will consider that a sub-category of uptime, but it's more than that. This is where you define how much of your allowable downtime you're going to take to bounce back from a problem with your edge transport server or some other part of your Exchange organization.
In this course, we're going to explore routing queues, connectors and more, which can be used to provide maximum resiliency, not just for the loss of a server, but for site outages as well.
- Planning and configuring transport and routing
- Understanding Safety Net
- Sending and receiving connectors
- Creating partner connectors
- High availability and site resilience
- Troubleshooting transport services
- Message security
- Filtering connections and recipients
- Spam confidence level thresholds
- Antivirus solutions