• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 510
  • Last Modified:

Duplicate emails in public folders after public folder restore

Hi All,

Mistakenly... permissions on our public folders were propagated from the root public folder down, (instead of a child public folder), which then gave all of our companys public folders default permissions (default-viewer). So the only way we could think of to put back the previous held permissions on all folders was to restore the public folders from the latest backup, (impossible to set them manually, 1000's of folders). Hours later after the restore was completed all the permissions were restored as before but we noticed that it actually merged the emails into the folders with the emails currently in there, it didnt overwrite them, some folders has 3 copies of the same email, so it may have even restored duplicates??

Were desperately trying to find a solution to delete all the duplicate emails but we cant find any, there are plenty of tools to do this in Outlook, but not public folders.

Does anyone know of a solution to eliminate these duplicates?

Exchange serveris 2003 latest updates and SP on W2K3 server.
Restore is Veritas.

Thanks alot!
  • 3
  • 3
1 Solution
Í am sure you played around with the idea of deleting your public folders, and doing a complete restore again, this maybe the easiest way ? By the first restore, it sounds like you had the settings wrong in veritas, should of using merge, or dont overwrite if file is newer than the one been restored. I am not too sure how quick you need the public folders back up or if you are replicating your public folders, but after deleting them (if you do) I would make sure that the delete has replicated to the other replicants if any, I would also wait a few extra hours on top of this if you can as I have ran into a few problems doing a restore straight after deleting public folders, mainly when a PF has a email address .Make sure you go through all of the veritas restore settings.

tolinromeAuthor Commented:
Hi Hugh,

Yes, we thought about deleting the public folders but probably as an only option, it makes me somewhat nervous doing that since it would be a first and I wouldnt be so sure of the results of the restore. I just did notice the "do not delete existing transaction logs on the server" setting in Veritas. How did you delete/restore your public folders?
Im thinking the that I can either:
1. Restore latest backup again of all public folders overwriting all files already in the current public folder database.
2. Use the "do not delete existing transaction logs on the server" setting in Veritas. (if needed?)
3. Problem solved.
or somehow:
1. Restore the lastest backup of the entire public folder database to another newly created exchange server storage group then transfer it to another the original exchange server- then delete the original database??

Hi Tolinrome,

I believe my situation was different to yours as we were backing up storage groups, & mail boxes and public folders. We were in the situation were we could restore public folders/single files without doing a complete restore of a storage group. But so long as you have your transaction logs all should be ok.. I would dismount your public folders, move the public databases else were, dont delete them just store them away in a safe place (can always use them again if anything goes wrong, better safe than sorry). use this howto then, just move the .edb and .stm files leave all the logs where they are. I am sure it is also ok just to make a copy of the pub.edb pub.stm files and overwrite the database.


Transaction logs from the storage media are then restored and added to the existing set of transaction logs on the Exchange 2000 server. When the restore operation finishes, Exchange 2000 automatically updates its database with uncommitted transactions found in the existing and newly-restored transaction logs. This option is selected by default.

Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

tolinromeAuthor Commented:

Thanks, I think thats a good idea to dismount the store and move the database to a safe location then do a restore, but just a couple of questions about what you wrote.

1. just move the .edb and .stm files - to where?

I am sure it is also ok just to make a copy of the pub.edb pub.stm files and overwrite the database. - This part I dont understand if I should move the files in the previous step.

1. Wouldnt it work as you suggested to move the current database elswhere and then do a complete restore?

tolinromeAuthor Commented:
I think I need to do a little more research on restoring pf's, just to learn the basics. Also, why would uncommitted transaction logs need to be restored since the pf, would be offline I asssume? Peopel simply wopuldnt have access to them.
Hi Troilname,

Read this explains database recovery. Also why transactional logs are best kept.


Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now