Exchange 2019 – Why?

With the formal release of Exchange 2019 the Exchange world was shaken up (yet again), and the main question most of us have is why? Since upgrading Exchange in your environment isn’t exactly a small task, why should you jump to the new, fancy flavor? Well, let’s hop right into that!



Exchange 2019 is the first flavor of Exchange that fully supports deployment on Windows Server Core. How’s that a security improvement? Well, since Core is lightweight, containing only the essentials, there’s a drastically reduced attack footprint.

Not sold on Core? How about this; Exchange 2019 out of the box will only use TLS 1.2.



We talked about Core, right? Well since it doesn’t install features and components that are not absolutely necessary (Internet Explorer?, Media Player?) there are fewer patches to be deployed, and fewer still that require reboot. Assuming you follow the preferred architecture when you deploy there should be no problems with rebooting, but why chance it when you don’t have to?

Not only that, but with major enhancements to search indexing the catalog fails over much, much faster and who isn’t a fan of that?!



With Exchange 2016 there were scalability struggles. Manufacturers started producing larger physical servers and Exchange supportability flat out didn’t cover those, which lead to complicated virtual deployments and customers working outside of supportability guidelines. Exchange 2019 now supports up to 48 (physical) cores and 256GB of RAM.

Search was also drastically changed to leverage Bing technology causing failovers will happen more quickly and reliably. How, you ask? By storing the search indexes within the databases themselves and changing index data to be shipped along with database log shipping.

SSDs! For the longest time they were supported, but not technically recommended due to cost and capacity. Well, the read latencies of spinning disks haven’t improved at the same pace as physical capacity did. The struggle here is that it’s tough to read TBs of data fast enough on disks that are only 7,200RPM. How was that addressed? MCDB (MetaCache DataBases)! Basically, part of the most actively accessed data is stored on the SSDs so it improves performance drastically. Since MCDB is entirely new and a little complicated I’ll come back later and write about it in detail soon.


Up next is a two part about preparation and installing!

Securing Exchange Online

For those of you who weren’t lucky enough to attend, or simply didn’t know it was happening, Microsoft wrapped up Ignite last week and left us with plenty of savory info!

For most of 2018 I’ve been working with customers of all sizes and helping them to understand security in Office 365, namely in One Drive for Business and Exchange Online. Most customers are at least a little leery about placing critical workloads like Exchange and file storage in the cloud without understanding at least a little bit about how that information is secured. Well, Microsoft took a moment to outline a few simple configuration changes that will immediately improve your security stance in Exchange Online.

So to get this shindig kicked off, let’s take a look at the different stages of breach. When defending against threats it’s important to understand this as a killchain and defend as far to the ‘left’ in the killchain as possible and of course, throughout.

S_EXO_Attacker Killchain

Attackers will perform a discovery, or recon of your tenancy to understand more about your users. During this phase, they’ll try to determine more about your users and what they may be able to use to exploit them. This may be as simple as checking your company’s webpage or wikipedia to find out who senior management is in order to either target them or use their information to convince others.

After they’ve gathered enough information, they’ll try to use it to actually breach your organization. Things like password spray, brute force, and just good ole’ fashion fishing will be their tools of choice.

Once they’ve gained access, then the exciting stuff starts! They’ll first enumerate who your users are, including your admins and specifically target them. Not only that, they’ll do their best to make sure that they retain access to anyone they gain access to with things like inbox rules, mobile device enrollment, delegation, external sharing requests, etc. Finally, they’ll use common practices like eDiscovery, mailbox protocols, and external forwarding to grab your information and sell it to the highest bidder!

So how do you protect yourself? Again, focusing to the left in the killchain we’ll want to start with end user education. Educate your users around things like passwords and what kind of information they divulge in social media. Then we’ll do our best to combat the initial breach. Enforcing things like extranet lockout in ADFS, ensuring mail authentication (SPF, DKIM, and DMARC) are set up correctly, and limiting app framework in Azure.

To address elevation of privilege, we really want to focus on admin roles and impersonation. First, multifactor auth is an absolute requirement for administrators. That’s non-negotiable. Impersonation should only be used when absolutely necessary, and that’s pretty rare. Some third party apps require impersonation to work, but other than that, almost no one should be grated impersonation permissions. Since it doesn’t change too often, a pretty easy way to review it would be to imply set up an alert policy in Office 365 to alert an admin when impersonation has been granted. If it wasn’t you, then remove the access and start an account breach remediation  process on the person who granted it.

Next, we’ll want to address entrenchment. Attackers will do their damnedest to retain the access/information they have. First, look into Azure information protection. If your information leaves the organization but is encrypted, it’s much better than the alternative. Attackers will create inbox rules for end users to automatically forward messages or to hide responses or remove responses based on key words like ‘Helpdesk’, ‘phish’, ‘hack’, etc. Then they’ll forward mail outside of the organization that looks interesting to them. Allowing automatic forwarding outside of your organization needs to be disabled unless absolutely necessary.

Finally, they’ll use admin roles to export all the information they can. You need to make sure that you don’t grant discovery permissions to people who don’t need it. Then you need to alert on who exports that information and audit on what else that person did.

There’s a lot here, but start with some simple things. Enforce multifactor authentication for both admins, and all users. That will drastically reduce the risk to your end users. Next, disable legacy protocols like POP, IMAP, and SMTP Authenticated Send to ensure that attackers can’t bypass MFA and can’t use accounts they have access to, to phish your internal users. Finally, set up alerting policies for forwarding, elevation or privilege, and eDiscovery.

Don’t believe me? Watch the presentation from Ignite: