Have you heard about a migration to modern public folders that has gone well? I haven’t. Apart that is from the demo migrations that appear at trade shows and conferences to show that all is well and that Microsoft hasn’t reneged on their promise to bring the cockroaches of Exchange kicking and screaming into the world of highly available mailboxes.
Microsoft has published a public folder migration checklist and written a number of scripts to support that checklist that you can download from their site (the scripts are also available in the $ExScripts folder on an Exchange 2013 server). The scripts support migration from legacy environments running on Exchange 2007 or 2010 servers to Exchange 2013 on-premises or Exchange Online (Office 365).
In theory, the procedure is straightforward.
- Wait until all mailboxes are moved to Exchange 2013. This step is mandatory because whereas Exchange 2013 mailboxes can access legacy public folders, the reverse is not true.
- Enumerate the legacy public folders and hierarchy and create a CSV file using the Export-PublicFolderStatistics.ps1 script.
- Examine the CSV output (a list of public folders and their sizes) to decide whether any adjustments need to be made. Pay attention to the limitations of modern public folders to make sure that you keep under whatever the currently documented limits are (250,000 folders and rising) after the migration is complete.
- Run the PublicFolderToMailboxMapGenerator.ps1 script to process the CSV file containing details about the legacy public folders and to map them to new public folder mailboxes. Essentially, the script attempts to break up the folders and divide them in a logical manner across a new set of public folder mailboxes. You control how many mailboxes are necessary by setting a maximum for the size of each mailbox. For instance, if you have 100GB of legacy public folder data to migrate, you could set the maximum size to 10GB and end up with 10 public folder mailboxes.
- Review the CSV file to decide whether public folders have been allocated in a reasonable manner.
- Create the public folder mailboxes, taking care to place them in databases that are capable of supporting the load that user connections will generate after you switch over to use modern public folders.
- Create a public folder migration request (only one can exist at any time) to process the CSV file that maps the legacy public folders to new public folder mailboxes. The processing is similar to a mailbox move in that the processing is performed by the Mailbox Replication Service (MRS) in the background. MRS connects to a public folder database, enumerates what it finds there (like a source mailbox), and transfers the data to the target (in this case, the public folder mailboxes).
- When MRS has moved the data, it halts (similar to a mailbox move that is auto-suspended).
- If everything seems to be good with the PF move request, you lock public folders for the organization (which has the effect of disconnecting users from legacy public folder databases), tell MRS to complete the move with Resume-PublicFolderMigrationRequest, wait for MRS to perform its incremental synchronization to move the last remaining vestiges of data from the legacy folders.
Get-PublicFolderMigrationRequest | Set-PublicFolderMigrationRequest -PreventCompletion:$false
Get-PublicFolderMigrationRequest | Resume-PublicFolderMigrationRequest - Once MRS considers the move to be finished (the status shown by Get-PublicFolderMigrationRequest is “Complete”), you can validate that the data has been moved to the new public folder mailboxes by connecting to one of them with a test mailbox. Logically, you cannot connect to a modern public folder mailbox until the migration job is complete. The best way to do this is to run the Set-Mailbox cmdlet to override the normal mechanism used by Exchange to locate the public folder hierarchy using the command shown below. You can also run some scripts to compare what exists on the legacy side with what has been moved.
Set-Mailbox -Identity "Some Test Mailbox" -DefaultPublicFolderMailbox "PFMailbox1" - If you are happy that everything has been properly moved to the mailboxes used by modern public folders, you can commit the organization to using modern public folders by performing a final switchover. To do this, you make sure that all the new public folder mailboxes are capable of providing the public folder hierarchy to clients and then run Set-OrganizationConfig to update the configuration and switch from old to new.
Get-Mailbox -PublicFolder | Set-Mailbox -PublicFolder-IsExcludedFromServingHierarchy $False
Set-OrganizationConfig -PublicFolderMigrationComplete:$True - Have a beverage of your choice to recover while basking in the admiration of users who are now totally happy to be connected to the new, improved, and most modern of public folders.
Update 14 July 2014: As MVP Andrew Higginbotham points out, if you don’t do everything properly, you might end up by forcing all clients to see the infamous “The Administrator has made a change that requires you to restart Outlook.” Check out his blog for details.
It all sounds good. It all seems like it might even work. And it does, in a test environment where you have 10 public folders to migrate.
The procedure runs into difficulty when confronted by the average public folder hierarchy. Invariably, the hierarchy is old, badly organized, unmanaged, and contains enough rubbish to occupy several skips. The problem you see is that public folders have been around for a very long time and during their existence it is extremely likely that many people, both users and administrators, have had their fingers in the pie. Folders exist for no reason; folders exist that once had a reason but one that is now long forgotten; folders exist that contain useful information that no one knows about; and public folders exist that contain the greatest collection of old rubbish and corrupt items that you will ever encounter in your career.
And the good news is that the procedure as laid down will faithfully attempt to migrate all the old, unwanted, unhappy, unreadable, and undesirable information from legacy public folders to their new homes. That is, unless you take steps to stop this happening.
We know that a CSV file is generated in step 2 of the procedure to enumerate the public folder hierarchy and its folders. The CSV file contains two columns – folder name and folder size, so you end up with something like this:
“FolderName”, “FolderSize”
“\IPM_Subtree”,”0”
“IPM_Subtree\Contoso”, “248844”
“IPM_Subtree\Contoso\Departments”, “12487744”
“IPM_Subtree\Contoso\HQ”, “45254”
“IPM_Subtree\Contoso\HQ\CEO Office”, “147755”
“IPM_Subtree\Contoso\HQ\CEO Office\2007 Business”, “477444”
Reviewing the contents of a CSV file to identify folders that should be pruned from the hierarchy is a tiresome business if you have a couple of hundred folders to examine, especially when you don’t know a lot about the content of the folders, why they were set up, who uses them, and when they were last accessed in any meaningful manner.
But many hierarchies have a few thousand or more folders and the thought of having to go through the full set becomes something that would only excite a lonely monk in a cell on an island in the middle of the Atlantic. Most administrators would prefer to tear out their own fingernails than process this CSV file, which is a real pity because the big flaw of the migration process is that if you don’t take the time to prune, remove, and destroy old rubbish from the public folder hierarchy before MRS starts to move data, all of the rubbish will be moved.
You can’t even take the obvious approach of deleting large batches of folders from the CSV file in the hope that MRS will ignore them during the migration. MRS is pedantic and exact. It will migrate everything it finds in the hierarchy even if you remove all reference to a folder from the input CSV file.
The next issue is that old public folders have a habit of storing old items (naturally), some of which fall into the category of “malformed MAPI items”. In other words, they are corrupt in the eyes of modern MAPI clients and servers. Unless of course you are a genius and know how to how to choose servers that allow for such things, I don’t know of any… Legacy public folders are not to be faulted for storing this information. Folders store items and the items were good when they were stored. But MRS will complain if it encounters one of these “bad items” and they will be discarded en route to modern public folders. You control the tolerance MRS has for bad items by setting a bad item limit when you create the public folder migration request, but it’s easy to blow the normal limit (10 or thereabouts) that you might use for mailbox moves with the rubbish lurking in the deep and dank corners of old public folders. Eventually you can force MRS to process everything, but be prepared to lose some data and to restart the public folder migration request several times after upping the bad item limit.
The dirty little secret of public folder migrations is not that the process does not work. It does, but it is excruciatingly manual in nature and execution and requires more time and effort from an administrator than you might possibly imagine.
We have not yet seen many public folder migrations because few companies have yet completed step 1 to move all their mailboxes to Exchange 2013. We will see more as time goes by. The potential for pain is out there…
Follow Tony @12Knocksinna
Thoughtsofanidlemind's Blog 
Hi Tony,
Hmm, I thought Public Folders were Exchange’s dirty little secret in as far as Microsoft have been concerned these past several years. If you ignore them long enough maybe they’ll go away was the consideration perhaps? Then again as you recently mentioned 2003 being a dead and forgotten piece of software to them, I imagine Public Folders will go away as by Exchange 201x release date Exchange 2010 will be a non-existent piece of software that Microsoft deny the existence of and as people won’t have been able to migrate away it becomes an SEP.
I have to say as ever, I’m fighting to resist being your eternal comment writer and expanding my blog when I can to avoid keep airing my opinions here. So saying, we do seem to hit similar topics on occasion and given my working on email since Network Courier I suppose we’ve followed similar paths. I tend to err on the less official path and am slightly more acerbic when it comes to the inequities of vendors I fear. Maybe it stems from hearing the words “Surely Microsoft have a plan for this?” too many times.
Public Folders do get me going more than many things though, as do migration tools and PST hunting software. There’s a common thread to all of these that have earned me a great deal of money and a no few grey hairs. The problem? Microsoft distancing themselves from Public Folders and ignoring the massive headache this causes for people using their software. Having just dealt with my first 50Gb OST and also finished cleaning up a 5.5(Yes Ms, it still exists out here in the real world) migration that was truly botched by yet another Gold Partner, I truly am fed up with this expanding lack of care.
Again in common with the PST and migration tools, I believe that Microsoft hoped and prayed that 3rd parties would get to grips with them and come up with a product that migrated them to Sharepoint so they could wash their hands completely and not include Public Folders in later releases. As that didn’t succeed, Public Folders continued to exist until they were removed in 2013 and replaced with slightly modified mailboxes.
Yet still there is no clear migration process, cogent purpose and definition document, nor tool that provides a mechanism to migrate effectively. Your document outlines just how painful this process could be. I also wonder who has migrated from pre-2013 PF to MPF yet as from a comment on my blog, responding to a CU1 comedy of errors post I made, mentioned that there is a bug preventing migration to MPFs that won’t be fixed until CU3, yet I saw no note of the bug in the list for CU3 at all.
One of my main questions to ask Microsoft is where there are any real-world test cases that they have undertaken that demonstrates how well a large PF>MPF migration works? The non-coexistence heralded as coexistence in CU1 continues to demonstrate a couldn’t care much approach to moving PFs as it is effectively suggested that one moves all mailboxes to 2013 and then test out your PF migration in one big hit hoping that it works.
I must admit I have still failed to see what value Modern Public Mailb…oops.. Folders bring and why anyone would migrate to them. Public Folders have historically been used for the following reasons.
Shared Calendar for room bookings, resource bookings and team calendars.
Shared mailboxes
File stores
Hidey holes for mailbox data on badly administered systems that impose DB restrictions but leave PFs open to user creation (heh and PSTs)
Public facing addresses or internal system mailing points
Company directory or shared phone lists
Custom developed workflow
So barring the custom dev stuff which I’ll bet you those carefully crafted scripts that call (hmm what executable to CSV could it be?) PFDavAdmin don’t cater for, all can be taken care of by other mailbox types and so we return to the crux of the matter. If Microsoft had taken the time to look at their customers who use PFs extensively and worked with them to develop migration plans to Sharepoint rather than cobbling together another type of mailbox that pretends to be a PF, this problem wouldn’t exist today and we wouldn’t need MPFs.
Many organisations gave up moving from PFs based on the reasons you outline and I’ve seen some of the environments holding hundreds of gigs in tens of thousands of folders so know how insurmountable the migration task can seem. Then again what migration of tens of thousands of mailboxes from multiple organisation into one was ever an easy task? For this Excel and techies were created!
I don’t currently have an answer but I am working with some people that may. Once I’ve input some detail on real world scenarios into a tool that’s been developed for another purpose, there may be a good PF/PST migration tool that can be used more effectively to allow organisations to never have to use MPFs and abandon PFs. If and when it comes about I’d be keen to get some input on how well people such as yourself view its capabilities.
In any case it will be interesting to see how much this aspect of legacy migrations delays the take-up of 2013. I will still go with my maxim of ‘avoid interim development versions of Exchange’ i.e. every alternating version since 5.5 and look forward to the next major release!
All the best and keep up with the helpful and clear insights, please also never apologise for expressing your ire as I noted when your frustration becomes apparent in some posts this year, you are always diplomatic, polite and inscrutable so if you’re annoyed with something in tech you can be sure the majority of techs out there are with you and appreciate your candour!
Ai
____________________________________________
Just for your reference Tony, I’m not that keen on publicising my blog or myself(yes I know so why have one?), this was my take on CU1 that touched on PFs. (I must admit I have worried as I put a link to your blog in another one of my posts and not knowing the blogging etiquette still wonder if one should let people know when commenting about them!) In any case I hope it reads as an amused onlooker who has worked at the heart of this industry rather than a tired old cynical hack having a go. (hang on aren’t they the same thing?) http://napoleonmoses.wordpress.com/2013/05/10/poor-old-microsoft-exchange-it-is-in-the-wars/
No problem commenting as we all have perfectly valid opinions. The key is to back up comments with facts, which is what I try to do (not always successfully). Maybe you’ll like my interview with Perry Clarke at http://windowsitpro.com/blog/talking-exchange-server-microsofts-perry-clarke… It addresses some of the issues that I think you are concerned with.
Thanks Tony, I’ve had a chance to read through that interview finally. The fact that the technical teams at Microsoft are second to none is the cause of my frustration when their message is distorted by corporate policy and third parties selling by spreading fear and confusion. (I’ll admit some shell-shock from spending a career picking up the pieces resulting from such practices)
The concerns Perry raises about the disparity between the technical message and the sales message coming from large software vendors seems most relevant.
Lets hope the recent appointment in Redmond paves the way for a clearer message in the future and the return to letting the quality of the software sell itself rather than a massive advertising department. An optimistic start to 2014 in any case.
Pingback: Exchange Public Folders | kay4ni
Pingback: Migrating to Exchange 2013 public folders | SME IT guy
Pingback: interesting things i have seen on the internet 30/12/2013 | 503 5.0.0 polite people say HELO
I’m working through a hybrid migration to O365 EOL. I’ve ran the New-PublicFolderMigrationRequest (your step 7). I would like to verify as you mention in step 8 but can’t figure out how to connect to the PF mailbox. Do you have any suggestions ?
thanks
Tim
Austin. Tx.
Run Set-Mailbox for a test mailbox to point it to a public folder mailbox (preferably the one with the default hierarchy). When you open that mailbox, you should be able to access the modern public folders that you have migrated. The command you want is Set-Mailbox -Identity -DefaultPublicFolderMailbox
Thanks Tony. After running the set-mailbox command, then trying to add a PF through O365 OWA, I receive a prompt saying “can’t complete your request no public folders are available. check that a public folder deployment exists in this exchange organization…”
Here is the status of my migration request:
Status : AutoSuspended
SourceServer : mail.txsg.state.tx.us
SourceVersion : Version 14.3 (Build 174.0)
BytesTransferred : 2.679 GB (2,876,674,062 bytes)
ItemsTransferred : 3328
PercentComplete : 95
Message : Informational: The move request has been automatically suspended because the PreventCompletion pa
[PS] C:\scripts>Get-o365Mailbox -PublicFolder
Name Alias ServerName ProhibitSendQuota
—- —– ———- —————–
Mailbox1 Mailbox1 blupr02mb132 49.5 GB (53,150,220,288 bytes)
TXSGPF TXSGPF bl2pr02mb468 49.5 GB (53,150,220,288 bytes)
Any suggestions for validating the migration request ?
thanks
Tim
Hi Tony,
Let me rephrase my questions.
1. Can I validate the migration (connect a test mailbox) before setting the PublicFolderMigrationComplete property to True , completing/resuming the migration request and unlocking the public folder hierarchy in EOL ?
2. Should I be able to see the migrated public folders in the EOL EAC before completing these steps ?
thanks
Tim
Hi Tim,
From your last comment, it looks like MRS has performed the initial synchronization from old to modern public folders (it has reached 95% completion and the move then auto-suspended). Before you can access the moved data, you need to allow MRS to complete the move by performing an incremental synchronization to capture all of the changes, additions, and deletions done since the initial synchronization was kicked off. This will ensure that you have a full and complete copy of the data on both old and new sides. You have to lock the public folder environment to complete the move too because you don’t want users adding new stuff or accessing the old public folders while MRS performs the incremental update. Exchange won’t allow you to access the modern public folders until the migration job has completed processing.
I never intended the post to be a step-by-step guide to migration because there are many other posts on this topic elsewhere. Instead, I wanted to call attention to the fact that substantial care and attention is required to prepare for the migration. However, I think that some extra detail is warranted in the post to provide a more accurate guide so I have updated it with some of the commands that are required. Can you look at the post again to review the changes and see if they answer your questions?
TR
Pingback: Exchange 2010 Public Folders: Part 1 | Thoughtsofanidlemind's Blog
We are wrapping up a public folder move from Ex 2007 to 2013 modern public folders.
Everything up to step 12 has gone very smoothly. Well all except for that CU2 bug that stopped the migration from completing for a few months.
Post migration we are sitting on 180 gigs of data in 17,000 folders spread across 60 public folder mailboxes. My goal was to keep PF mailbox sizes down to 3 gig each.
We have one tiny little issue. Unless a user is set to use the Primary Public folder hierarchy mailbox AND the the folder itself is stored in the primary PF mailbox the user cannot create new sub folders from Outlook. They get a “Cannot create the folder” error after a short delay. I can create sub folders in the ECP or powershell but you can’t create any of the other folder types, Calendar, tasks and so on unless everything is set to the primary PF mailbox.
Everything I’ve read says these requests should proxy to the Primary Mailbox but appears to be failing..
Scott, by any chance did you file a support ticket with Microsoft? If so, can you let me know the reference.
Pingback: Outlook Web App 2013 and mail public folders | Thoughtsofanidlemind's Blog
Pingback: Exchange 2013 public folders crippled by newly revealed limits | Thoughtsofanidlemind's Blog
Scott, i am having the same issue you are experiencing. Did you ever get a resolution to it? Users at my company cannot create new public folders, or delete current ones. I can do it fine from the EMC and through powershell though.
I posted this to the new thread on 2013 Pf limits but felt it needed a response here too.
We opened a ticket with MS support about users not being able to create new public folders from outlook. They determined that the large Hierarchy is causing the issue. The primary Pf mailbox is taking to long to return the Hierarchy causing new folder requests to time out and fail.
We don’t have a solution yet but Support is working on it. We can work around it for now with the esc and moving folders & users to the primary mailbox when needed.
I have just encountered the same problem with Outlook 2010 and an Exchange 2007 – 2013 migration. The PF migrated fine but users are not able to create new PF from Outlook. What did MS Support come up with?
You should report the issue to Microsoft and see whether they have a hot fix. I haven’t heard much. Exchange 2013 CU8 is on the way and should be with us very soon, so that might be the fix.
Did you tried this:
http://support2.microsoft.com/kb/3035230
Amazing! That simple fix worked. Thank you so much. We’ve been searching for a solution for 3 days. We were getting ready to open a ticket with Microsoft.
Cool! Thanks for your feedback!
Pingback: What caused the crippling of Exchange 2013 modern public folders? | Thoughtsofanidlemind's Blog
this is so true.
Im in the process of Migration a PF Hierarchy with 1200+ folders and 15GB.
Been working on it for a week and havent got further than starting the migration attempt which immediatly fails. Complaining about unsupported characters, on folder which dont exist anymore!.
Gone through all the folders manually now and removed spaces and slashes and so on.
Still no luck
https://technet.microsoft.com/en-us/library/jj906435(v=exchg.150).aspx
I tried this and it did not work for me. Intermittently users will be able to create public folders and other times they cant, then eventually it shows up hours later. I set the registry key to 2. What is eveyone else doing to make it work?
Dave, given the size of your deployment as reported in another comment, I think you need some on-site help. Either ask Microsoft Support for assistance by filing a support ticket or get a consultant who knows modern PFs backwards (or both). Resolving questions by appealing to blog readers is seldom a great approach because you rely on the ability of others to understand the complexities of your deployment, and that just can’t happen through an interaction like this.
I have over 180,000 public folders with around 2.5 TBs of data. I am not looking forward to having to migrate these to modern public folders. The effort right now is to clean them up as much as possible, but I am sure when the time comes to move to Exchange 2013, I will still have well over 100,000 folders.
Shoot me now 😀
Hi
I m migrating public folder 2010 to 2013
When i do :
Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics -IncludeReport | Format-List
I have a lot of line like this
00-00-00-00-1A-44-73-90-AA-66-11-CD-9B-C8-00-AA-00-2F-C4-5A-03-00-36-B9-C6-5D-38-99-D6-11-9B-D6-00-08-02-55-A6-70-00-00-00-18-33-94-00-00 ». Ce dossier peut être
lié manuellement en exécutant la cmdlet Enable-MailPublicFolder une fois la migration terminée.
23/05/2014 19:18:02 [serveur] Avertissement : échec de recherche ou de liaison de l’objet destinataire « 96-7D-85-6C-DC-A6-83-42-AC-77-A4-5E-BD-CD-52-9B » dans
Active Directory pour le dossier public à extension messagerie « Public Root/IPM_SUBTREE/Secrétariat RC/PAYS/VENEZUELA/2006/SINCOR » avec l’ID d’entrée «
00-00-00-00-1A-44-73-90-AA-66-11-CD-9B-C8-00-AA-00-2F-C4-5A-03-00-36-B9-C6-5D-38-99-D6-11-9B-D6-00-08-02-55-A6-70-00-00-00-13-4D-8A-00-00 ». Ce dossier peut être
lié manuellement en exécutant la cmdlet Enable-MailPublicFolder une fois la migration terminée.
23/05/2014 19:18:52 [serveur] Avertissement : échec de recherche ou de liaison de l’objet destinataire « 25-86-EC-2D-ED-25-C6-49-83-B6-5F-E9-8C-2E-34-A4 » dans
Active Directory pour le dossier public à extension messagerie « Public Root/IPM_SUBTREE/Secrétariat RC/Repertoire 2007 » avec l’ID d’entrée «
00-00-00-00-1A-44-73-90-AA-66-11-CD-9B-C8-00-AA-00-2F-C4-5A-03-00-36-B9-C6-5D-38-99-D6-11-9B-D6-00-08-02-55-A6-70-00-00-00-11-F5-9D-00-00 ». Ce dossier peut être
lié manuellement en exécutant la cmdlet Enable-MailPublicFolder une fois la migration terminée.
23/05/2014 19:18:57 [serveur] Avertissement : échec de recherche ou de liaison de l’objet destinataire « ED-80-51-1F-67-6A-B9-41-AA-B8-0C-14-C4-BF-07-A3 » dans
Active Directory pour le dossier public à extension messagerie « Public Root/NON_IPM_SUBTREE/EFORMS REGISTRY/Organization(409) » avec l’ID d’entrée «
00-00-00-00-1A-44-73-90-AA-66-11-CD-9B-C8-00-AA-00-2F-C4-5A-03-00-36-B9-C6-5D-38-99-D6-11-9B-D6-00-08-02-55-A6-70-00-00-00-00-1F-49-00-00 ». Ce dossier peut être
lié manuellement en exécutant la cmdlet Enable-MailPublicFolder une fois la migration terminée.
it scared me, what does it means ? Do i do something wrong?
I have let it work
And when i check status i have this :
Statut: Failed
Détails status : Failed other
Syncstages : Copying message
Estimed transfert size : 0
Pourcentcomplete : 95
What do i do? Can You help me? I m a little scared right now
Thanks
Your PF migration request is stalled because errors have been encountered. You will have to check each one of the folders to see what the problem might be. It might be that the mail-enabled properties are incorrect, it might be that the name of the folder contains one of the special characters that cause the migration to halt. If possible, delete the folders (if you don’t need them). After you fix everything up, restart the migration.
TR
Thank You!
Pingback: Progress in raising public folder limits – but we’re not there yet | Thoughtsofanidlemind's Blog
Hi Tony
A great article. I need to migrate 2500 PF’s totalling about 50GB. There is a few PF’s over 2GB and one over 9GB. Trouble is I don’t really want to make a 10GB limit for the migration. Is there a way I can move the big PF’s first and then set a 1GB limit for the rest of migration?
Thanks in advance
PR
Regretfully the PF migration is a one-time take-everything affair. MRS will process every PF in the hierarchy as it moves content from old to new. And switching over is a one-time affair too as you can’t have some users accessing old PFs and others new.
TR
Pingback: Exchange 2010 to 2013 Migration - Moving Public Folders
I would be interested in anyone who has migrated Public Folders from 2010 to 2013 – Step #9 – where the public folders are locked – how much down time do you incur. Some of you have mentioned PF DB’s over 100GB – what was your experience.
Downtime only occurs after the migration stage has migrated everything and then suspends automatically. At that point when u lock the 2010 PFs and resume, only tje changes that have taken place since it reached the suspended state need to be migrated. My PF database was 130Gb with 75,000 folders and 13 million emails. The migration took a week, but after I locked the 2007 PF database and did the final migration it just took a few hours. Everything went well except for the intermittent problem I have where users cannot create new folders. Ive only been on modern public folders for 3 days now.
I am doing an exercise migration from exch2010 to 2013. I am at the pf migration steps. I stepped through many of the steps and to say its tedious and painful would be an understatement. I immediately started looking around for other options, you would think someone would make a tool for this?
You know, I have suggested to a couple of ISVs that they could usefully create a tool to assist PF migration. But all declined on the basis that Microsoft might come along and replace their code with some “approved” solution. I still think that it would be a good thing to do, even just to create some visibility in the market.
I ready to migrate my pf’s from 2007->2013. I ran the prep scripts and so far so good. Couple of questions. The publicfoldertomailboxmapgenerator.ps1 script output calls for only one mailbox. Is this because I don’t have a huge pf hierarchy? What determines how many mailboxes are needed to house pf’s? Most of my pf’s are mail enabled. Does this attribute get migrated along with permissions? Will I be able to email the migrated pf’s immediately after they are migrated?
You can create multiple public folder mailboxes and then edit the CSV file to allocate the public folders to whatever mailboxes you like. The migration process will then move the folders to the destination mailboxes.
Okay, what about the email enabled question? Will all of that be preserved?
Yep. Mail-enabled PFs should be migrated. At least that’s what happened the last time I looked. But you’re testing this migration, right?
Hi Tony,
According to MS’s PF migration guide (http://technet.microsoft.com/en-us/library/jj150486(v=exchg.150).aspx), the end of Step 2 states that existing public folders in Exchange 2013 must be removed before a PF migration can be created. Is this absolutely necessary?
What happens when multiple Exchange organizations with their own PF hierarchies are being consolidated into a new Exchange 2013 organization? How does one migrate those separate PF structures into 2013?
I believe (but might be incorrect) that the reason why you should remove existing PFs from Exchange 2013 before you commence a migration is to avoid any potential problems with duplicate PFs. I don’t think the migration will be able to process an inbound PF if one with the same name already exists in the same place in the folder hierarchy. At least, I have seen issues with this in the past (but a while ago now – during original testing in 2012).
I don’t know the answer to your second question because I have never had to migrate PFs from multiple organizations to a single target Exchange 2013 organization. I’m not sure that this is strictly possible using the standard toolset because they all assume that the tools and processes operate in the context of a single organization. Given that this is the case, you might have to export data to PSTs and move them that way – or perhaps one of the commercial vendors who specialize in moving Exchange data around (like TransVault) have an answer.
Sorry…
I have an Exchange 2103 environment and am migrating to Office 365. I’ve migrated all of the User Mailboxes, but am stuck trying to migrate the public folders. Not realizing that it was an all-or-none thing, in O365 we created a single PF with a single sub-folder and 2 sub-sub-folders, for calendar & tasks, respectively. There is VERY little data (almost none) in the O365 PFs
In our on-premise Exch’13, we have about 30 total folders (mainly calendars) with <1GB of total used space.
When I try to run the command on Step 2, I get:
[12/23/2014 12:21:50 PM] Enumerating folders under NON_IPM_SUBTREE…
A parameter cannot be found that matches parameter name 'Server'.
+ CategoryInfo : InvalidArgument: (:) [Get-PublicFolder], ParameterBindingException
+ FullyQualifiedErrorId : NamedParameterNotFound,Get-PublicFolder
+ PSComputerName : swmi-owa.swmitech.org
[12/23/2014 12:21:50 PM] Enumerating folders under NON_IPM_SUBTREE completed…0 folders found.
[12/23/2014 12:21:50 PM] Exporting statistics for 0 folders
[12/23/2014 12:21:50 PM] Exporting folders to a CSV file
In a very small environment like mine, are there any other ways to migrate this small about of PF infrastructure? What about exporting the PFs to PSTs, recreate them in O365 and then import the data back afterward?
You’ll have to remove all the Office 365 PFs and mailboxes before starting the migration. But in any case, make sure that you have the correct versions of the scripts – you can get copies from http://www.microsoft.com/en-us/download/details.aspx?id=38407. The error seems to indicate that the script has a problem finding the server that you point it at to retrieve PF information. Is it online? Is it the right one? And yes, you could simply export all the data to PSTs and import them into Office 365. It would be manual and boring but manageable with that amount of data.
Hi Tony,
I am dealing with challenging PF migration, would appreciate some help:
On-premise co-existence Exchange 2007 SP3 with Exchange 2013 SP1, all the users already in Exch2013 (2CAS, 2MB in One DAG).
Migrating PF failing at Step 7: Status changes from Finalization to DataReplicationWait to FailedOther. It fails after several attempts: ‘Waiting for mailbox changes to replicate’.
I have tried restarting MRS and resume several times but didn’t help.
Would appreciate any advice- Thanks
Have you problems with database replication within the DAG? That’s what the error is telling us. Exchange is waiting for the data transferred into the target database to be replicated to other database copies.
Hi Tony,
Thanks for the clue. I didn’t see replication issues on DAG but decided to remove second copy anyways. I had two options either to remove the second copy of PF database or changed DataMoveReplicationConstrain property to None. I picked the first, resume the migration and completed 100% in few minutes.
Truly appreciate your help.
Thanks
What are the reasons that would prevent one from using a shared mailbox as a replacement for the Public Folders? On the surface, it seems like the simplest solution. The new mailbox could even be called “Public Folders”, and the folders in it could be given the appropriate permissions. In fact, when I tested copying a Public Folder to a shared mailbox, I found the permissions were copied, too (using Exchange 2010 SP3 CU7).
Thanks in advance for your comments.
M.
I think the new Office 365 Groups will be the long term replacement for public folders. http://windowsitpro.com/office-365/exploring-office-365-groups – After they fix some issues!
Hi Tony,
How can we see when step 6 is done. MS says “This may take several hours”, but is it not important to know that it is done before continuing to step 7 ?
thanks.
/carsten
I think you mean step 7, which is when MRS moves the public folder data from the legacy databases to the new public folder mailboxes. You have to check the status of the public folder migration request by running the Get-PublicFolderMigrationRequest cmdlet, Once the job has reached the autosuspended state, you know that the initial synchronization has finished. And as Microsoft says, this can take several hours – or even days – depending on the size of the data to be migrated.
thanks for FAST reply 🙂
no, step 6 : Set-OrganizationConfig -PublicFoldersLockedForMigration:$true
in the end it says:
“If your organization has multiple public folder databases, you’ll need to wait until public folder replication is complete to confirm that all public folder databases have picked up the PublicFoldersLockedForMigration flag and any pending changes users recently made to folders have converged across the organization. This may take several hours.”
BUT, there is no way to check if it is done ?
from this guide (not the new’er 365 guide):
https://technet.microsoft.com/en-us/library/jj150486(v=exchg.150).aspx
Thanks
Sorry… I misread. One way to be sure that replication is complete is that users can’t connect to PF databases. If they can, then the news that the folders are locked for migration hasn’t reached the database and that’s an indication that replication hasn’t happened for some reason. This report might help you: http://blog.mikewalker.me/2013/05/exchange-2010-public-folder-replication.html
ok thanks. im at 96% so that would be the NeXT step. but cannot rely on whether or not users can connect, so needs to know when I can fire the last steps*. Will try the stats report you linked. Missed this point was not very well explained in the guide before I began.
last steps*
Set-PublicFolderMigrationRequest -Identity \PublicFolderMigration -PreventCompletion:$false
Resume-PublicFolderMigrationRequest -Identity \PublicFolderMigration
By the way. in “step 8” there must be a BUG.
Set-Mailbox -Identity -DefaultPublicFolderMailbox
from the moment the new public folder mailbox was created, EVERY user got that mailbox assigned to their DefaultPublicFolderMailbox attribute.
that Means step 8 cannot be done to only one or two test mailboxes.
(almost all servers at cu7, cas servers cu6)
/anker
If there’s only a single public folder mailbox in the organization then by definition that’s the one which is assigned to every mailbox.
The idea is that you can use just one of the PF mailboxes for testing… assuming that you have a set to select from.
I’d like to make it clear at this point that the purpose of this post was not to provide an exhaustive guide to PF migration because there’s plenty of material on TechNet to cover. The entire purpose of this post was to focus in on the manual nature of the migration, especially the review of legacy PFs captured in the CSV file. But anyway…
Ok fair 🙂
But …………
step 8.3:
3.If you run into any issues, see Roll back the migration later in this topic. If the public folder content and hierarchy is acceptable and functions as expected, run the following command to unlock the public folders for all other users.
Get-Mailbox -PublicFolder | Set-Mailbox -PublicFolder -IsExcludedFromServingHierarchy $false
………. Does NOT give any sense, as the default mailbox public folder from the beginning has that attribute set to $false.
Just crossing fingers from now (as always when dealing with PF) and BTW thanks for the first line:
“Have you heard about a migration to modern public folders that has gone well? I haven’t. ”
Nervous enough before that 🙂
/anker
The step that is being taken in 8.3 (of the Microsoft process) is to enable all public folder mailboxes to be able to provide information about the PF hierarchy to clients. Now, this might not be necessary if you only have one PF mailbox and have already enabled it (or it was already enabled – it’s been a while since I looked at this topic), so you can treat this as an action that will do some good if there are PF mailboxes to be enabled and will do no harm if your one and only PF mailbox is already enabled. So it does make sense.
I hate migrations. They are nearly always messy and something goes less well than you expect.
I’ve been able to move a lot of root public folders from one mailbox to another in Exchange 2013 CU7 using the move-publicfolderbranch.ps1 script. However, I’m getting the following error when trying to move one of my root folders.
[5/23/2015 7:58:40 PM] Issuing request to move the public folder branch: \human resources
WARNING: An unexpected error has occurred and a Watson dump is being generated: The call to
‘net.tcp://mail02.company.com/Microsoft.Exchange.MailboxReplicationService MAIL02.company.com
(15.0.1044.22 caps:1FFF)’ failed. Error details: The formatter threw an exception while trying to deserialize the
message: Error in deserializing body of request message for operation ‘ValidateAndPopulateRequestJob’. The maximum
string content length quota (262144) has been exceeded while reading XML data. This quota may be increased by changing
the MaxStringContentLength property on the XmlDictionaryReaderQuotas object used when creating the XML reader..
Any suggestions?
Maybe some of the folders in this part of the hierarchy have illegal characters in their names?
Would I have been able to migrate them from Exchange 2007 to 2013 if they did? I just migrated everything last weekend after cleaning up illegal characters in PF aliases. I just thought it exceeded the number of characters since there were so many subfolders….
The migration to modern public folders is pretty specific in terms of its requirements for folder names. Moving old-style PFs from Exchange 2007 to 2013 wouldn’t hit the same problems. But in saying this, I am totally in the dark as to what you have in front of you which is why I recommend looking for support from Microsoft.
Hi Dave,
I run into the same Error Message as you – have you found any workaround for this issue or where to set the MaxStringContentLength in this context?
Kr,
Markus
Should I just export that particular root folder to PST, delete it from the public folders, and then recreate the root folder in the new mailbox and move everything back from the PST? I’m just hoping someone could point me in the right direction of where I can modify the value for “MaxStringContentLength”
If it’s only one folder that is causing problems then this is a reasonable workaround.
Q:I migrated PF 2007 to 2013 (350G) and got to the 95% autosuspended, the real cutove will be done only in a month from today and might have lots of changes during that time, is it possible at this point to sync all the changes of the last month WITHOUT any downtime to users? I would like to sync it about 4days before the real cut over step, possible?
If you have lots of changes in your PFs, it will take time to perform the last incremental synchronization. I think you indicate that 350 GB of data is in your PFs, so we can assume (worst case) that 10% of this has changed. If that is so, then 35 GB has to move from Exchange 2007 to 2013. Assuming a high-speed internal network, that shouldn’t take too long, so the downtime should not be bad. I would switchover at the weekend and minimize the impact to users that way.
You can do that when ever you want to. Its not doing anything before you apply the “Set-OrganizationConfig -PublicFoldersLockedForMigration:$true”
I haven’t tried it, but I assume it will hold the migration ones again at 95 % autosuspended.
That what I get from reading step 6:
https://technet.microsoft.com/en-us/library/jj150486(v=exchg.150).aspx
/anker
Thanks for the replies…im little confused as I got few different answers…
from techmet step 6 is written:
“The amount of downtime required depends on how much new content was generated since the migration reached the AutoSuspended state. If a long time has passed between the migration request reaching an AutoSuspended state and when you can finalization the migration, we recommend that you run the following command so you can synchronize the changes made since the original synchronization. This will reduce the amount of downtime required to finalize the migration.
Resume-PublicFolderMigrationRequest \PublicFolderMigration”
if I understand correctly…once I ger to the 95% Autosuspended….I can run any time AFTER that and before causing any downtime the Resume-PublicFolderMigrationRequest \PublicFolderMigration
I had MS to plan with me on my site and I asked him the same Q and I got MS reply that actually I dont need to worry a bit as the sync will be done automatically always once it get to the 95% Autosuspend with no downtime, that it will be sync in the background and that I don’t need to do anything manually, I really want to know becuase it took us almost 24h to sync 30GB so I really would like to make sure all is synced before the downtime
I hoped that someone out there actually had such scenario and know for sure what need to be done
The synchronization occurs using the same approach as a mailbox move. You get to 95% and then auto-suspend. If you resume the move, Exchange performs another synchronization to ensure that the source and target are as close as possible, but as changes are still going on in the source, you have a condition where the two will never be identical until you freeze the source and allow a final incremental synchronization to occur. This is what happens when you lock the public folders to perform the switchover. All of the old PF databases are told that no further changes are possible, Exchange synchronizes, the two are brought up to the same state, and you can switch. The time required for the final incremental synchronization depends on how much activity has occurred in the source since the last synchronization. If it’s small, then the switch will be very fast. If lots has happened, it could take an hour or more, depending on the volume of data and the network connection between the source and target.
Thanks, I did suspect that the MS reply was NOT correct (that even on autosuspend sync does occurs contently in the background…)
Thanks for your help!
Rika
Actually, I think that the public folder move request does perform an automatic synchronization in the background for up to 30 days. I am on vacation at present and don’t have all my files here to check, but I think this does happen. In any case, the incremental synchronization required to bring source and target to the same point is required and the delta between the synchronization state and the current state might be large depending on a) how long since the last synchronization and b) the amount of activity in the public folders since that time.
FYI, I completed successfully the migration, had to manually “Resume-PublicFolderMigrationRequest \PublicFolderMigration” after it got to the AutoSuspend 95% before the final cut-over (avoided downtime to sync 30days, it does not do ant automatic sync once on AutoSuspend )
Hello there,
ive started the public folder migration from exchange 2007 to my new exchange 2013 server a week ago. Now it is at 87% and fails at the same point everytime i restart it. The error i am getting is “JobIsPoisonedPermananentException”. It says “relinquishing job because the mailbox is locked”. Ive already tried some things, but nothing helped me with this problem. Does anyone have an idea why this error message could be showing up to me?
I wonder if some of the public folders that are in the specific CSV file have some forbidden characters in their names?
But the only .csv which is used for the execution of the migration is the “PublicFolderToMailboxMapGenerator.csv”, isnt it? Is the other one also directly used for migration or only for specifying the amount of mailboxes to create?
Well, you can call the CSV files whatever name you like. The point is that you feed a CSV file in as input to the public folder migration job. If that CSV file contains some illegal data in PF names, it will fail. I think Sigi Jagott covers this in his MEC 2014 session https://channel9.msdn.com/Events/MEC/2014/DMI310. I’m on vacation at present and don’t have time to look into the issue in detail. But in any case, if you have a fundamental problem with a migration, you should log a support call with Microsoft and have them sort it out.
TR
Pingback: Exchange 2013: Public Folder Migration | martinsblog.dk
I feel so bad for the many frustrations that folks have had with PF migrations. It’s certainly no fun to work out all the patterns for a successful mailbox migration only to be blocked or get snagged at the end with PFs.
I want to let those who may pass by this blog post know there is an alternative. Priasoft (whom I represent) has created a PF sync solution that seems to address many of the complaints seen here. Full disclosure, this is not a free tool, but I’m a tech minded person (CTO at Priasoft) and care more about the end result and technology.
Priasoft PF sync is a MAPI only solution, meaning that as long as an Outlook profile can be made to connect to a source or target environment, a sync can be performed. This includes data, structure, permissions, and email addresses. Sync is by-directional by design and supports Exchange 2003 thru 2013 and Office365. Initial tests show Exchange 2016 support out-of-the-box as well.
It can scale very well and internal tests showed 35,000 PFs sync’d to Office365 in 24 hours. We ran with 12 worker processes and it was 450,000 items. Multiple sync profiles can be created for different parts of a PF tree, the idea surfacing that one profile handles the whole tree while several smaller ones focused on individual folders handle high-frequency updates.
Lastly, PF sync inherently supports multiple orgs and multiple consoles running concurrently. All tracking data is stored in exchange so the footprint and deployment is very simple – no SQL servers, for example.
I hope some find this of value.
Contact me at Eriq.vanbibber@priasoft.com if there are any questions. I’ll try to monitor this blog for questions as well.
Regards,
Eriq VanBibber, CTO
Priasoft Inc.
Shoot…silly me, here’s a link to our site (for those that didn’t see my email address above):
http://www.priasoft.com
Additionally, here’s a link to a public showing I did on an O365 user group of the sync tools:
[video src="http://download.priasoft.com/Online_Demos/Priasoft%20PF%20Sync.mp4" /]
Hi,
is there anyway to migrate public folders to Exchange Online when Public folders already exist on Exchange Online?
Thanks
Oh ouch… I think you’re going to have to look at third party tools such as BitTitan MigrationWiz to do something like that…
the on-prem public folder DB is only 10GB so I’m thinking PST migration to a new public folder in ExOnline. can create a new public folder db up there and link it to a new mailbox.
It seems like it could work!
Col, I’m a bit late on your response…but the tool mentioned above from Priasoft DOES support O365-to-O365 synchronization.
A PST export/import routine will obviously only handle the data, and things like Calendar items, folder permissions, and mail-enabled folders are lost in that routine.
Hi Tony,
I’m having an issue with migrating public folders. We lost power in the middle of the migration and now i am trying to perform the migration again but I see in the ecp a migration batch for pfmigration stuck on completing. I am unable to delete it (the garbage can is grayed out). Get-PublicFolderMigrationRequest shows nothing. and when i run the command
[PS] C:\Windows\system32>New-MigrationBatch -Name PFMigration -SourcePublicFolderDatabase (Get-PublicFolderDatabase -Ser
ver ex2010) -CSVData (Get-Content C:\PFMigration\PFMailboxMap.csv -Encoding Byte)
I get the following error:
The migration batch PFMigration already exists.
+ CategoryInfo : NotSpecified: (:) [New-MigrationBatch], MigrationPermanentException
+ FullyQualifiedErrorId : [Server=EX01,RequestId=31047d0a-0f03-44d5-9471-76c56f8b8def,TimeStamp=7/5/2016 8:34:17 P
M] [FailureCategory=Cmdlet-MigrationPermanentException] 98EC7A2E,Microsoft.Exchange.Management.Migration.NewMigrat
ionBatch
+ PSComputerName : exchange 2013 computer name
any ideas?
Call Microsoft support and get them to help. There’s no point in trying to debug complex issues like this on the web…
Hi. First off great article with lots of good information from many other admins in a similar situation to us. I’m really looking for advise on our migration to Exchange Online, our situation is a lot larger that what others have posted…
We have an Exchange 2007 SP3 infrastructure with Exchange 2013 hybrids. We are currently in the process of migrating all our users to Exchange Online and Public Folders will follow shortly afterwards…
Our problem is that we have…. 440,000 folders, nearly 25TB of data with nearly 56 million items – and still growing…
We are aware of Microsoft’s ‘published”limits however we are speaking with MS Exchange product team and they have agreed they can support our migration, in fact MS have increased our Public Folder limit to 1.5 million folders with 100GB PF mailboxes… We have already created out mailboxes on O365 (nearly 600) and run all the CSV scripts (so we have allocated data to mailboxes).
As a lot of people have said before me, I’m concerned over this process, especially around the data that may be read as corrupted and not moved. How in the world do we check/ensure that all data has been migrated? Yes we have CSV exports with folder count, item count and sizes etc, but it’s the completing migration and then check it that concerns me. I’d like to be able to “know” it’s going OK before we cutover.
I should say we have Enterprise Vault which means we’ll only be migrating about 3TB of data. We will restore them once it’s all over…
Is anyone able to help ease me pain with some kind words :)…..
Thanks
I think you might want to have a chat with QUADROtech and have a look at their ADAM product, which is a new way of taking public folders to Exchange Online. Basically, ADAM http://www.quadrotech-it.com/products/adam/ will do the hard work of figuring out what you have in your public folder hierarchy and make recommendations about where individual folders should go – some can be removed because they are obsolete, some should go to modern public folders inside Exchange Online, some should be archived, and some should go to Office 365 Groups. Try it!
I’d also see if QUADROtech can help you with Enterprise Vault. Their ArchiveShuttle product is pretty good at moving data out of EV to Office 365. http://www.quadrotech-it.com/products/archiveshuttle/ I recently wrote about this topic on https://www.petri.com/moving-legacy-archives-office-365-painful.
James,
Priasoft has a bi-direction PF sync solution that may be valuable for you in this case. It is highly scalable and also sync’s permissions. There also a component that can migrate mail-enabled folder settings.
This works with any version of exchange at or greater than Exchange2003, including O365.
Some immediate gotchas to watch out for regardless of tools…
* The default setting is such that no single folder can have more than 2gb of data. Look at get-OrganizationConfig |fl *public* to see the case. There is an attribute named DefaultPublicFolderProhibitPostQuota that manages this limit.
* Also pay attention to the default max item size, in case that may be an issue.
* Currently no folder can have more than 10,000 immediate children. This doesn’t mean the entire subtree…you cannot have 10,000+ folders at the same level.
* You will have to work out a strategy to distribute the data across multiple PF mailboxes. This require some analysis of folder “weight” and the Priasoft tools has a statistics report that provides “roll up” sizing for each folder.
* Related to the above, you can only partition data at a folder level. The importance to consider here is that if any single folder (not including children) has more than 50gb of data, you will HAVE to splith that data apart in the source before you start. You cannot split the contents of a single folder across multiple PF mailboxes.
Regards,
Eriq VanBibber
CTO, Priasoft.
I know this post is pretty old, but perhaps you could help me understand something. My organization has a total of 433 public folders, some of which are subfolders of others. I had assumed that when I ran the PublicFolderToMailboxMapGenerator.ps1 script against the csv of our 433 public folder names and their sizes that I would receive a file containing one row for every public folder, showing which mailbox it should be mapped to, or at the very least, a map of every parent public folder, but that doesn’t seem to be the case. Instead, I get a csv with just a few entries.
Was my assumption incorrect, or am I running into an actual problem here?
you’re probably seeing entries for folders that contain a set of sub-folders? If so, that’s expected.
I’m seeing this same thing when I try to do it. My 1000 PFs (most of which don’t have sub-folders) turn into a CSV of 20 or so lines.
Hi Tony,
I am doing migration from 2010 to 2013, almost 5000 public folders.
First I got errors on names, so I renamed all mail enabled public folders and also all PFs where I replaced blank spaces with underscores.
When I re-done all PF mapping, all names were showing correctly in the CSV files and on the old server 2010.
When I am re-running the PF migration, it keeps failing with the same error
PS C:\source\PFs> Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics | fl message,failuretype
Message : Error: Property expression “name othername/name anothername” isn’t valid. Valid values are: Strings formed with characters from A to Z
(uppercase or lowercase), digits from 0 to 9, !, #, $, %, &, ‘, *, +, -, /, =, ?, ^, _, `, {, |, } or ~. One or more periods may be
embedded in an alias, but each period should be preceded and followed by at least one of the other characters. Unicode characters from
U+00A1 to U+00FF are also valid in an alias, but they will be mapped to a best-fit US-ASCII string in the e-mail address, which is
generated from such an alias.
FailureType : DataValidationException
But when checking the names, there are no more blank spaces and the folder in the error is in this format: name_othername|name_anothername
I am wondering if anyone knows what else needs to be checked or give me a direction what I have missed?
thank you
Dusan
Any leading spaces? Or trailing spaces?
since the error message is referencing “alias”, i suspect that the source folder has a mailNickName value that is at issue. understand that every mail-enabled public folder has a proxy object in active directory that holds the email addresses and other settings.
you may need to pump out all the mail-enabled folder details via powershell so that you can look at the mail alias and email addresses. i bet there’s one or more invalid characters there.
fyi, spaces are allowed in folder names. you can put those spaces back if you like. but you cannot have spaces in the mailNickName (alias) of a mail enabled folder.
-Eriq
Hi,
I’ve performed this migration, except for Exchange 2010 to 2016, and it’s the same process and it went smoothly. I’ve come to the moment of starting to decommission my 2010 environment and remove the legacy public folders. The issue I’m having is that I need to clear out the databases before I can remove them and I can’t actually access the Public Folders. I receive an error:
No existing ‘PublicFolder’ matches the following Identity: ‘\’. Make sure that you specified the correct ‘PublicFolder’ Identity and that you have the necessary permissions to view ‘PublicFolder’. It was running the command ‘get-publicfolder -getchildren -identity ‘\’ -server ‘serverName”.
There’s plenty of information on how to remove Public Folders but almost nothing on this particular error, or removing the publiv folders in a co-existence scenario in general. Have you every encountered anything like this or have any insight on how to resolve it so I can finally get rid of these PF databases on 2010?
Thanks,
Kevin
“\” is the root PF. Maybe the command will work if you add -recurse to it?
It’s because they are still locked
Try: Set-OrganizationConfig -PublicFoldersLockedForMigration:$false
Pingback: Migration of public folders to exchange 2013/2016 | Hayes Jupe's Blog
Would it be safe to do a PST export of Public folders and then import to Office 365 Public folder for 20 GBs of data?
Im not looking to bring over any permissions. Just want to move the folder structure and data. Will I need to worry about auto splitting?
Using PSTs to transport public folders to Office 365 sounds like a terribly inefficient process. Why would you want to do such a thing?
Very interesting thread indeed … seems that more and more companies are finally biting the bullet and moving their PFs to O365. There is now a product that helps get rid of unwanted PFs before migration via an extensive reporting tool, and then automates the migration process. Check out http://www.ultimatemigrator.com
Hey Tony,
Looking for information on how to completely remove PFs from on prem Exchange 2016. I find lots of info on migrating. I want to be completely off PFs before migrating to O365
Remove all public folders, then remove all public folder mailboxes… and then don’t migrate anything. But this might help too: https://medium.com/365uc/decommissioning-on-premises-public-folders-post-exchange-online-migration-daf90b73285