Honestly, forgot about this group. I searched newsgroups up and down, and could only find others with the same problems, not anyone with this solution.
Next time . . . -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy David Posted At: Thursday, June 29, 2006 4:16 PM Posted To: exch list Conversation: Recover Unrecoverable Deleted Public Folders Subject: RE: Recover Unrecoverable Deleted Public Folders Should have just posted here, we use pfdavadmin to recover deleted public folders all the time! :) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin, Jon Sent: Thursday, June 29, 2006 7:09 PM To: Exchange Discussions Subject: Recover Unrecoverable Deleted Public Folders Long, sad story with a punch line (which is worth getting to): Exchange 2003. Ran into a situation where a user deleted 10 public folders by mistake. Using Recover Deleted Items to retrieve them, got back five of the folders (the ones that were empty in the first place) but we received the following error message when attempting to recover the other five (the ones with actual stuff in them): "Outlook was unable to recover some or all of the items in this folder. Make sure you have the required permissions to recover items in this folder and try again. If the problem persists contact your administrator." Surfing around, I found a number of people with the same problem. Many had had success using OWA's Recover Deleted Items function (http://ExchangeServerName/public/FolderNameWithSlashesBetweenEachTreeLe vel/?cmd=showdeleted) when this problem developed. Unfortunately, not us. >From what I could find I was going to be stuck restoring a previous public folder database to the Recovery Storage Group and sucking out the needed folders. I called Microsoft PSS to go over the problem, and they confirmed that I would have to go to tape, but the bad news was that Recover Storage Group does not work on public folder databases, only mailbox databases. I was going to be stuck setting up a recovery server and restoring there. The news got worse - the server had to have the same server name, Exchange organization name, etc. as our production server, so this all had to be done on a separate network, with a new domain controller, etc. They gave me a bunch of Q-Doc numbers and a 'good luck'. The requirements are best synthesized in a document from Veritas: http://seer.support.veritas.com/docs/247985.htm. However, this did not mention having the same server name that the MS folks said was required. Decided to use VMWare for the task, because I already had VM files that mimic our production domain controllers and Exchange servers, although not with the same names as out production servers, domain or Exchange org. Also, VMWare has an option to open up VMs in a private network, where the VMs see other VMs on the host, but nothing off the host. This way I could still do all of the work remotely (i.e. sitting on my couch at home with a laptop and some cool jazz going, and not in a freezing data center room). Got four VMs up and running, a DC, an Exchange server, a client and a server running Veritas Backup Exec. This last VM had no problem seeing a tape drive we attached to the host. Now, since I was using a pre-existing VM with an Exchange org with a different name than the production Exchange org, I had to uninstall Exchange from the server. I then re-named the server to be the same as our production server, and re-installed Exchange, using the same organization name as our production org. The next thing was to rename the Administrative Group (normally First Administrative Group, but not in our production environment). For this I had to get into ADSI Edit to find the appropriate object and change the attribute (Configuration Container - Configuration - Services - Microsoft Exchange - Org Name - Administrative Groups - First Administrative Group). Then, we had to do the restore. This on the surface was relatively straightforward, using the Veritas documentation. We ran into a problem, however, because our tape unit on the recovery server was a single tape drive, while the production tape system uses a multi-drive library with multiple tapes per job. The backup/recovery guys had found the one tape that had the public folder database on it, and had cataloged it in the recovery TBU server. But when I went to run the restore, it appeared to write out all of the bytes and then the job failed. According to the Veritas folks, just cataloging one tape out of a multi tape job will not work - you have to catalog all tapes from the job and then run the restore. I turned this over to TBU guys to handle. They contacted me after a successful restore. (Note: This next step and the problem that the ensued only required if you have changed the name of the First Administrator Group in your production system.) Now, at this point to get the public folder database to mount, you have to run a public MS utility - LegacyDN - to change all of the LegacyExchangeDN attributes on all of the objects that still have the LegacyExchangeDN set to First Administrative Group. That worked fine, and the database mounted. The problem is that the mailbox database would not mount now. Since I am trying to get to public folders, maybe not a problem. Wrong - cannot connect with Outlook without a mailbox to get to. So, I created a second mailbox store and moved the Administrator mailbox there, and got Outlook up and running. OK, now I have Outlook up and running and can get to the public folders, which I can then export to PST files. Opps, not so fast. There are permission problems. I can see the number of items in the folders, but not the items themselves. So I go to Exchange Systems Manager and drill down to the public folders in question, right click and properties, I got the following error message: "The mail proxy for this folder cannot be found. This may be due to replication delays. The mail enabled pages will not be shown. ID no: c1038a21" After clicking on OK, I got to the properties screen. Clicking on Security, and then Client Permissions, it waited a while and then gave me this error message: "Your profile is not configured. An unexpected, unknown error has occurred. Microsoft Exchange Server Information Store ID no: 8004011c-0521-00000000 ID no c1050000 Exchange System Manager " After bit of research, it was back to the MS PSS folks. This time they send me a private MS utility - PFDavAdmin - that they used to tweak the ACLS, DACLS and permissions on the public folders. After a while, I am able to see the content of the folders in Outlook, and save them off to PST files. Great!! We are home free. Note: the punch line is coming up. Since I have the guy on the horn I force him to go back and address the original problem: why did Recover Deleted Items not work. He calls in the reserves, and we begin looking at stuff in our production environment. I show them the problem, they 'Um' and 'I've never seen that before' for a while. They have me put the PFDavAdmin tool on the production server and poke around a bit, looking at various things. They go off to discuss for a few minutes. While they are off discussing, I play with the PFDavAdmin tool. I find an option for 'Show Deleted Folders' and click on it, and my deleted folders show up in the list. I right click on one, and the only option is 'Recover Deleted Folder'. Of course I click on that. The system freezes for about 10 seconds, and then I get an 'Operation successful' message. Go out to Outlook, and there it is, plain as day, one of the five folders I have been trying to recover. I recover another folder. The MS guys come back on the phone and are about to ask me some more questions when I say' 'Uh, guys, did you know this PFDavAdmin tool you gave me just undeleted a couple of these folders?' They are like 'No way, dude' (with a bit of an Indian accent). I show them the steps, and they are now saying 'we didn't know that option was in there - we need to write an article!' So we are all happy now, except for one small thing: going down the road that MS PSS had originally told me, I and my TBU guy had spent a total of 64 (!!) hours getting the PF database restored and the PST files created. With this tool, it could have been completed in 10 minutes! _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/read/?forum=exchange To subscribe: http://e-newsletters.internet.com/discussionlists.html/ To unsubscribe send a blank email to [EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with. _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/read/?forum=exchange To subscribe: http://e-newsletters.internet.com/discussionlists.html/ To unsubscribe send a blank email to [EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with. _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/read/?forum=exchange To subscribe: http://e-newsletters.internet.com/discussionlists.html/ To unsubscribe send a blank email to [EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with.
