This step can be run in parallel with #9 if desired and should be run at least 24 hours or more before the cutover event. Generally, mail-enabled public folders are not created at high frequencies nor are changes to them. As such, there should not be too much concern of running this task many days before cutover as long as confidence exists that there will not be changes to MEPFs between the script creation and execution.
The script generation is performed by the PF Toolbox feature “Mail Enabled Folder Migration”. This option in the PF Toolbox will enumerate all the public folders in the hierarchy and for each one that is mail-enabled, the details of the folder will be collected and written to a PowerShell script file. If the total number of folders in the hierarchy is very large – 10s of 1000s of folders – this process may take many hours to complete. Please plan accordingly.
The script generation will capture all of the possible features of a mail-public-folder such as:
- Email addresses (proxyAddresses)
- legacyExchangeDN
- Mail Alias (mailNickName)
- Delivery restrictions
- Moderation
- Forwarding
- Send-As permissions
- Group memberships
The script is expected to be run within the context of an exchange PowerShell session for the target environment. The script uses PowerShell commands such as Get-PublicFolder, Enable-MailPublicFolder and so on. Priasoft recommends authenticating to Exchange in the PowerShell session with an account that is an Exchange Administrator so that all PowerShell commands can be received and used.
The script execution may take as little as a few minutes to many hours to complete and is primary influenced by the number of mail-public-folders to be enabled. As a PowerShell script, the actions performed are inherently single-threaded. Office 365 PowerShell actions are also throttled and execute over the Internet and are slower than the same actions performed on an on-premises environment. Folders with large quantities of group memberships or send-as rights can further extend the duration of the script. Please plan accordingly.
The script is only focused on mail-enabling the target public folders. It does not setup any forwarding on the source folders, nor does it disable or remove any of the values of the source objects.
This step in the process is only focused on the creation of this script file. The actual execution should occur during the cutover event.
Furthermore, a reminder that if there are already conflicting objects in the target environment – pre-existing fake mail-public-folders or contacts or mailboxes with overlapping addresses – the script will fail when it attempts to add the email addresses of the source folder to the new folder. The folder will still be mail-enabled since that process will never fail due to address conflicts – Exchange will simply add a number to the user part of the email address, like: sales1@priasoft.com, if sales@priasoft.com is already in use.
If there are many 100s or 1000s of folders to be mail-enabled, it may take many hours to complete and over a timespan such that the underlying PowerShell connection to the exchange server expires or is dropped. This will cause the script fail and stop. It may be required to rerun the script several times in order to overcome this behavior. Note: Microsoft recently released V3 of the Office 365 Exchange Online Management module with is inherently REST-based and does not suffer from the timeout issues of previous versions.
