Exchange

Update: If you are migrating to the modern public folders in Exchange 2013 you may want to check out this article instead. This is the new and improved method for migrating public folders. However, it requires Exchange 2013 CU7 or later. As of CU11 the method below still works if you prefer to use it. But it will eventually be deprecated.

If you are in the planning stages for migration to Exchange 2013, then you have probably seen this TechNet article.

At first, it may seem daunting.

So many scripts. So many PowerShell commands.

If you are not comfortable with PowerShell it may seem a bit overwhelming.

Plus, it is vastly different than any previous migration process.

Why the change?

Architecture

Public Folders underwent a major architectural change in Exchange 2013.

Gone is the Public Folder database. And hello are the new Public Folder Mailboxes.

The benefit?

No more Public Folder Replication. Boy, did that used to be a pain!

With Public Folders stored as a mailbox, that mailbox can now be part of a Database Availability Group (DAG). And with that, all the benefits of Windows Failover Clustering.

This makes the migration process vastly different.

On a high level, it is the process of moving all data out of a database and into a special mailbox. That is where the scripts come in. I’ll explain along the way.

Let’s get started!

So what exactly is that title all about?

Aren’t DAGs a good thing?

Why would I ever want to decommission them?

Well, yes. You are correct. They are a good thing. And I always recommend putting them in place.

This article is for the organization that has migrated to Exchange 2013. It assumes you have successfully moved all user, shared & resource mailboxes. That you have migrated and removed all Public Folder content. That you are ready to delete your 2010 DAG.

So, what’s first?

Verify databases are empty

Before we can delete a database we need to check that no objects are homed to 2010 anymore. The easiest way to do this is PowerShell.

One of the most frequent questions I receive concerns namespace design.

I covered this recently in an article geared towards Exchange 2010. However, it quickly became apparent I needed to revisit this topic specifically for Exchange 2013. Especially with the big GUI rewrite.

So, let’s get started!

What’s in a namespace

Namespace is very important.

Not only does namespace govern services like Outlook Web App, or, ActiveSync, but it also governs items such as the distribution of the Offline Address Book, or, the Autodiscover service.

A correct namespace design is key.