Decommissioning on-premises Public Folders Post-Exchange Online Migration
Quick Jump Guide
Part 1 — Preparing for Migration (1/2)
Part 2 — Preparing for Migration (2/2)
Part 3 — Starting the Migration Request
Part 4 — Monitoring and Fixing the Sync (1/3)
Part 5 — Monitoring and Fixing the Sync (2/3)
Part 6 — Monitoring and Fixing the Sync (3/3)
Part 7 — Completing the Batch
Part 8 — Testing & Unlocking Public Folders
Part 9 — Post-Migration Issues (Hierarchy Update)
Part 10 — Post-Migration Issues (Access Denied Deleting)
Part 11 — Post-Migration Issues (Add/Remove Permissions)
Part 12 — Decommissioning on-premises Public Folders
Part 13 — Troubleshooting Hierarchy Issues
Following on from my Public Folder migration series where we saw a successful migration of nearly 500k folders, now comes the time to decommission the legacy servers. Let’s begin…
At first I thought this would be just the normal decommissioning process of unreplicating the servers from all folders and system folders etc, however very quickly I realised that wouldn’t be possible.
At the end of the migration to Exchange Online you lock the on-prem organisation and mark it as complete. At this point you are effectively locked out of your on-prem data. You will no longer be able to access the Get-PublicFolder cmdlet as well as the GUI.
After exhausting the internet looking for some guide on how to decommission these servers, I ended up logging a Premier ticket with Microsoft. I thought there must be a simple way that I’ve missed… turns out there isn’t one, and ironically the only way (and Microsoft recommend way) was to delete all Public Folder databases through ADSIEdit. Drastic I know..!
The process is quite straight forward however I’ll go through the steps I took so it’s clear.
Before we start, just double check your Public Folder configuration does indeed point towards Exchange Online. Below we can see that our Public Folders are hosted locally to Office 365. Also you may want to validate that your users are indeed connecting to outlook.office365.com for their Public Folder referrals in Outlook.
Step 1 – Ensure User Mailboxes are Empty
Quite an obvious step, but make sure all user mailboxes across all Public Folder servers are indeed empty. If they aren’t move them to another server.
Step 2 – Change/Clear the Default PF Mailboxes
Each mailbox database will likely have a Default Public Folder database allocated to it. If you are decommissioning your on-prem Public Folder estate (as we are), you can just clear these values.
Step 3 – Address Book Public Folder Replication
If you have migrated to Exchange Online this is likely already sorted, but just double check your Offline Address Book creation that you don’t have Public Folder Replication enabled. If you do, disable this.
Step 4 – Clear the siteFolderSever Value in ADSIEdit for your Exchange Site
It was recommended to us to clear this value as it ensures a cleaner removal of Public Folders. This value is the default Public Folder database for all user databases that created under that Exchange site. As Public Folders are being decommissioned from on-prem, then there is no longer any requirement to have this value set.
If you check in Event Viewer for Event ID 2937, you’ll see this. In our case the siteFolderServer value was pointing toward a deleted object (an old Ex2007 server). As we are decommissioning all on-prem Public Folders, we delete the value and leave it blank.
To find these values in ADSIEdit;
1. Under Connect to… select Configuration under “Select a well known Naming Context”
2. Expand Configuration > Services > Microsoft Exchange > Domain > Administrative Group
Under each site (if you have them), check the Properties of them and look for the siteFolderServer value.
3. Either move the entry to another server, or clear the value. As we are decommissioning all on-prem PF servers, we cleared the value.
Step 5 – Power down all Public Folder servers for one week
To ensure you have no unforeseen problems, like replication issues, it’s best to turn off the targeted servers for a period of time. If there are issues, your users will shout or you will see them in the event viewer or messaging queues.
Step 6 – Deletion from ADSIEdit
Once you’ve confirmed there are no issues you can proceed in deleting the Public Folder databases from ADSIEdit. You only need to delete the PF databases, as once they are gone you can delete the user databases and then uninstall Exchange cleanly.
1. Under Connect to… select Configuration under “Select a well known Naming Context”
2. Expand Configuration > Services > Microsoft Exchange > Domain > Administrative Group > Databases
3. Delete all Public Folder databases. In this example all the PF databases were called PF24xx (as we saw in Step 4).
Step 7 – Delete User Databases
You can now power on the servers and process to decommission the Exchange servers as per normal. First job delete the empty user databases.
Step 8 – Uninstall Exchange 2010
Quite simple… Control Panel… Uninstall Exchange Server 2010.
