Making your public folder migrations faster and more reliable

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.

The key for a successful migration (of any type) is to ensure that source data is in a healthy condition. Public folder migrations are no different, especially if you have been using public folders for years. Orphaned ACLs, mis-matched Mail Enabled Public Folder objects (MEPF’s), or corrupted dumpster folders can cause public folder migrations to slow down considerably, if not fail altogether.

We are happy to provide admins with a Source Validation script (clicking will start download of the script) which can scan and report on issues found with public folder deployments. The script can be used to scan legacy public folder deployments hosted on Exchange Server 2010 or modern public folder deployments on Exchange Server 2013, Exchange Server 2016 or Exchange Server 2019. It is recommended to use this script to scan public folder deployments before the start of a migration and fix any issues reported before proceeding with migration.

Currently, the script checks and reports:

  • Orphaned ACLs
  • Health of Mail Enabled Public Folder (MEPF) objects*
  • Health of Dumpster folders*
  • Check if the source fits in the current EXO limits.

*These tests are valid for public folder deployments on Exchange 2013 and above.

Script usage

Download the script from here, copy it to on-premises servers and execute from Exchange Management Shell. The script reads public folder hierarchy and stores the information into CSV files on the disk. Then, various checks are performed using the information stored in the CSV files. The results, along with actions to be performed, are presented in a log file named “SourceSideValidations.[yyyyMMdd_HHmm].log”

Important parameters:

Parameter

Required

Description

verifyMEPF*

Optional

Specifies if MEPF integrity check needs to performed. By default, set to true. The option works for Exchange Server 2013 and above.

checkLimits

Optional

Specifies if Limits need to be checked for public folder. By default, set to true.

verifyDumpsterMapping*

Optional

Specifies if public folder mapping with dumpsters needs to be verified. By default, set to true. The option works for Exchange Server 2013 and above.

chekPermissions

Optional

Specifies if permissions need to be checked on public folders. By default, set to true.

startAfresh

Optional

Specifies if the script should read from files on the disk or read from PF structure again. Default value is true. The script will read the PF structure and create log files on the disk. Specify startAfresh:$false in case the script execution was interrupted for any reason and needs to be resumed from the point where script was interrupted.

Examples

The following example shows how to perform only dumpster mapping check:

 

.\SourceSideValidations.ps1 -verifyMEPF $false -verifyDumpsterMapping $true -checkLimits $false -checkPermissions $false

 

The following example, without providing any parameters performs, all the checks (i.e. -MEPF, Limits, DumpsterMapping and Orphaned ACL check):

 

.\SourceSideValidations.ps1

 

The following example shows how to have script read public folder information from the existing files. This is useful in scenario if the script execution was interrupted and needs to be resumes from the time of interruption:

 

.\SourceSideValidations.ps1 -startFresh:$false

 

Additionally, here are some important points to be noted:

  • Script execution time depends on the size of public folder deployment on-premises. For larger deployments, script may take several hours to complete.
  • The script must be executed from the appropriate source server within your on-premises deployment of public folders. For example, if you have public folders deployed on Exchange 2010 (legacy public folders), even if the environment also has Exchange 2013/2016 servers installed, the script must be executed from the Exchange 2010 server. But if your environment uses modern public folders, you would run this on an Exchange 2013/2016/2019 server.
  • The script reports issues into a log file, saved in the execution folder. The log file name looks like:

SourceSideValidations.<timestamp>.log

SourceSideValidations.20190923_08.log

  • The script will also recommend actions to be performed to fix the issues, however, the script itself will not fix any found issues.

Please leave a comment to let us know your feedback about the script. Happy public folder migrations!

Public Folder Team

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.