Exchange

PREVIOUS: Exchange 2016: Public Folder migration Part 1

In part one of public folder migration, we prepared our environment. Then we ran all the necessary scripts to size and create the new public folder mailbox hierarchy.

In this second and final part of our series, we will copy the data from the legacy public folder databases into our newly created modern public folders. We will also finalize the migration process.

Step 3: Data Migration

Let’s start moving our data. First, let’s create the migration batch. From the Exchange 2016 server issue the following command.

 C:\> New-MigrationBatch -Name PFMigration -SourcePublicFolderDatabase (Get-PublicFolderDatabase -Server EX10) -CSVData (Get-Content C:\PFScripts\FolderToMailbox.csv -Encoding Byte) -NotificationEmails headgeek@exchangeservergeek.com

In our example:

-Name specifies a display name to help identify the batch.
-SourcePublicFolderDatabase (-Server) specifies the 2010 server hosting the public folder database. In my lab, this is called EX10.
-CSVData specifies the path to our map file we created in part one of our series. We had called this FolderToMailbox.csv and saved it to C:\PFScripts.
-NotificationEmails specifies where to email the batch migration report. This is optional.

 C:\> New-MigrationBatch -Name PFMigration -SourcePublicFolderDatabase (Get-PublicFolderDatabase -Server EX10) -CSVData (Get-Content 
C:\PFScripts\FolderToMailbox.csv -Encoding Byte) -NotificationEmails headgeek@exchangeservergeek.com

Identity         Status       Type              TotalCount
--------         ------       ----              ----------
PFMigration      Created      PublicFolder      1

[PS] C:\>

This only creates the job. To start the actual data copy run the following command. If you named your job anything other than PFMigration you will need to change that here.

 C:\> Start-MigrationBatch PFMigration

We can check the progress of the batch by logging into the Exchange Admin Center. Once logged in, navigate to Recipients >> Migration tab.

If you are in the planning stages for migration from Exchange 2010 to Exchange 2016, 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

Beginning with Exchange 2013–and continued with 2016–public folders underwent a major architectural change.

This new architecture is referred to as Modern Public Folders. The old architecture is now known as Legacy Public Folders. But its much more than a name change. 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!

Works with 2013: This process also works with migrations to Exchange 2013 (from 2007 SP3 RU15 or 2010 SP3 RU8). It requires Exchange 2013 be on Cumulative Update 7 or later. If not, you will need to perform the older serial migration method documented here.

If you have multiple Exchange servers it is imperative that each server have a valid 3rd-party certificate reflecting the namespace. If you don’t some client connections will get certificate errors.

In our example below we have two Exchange 2016 servers behind a load balancer in a single site; EX16-01 and EX16-02. Our third-party (affiliate) certificate request was generated and completed on EX16-01. We have also assigned services to that certificate. However, that certificate does not yet exist on EX16-02. Only the default out-of-the-box certificates exist on EX16-02.

When user Amy Pond connects she is load balanced to EX16-01 which has a 3rd party certificate. The certificate matches the namespace. Her connection is established without error. On the other hand, when Rory Williams connects he is load balanced to EX16-02. EX16-02 returns its self-signed certificate. This certificate does not match the namespace. Rory receives a security error.

In this article, we explore transferring a third-party SSL certificate from one Exchange server to another.

We explore this process through both the Exchange Admin Center and PowerShell.

Let’s get started!

Note: These steps are identical for Exchange 2013, 2016, and 2019.

Export the certificate with Exchange Admin Center

Log in to the Exchange Admin Center. It doesn’t have to be the server you created your request on.

Navigate to the Servers tab and Certificates sub-tab.

In the Select Server drop-down, pick the server you completed the certificate request on. In our example, this was EX16-01.

In previous articles, we generated and completed a certificate request. Keep in mind that despite the request being completed it is not yet live. We must still assign services to that certificate.

In this article, we will assign services to a certificate (affiliate) in Exchange 2016. We explore how to accomplish this using the Exchange Admin Center and PowerShell.

Let’s get started!

Note: These steps are identical for Exchange 2013, 2016, and 2019.

Assign Services to a Certificate with Exchange Admin Center

Log in to the Exchange Admin Center (EAC). Select the Servers tab and Certificates sub-tab.

Select your certificate and click the Edit () button.