locked
Migration of Public Folders from 2007 to 2013 RRS feed

  • Question

  • Hello everyone!

    I'm in the process of migrating a public folder database from Exchange 2007 to 2013. The problem I have is that there's a PF in 2007 that is damaged and, for some reason, cannot be deleted. I would like to exclude this particular folder from the migration.

    Does anyone have any ideas as to how I can do that?

    Monday, September 23, 2013 7:41 PM

Answers

  • Since I was under the gun to move the PFs, I went ahead and did it and ran into a *ton* of errors related to the damaged folder. It was still readable for the most part however and I simply increased the number of BadItems to a ridiculous number.

    The folders did migrate and, happily, I was then able to delete the "bad" PF on 2013.

    What's strange is being told by Jesse up there that I could exclude them but that turned out to be wrong. Konrad also didn't seem to know what he was talking about either.

    Well thanks, Fred, for the information.

    • Marked as answer by SamLair Monday, October 7, 2013 2:33 PM
    Monday, October 7, 2013 2:33 PM

All replies

  • Well, you can still delete it from PF Hierarchy (with ADSIEdit.msc)

    Regards, Konrad Sagala, MCT, MCSE+M, MCITP: Exchange 2007/2010, Lync 2010, Office365, Windows 2008, Virtualization

    Monday, September 23, 2013 8:00 PM
  • Migration of public folders is done not by database, but by folder.  You can specify which folders to migrate, and by omission which not.

    Note that the New-PublicFolderMigrationRequest command requires a CSV file (in the -CSVData parameter) in which the list of the public folders to migrate should appear.  The legacy database is provided only so that the migration request can locate the public folders specified.

    So if you follow the process to prepare for and create a public folder migration request you can edit the last CSV file so that the folder you don't wish to migrate is not in the list.

    The overall process can be found starting here:

    Migrate Public Folders to Exchange 2013 From Previous Versions
    http://technet.microsoft.com/en-us/library/jj150486(v=exchg.150).aspx

    • Edited by Jesse Tedoff Tuesday, September 24, 2013 5:32 AM
    Tuesday, September 24, 2013 5:30 AM
  • Interesting idea, thanks. Can you tell me more about how to do this?
    Tuesday, September 24, 2013 6:16 PM
  • Beautiful, thanks Jesse. I was hoping that was the answer because that's exactly what I did. I'm going to try that now.

    BTW, as a sanity check: the damaged folder is part of the root and the root (by which I mean, "\") is going to be in one mailbox. Does this not mean that it will take everything not in "\" including the damaged folder?

    This is what I meant:

    "FolderPath","TargetMailbox"
    "\","Mailbox1"
    "\IPM_SUBTREE\GOV","Mailbox2"
    "\IPM_SUBTREE\GOV\DFM","Mailbox3"
    "\IPM_SUBTREE\GOV\DFM\Backup","Mailbox4"
    "\IPM_SUBTREE\GOV\GM\Backup","Mailbox5"

    Won't the first line contain, by default the damaged folder (which is named "\DAMAGED" by the way.)

    • Edited by SamLair Tuesday, September 24, 2013 7:34 PM Additional information
    Tuesday, September 24, 2013 6:17 PM
  • SamLair,

    While you can omit the damaged folder from the CSV map, that actually doesn't exclude the folder from the migration. The CSV map works as a hint for the migration component so it knows where to put the folders.

    While enumerating the folders in the source MRS (mailbox replication service) should fail to read the corrupted folder and it should consider that folder as a bad item, which should cause your migration to partially fail. In order to proceed with the migration, what you can do is to increase the number of bad items when submitting the migration request (there is a -BadItemLimit parameter on the request).

    Fred


    • Edited by Fred Cruz MSFT Wednesday, September 25, 2013 8:58 PM fixed MRS meaning
    Wednesday, September 25, 2013 8:55 PM
  • SamLair,

    While you can omit the damaged folder from the CSV map, that actually doesn't exclude the folder from the migration. The CSV map works as a hint for the migration component so it knows where to put the folders.


    So it's as I thought then. Someone mentioned earlier there may be a way to remove all reference to the damaged folder in the Public Folder hierarchy. I'm not too sure I'm exactly comfortable with leaving the MRS and the corrupted folder to their own devices. Any help would be appreciated.
    Thursday, September 26, 2013 1:37 AM
  • Any news on this? Anyone?
    Thursday, September 26, 2013 5:22 PM
  • Fred:

    The problem isn't that it's a corrupt so much as a weird folder structure. It's a VERY long series of repeating folders named the same. So the scripts will read it and may very well succeed in moving the folder. Is there no way of excluding a particular folder from migrating?

    Thursday, September 26, 2013 5:24 PM
  • You can try removing the bad folder from the source, but since you pointed out that you couldn't remove them from the hierarchy, I'm not sure if you have more options here. Things that you might want to consider:

    * If you have more than one replica of that folder, you can check if the folder isn't corrupted in some of the replicas. If that's true, you can use the database containing that replica as the entry point for your migration. MRS will follow redirections for other folders that aren't replicated on that database.

    * You can try removing the folder from somewhere else that you have not tried before (server side or client side, it's not clear which way you are trying to do when you face the problem).

    * You can also try a tool like MFCMAPI (it will essentially be the same as trying to remove it from Outlook, but without the whistles-and-bells). Try that with different sets of credentials if you can. Also check permissions on that particular folder, just to be sure that it's not a permission problem.

    If all attempts to fix the problem in the origin fail, you can always let MRS run the migration and wait it to fail reading from that corrupted folder. Then you increase BadItemLimit by 1 and resume the migration. It should just skip that folder and move on.

    Thursday, September 26, 2013 5:30 PM
  • Ah, so the folder is still readable... Would you mind explaining in more details how it looks like?

    Is it possible for you to enumerate all these folders? If it is, although I'm not fully familiar with Public Folders in Exchange 2010, at least in 2013 you can address folders by their EntryId, which is (or should be) unique. If you can find that these folders that you don't want really have unique EntryIds and that you can remove the folders by using the EntryId, then you can clean up the source.

    If MRS can read the folders, it will attempt to copy them.

    I'm not aware of any way that you can exclude folders during migration, option here would be excluding them from the source.

    Thursday, September 26, 2013 5:38 PM
  • Hello Fred,

    Somehow, I'm not sure how, the top-level folder created a very long list of cascading sub-folders named the same as the top. It cannot be opened in Outlook though, giving an error about the Exchange server. The source server is Exchange 2007.

    You say that you can exclude them from the source. How?

    Thanks,

    Fred

    Friday, September 27, 2013 1:56 PM
  • You can run Get-PublicFolder cmdlet on the source side.

    I'm not sure how bad it is on the source, but we have the ability of both retrieving folders recursively and removing folders recursively. Since we don't know how big is the problem I wouldn't recommend you to run any recursive action on the source, but you can write a script that can explore how deep the problem is after you figure out some aspects of it.

    Experiment with retrieving a couple folders deep and use Format-List to double check that their metadata is different (they don't carry anything that suggest they are in a loop and things like that).

    Once you find out how extensively bad your source is (and even if you don't have any data you cannot afford losing stored on those folders), then you can either simply issue a "Remove-PublicFolder \path\to\the\problematic\folder -Recurse" or individually remove each one of the descendents, from leaf to root.

    Always exercise care when executing these operations recursively since data loss is a possibility.

    Tuesday, October 1, 2013 9:08 PM
  • Since I was under the gun to move the PFs, I went ahead and did it and ran into a *ton* of errors related to the damaged folder. It was still readable for the most part however and I simply increased the number of BadItems to a ridiculous number.

    The folders did migrate and, happily, I was then able to delete the "bad" PF on 2013.

    What's strange is being told by Jesse up there that I could exclude them but that turned out to be wrong. Konrad also didn't seem to know what he was talking about either.

    Well thanks, Fred, for the information.

    • Marked as answer by SamLair Monday, October 7, 2013 2:33 PM
    Monday, October 7, 2013 2:33 PM