How do you plan and execute a successful Public Folder migration?

From all the years as a consultant, and now directly in the migration business, helping partners successfully plan and execute migrations, Public Folders as always been the one of the most challenging workloads I had to deal with.

There’s always a lot of questions when you have to execute such migrations, so I decided to write a blog post about it, where I am going to try and address as much as possible.

To try and keep it as organized as possible, and because there are so many different scenarios, I will divide this post into three main sections: General migration considerations, Migrating Hybrid Public Folders and Migrating Public Folders cross organization.

We will then also discuss some more generic questions, such as why use a third party tool vs the Microsoft native tool.

General migration considerations

This blog post is focused both on Hybrid and cross organization Public Folder migrations. Some steps however are exactly the same, regardless of what the migration scenario is. Those steps are described below. After reading this section you can then focus on your specific scenario in the sections that follow.

Prepare your On Premises Environment

One of the first things you need to look at is to the On Premises Public folder structure, to check if there’s any inconsistencies or invalid folders. The best way to that is of course via scripting, and you should use this excellent script from Aaron @Microsoft, called IDFix for Public Folders. Download it, run it and fix everything that the script highlights as needing to be fixed.

You should also make sure you create a report with all mail enabled Public Folders and address, and to do so you can leverage the Get-MailPublicFolder cmdlet.

How to migrate Public Folder access permissions, as well as Send-As and Send-on-behalf rights

Public Folder permissions should be migrated by the migration tool, provided of course identities match between on premises and Exchange Online (which should of course be true for Hybrid scenarios), or between premises  in cross organization migrations.

As for the Send-As and Send-on-behalf rights, the best option is to export them from the source system and import them into the destination system, once the migration is completed. Since this is not PowerShell code I’ve focused on recently, I did a quick research online and found this article online where you can find the code to export and import those access rights.

Note: I am not the author of the code below and I am only putting it directly in my blog post just so it’s easier for you to locate it and copy it. The code was taken from the article mentioned in the line above, written by Aaron Guilmette.

Export Send-As

Get-MailPublicFolder -ResultSize Unlimited | Get-ADPermission | ? {($_.ExtendedRights -Like "Send-As") -and ($_.IsInherited -eq $False) -and -not ($_.User -like "*S-1-5-21-*")} | Select Identity,User | Export-Csv Send_As.csv -NoTypeInformation

Export Send-on-behalf

Get-MailPublicFolder | Select Alias,PrimarySmtpAddress,@{N="GrantSendOnBehalfTo";E={$_.GrantSendOnBehalfTo -join "|"}} | Export-Csv GrantSendOnBehalfTo.csv -NoTypeInformation

$File = Import-Csv .\GrantSendOnBehalfTo.csv
$Data = @()
Foreach ($line in $File)
    {
    If ($line.GrantSendOnBehalfTo)
        {
        Write-Host -ForegroundColor Green "Processing Public Folder $($line.Alias)"
        [array]$LineRecipients = $line.GrantSendOnBehalfTo.Split("|")
        Foreach ($Recipient in $LineRecipients)
            {
            Write-Host -ForegroundColor DarkGreen "     $($Recipient)"
            $GrantSendOnBehalfTo = (Get-Recipient $Recipient).PrimarySmtpAddress
            $LineData = New-Object PSCustomObject
            $LineData | Add-Member -Type NoteProperty -Name Alias -Value $line.Alias
            $LineData | Add-Member -Type NoteProperty -Name PrimarySmtpAddress -Value $line.PrimarySmtpAddress
            $LineData | Add-Member -Type NoteProperty -Name GrantSendOnBehalfTo -Value $GrantSendOnBehalfTo
            $Data += $LineData
            }
         }
    }
$Data | Export-Csv .\GrantSendOnBehalfTo-Resolved.csv -NoTypeInformation

Import Send-As

