Introduction
In this second article of the PowerShell and Public Folders Migration Issues series, we explore other topics which surround Public Folders like Indexing, Circular Logging, Disk Space and monitoring migrations for errors / completion. The intent is to cover ways to improve your migrations and hopefully help avoid or at the very least detect migration issues before they get to hard to resolve. Let’s dive in:
Content Indexing Disabled
Content Indexing is a feature in Exchange Server databases that allow for searching of content in the databases. The database could contain any sort of mailbox (user, shared, Public Folder, etc.) and they all rely on the Index to enable users to search through them. Content Indexing as you might imaging is a CPU/Disk resource intensive process and could impact a Public Folder migration by slowing down data copies. We can control this during the migration by disabling it as it will have no impact on user functionality as users are accessing the old servers for Public Folder access and not the newly replicating copy present in the destination database. To make the change, we can set this value to $False on the Public Folder database and then verify the change:
Set-MailboxDatabase PublicFolders -IndexEnabled $False Get-MailboxDatabase PublicFolders | Ft Name,IndexEnabled
Which shows that Indexing is disabled.
Once a migration is complete, we need to turn the Indexing back on:
Set-MailboxDatabase PublicFolders -IndexEnabled $True Get-MailboxDatabase PublicFolders | Ft Name,IndexEnabled
Now Indexing is back on and the Search function works again from clients.
Circular Logging
Turn on Circular logging to reduce logs written and allow for more disk space usage:
Set-MailboxDatabase PublicFolders -CircularLoggingEnabled $True Get-MailboxDatabase PublicFolders | Ft Name,CircularLoggingEnabled
Once a Public Folder migration is complete, make sure to turn this feature off (setting it to False):
Set-MailboxDatabase PublicFolders -CircularLoggingEnabled $True Get-MailboxDatabase PublicFolders | Ft Name,CircularLoggingEnabled
Disk Space
Wanted to include this gentle reminder because with any Exchange migration, sufficient disk space is very important as full disks can result in dismounted databases, disrupted service and possible business interruption. Make sure the monitoring (and backup!) software is configured on your destination server for on-premises migrations.
Exchange 2010 To 2016 Cutover with Exchange Hybrid
One background piece of information that I’ve held back is that ALL users were in the cloud during these operations. This meant reconfiguration of the Remote Public Folder mailboxes feature in Exchange Online. It also beings up another find point – make sure to cut over your Client Access Services (MRS, AutoD, OWA, OA, etc) prior to this point as we need to make sure all requests go to Exchange 2016 first as well.
Secondly, when completing the migration of Public Folders, there is a step documented by Microsoft that specifically states that we can assign a Public Folder mailbox to an individual user. What this does is allow a user to test their access to the Public Folder copy on the new server (Exchange 2016 in this scenario). – this mailbox needs to be on Exchange 2016. What you may not know is that there is another configuration issue that you need to be aware of when making this change – not documented in the migration docs.
Scenario
Old configuration in Exchange Online is still present:
Get-OrganizationConfig | Fl RemotePublicFolderMailboxes
Notice that the configuration is all pointed to 2010. If we want a user to test the new Public Folder instance, we can point their mailbox to any of the PFMAilbox1 to 27 that are present. So, we do so like this:
Set-Mailbox dscoles -DefaultPublicFolderMailbox PFMailbox1
However, this fails:
This message is misleading as we know the mailbox exists in Exchange 2016, however the cmdlet’s error message declares the mailbox cannot be found. What is the real issue? Problem is that the current ‘RemotePublicFolderMailbox’ values are set to the mailboxes in Exchange 2010 and because the mailbox we are specifying is not in this list, we cannot assign it. To illustrate this, if I want to assign one of the existing Exchange 2010 Public Folder proxy mailboxes, I can:
Set-Mailbox dscoles -DefaultPublicFolderMailbox PFMailbox01
So that was successful. However, we need to point it to the new Exchange 2016 servers. How?
Set-OrganizationConfig -RemotePublicFolderMailboxes PFMailbox1, PFMailbox2, PFMailbox,3, PFMailbox4
Now we see the updated list, with the mailbox GUID (expected in Exchange 2013+):
Once we do that, this one-liner now works, and we can test Public Folder access:
Set-Mailbox dscoles -DefaultPublicFolderMailbox PFMailbox1
It’s easiest to visualize the Remote Public Folders Mailbox setting as a pool of Public Folder mailboxes from which to assigned users to and if the mailbox is not in the list, you cannot assign it. Seems so easy now.
How to Monitor the migration?
Public Folder migrations generally run nearly as smooth as mailbox migrations and are partially complicated, in the cases of legacy to modern Public Folders, by the conversion process of putting all Public Folder data into mailboxes. This restructuring can cause issues
PowerShell
The migration batch itself is created and can be monitoring with cmdlets of the same noun – ‘MigrationBatch’, however, getting any level of detail from these cmdlets just isn’t possible. What we are looking for are Statistics cmdlets which can reveal details about what is occurring on the lower level of the migration and not just an overarching status of complete or not.
Get-MigrationBatch example:
If we search in PowerShell for relevant statistics based migration cmdlets, we can come up with these:
Get-Command *Migration*Statistics*
OK, we can combine the Get-MigrationUser cmdlet and pipe the information it gathers over to the Get-MigrationUSerStatistics to provide what we need for determining migration progress. What does that look like?
Get-MigrationUser | Get-MigrationUserStatistics | FT Identifier,SyncedItemCount,TotalItemsInSourceMailboxCount,BytesTransferred,EstimatedTotalTransferSize,PercentageComplete,Status,TotalInProgressDuration -Auto
Which provides this information:
If there are issues or you think something is not completing in a timely fashion, we can also extract the migration report which goes into detail about the migration for each destination Public Folder mailbox:
Example, PFMailbox6 appears to ‘recycle’ the percentage complete as it gets to 95%, you notice it changes back to 20%, which is the start of a migration process for mailboxes and Public Folders. So we use this one-liner to pull a report:
(((Get-MigrationUser PFMailbox6 | Get-MigrationUserStatistics -IncludeReport).Report).Entries).LocalizedString | ft LocalizedString
We then look at the output from this one-liner to see if there any issues to worry about or if the issues are transient.
For additional monitoring, refer back to the first article and the Last Successful Sync Date information as this could be crucial to nailing down an issue.
Conclusion
Well there you have it. The two-part series on Public Folder issues is now complete and hopefully you gleaned some useful information as well as some tips / tricks on how to handle these migration types. Outside of these twoblog posts, there are innumerable other blog posts that list other ways to tweak migration performance as well as good resources for Exchange Online moves like this one from Microsoft.
———————————————————————————————————–
Comments? Questions?
Feel free to leave your Comments below! Learn to more efficiently utilize PowerShell to manage Exchange Server, Exchange Online, Microsoft Defender for Office or Microsoft Purview Compliance portals by picking up frequently updated eBooks:
