ENow Exchange & Office 365 Solutions Engine Blog (ESE)

Andrew Higginbotham

Recent Posts

Alternative Architecture for Exchange On-Premises (Small Businesses)

Posted by Andrew Higginbotham on Jul 13, 2017 6:00:00 AM

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:

Read More

Topics: Exchange 2010, Office 365, Exchange 2013, Exchange

A Practical Look at Exchange Database Internals Part 2: Transaction Logging and Recovery

Posted by Andrew Higginbotham on Aug 30, 2016 9:50:31 AM

In part 1 of this series, I discussed how to connect to the Exchange database cache and the importance of transaction logs in database transactions. In this next part, you'll learn how transaction logging and recovery work in Exchange. 

The following blog post is a trimmed-down excerpt from the e-book "Exchange Server Troubleshooting Companion."

Transaction Logging and Recovery in Exchange

Of course, there is another reason that Exchange writes transactions to the log files before being committed to the database (.edb) file. By quickly committing transactions to disk (via transaction logs), it means that the transactions exist in two locations; memory and disk. If a failure occurs that causes the Information Store to terminate unexpectedly, the most recent transactions are still available and can be replayed into the database from the transaction logs after the database is mounted and to bring the database up-to-date.

For a long time, it was recommended to place your Exchange database file (.edb) onto different spindles than your transaction logs. This is still the recommendation when only one copy of a database exists (non-DAG protected). In fact, this is not for performance reasons but to assist recovery in the event of a storage failure. Say you lost your database drive, leaving you only with the transaction logs. Technically, if you still had every transaction log present since the database was first created, you could use ESEUTIL to generate a new database and commit every transaction from the logs into it. However, this is not usually the case. People usually resort to an Exchange-Aware backup, which leads us to why an Exchange-Aware backup truncates log files. When a Full Exchange-Aware backup is performed against a database, the .edb file is copied to the backup location, as well as any transaction logs present for the database. With these files, the database can be restored and the database can be brought into a Clean Shutdown state, meaning all transactions in the logs have been committed to the .edb file and the database can be mounted. As the backup completes, it sends a command to the ESE database engine stating that any transaction logs older than a certain point can be truncated (deleted). These logs are no longer required on the Exchange server because we now possess a copy of them in the backup set.

Read More

Topics: Exchange, MSExchange

A Practical Look at Exchange Database Internals — Part 1

Posted by Andrew Higginbotham on Aug 22, 2016 1:58:00 PM

The following blog post is a trimmed-down excerpt from the e-book "Exchange Server Troubleshooting Companion."

Exchange database internals might seem to be a complicated topic, but we’re going to briefly discuss database internals from a very practical perspective.

Read More

Topics: Exchange, MSExchange

Understanding controller caching and Exchange performance

Posted by Andrew Higginbotham on Jan 12, 2016 2:30:00 AM

The following blog post is a trimmed-down excerpt from the eBook "Exchange Server Troubleshooting Companion":

One of the primary talking points of my Storage Configuration Options for Exchange session at IT Dev Connections was around JBOD with Exchange, and what that definition means to various people. Since Exchange 2010 and the advent of the Database Availability Group, the idea of deploying Exchange onto JBOD has spread like wildfire. Starting with laughs and jeers from the IT community at the mere idea of placing production workloads onto non-RAID protected direct-attached storage, evolving to the largest Exchange deployment in the world (Office 365) running on JBOD storage. Not only does Exchange Online run on JBOD, but mailboxes in the service do not have traditional backups performed against them. Instead relying upon Exchange Native Data Protection. Quite a shocking fact, especially if you were to present it to an Exchange Admin around the year 2009.Exchange.jpg

For the correct deployment architecture, JBOD actually makes a lot of sense once you understand the performance and High Availability improvements made in the product. Exchange 2013/2016 requires ~90% fewer IOPS than Exchange 2003, making large/slow/cheap disks such as 6TB 7.2K NL SAS a deployment option. This also removed the requirement for expensive SAN storage with optimized RAID configurations to achieve acceptable performance. Also, with a DAG providing up to 16 geographically diverse copies of your mailbox database (although 3-4 is a more practical number), there’s no need to waste drives on RAID when the application itself can handle your data availability and redundancy.

