Exchange disconnecting VHD

Do any Warning/Error entries in the Windows Application and/or System logs help?

I see three erros.  2 x Event ID 15 : Device not ready for access.  1x Event ID 15 : Filter Manager failed to attach volume.

I tried again to get the errors and the file mounts and I can then see it and access the volume in Windows Explorer.  Then the volume unmounts.

Just saw this answer but I am not sure what it means.

ID: 38921769

Ok, I managed to find another error under the Exchange log and it says the edb file is missing.  I managed to look in the vhd folder just befor it disconnected and I couldn't see it.  I think this may have been caused by Backupassist running a mailbox backup as the move request was in process.

Not sure why the vhd disconnects but this maybe the cause.

I guess I should use Eseutil / R to recover.  Is this correct or should I follow a different procedure?

I would firstly stop Backupassist. Consider starting it again when everything is fine and the move process is over.
As per the Eseutil: I thought your issue was only related to the dismount of the VHD. But, what you wrote on your last post makes me believe that you also lost the EDB file "hosted" on the VHD. Is this correct? If this is it, where are the logs located? You can recover if the logs aren't lost (too). Let me know.

Well, I don't know if the two are related.  All I know is I started a move request last night that was almost completed when I left it.  In the morning I saw the problem and the VHD wouldn't stay mounted.  The backup if the mailboxes showed as failed.  I now see the issue with the edb file so I assume BackupAssist failed backing up mailboxes that had moved and somehow the edb file was deleted.  As to why this forces the VHD to unmount I am unsure.  When I do mount the VHD it says it is healthy.

Is there any AntiVirus running real-time scan? If yes, is it possible that you excluded the original EDB files from real-time scans but did not exclude (new) EDB files hosted on the VHD? If this is it... the AntiVirus might have found infected elements inside the new EDB and moved it to Quarantine (or even deleted the file).

Very good thinking.  Yes, I run AVG and didn't exclude the new path.
Ill exclude and then run a recovery.
Thanks

Ok, I have spent a few hours on this and the common factor is that as soon as I try to copy or zip or run eseutil on the mail.edb file, the vhd disconnects.  It's fine as long as nothing tries to read the file.

So my problem become how does one recover a edb file if the eseutil fails?  If it is irrecoverable then can I just delete the mailbox db from Exchange and then recreate the mail boxes and import the pst files?

Simpler question, is there a recovery procedure if the edb file is corrupt.  The move request was to a new Mail database.  All the logs seem to be there and the .jrs files.  There is also a catalogue folder.

Thanks for your reply.  I ended up deleteing the edb file and Exchange recreated it and email flowed to my mailbox.  However, it seems the same problem then occured and the vhd was dropped.  This morning I couldn't access the NAS and someone on site confirm the NAS drive had a system failure light flashing....  So, I'll see what I can find on the NAS drive tonight but clearly there would seem to be an issue there as you summised.  The drive had been fine as it was being used for backups.  Not sure I'll find out if the problem was caused by a NAS error or if there was a problem with the VHD that caused the problem with the NAS.

Will respond later with an update.

Thanks

I spoke to EMC and it seems one of the disks failed.  It has a RAid 1 setup so i have removed one disk as advised and the device is now running a startup check which may take some time as it is 2T.

The EMC devices support hosting iSCSI drives.  When I get this back to normal would it be better to run iSCSI from the NAS drives or continue to use Windows 2008 to create Vhd drives on the NAS?  They appear to be similar to me but wondered if one was more reliable?  Main issue is startup as I use a startup script to make the connection which can at times fail. Would the iSCSI initiator be more reliable for auto mount?  Also, if the router restarts during the day then the VHD is dropped.  Would the iSCSI initiator reestablish the connection in this situation?

Sorry for all the questions.  I'll mark your previous reply as the solution.

Cheers

Your questions, my answers:

would it be better to run iSCSI from the NAS drives or continue to use Windows 2008 to create Vhd drives on the NAS?
I would choose the iSCSI instead of a VHD. The next question/answer might explain better why.

They appear to be similar to me but wondered if one was more reliable?
The result is quite the same (it is more than similar): obtain disk space from the NAS and make it available to the server. I think they are both equally reliable in ideal conditions (hardware working, complete patching, and so on) but I would choose iSCSI instead of VHD because it's more "direct" (has less layers) than the VHD approach.

Would the iSCSI initiator be more reliable for auto mount?
It should be even though testing deeply is the only secure way of discovering it.

Would the iSCSI initiator reestablish the connection in this situation (router restarts during the day)?
Yes, it should. I would spend some words on this issue. An iSCSI connection should be persistent and as a result all devices involved should work 24x7 including routers. If the router needs restarts during the day and it is crucial for your iSCSI link, investigate why that is needed and make it work 24x7.

Have a nice day!

Thank you very much.  Points noted.

Router restart has been required because it seems the UDP DoS was reaching its threshold so stopping NAT routing for HTTP traffic.  I think this is now resolved so hopefully less of an issue.  However, I was thinking to look at moving the VDSL router so that it is not the main router.  Need to do a bit of reading.

I like the VHD concept but I prefer reliability..  I use it at another clients site and it has been faultless but they are smaller.

Thanks again.  It's Friday so have a good day and weekend.