Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Edb.log File Deleted
- Thread starter SymGuy
- Start date
ShackDaddy
MIS
Give us more information. Is there an actual problem at this point? Will your Information Store not start? If your server is still up and running, just do a full backup of your Information Store(NTBACKUP or something that can interact with Exchange), which would normally truncate (delete) the .edb log anyway.
If this doesn't work, and there are more serious problems, let us know and I'll walk you through the more complex recovery steps.
ShackDaddy
If this doesn't work, and there are more serious problems, let us know and I'll walk you through the more complex recovery steps.
ShackDaddy
xsierrax123
MIS
Same thing happened to Our Exchange 5.5 server this morning. NAV thought edb.log was infected with Novarg, it was deleted. The information store is dead in the water, won't start. What next Help!
IceHockeyRock
MIS
Please post some more details, error messages, event logs etc!
xsierrax123
MIS
Our NAV was set to delete files if a repair was unsuccessful, thus the edb.log file is gone. If we attempt to restart the information store this is what event logs report:
"Event ID:1120; Error Current log file missing initializing the Microsoft Exchange Server Information Store database. "
"Event ID:5000; Unable to initialize the Microsoft Exchange Information Store service. Error Current log file missing. "
"Event ID:1120; Error Current log file missing initializing the Microsoft Exchange Server Information Store database. "
"Event ID:5000; Unable to initialize the Microsoft Exchange Information Store service. Error Current log file missing. "
trent1980
IS-IT--Management
- Dec 18, 2002
- 36
- 0
- 0
same thing to us friday afternoon. here are the steps i took to get the IS back up -- but i do have some issues i'll post after --
step 1: eseutil /p /ispriv
step 2: delete all log files, .chk and temp.edb
step 2: isinteg -pri -fix -test alltests
step 4: isinteg -patch
step 5: start the IS
now my issue -- we have corrupt email in that the user can see the header but cannot delete or view the mail. is there any other way to fix that without defragging? i know it is caused by the uncommitted transactions from our log.edb.
thanks,
step 1: eseutil /p /ispriv
step 2: delete all log files, .chk and temp.edb
step 2: isinteg -pri -fix -test alltests
step 4: isinteg -patch
step 5: start the IS
now my issue -- we have corrupt email in that the user can see the header but cannot delete or view the mail. is there any other way to fix that without defragging? i know it is caused by the uncommitted transactions from our log.edb.
thanks,
NonProfitTheatre
IS-IT--Management
We're working w/this suggestion right now because we're running into the same problem!
jackofallm
MIS
Im working on exchange 2000 right now. I have exactly the same problem (if not more). I did exactly what trent and nonprofittheatre suggested. (except that i created a new mail store and then replaced my working edb files in them)
It worked fine for about 30 min..... then all hell broke loose. The priv.edb file grew from 4gb to 14 gb in no time ...creating all sorts of server problems. I have taken a back up of the 4gb and 14gb edb files and forced to delete then from the server to make space.
what is the reason for the increase in size and is there any way i can resolve this issue ?
It worked fine for about 30 min..... then all hell broke loose. The priv.edb file grew from 4gb to 14 gb in no time ...creating all sorts of server problems. I have taken a back up of the 4gb and 14gb edb files and forced to delete then from the server to make space.
what is the reason for the increase in size and is there any way i can resolve this issue ?
Hello,
Our edb.log file was quarantined by NAV as well on saturday.
Fortunately for us, the file was still in quarantine and not deleted.
I turned off the real-time scan for that particular file (edb.log in
the exclusion list), and then restored the edb.log file.
A restart of the server brought everything back up fine, so we were
fortunate to not have any corrupt priv.edb or pub.ebd files.
My question is whether or not leaving the edb.log file excluded from
future real-time scans is an issue? My gut instinct is that it is
not, as it is just that 'a log file' and can't have the binaries that
are inside of it run.
Should I wait for the current edb.log file to fill up to its 5mb limit
and when it is rotated out to the new name just delete the
'edbXXXXX.log' files, then turn back on the real-time protection for
the edb.log file?
Or just leave that file excluded for the future?
Thanks for the advise,
Jason
Our edb.log file was quarantined by NAV as well on saturday.
Fortunately for us, the file was still in quarantine and not deleted.
I turned off the real-time scan for that particular file (edb.log in
the exclusion list), and then restored the edb.log file.
A restart of the server brought everything back up fine, so we were
fortunate to not have any corrupt priv.edb or pub.ebd files.
My question is whether or not leaving the edb.log file excluded from
future real-time scans is an issue? My gut instinct is that it is
not, as it is just that 'a log file' and can't have the binaries that
are inside of it run.
Should I wait for the current edb.log file to fill up to its 5mb limit
and when it is rotated out to the new name just delete the
'edbXXXXX.log' files, then turn back on the real-time protection for
the edb.log file?
Or just leave that file excluded for the future?
Thanks for the advise,
Jason
- Thread starter
- #11
Sorry, I thought I posted back on this thread. Must have been distracted and forgot to post it. The file was completely deleted by NAV and it took us down immediately. The IS would not start again. Here is how we got it fixed finally. Maybe it will help someone else in the same boat.
While researching I came across this issue listed as a DoS exploit on a hacker site. Delete will no longer be our last resort setting on NAV! For those who are wondering why we had it set that way, it was because another virus once filled our quarantine to the point where NAV would no longer open and the machine was running like a dog.
1. Rename existing \MDBDATA folders on all drives to \MDBDATAOLD.
2. Create new blank \MDBDATA folders on the same place.
3. Restore INFORMATION STORE from the last good backup. Do not start the service.
4. Check the RIP key ( Restore In Progress Key) in the registry \HKEY_LOCAL_MACHINE \ SYSTEM \ CURRENT CONTROL SET \ SERVICES \ MSEXCHANGEIS \ RESTORE IN PROGRESS.
5. Check HighLog Value and Lowlog Value files. ( HighLog Value = High Number Log commited ) ( LowLog Value = Low Number Log Commited )
6. Confirm the number of logfiles restored from the backup should be between HighLog Value and LowLog Value.
7. If all log files are intact and in sequence.
8. Start the INFORMATION STORE SERVICE.
SymGuy
While researching I came across this issue listed as a DoS exploit on a hacker site. Delete will no longer be our last resort setting on NAV! For those who are wondering why we had it set that way, it was because another virus once filled our quarantine to the point where NAV would no longer open and the machine was running like a dog.
1. Rename existing \MDBDATA folders on all drives to \MDBDATAOLD.
2. Create new blank \MDBDATA folders on the same place.
3. Restore INFORMATION STORE from the last good backup. Do not start the service.
4. Check the RIP key ( Restore In Progress Key) in the registry \HKEY_LOCAL_MACHINE \ SYSTEM \ CURRENT CONTROL SET \ SERVICES \ MSEXCHANGEIS \ RESTORE IN PROGRESS.
5. Check HighLog Value and Lowlog Value files. ( HighLog Value = High Number Log commited ) ( LowLog Value = Low Number Log Commited )
6. Confirm the number of logfiles restored from the backup should be between HighLog Value and LowLog Value.
7. If all log files are intact and in sequence.
8. Start the INFORMATION STORE SERVICE.
SymGuy
jackofallm
MIS
sandsrfr, your comment seems to be a solution.
I just created a new edb file and mounted the mailstore. But a few mails later novarg pops up and the log file gets deleted again. Back to square one.
I could not find the option to exclude the 'edb.log' file. I use NAV corporate edition. Both file and ms exchange real-time protection have the option to leave alone (log files) or exclude all .log extensions. Is that what u did ??
I just created a new edb file and mounted the mailstore. But a few mails later novarg pops up and the log file gets deleted again. Back to square one.
I could not find the option to exclude the 'edb.log' file. I use NAV corporate edition. Both file and ms exchange real-time protection have the option to leave alone (log files) or exclude all .log extensions. Is that what u did ??
trent1980
IS-IT--Management
- Dec 18, 2002
- 36
- 0
- 0
Jackofallm --
open your norton AV and expand the configure tree. select "file system realtime protection" .. in the options portion, check the "exclude selected files and folder" and then browse to exclude the logs folders --
open your norton AV and expand the configure tree. select "file system realtime protection" .. in the options portion, check the "exclude selected files and folder" and then browse to exclude the logs folders --
Dear all,
I got that same error in our exchange 5.5 , we work all day long for this , installing new exchange and member it on same zone, testing are done to this server as we come up to deleting the files under mdbdata folder , which means installing new database both for pub and priv, all contact mails and calendar as well as in the all public folder were erased, its a practical move, instead of reviving the whole database , using the eseutil /p , having the problem on user side, difficult to explain on non tech user, inform the user that your server were infected by virus, and nothing can do about it, than creating new databse for it, this is really works, make sure you backup first the content of mdbdata folder , for your reference, i hope that it would help you guys
I got that same error in our exchange 5.5 , we work all day long for this , installing new exchange and member it on same zone, testing are done to this server as we come up to deleting the files under mdbdata folder , which means installing new database both for pub and priv, all contact mails and calendar as well as in the all public folder were erased, its a practical move, instead of reviving the whole database , using the eseutil /p , having the problem on user side, difficult to explain on non tech user, inform the user that your server were infected by virus, and nothing can do about it, than creating new databse for it, this is really works, make sure you backup first the content of mdbdata folder , for your reference, i hope that it would help you guys
jackofallm
MIS
Thanks trent,
just excluding the E00.log file seems to have done the trick.
just excluding the E00.log file seems to have done the trick.
- Status
Similar threads
- Locked
- Helpful tip
- Locked
- Question