$SendAs = Import-Csv .\SendAs.csv
$i=1
foreach ($obj in $SendAs) 
    { 
    write-host "$($i)/$($SendAs.Count) adding $($obj.User) to $($obj.Identity)"
    Add-RecipientPermission -Identity $obj.Identity.Split("/")[2] -Trustee $obj.User.Split("\")[1] -AccessRights SendAs -confirm:$false; $i++
    }

Import Send-on-behalf

$GrantSendOnBehalfTo = Import-Csv .\GrantSendOnBehalfTo-Resolved.csv
$i=1
Foreach ($obj in $GrantSendOnBehalfTo)
    {
    Write-host "$($i)/$($grantsendonbehalfto.count) Granting $($obj.GrantSendOnBehalfTo) Send-On-Behalf to folder $($obj.PrimarySmtpAddress)"
    Set-MailPublicFolder -Identity $obj.PrimarySmtpAddress -GrantSendOnBehalfTo $obj.GrantSendOnBehalfTo
    $i++ 
    }

Migrating Hybrid Public Folders

This scenario, when compared to the cross organization migration, is far more complex, because besides moving the data you will also have to worry about things like mail flow, user public folder access, etc. But lets address one thing at the time.

Microsoft Official guidance to configure Hybrid Public Folders

If you’re reading this article because you’re planning to migrate your Hybrid Public folders, chances are you already read and executed the Microsoft guidance to make your on premises Public Folders available to Exchange Online users, under a Hybrid deployment. Configure legacy on-premises Public Folders for a Hybrid Deployment is the article for legacy public folders and Configure Exchange Server Public Folders for a Hybrid Deployment is the one for modern Public Folders.

Both articles are focused on the hybrid coexistence and not the migration planning of the Public Folders, but they are important to mention as they impact the migration planning, based on what type of coexistence you configured and steps you followed.

Public Folder end user access in the context of a hybrid migration

When planning a Public Folder migration, under a hybrid scenario, one of the most important things you need to consider is, end user access. With that in mind, consider the following:

  • On premises users cannot access Exchange Online Public Folders
  • Exchange Online users can access on premises public folders and/or Exchange Online Public folders, although you cannot configure a single user to access both, you can configure some users to have access to on premises folders and some to see them locally, in Exchange Online.

Have the two principles in mind, during your planning. The Public Folder access for Exchange Online users is complex and by itself worthy of a dedicated blog post.

The Microsoft official guidance, mentioned in the previous section, explains how you configure Exchange Online users to access on premises Public Folders.

The bottom line of this section is, make sure you move all users to Exchange Online, before you consider moving the Public Folders, and if you don’t, make sure that the users left on premises do not require any Public Folder access.

Public Folder mail flow coexistence before, during and after the migration. How do you handle mail enabled Public Folders.

Another very important component of your Public Folder migration is the mail flow coexistence, or to be more precise, the way you deal with the mail enabled Public Folders.

Mail Enabled Public Folders before the migration

When you follow the guidance provided by Microsoft, you will be asked to execute the Sync-MailPublicFolders script.

This script enables Exchange Online users to send emails to on premises mail enabled Public Folders, by creating mail objects in Exchange Online with the primary and all other SMTP addresses that those folders have on premises. This objects are not actual Exchange Online Public Folder nor they are visible in the Exchange Online Public Folder tree. They also allow those on premises Public Folders to be present in the Exchange Online GAL (Global Address List), and once a user in Exchange Online emails that folder, the email gets forwarded to Exchange On Premises.

Mail Enabled Public Folders during the migration

During the Public Folder migration, whether it’s a single or multiple pass (with pre-stage + full migration) migration strategy, you should not change the Public Folder mail flow. That means that you should not mail enable the Public Folders in Exchange Online (chose a tool that gives you that option). Actually as you will see below, there are things that you need to do in Exchange Online, before mail enabling the Public Folders.

Mail Enabled Public Folders after the migration

Once your migration (or the pre-stage) is completed, you should transition the Public Folder mail flow to Exchange Online. To do so, you should follow these steps:

  1. Start the pre-stage or full migration and wait for it to be completed
  2. Once the migration pass is done, go to Exchange Online and delete all mail objects created by the Sync-MailPublicFolders script (NOTE: this will temporarily break mail flow between Exchange Online users and mail enabled Public Folders, online or on premises)
  3. Mail enable the Exchange Online Public Folders, either via a script or using the migration tool. Make sure you add all addresses from the on premises to the online Public Folders
  4. Run a full migration pass if in step 1 the pass that you ran was a pre-stage

To elaborate a little bit more in step 2, the reason that you need to delete those objects is because you need to avoid conflicting addresses, when enabling the mail enabled Public Folders in Exchange Online, and those objects are not associated with the new EXO Public Folders.

Migrating Public Folders cross Organization

Migrating Public Folders cross organization is not as complex, and you’ll see why in the sections below. This scenario can include migrations such as:

  • Exchange Online to Exchange Online
  • Hosted Exchange to Exchange on premises or Exchange Online
  • Exchange on premises to Exchange on premises

When to migrate users and Public Folders

Usually this Public Folder migrations cross organization come as an additional step to a migration that also includes mailboxes.

Although there’s no 100% correct answer, when it comes to the question of what should be migrated first, mailboxes or Public Folders, in this cases normally the best option is to migrate mailboxes first and Public Folders last. The main reason for that is because you should migrate the Public Folders when they’re not being used anymore, allowing you to do a clean single pass migration of all the data.

Public Folder end user access and mail flow coexistence

This is where things gets simple, for this type of scenarios. There’s no Public Folder access cross organization (unless the user is using the credentials for the 2 systems) and although technically you can configure mail flow between any two email systems, it’s not something you should consider for the majority of the cases.

Mail enabled Public Folders can and should be created at the destination during the folder hierarchy creation.

Why use a third party tool to migrate Public Folders

That’s probably the question I get the most, working for a third party migration tool company, that has an amazing Public Folder migration tool, BitTitan. And here is a list of reasons:

  • Migrate large volumes of data: Migrating 2, 5 or 10GB is easy with any tool, but not all tools can deal with Terabytes of Public Folder data.
  • Migrate parts of the structure or prioritize data: Either by targeting just specific parts of the Public Folder hierarchy or by using folder filtering. This is a very commonly used feature in tools like BitTitan MigrationWiz.
  • Flexibility on handling mail enabled Public Folders: As explained in the Hybrid mail flow section of this posts, you might need some flexibility on how to handle mail enabled Public Folders during the migration. MigrationWiz will mail enable in the destination all Public Folders that are mail enabled at the source, but you can also suppress that option, and should in some scenarios.
  • Data transformation: While planning a migration of Public Folders, some customers want to take that opportunity to also move that data into a different structure, which can be shared or resource mailboxes, office 365 groups, etc. That is something that can be successfully done with tools that are flexible enough to perform that transformation (i.e in many cases requires recipient mapping, folder mapping, folder filtering, etc), like MigrationWiz.
  • Supported sources and destinations: Exchange 2007+ to Exchange 2007+, including of course Exchange Online and hosted as source and/or destination – this is the answer most customers want to hear from the support ability stand point of a third party tool, to migrate their Public Folders, and that is something they won’t get with the native tool.

The bottom line

While reading this post, before publishing it, I always get the feeling that there’s so many other things that I could mention and talk about, but I do think that it addresses the core concerns of most Public Folder migrations, and hopefully it addresses yours.

Nevertheless, if you do have any questions don’t hesitate to reach out.

 

 

 

Advertisements

The differences in quotas and how to handle Public Folder migrations to Exchange 2013+ On premises vs Exchange Online

When we talk about migrating Public Folders, and believe me I talk about that a lot, the usual assumption is that the migration is to Exchange Online. That is true most of the times, but not all.

BitTitan MigrationWiz is a tool that adapts to all sorts of scenarios, the rule being if you have an Exchange 2007+ in the source and destination, and that of course includes Exchange Online, that MigrationWiz will be able to migrate your Public Folders. That being said I find myself discussing scenarios such as migrating Public Folders from Exchange on premises or Exchange Online, to a destination Exchange On Premises.

For those used to migrate Public Folders into Exchange Online, you would know that one of the main things to take into account is the volume of data to be migrated and how to make that work seamlessly, since the Public Folder mailboxes in Exchange Online have quotas you can’t change, as you can see here.

One of the things that makes MigrationWiz such a good tool to migrate large volume of Public Folder data, into Exchange Online, is that we will automatically split the Public Folder data into multiple mailboxes, therefore preventing a migrate failure and delay if one of the mailboxes gets full during the migration. This is done via support and explained in all the relevant migration guides, such as this one.

So the question now is, would this process be necessary when the destination are Exchange On Premises 2013+?

Answer: No. You can’t change Public Folder mailbox quotas in Exchange Online, but you can change them in Exchange On premises, so you don’t need to automatically split the data into multiple destination mailboxes.

And should I use a single On Premises mailbox for a large volume of data?

Answer: You can, but you shouldn’t. If you have 100, 150 or 200GB of Public Folder data, then yes a single mailbox approach seems reasonable, but if you have more than that you should think about having multiple mailboxes, for reasons like backup and restore management, among others. Another reason for having multiple Public Folder mailboxes might be if you have a multi region Exchange Organization and you want to provide localized access to Public Folders.

Why do you reference the destination as being Exchange 2013+?

Answer: Because this blog post focuses specifically in modern public folders (mailbox vs database).

Now lets have a look at a Public Folder mailbox in Office 365:

PFMBX1

As you can see above the quotas are well defined and cannot be changed.

How does that look in Exchange On premises?

PFMBX2

Above you can see 2 Public Folder mailboxes. One comes with the quota set to unlimited, which is the default when you create a new Public Folder mailbox in Exchange 2013, and for the other one I’ve set the limits to 150GB, with the following command:

Set-Mailbox -PublicFolder <mailboxname> -ProhibitSendReceiveQuota 150GB -ProhibitSendQuota 150GB -IssueWarningQuota 150GB -UseDatabaseQuotaDefaults $false

Note: Don’t forget to set the database quota defaults to false, if you want the new quotas to apply at the mailbox level.

As you can see above there are differences between Exchange Online and On Premises, and the control you have over both. Consider them when planning your migration.

 

While having Public Folder access in 365 set as remote in the Organization Config, point some users to the Exchange Online Public Folders

Some key things you should have in mind, when you’re moving your Exchange Organization from On Premises to Office 365, and Public Folders are in scope:

  • Before moving the Public Folders to Exchange Online, you need to move all of your users (at least you should move all of the ones that require Public Folder access). Users in Exchange On Premises cannot access Public Folders in Exchange Online.
  • You need to follow the Microsoft Official guidance to configure legacy on premises Public Folders under a hybrid deployment.
  • You can (and should in some scenarios) point some mailboxes to the online Public Folders and that’s what this blog post is all about

Now lets look at how a Hybrid Public Folder Organization Config looks like:

PFOrg1

As you can see above, the Public Folders in 365 are configured as remote (step 5 in the guide mentioned above), and an on premises public folder mailbox is defined as their mailbox (created in step 2 of the guide).

What this does is very simple: at the mailbox level, for each mailbox, it will set the parameter “EffectivePublicFolderMailbox” to the mailbox “OnPremPFMBX”, which is a synced mailbox object from on premises, as you can see below:

PFOrg2

And how do we change this, per user?

The answer is simple, you run a set-mailbox cmdlet, to one or multiple users, and you define the -defaultpublicfoldermailbox parameter, to a 365 Public Folder mailbox, that you of course need to have created before hand.

set-mailbox <Mailbox> -DefaultPublicFolderMailbox 365PFMBX

The command above is what you need to run, and you can adapt if to multiple users. Let me know if you need help with that.

Before closing this blog post lets just discuss one last thing: creating the Office 365 Public Folder mailbox.

A Public folder mailbox created under a Hybrid scenario, where public folder access is set to remote, will be set by default to a HoldForMigration state. Follow this excellent BitTitan article to understand why and resolve that issue. You need to resolve it before you can create new public folders in Exchange Online.

And while doing that don’t forget that, the best tool out there to migrate your Public Folders is the BitTitan MigrationWiz tool, so while you’re in our help center go ahead and read our migration guides and ask for a quote from our sales team.

Public Folders to Office 365 groups, anyone?

Just recently, the Microsoft Exchange Team reached out to the public again asking if partners or customers out there are interested in moving from the well known ancient Exchange Public Folders (and yes they can be modern or legacy) to the new Office 365 groups.

In the Microsoft Exchange Team Blog they state that the main focus will for now be to migrate mail and calendar items, but they do leave the “door open” to future support to be extended to other item types. How awesome would it be to convert Public Folder posts into OneNote in the Office 365 groups, right? 🙂

As a final note, they also state that, this will be focused in source Public Folders that can be on-premises or in Office 365.

Now before we look at all migration (and in some cases conversion) options, lets look at all the item types that you can have in when you create a Public Folder:

  • Mail and Post
  • Calendar
  • Contact
  • Note
  • Tasks
  • Journal
  • InfoPath forms
  • Documents

So what can you move to Office 365 groups and how? Ideally you would migrate mails and calendars into the Office 365 group mailbox, documents into the Office 365 group document library and Posts into OneNote. That I’d say would cover a huge percentage of the Public Folder usage we have out there today, don’t you agree? Hopefully if you’re reading this post, and thinking on doing the conversion from Public Folders to Office 365 groups, the Public Folder usage of your organization is focused in mail, calendars, contacts, posts and documents.

So now your question might be: is there any option out there that can migrate at least part of this content, from Public folders to Office 365 groups? And the answer is YES!

BitTitan MigrationWiz will help you do the following migrate from Public Folders (Exchange 2007+ on premises or Exchange Online) into Office 365 groups. Not all content will be moved, due to limitations in the EWS API, currently used by MigrationWiz to migrate Public Folders as a source, but here’s what you should expect:

  • Emails get migrated from mail enabled Public Folders into the Office 365 group mailbox. They will show in the conversation section.
  • Posts get migrated from Public Folders into the Office 365 group mailbox (attachments included). They will show in the conversation section.
  • Calendar items get migrated from the Public Folder calendar into the Office 365 group mailbox calendar.
  • Office 365 groups do not have a way of showing shared contacts and tasks, therefore you should not try and migrate them.
  • Documents do not get migrated from Public Folders to the Office 365 group SharePoint library.

Migrating data between different systems (Public Folders vs Office 365 groups) is not all about the question “Can the data be migrated or not?”. A good example is what I highlighted above about the tasks and contacts, why?

  1. MigrationWiz can migrate the tasks and the contacts
  2. The tasks and the contacts, after being migrated, will show up in the statistics of the mailbox (that you can extract via PowerShell)
  3. The design of the Office 365 groups won’t allow your users to see those tasks and contacts in any of the clients where you can use to access the groups
  4. That makes migrating contacts and tasks a pointless exercise

Finally some high level tasks on how to perform the migration:

  1. Create MigrationWiz Public Folder project
  2. Edit the advanced options a change the destination to shared mailbox
  3. add in the advanced support options: RemoveFilterBasedOnFolderType=1
  4. Add one line item per item type: One for email and one for calendars
  5. Add folder mapping to each line item to map the items into the correct folder in the destination (i.e FolderMapping=”^.*$->Calendar”)

Like stated in the disclaimer below, BitTitan does not have currently a migration guide for this scenario. If you want more detailed steps please leave a comment and I will reach out.

Disclaimer: To migrate from Public Folders to Office 365 groups I used the BitTitan feature of migration from Public Folders to Shared mailboxes. Technically an Office 365 group has a mailbox in many ways similar to a shared mailbox, but with some differences.

BitTitan does not have a migration guide nor it states (at the day and time that this blog was written) that it supports the migration from Public Folders to Office 365 groups.

This blog post was written after careful testing and verification and the migration worked without any issues. If you are interested in using MigrationWiz to migrate from Public Folders to Office 365 groups I highly recommend that you contact BitTitan and engage in a POC (proof of concept).

As always, any comments are welcomed and let me know how that migration went.

Office 365 Public Folders Migration: Why and when to use MigrationWiz and not the Microsoft native tool

Migrating legacy Microsoft Exchange Public Folders to Office 365 is a challenge that many Organizations are facing at the moment, and the first question that comes to mind is: “What tool shall I use?”

From my perspective and experience, you have two valid options to push your Public Folders to Exchange Online:

  1. The Microsoft Native tool
  2. MigrationWiz from BitTitan

Reasons to use the MigrationWiz Tool

When the source is a Hosted Exchange

Most of the steps you need to follow on the Microsoft TechNet article, to migrate the legacy public folders to Office 365, require full control on the source system. No Exchange hoster will give you the control and permissions you need to use the Microsoft Native tool, therefore using MigrationWiz will be the best option in this scenario.

When the source is Exchange 2013

Microsoft states the following, on the official technet article:

“Exchange supports moving your public folders to Office 365 and Exchange Online from the following legacy versions of Exchange Server:

  • Exchange 2010 SP3 RU8 or later
  • Exchange 2007 SP3 RU15 or later”

This means that when the source is Exchange 2013, at the moment there is no official and supported migration path to move the public folders to Office 365, as you can also read on the BitTitan’s blog article, that describes the experience of the Microsoft Exchange expert and blogger Todd Nelson.

Because you don´t need to patch your existing Exchange Servers

As described above, and stated by Microsoft, to run the native tool your source servers need to be patched with at least Exchange 2010 SP3 RU8 or Exchange 2007 RU15. Patching Exchange servers might require downtime, and if you´re moving to Office 365, chances are you will decommission all Exchange Servers, keeping only one for management if you are using AADSync. So why schedule a maintenance window and patch servers there are soon to be decommissioned? MigrationWiz supports major versions with no specific requirements on the service pack or update rollup.

Support for large Public folders

MigrationWiz adds great value, when you have large individual public folders, and/or the total amount of public folder data to be migrated is very large.

But let’s start with the individual public folders. Microsoft clearly states the following, on the native migration TechNet article:

“Before migration, if any public folder in your organization is greater than 2 GB, we recommend either deleting content from that folder or splitting it up into multiple public folders. If either of these options isn’t feasible, we recommend that you do not move your public folders to Office 365 and Exchange Online.”

Which means that they do not support the migration of public folders larger than 2GB, or at least if and when you have a problem with your migration (and believe me, chances are you will), related to folders bigger than 2GB, the Microsoft support will probably give you an answer based on the statement above.

By default the Public folders on Office 365 cannot be larger than 2GB, but as you can see on the Public Folder limits Technet article, that limit can be extended up to 10GB. If you have public folders with more than 2GB (and of course less than the 10GB limit), all MigrationWiz requires is that you prepare your target environment, by following this article.

Regarding the large total amount of data to migrate, the great value of the MigrationWiz tool, when compared to the native tool, is the capability of, in case of error, getting more detailed information, and more importantly, not having to restart a migration. I was forced to restart very big migrations, done with the Microsoft Native tool, after getting very vague errors, and because the Resume-PublicFolderMigrationRequest was not working, to get my failed migration back in motion. As you can imagine having to restart a 400GB Public folder migration that was 50% done, it´s not a good experience 🙂

1

As you can see on the example above, the errors on the MigrationWiz portal are very clear and detailed, which helps a lot when troubleshooting. Public Folder mailboxes in Office 365 have a limit of 50GB per mailbox, therefore, if you´re migrating more than 50GB of data you need to follow this MigrationWiz article.

More details and statistics during the migration

Although with the native tool, you can run a Get-PublicFolderMigrationRequestStatistics, with the “-includereport” option, and export it to csv, that is nothing compared to what the MigrationWiz portal provides you.

2

You can see both the total number and size, per item type, with errors or migrated successfully.

3

There’s also information on the data migrated, items migrated or transfer speed, for you to have a better understanding of how things are progressing and estimate total migration times.

4

You can see the migration history, and all kinds of statistics, including a very useful data and item speed per hour statistic.

All the above is, in my opinion and based on my experience, very important when you are migrating a large amount of data.

It´s easy to migrate

The way I see it, unless you have very good technical knowledge of both Exchange online and on-premises, you should go for a tool like MigrationWiz that makes your life much easier.

I’ve seen a lot of issues when using the Microsoft Native tool (and you can find some posts in my blog on how to solve them), and if you don’t have advance knowledge, and you want to use the tool, you should find someone that has that knowledge and experience, and can assist you with the migration.

To be clear:

Is the Microsoft native tool, to migrate public folders, a good tool? Yes!

Does it work? Yes!

Is it challenging from a technical perspective? Yes!

Reasons to use the Microsoft Native Tool

If none of the above is relevant to you or your Organization, and you are an expert on Exchange online and on-premises, then you can use the native tool.

The bottom line is that, everything I stated on this post is based on the large experience that I have with Office 365, and more specifically with migrating Public Folders to Exchange Online. I´ve helped dozens of Organizations to achieve that, and learned a lot in the process.

I hope this post was helpful and as always, let me know if you have questions!

MigrationWiz: Public Folder migration fails to check destination credentials “No Public folder mailbox found” error

Are you trying to migrate your Public Folders to Office 365 and getting the error below?

1

Of course the first thing I recommend is obviously for you to check if you do have Public Folder mailboxes created in your Office 365 tenant. Log into the 365 portal, click to Admin Exchange, and then go to Public Folders > Public Folder Mailboxes.

4

You might need to wait up to 5/10 minutes after you create the Public Folder mailboxes and before running the MigrationWiz Public Folder project.

Also please make sure your MigrationWizAdmin user has the necessary permissions on the Public Folder structure. Read here for guidance.

Now what if everything described above is configured correctly, and you still have the same “No public folder mailbox found” error? Of course all the configurations described above are mandatory, but the real reason for this post is that something else might cause this error.

If all your users were moved to Office 365, and are accessing the Public Folders on premises, before you move those public folders to Office 365, I am sure you followed the Microsoft official article “Configure Legacy on-premises public folders for a Hybrid deployment“.

To enable the access to the legacy public folders, amongst other things, you need to run the following cmdlet:

Set-OrganizationConfig -PublicFoldersEnabled Remote -RemotePublicFolderMailboxes PFMailbox1,PFMailbox2,PFMailbox3

What the above cmdlet will do is, at the organization level set the Public Folders to remote, and more importantly, by setting the “RemotePublicFolderMailboxes” parameter and the OrganizationConfig level, it will change the “DefaultPublicFolderMailbox” parameter at the mailbox level, for all user mailboxes.

2

Above you can see that the RemotePublicFolderMailboxes is set to a mailbox called admin.vargas, and in your scenario it should be the name of an on premises mailbox, “dirsynced” to Office 365.

3

And if you look at the DefaultPublicFolderMailbox on your users, including the MigrationWiz admin user, that value will be set for the on-premises mailbox setting to match the “RemotePublicFolderMailboxes” parameters on the Organization Config.

So how does this affect the MigrationWiz project? Simple. Looking at the example above, the DefaultPublicFolderMailbox of the migwizadmin user is an on-premises “dirsynced” to 365 mailbox named “Admin.Vargas”, and that causes MigrationWiz to assume that there is no available public folder mailbox on 365. The solution is simple. Run the following cmdlet on your Office 365 Exchange PowerShell:

Set-Mailbox -identity migwizadmin@domain.onmicrosoft.com -DefaultPublicFolderMailbox PFMBX

4

You can see your Public Folder mailbox name, on your Office 365 Exchange Admin Centre, as shown above.

5

The cmdlet and the output, from the Exchange Online PowerShell.

Once the change is made, retry the MigrationWiz project, and job done!

There are a lot of good reasons for you to be in the scenario described above – Using MigrationWiz under a hybrid scenario, to move your public folders to Office 365 – especially if you have Public Folder with more than 2GB and a total amount of Public Folder data of more than 50GB. I will soon blog about all the advantages of skipping the Microsoft native tool to migrate the public folders and using MigrationWiz. Stay tuned!

Public Folder migration request error creating the Public Folder Hierarchy – “Property Expression [property name] isn’t valid”

To migrate your legacy public folders to Exchange 2013, you should follow all the steps described on the official Microsoft article.

Step 2 of the article mentioned above, helps you prevent errors related to the public folder name, such as having a “\”. But this blog post is related with something which is not covered by the article, and that can make your public folder migration request throw an error: Invalid alias on mail enabled public folders.

So as described on step 5 of the article, you start your migration request by running the following cmdlet:

1-done

 

New-PublicFolderMigrationRequest -SourceDatabase (Get-PublicFolderDatabase -Server <Source server name>) -CSVData (Get-Content <Folder to mailbox map path> -Encoding Byte) -BadItemLimit 200 -acceptlargedataloss -largeitemlimit 200

Note: On the above cmdlet i used both the baditemlimit and largeitemlimit set to 200, because i knew that my public folders had a significant number of both bad and large items. If that is not your case keep the bad and the large item limits to a minimum if at all specified.

Once the public folder migration starts you can run the following cmdlet to see the progress. If you have invalid alias on the mail enabled public folders, the migration request will fail at 10%, when creating the Public Folder Hierarchy:

3.1-Done

 

 

To get the details of the error you need to run the same cmdlet, but with the “|fl” at the end, as shown below:

2-done

 

Get-PublicFolderMigrationRequest |Get-PublicFolderMigrationRequestStatistics |fl

On the details you can see the following:

3.2-done

On the screenshot above you can see that the mail enabled public folder “Accountancy Properties” has an invalid alias, and that is because you cannot have spaces (and other characters as shown above) on the alias. So the next step would be to fix all mail enabled public folders with invalid aliases.

Go to your Exchange Management Shell and run a cmdlet that will list all the mail enabled public folders with spaces. Of course some other mail enabled public folders can have other problems, but in my case it was only the spaces. If you have other problems besides spaces you can adapt the “where-object” filtering from the cmdlet below, to those characters. Also to get an output of all the mail enabled public folders with issues, you can run the following cmdled and see which public folders throw a warning:

Get-MailPublicFolder

All the mail enabled public folders will throw a warning on the output, but of course we need to have a list of only the ones with problems to resolve the issue quicker. So to have a list with all the ones with spaces, and export it into a csv file, run the following cmdlet:

5-done

 

 

 

 

Get-MailPublicFolder | Where-Object {$_.Alias -like "* *"} | Select-Object alias, identity |export-csv [CSV file path and name]

Note: On the cmdlet above, if you’re problem is not limited to spaces on the alias, you can change the where-object filtering to try and find other invalid characters.

Once that is done you will get a csv file with all the mail enabled public folders with invalid aliases, as shown below:

6.1-done

 

 

Having that information you can now fix all the mail enabled public folders. You have two ways of doing it:

Option 1:

You can open your Exchange Management Console, go to tools and then open the Public folder Management Console. Expand the Public Folder tree and go to the properties of each public folder with problems. On the “Exchange General” tab change the alias and apply, as shown below.

7-done

 

 

 

 

Option 2:

You can use the Exchange Management Shell, and run the following cmdlet:

8-done

 

 

 

 

Get-MailPublicFolder [Public Folder Name] |Set-MailPublicFolder -Alias [PublicFolderAlias]

Once you set the valid alias you problem is solved for that specific public folder. You might be thinking “how can i automate this for the dozens or hundreds of public folders i have with issues?”. Well the answer is you should use that csv file you exported with all the public folders, insert a column with valid aliases, build a script that reads from the csv file and run it from the Exchange Management Shell to have all your folders fixed in one go. In my case i had a low number of folders with issues, so i haven’t built the script. I am planning to build 2 scripts, one to export public folders with issues and another one to use that exported file and fix those issues, but at the moment i don’t have it. Feel free to ping me an e-mail or comment if you’re interested on the script and i can find some time to build it. It should be a fairly simple script. Or feel free to have a go on doing that.

But back to the issue. Once you have all your mail public folders with valid aliases, i recommend that you remove the current public folder migration request and create a new one. To do that run the sequence of cmdlets shown below:

9-done

 

 

 

 

 

To see the current failed request:
Get-PublicFolderMigrationRequest

To delete the current failed request:
Get-PublicFolderMigrationRequest |Remove-PublicFolderMigrationRequest
To create a new request:
New-PublicFolderMigrationRequest -SourceDatabase (Get-PublicFolderDatabase -Server <Source server name>) -CSVData (Get-Content <Folder to mailbox map path> -Encoding Byte) -BadItemLimit 200 -acceptlargedataloss -largeitemlimit 200

Finally after the new request is created, you can see that now the migration is ongoing and went past the Public Folder Hierarchy creation without issues.

10-done

 

 

Problem solved and happy migration! 🙂

 

 

 

 

 

 

Public Folders migration to 2013 gets “StalledDueToMailboxLock” Status

Are you trying to migrate your public folders from legacy Exchange versions to Exchange 2013? And are you getting stuck on a “StalledDueToMailboxLock” error when you try to resume the migration? Well then continue reading. I will try to keep this post short and simple, just like the solution to your problem.

First things first.. the migration process.. To successfully complete the migration, and if you don’t have experience on doing it, you should follow all the steps from the link below:

https://technet.microsoft.com/en-us/library/jj150486(v=exchg.150).aspx

So in summary, you download the scripts, estimate the number of public folder mailboxes you will have, name and create those mailboxes and start the migration process, that will suspend at 95% with all the data migrated except the delta.

Once that is done you then lock the public folders on the legacy version (step 6 on the link above), by running the following cmdlet:

Set-OrganizationConfig -PublicFoldersLockedForMigration:$true

And what is the purpose of this cmdlet? Simple.. to block the access from the users to the legacy public folders, so that you can migrate the delta, unlock the access on 2013 (Step 8), and have all users using the new modern public folders.

So what can go wrong and when can you see the “StalledDueToMailboxLock” Status?

After you run the Set-OrganizationConfig -PublicFoldersLockedForMigration:$true cmdlet, the changes need to apply on the legacy public folders, before you resume your migration by running the Resume-PublicFolderMigrationRequest -Identity \PublicFolderMigration cmdlet.

If the changes are not applied yet, than your public folder migration request will resume and a minute or two later it will get into a “StalledDueToMailboxLock” status.

When you get into that status there are two things you need to do:

First try and access the public folders, from an Outlook client. Can you still access them? Well that means they are not locked and the changes didn’t apply yet.

So you can either wait for the changes to apply, and keep checking the access to the public folders until it’s blocked, or alternatively you can force the changes to apply, by restarting the Information Store service on the legacy server(s), where the public folder database being migrated is. Once you restart the Information Store service, retry accessing the public folders from an Outlook client. The access should now be blocked. Then you can suspend and resume your public folder migration request, to get it going quicker, by running:

Suspend-PublicFolderMigrationRequest -Identity \PublicFolderMigration
Resume-PublicFolderMigrationRequest -Identity \PublicFolderMigration

The request should now complete without issues, and you can continue following the steps on the link i provided earlier on this post, to get your public folders running on 2013.

Any questions about the entire process let me know.