ENow Exchange & Office 365 Solutions Engine Blog (ESE)

New Exchange Online Migration Options

Posted by Nathan O'Bryan MVP, MCSM on Dec 28, 2016 1:58:23 PM

Microsoft is constantly updating and improving services; it’s a hallmark of Office 365. The constant Office 365 updates are great for me, providing new content and tips to share with you on a regular basis.

Read More

Topics: Exchange Migration, exchange online, Office 365, Exchange, Office 365 groups

Our Top Exchange & Office 365 Blog Posts of 2016

Posted by ENow Software on Dec 20, 2016 9:35:16 AM

Another year, another slew of exciting Exchange and Office 365-related news. To give you a glance at top events, insights and conversations of 2016, we've compiled a list of our favorite blog posts of the year. Browse through these posts, and let us know others you'd add to the list!

Read More

Topics: exchange online, Office 365, Exchange, Azure, ADFS, Office 365 groups, Azure active directory

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

Enabling DKIM in Exchange Online

Posted by Nathan O'Bryan MVP, MCSM on Mar 30, 2016 6:30:00 AM

 

Spam is the bane of all messaging administrators, as well as a major pain for all email users. Using email means a consistent battle against spam, malware, and unwanted nonsense flooding your inbox. There are a number of different tools and tactics we, as administrators, can use to reduce the impact of these attacks and recently Microsoft has added another one to the toolboxes of Office 365 customers. In this blog post I'm going to explain what DKIM is, and how you can use it to help make the world a safer place for legitimate email messages.

Read More

Topics: Office 365, Exchange, Microsoft

Hybrid Headache: Hybrid mailbox moves and the “expect 100-continue” header

Posted by Michael Van Horenbeeck MVP, MCSM on Mar 9, 2016 6:30:00 AM

 

A little over two years ago, I wrote about an issue I encountered with a KEMP load balancer and how Microsoft performs hybrid mailbox moves. More specifically, the issue evolved around a seemingly different interpretation between KEMP and Microsoft regarding the implementation of the expect 100-continue header. As I noted then, the workaround was to configure the KEMP load balancer to ignore the 100-Continue rules as described in RFC 2616.

A while ago, my good friend Bhargav Shukla reached out to me informing me that KEMP had tracked and solved the problem I described back then. As it turns out, Microsoft had based their interpretation of the expect 100-Continue header on RFC 7231 which superseded RFC 2616. I believe KEMP based itself on the latter, ultimately leading to the issue I described. This illustrates that it’s not always easy to keep up with the fast pace in the tech industry…

Read More

Topics: Office 365, Exchange, Microsoft

Configuring and Managing Multi-factor Authentication for Exchange and Skype for Business

Posted by Bhargav Shukla MVP, MCSM, MCM on Feb 24, 2016 4:00:00 AM

Microsoft has been making changes in the Office suite of products to secure access with multi-factor authentication (MFA). Watch Bhargav Shukla go over how to best use multi-factor authentication solutions to secure Microsoft Exchange and Skype for Business Server products in your company. 

Read More

Topics: Office 365, Exchange, Skype for business, MULTI-FACTOR AUTHENTICATION

Hybrid Headaches - The Confusing Case of Cross-Forest

Posted by Nathan O'Bryan MVP, MCSM on Feb 18, 2016 5:00:00 AM

The Confusing Case of Cross-Forest Delegation

If you've even participated in an Exchange Online migration at almost any level, it's likely you've run into the issue of cross-forest delegation. You know that Exchange allows you to delegate rights from one mailbox to another, allowing users to access other mailboxes. When you do an Exchange hybrid migration, there are some special considerations you have to take to keep these delegated rights working. Depending on who you ask, you'll get all kinds of different answers about what works when. In this blog post I will explain the confusing case of cross-forest delegation, and what you can expect to work or not work.

forest-trust.png

There is no cross-forest delegation

Much of the success of Office 365 is built on the Exchange hybrid migration. Since the initial release of Office 365 it has been possible to connect your on-premises Exchange organization to Exchange Online and have the two organization work almost like a single Exchange deployment. In the early days getting hybrid to work was a long and complicated process, but it was possible. The introduction of the hybrid configuration wizard has made the process of configuring hybrid Exchange much better.

Read More

Topics: exchange online, Exchange, Exchange Hybrid Deployments, cross-forest

Setting Up a Simple Exchange Server 2016 Lab

Posted by Paul Cunningham on Jan 20, 2016 2:53:00 PM

The best way to learn about Exchange Server is to get hands-on with the product. And the best way to get hands-on without risking a production environment is to build your own test lab.

Read More

Topics: Exchange, Exchange Server, Exchange Server Tips, Exchange 2016

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

Gain visibility into your Office 365 Deployment

See why monitoring makes sense in a cloudy world.