In the previous steps we’ve done an awful lot of preparation work in getting to this stage. We are now ready to begin the syncing of the data, which is actually a quite a straight process now (I’m glad we could find all the bug — and there were a lot of bugs!!!). This process should now be a lot smoother for you as the commands in the TechNet article now actually work for a migration of this size…

If you have multiple servers running your Public Folder estate, I’d strongly recommend finding the most idle server of the lot and using this one as your source endpoints. All data will be pulled from this server and if it’s under heavy load you will have issues.

Step 8 — Creating the Migration Endpoint
You will need to create a service account that has access to your Public Folder data (we added ours to Exchange Public Folder Administrators).

On the legacy Exchange server (in our case Exchange 2010) run the following commands:

Collect the relevant data for your Public Folder migration endpoint

Now you have the data from above, you need to create your Public Folder migration endpoint…

Collecting the data for the Migration Endpoint…

Now we can finally create the Public Folder Migration Endpoint…
IMPORTANT: Be sure to set your authentication to the correct value. By default it’s Basic, but you maybe using NTLM as we were…

Creating the Migration Endpoint…

Once you have created your Migration Endpoint, it should look something like this…

We increased our MaxConcurrentMigration and MaxConcurrentIncrementialSyncs to 40 each. You can do this by using the Set-MigrationEndpoint cmdlet.

While you can go higher, we did go as high as 100 however as you get further into the migration you begin to test Microsoft’s timeouts and throttling limitations.

Step 9 — Start the Migration (then run away)
Once you are ready to go (and you have your flights booked to get as far away as possible)… start your migration batch.

Start your migration batch…

--

--