Missing Attachments in E-mails after Repair of Priv.edb 1

[gclumpkin]

All:

I've searched all posts about getting back a data store and have seen some good advice, but my situation is a little different. Here's my scenario:

We have an Exchange 5.5 server running on Windows 2000 Server. It is also our Domain Controller, DHCP Server and DNS Server. I know having an Exchange Server as your Domain Controller is a no-no, but I inherited this network a few months ago.

Our Exchange data store, Priv.edb was at 14.8 Gigabytes and we were getting some weird errors in the Event log so we had planned to defrag the data store. Over the Christmas break, a consultant logged into the server and did some repairs on the data store before defragging it. Now, some e-mails in people's Inbox and Sent Items in Outlook show as having attachments, but when you open the e-mail, a dialog box displays a message stating "Could not open one or more attachments." The e-mail will open after clicking OK, but sure enough, no attachments(s). We didn't know about this until days after everyone was back to work and using the Exchange Server. The consultant made a copy of the entire "exchsrvr" folder so I have all the files as they were before he got started.

The problem is that I have been tasked with finding a way for us to get into the old data store so we can have the ability to get attachments from e-mails that our end users might need. I have hardware that I can use to set up another Exchange Server, but all Disaster Recovery scenarios I've seen don't address a situation like mine.

Does anyone have any advice?

Thanks,
Greg

 

[zbnet]

If you have all the online backups of the store and the transaction logs since the consultant repaired your db, then you could restore the last good backup prior to his work, and also restore all the subsequent transaction logs, which will then replay when the store is restarted, bringing the old db right up to date with all the latest email.

It sounds like the cnsultant didn't know what he was doing to me - you should make him (or his company) sort it out, or at least extract reparations from him to pay for the restorative action you are taking.

 

[gclumpkin]

I gratefully appreciate your advice, zbnet. I'm not an Exchange administrator, so I need some clarification of the terms you are using. Online backups - I have a complete copy of the Priv.edb as well as tape based backups of the data store. We just recently upgraded from NT Backup to Arcserve 11.1. Transaction logs - are they in a folder on the Exchange Server? Is there a step-by-step document that can walk me through this? I don't want to make things any more worse than they are now.

Again, I appreciate your help.

Greg

 

[zbnet]

If you're not that familiar with Exchange, then you may well struggle to achieve your goals. You really need an experienced Exchange guy to help.

The transaction logs live by default in a directory called mdbdata, although its location is user-definable. An online backup (NTbackup can do those, because when you install Exchange on an NT server it patches NTbackup to make it Exchange-aware) runs whilst the Exchange store is still mounted, and purges away the transaction logs from the disk after successfully backing them up to tape - this assumes you have circular logging disabled (which it should be on all production mailbox Exchange servers). So if you've been doing online backups since the day the consultant worked on your db, and you still have all those tapes in sequence, you can recover the old db and all the transaction logs (sequentially numbered). If not, you can't do this restore.

First, then, secure the tapes if the above is true, then read faq10-6004 before you start to play, so that you don't make the situation worse.

 

[gclumpkin]

I totally agree with you zbnet. I know my limitations and I don't need this to get any worse than it is already.

That being said, I downloaded a copy of PowerControls by Ontrack. This is amazing software. Since we only have 60 e-mail boxes and this looks to be the most expedient and safe method, we've decided to pony up the $950 for the Standard version and get this over with. I plan to extract the data to individual PST files and train the end-users on how to open the file and get to their data.

Again, I appreciate your help.

Greg

 

[mmiram]

I am not an expert here but I had a similar problem with my exchange server (where users were getting the message "Could not open one or more attachments." and the attachments were missing). For almost two weeks, I had this issue.

I finally figured out that it had more to do with the anti-virus running on the exchange rather than the store itself. If the back ground scanning is set to on, everytime there is a major change to the store or new definitions are downloaded, the anti-virus runs the check on all the attachments in the store in the background. As such, if you try to access an attachment that has not been scanned, you will not be able to open it.

If you do have an exchange anti-virus (I have McAfee GroupShield) running, you can try to disable background scanning for attachments and see if that fixes the issue.

Disabling it will not be a security hole. It jsut means, that the attachments will be scanned on access (as and when the user opens the email).

It might not be the issue you are facing but I think it might be worth a try.

 

[gclumpkin]

We use Symantec AntiVirus Corporate Edition, but let me look at the settings anyway and I'll let you know.

Thanks,
Greg

 

[shiv9]

If you are using Norton AntiVirus for MicroSoft Exchange (NAVMSE) then you may wish to look at the Auto-Protect options. The Mode you are in could be critical. There is MAPI, VAPI, and MAPI/VAPI.
MAPI scans all new mail as it arrives in the MailBox
VAPI scans all attachments in the information store
MAPI/VAPI combination mode attempts to use both technologies

http://service1.symantec.com/SUPPORT/ent-gate.nsf/0/12d0af0d0f9534ad88256bd0007e4d9f?OpenDocument

The VAPI mode can be quite intensive and pull more than you bargained for.
Also check the Bloodhound level.