Keys to Deploying Exchange Without Emptying the Wallet

Previously, we discussed keeping three things in mind when you're trying to find the most cost-effective option for deploying on-premises Exchange: using just a bunch of disks (JBOD) for your deployment, letting Exchange handle its own availability, and automating as much as you can. We went into detail about JBOD deployments, default configurations and approaches to consider for your deployment.

Take a closer look at other factors to keep in mind as you continue researching the best on-premises Exchange deployment option for your organization, including cost comparisons, standardization, backups and the importance of the IT department through all of this.

Compare the cost of different deployment types

Comparing the costs of different Exchange deployment models isn't easy, but the basic principle of comparing CPU, memory and disk capacity remains the same, regardless of the environment.

Let's take a high-level look at three deployment types: a standard option (physical servers and JBOD), a custom option (physical servers and RAID) and a second custom option (physical/virtual servers and a storage area network [SAN]).

As a reference, we'll use a common example for deploying Exchange: a company with three multi-role Exchange servers that are all members of a database availability group. User mailboxes are evenly spread across all servers. To avoid a network failure from immediately knocking out a server or causing a database failover, each server is equipped with multiple teamed network cards. To keep things simple, we'll assume the custom RAID deployment leverages RAID 1 for its database and log file drives. Because of the complexity of calculating operational costs that vary from company to company, we'll focus solely on the hardware purchase price, CPU, memory, disks and networking.

The prices and configurations are based on an HP DL380 Gen.8 server. All calculations were made through the configuration on HP's website using list prices.

From the table, you can see a system following the design guidelines and principles from a default JBOD deployment costs less than a system from the custom deployment using RAID and additional network interfaces. The cost for a SAN-based deployment would increase substantially because the price per system doesn't yet include storage.

You may be confused because I said in part one that running a JBOD deployment is supposed to be cheaper. And it can be. In our example, the cost for running JBOD to a RAID deployment is similar, but we added a fourth server to the JBOD deployment. This setup means you get more resources and resilience for the same amount of money.

Automate and standardize as much as possible

The way an Exchange deployment operates is important. A key element to achieving efficiency and greatly reducing the risk of human interaction is to automate as much as possible out of the equation. PowerShell technically offers everything to do just that, but automation can also benefit from standardization.

I don't advocate for a one-size-fits-all approach, but standardization would make your life a lot easier. You don't have to take exceptions into account and can easily define a set of procedures and scripts for any necessary exceptions. Standardization can still have the flexibility to offer a user-specific experience that differentiates an on-premises deployment from cloud-based offerings.

If you choose this option for deploying Exchange, you'll need to balance between standardized services and the ability to deviate from these services with as few exceptions as possible. You can define several service levels and compare them to Office 365 plans. You could create plans to offer slightly different feature sets so you can easily assign services to end users based on the plan they fall into.

This approach greatly improves the accountability of consumed services and eases analysis of per-user costs. It also helps with the environment's predictability. If you need to expand your environment's capacity, you know what resources you need based on services you offer.

Consider removing backups, but exercise caution

Ever since Microsoft said Exchange could happily exist without backups, there has been a lot of controversy. Backups are costly, so if you really want to trim down your messaging system, look at removing as many backups as possible. When talking about backups in Exchange, we're talking about large amounts of data. Copying the data requires time, bandwidth and storage resources. For every terabyte of data you have, you have to add the same amount as overhead and more if you want to keep historical backups.

There can be problems with removing backups. There are regulatory and compliance requirements that can force you into using a backup, so revisit these requirements to choose the right option for deploying Exchange. For instance, if there's a requirement to keep data for a specific amount of time, it might be better to configure a time-based hold on your mailboxes to keep the data in Exchange itself for a specified amount of time. This will grow Exchange's data footprint, but it will still be less costly than having to provide backup and all the means to build and support it.

Have the IT department continue to do its job

We've talked about simplifying things, creating standardized services, killing backups and automating as much as possible. These things can't happen without the IT department to execute them. There has to be a certain operational maturity to ensure that processes are followed, monitored and modified. Exchange may be better, but someone still needs to follow up on issues, requests, monitoring and alerting.

If your department has this operational maturity, take your deployment to the next level. If you're sure you have the operations under control, look into thin provisioning Exchange storage. Although you could, for example, provide end users with a 20 GB mailbox, you count on them to not use all of that space. All of the mailboxes won't use all of the space they have, and they certainly won't be full from the start. But while this approach sounds tempting, you have to be proactive with adding additional resources to your environment. You don't want to run out of disk space before new hardware gets commissioned.