While I’m not here to tout the awesomeness that is Exchange High Availability (that actually is its own book), I did want to discuss a common misconception around the hardware requirements for an Exchange JBOD solution (which is the Preferred Architecture). Misconceptions that I’ve seen many encounter, which resulted in poor performance and escalations to their hardware vendor. In every case, it was not the deployed hardware which was at fault, but rather an inappropriate hardware configuration.

Read More

Topics: Exchange

Overcoming corruption during mailbox moves

Posted by Andrew Higginbotham on Oct 26, 2015 4:44:06 PM

The following blog post is a trimmed-down excerpt from the eBook "Exchange Server Troubleshooting Companion":

Mailbox corruption is not a new problem for Exchange Administrators, Support Engineers, and Consultants. Causes of corruption can vary and include:

Read More

Topics: Exchange 2013, Exchange 2016, mailbox corruption, repairing logical corruption, mailbox quarantine

CPU Contention and Exchange Virtual Machines

Posted by Andrew Higginbotham on Apr 8, 2015 2:37:00 PM

Overview

Virtualization has been around for a while now & its best practices are well known amongst virtualization experts. Unfortunately, as I’ve seen with many different customers, some guidance isn’t followed or taken as seriously as it should. This can be the case when someone who isn’t a virtualization specialist (maybe an Exchange admin or an IT generalist) is tasked with managing a virtual infrastructure.

 

There are several areas of sizing & performance that any virtualization admin should become intimately familiar with; CPU, Disk, Memory, HA, DR, etc. Specifically, I’d like to call out CPU sizing & the negative ways it can impact a virtual Exchange deployment when not done correctly.

Background

First off, there are many well-written articles on CPU sizing, most of which are from the VMware perspective:
CPU Overcommitment and Its Impact on SQL Server Performance on VMware
Virtual Machine Performance – CPU Ready
How to successfully Virtualize MS Exchange – Part 1 – CPU Sizing
Hyper-V CPU Scheduling–Part 1

They’re all excellent reading but I’ll summarize for the purposes of this article. In vendor-neutral terminology, on a given host, the total number of assigned processor cores on all of your virtual machines can potentially be greater than the total number of actual cores on the physical host.

Example:
Read More

Topics: Exchange, MSExchange, Exchange Virtualization, Virtualization,, CPU

Tracking Down Overactive Mailboxes With Get-StoreUsageStatistics

Posted by Andrew Higginbotham on Jan 28, 2015 3:00:00 PM

Overview
Often times I’ll find myself writing a blog post because the topic recently became relevant due to  customer need. Other times I spend hours banging my head against the keyboard trying to resolve an issue & would like to keep others from going through the same ordeal.

In this particular case, I found myself thinking of this fall’s release of Apple iOS 8 & some of the traditional unexpected consequences that arose when used to connect to Exchange via ActiveSync. In past cases, an update could lead to excessive CPU usage & transaction log growth; of course it’s not just Apple with a long rap sheet of poor implementations of ActiveSync. With it being the holiday season, we can expect a wave of new gifted devices being brought into work by users and administrators everywhere will face the challenge of ensuring they don’t have an adverse impact to the stability of Exchange.

Of course it’s not accurate to say that ActiveSync is the cause of all individual mailbox performance issues. In my experience, the following can cause mailboxes to put more strain on the server than expected:

  • Bugs in phone vendors’ ActiveSync code (as already mentioned)
  • Third-party Outlook add-ins
  • Mailbox/Item/Rule corruption (usually resulting in a Quarantined Mailbox)
  • Bug in Exchange or Outlook Code
  • Third-party applications that interact with Exchange using a service account (i.e. BES)
Read More

Topics: Exchange, Microsoft Exchange

Gain visibility into your Office 365 Deployment

See why monitoring makes sense in a cloudy world.