As a BitTitan customer, all of the configuration necessary to migrate public folders can get confusing. This article outlines some of the things that users can do to make a public folder migration run more smoothly. The article will include:
- Creating the public folder mailbox at the destination
- User permission levels at the source and destination
- Hybrid public folders need to be disabled for migration
- Supported folder operations –mail-enabling (yes), alternate email addresses (no)
- Why does it look like my public folder migration is stuck?
- There are several things that users can do in order to make a public folder migration go as smoothly as possible. Let’s go over a few of them.
Public Folder Mailbox
The Exchange team decided to rewrite how public folders are stored in the latest version of their product. This means that when migrating public folders, we cannot simply create a new public folder at the destination without a little bit of setup beforehand. Similar to how you have to create a mailbox for a user before we can migrate any of their mailbox items into the mailbox, a public folder mailbox has to be created before we can migrate any public folder items. In Office 365 and Exchange 2013, you can manage public folder mailboxes from the Exchange Admin Center (EAC). You will have to create the first public folder mailbox here before the migration can begin.
According to the current limits, one public folder mailbox must be created for every 50 GB of public folder data for Office 365 and 100 GB of data for Exchange 2013. You can provision all of the necessary public folder mailboxes before the migration begins. If you do not, we will attempt to create extra public folder mailboxes if we have sufficient permissions to do so, otherwise you will get an error stating that the maximum size has been reached for the public folder mailbox.
Picking Users with the Right Permissions
In order to properly migrate public folders, we require that you enter administrative credentials for both the source and the destination. What this actually means is that we require full read permissions at the source from the root public folder to all subfolders, and we require read and write permissions at the destination from the root public folder to all subfolders that are going to be created. For the source, this only requires the use of credentials for the administrative user on the server. For the destination, however, there is a little more setup involved. Firstly, the user has to be part of the Organization Management administration role. You can find this role in the EAC under permissions.
Secondly, it is required that the user is given explicit access to the root public folder (and all subfolders if they exist) in order for the migration service to properly access the folder structure and create the folders and items within those folders. This can be done by going to the EAC and opening the public folder section, and then selecting the ‘…’ option to set the ‘Root Permissions’.
Follow this up by adding ‘Owner’ level permissions to the admin user for the root folder (IPM_SUBTREE) and apply the change to all subfolders as well.
After you have set the admin user at the destination with these permissions and roles, then the public folder migration will be able to proceed without hitting permission errors.
Disabling Hybrid Deployments
An option that is available for organizations that are migrating to Office 365 is to enable a hybrid deployment where users’ mailboxes are hosted in Office 365, but public folders still exist on the on premise server. This is done by redirecting requests for public folders from Office 365 back to the on premise Exchange server after a specific hybrid setup has been performed to allow for this. Because requests for public folders are redirected back to the on premise server, migrates are not possible when a public folder hybrid deployment is enabled in an Office 365 account. In order to perform the public folder migration, the hybrid deployment must be disabled during migration. It can be re-enabled after the migration has completed, but note that the Office 365 public folders will not have the latest content for the public folders unless a delta pass is performed after the hybrid deployment is once again disabled.
Support for Folder Operations
Public folders have two unique characteristics that other folders do not have. Firstly, they can have email delivered directly to them. This is called being ‘mail-enabled’. When a public folder is mail-enabled, it is assigned an email address and whenever email is delivered to the Exchange server with that email address, the email is put directly into the public folder. The second unique characteristic that public folders has is that aliases can be setup for email address that is assigned to these mail-enabled public folders. This means that you don’t have to use the default assigned by the Exchange server as the email address, but you can setup a shorter (or longer) email address which will also be used to deliver email to a given folder. Oftentimes, an organization will have setup a detailed configuration for both of these options in order to facilitate the functionality they want, and they want to migrate over these options along with the folder structure and contents. The good news is that we do migrate mail-enabled public folders automatically, the bad news is that we do not migrate over the alias email addresses for these mail-enabled public folders.
In order to automatically migrate over the setting which will mail-enable a public folder, we require sufficient access and permissions to do so. If you have set the permissions at the destination as stated above, then the user should have sufficient permissions to set a folder as mail-enabled. Allowing access to perform this operation is a different story. Microsoft has moved away from providing native support for administrative operations within their APIs, and in its place has moved towards only allowing these operations to be performed by using PowerShell. This means that in order to mail-enable a public folder, we have to remotely initiate a PowerShell script which will perform the action. For Office 365, remote PowerShell is on by default for all new organizations so we have no problem here. But for on premise Exchange 2013, remote PowerShell is often disabled for security reasons. This means that we can usually only migrate over the setting which mail-enables a public folder when the destination is Office 365, though in the rare case when an organization has enabled remote PowerShell for Exchange 2013 we can do it here as well.
The aliases for mail-enabled public folders are not actually a property that is stored within Exchange. They are actually something that is associated with the primary email address within Active Directory. Because of the sensitive nature of Active Directory, it is rarely exposes via any interface to the public internet. This means that we have no recourse to be able to set these aliases by any traditional means. As an alternatively, we have come up with a set of manual instructions that you can follow in order to migrate over all of these aliases on your public folders. You can find the article outlining these steps here.
Why does it look like my Public Folder migration is stuck?
One thing that customers often do not realize is just how big their public folders actually are. Because public folders are often hundreds of times larger than the average user’s mailbox, it can take much longer to migrate a set of public folders than a user’s mailbox. Further, there are three steps required during any migration – authentication, discovery, and migration. The first step is usually very quick, requiring that we verify that the credentials you have provided us will allow us to login to the source and destination systems and access the public folder hierarchy. The last step can take a long time, but it is obvious things are happening because statistics are being generated and content that you can see in the target folder is being moved. The second step, however, can be quick or it can take a long time depending on the complexity of your public folder hierarchy. In the past, we have seen migrations with as many as 7,000 folders in a public folder hierarchy that was 10-20 levels deep. Since access to public folders is limited to being non-recursive, every sub-tree has to be processed separately, one level at a time. This means that this discovery can take some time to perform, and though it may look like nothing is happening, behind the scenes we are retrieving and traversing all levels of your public folders in order to catalog what we need to migrate. And since this operation doesn’t actually move any data, no statistics are generated other than the fact that we have found more folders, which can get a little frustrating. We are working to make this experience better for you as best we can.
Overall, public folders are very useful and provide an organization with indispensable functionality which they do not want to lose when they migrate to a new system. We do our best to enable this for all our customers and the tips above should help your public folder migrations run more smoothly. Please let us know if there is anything else we can do to make your experience better.