some messages staying in local delivery queue

Does the database mount?  If so, you may just get away with running ISINTEG - found in the \bin directory of Exchange Server.

Dismount the database you want to check and run the following from the command line:

ISINTEG -S {servername} -TEST ALLTESTS -FIX -VERBOSE

Select your database that you've dismounted, then let it run through.

Hello,
I have executed the command 'ISINTEG -S serveur-ml350 -TEST ALLTESTS -FIX -VERBOSE' twice yesterday evening. First time, some fixes were done, second time everything has been found OK. The problem remains identical. I still have 74 mails stuck ...
Any other idea ?
Regards.
Francis

Are the emails all for a specific email address / account or several addresses / accounts?

Have you checked Exchange to see if that mailbox still exists?

Did you run eseutil /p and eseutil /d ?

Alan

I only ran ISINTEG and not ESEUTIL as I've been told it might be sufficient. Do you recommend it ?
The problem impact several users but only one complains about it. Until a  final solution is found, I think I'm going to delete and recreate the mailbox for this VIP (saving all currently available mails before). Please advise ...
Francis

Is there any log where I could find clues regarding local delivery problems?
Regards.
Francis

I would recommend you run eseutil /p, then eseutil /d and then finally isinteg (at least twice), but that will mean down time, and you will need 110% of the database size in free disk space to run the defrag (eseutil /d), but it should solve your problems.

I wouldn't zap the mailbox - I would get repairing.

Make sure you have a backup of the database before you start, or repair / defrag a copy of the database so you can roll things back if you need to.

Alan

Ok, I'm going to schedule these 3 commands at 17h30 today. I let you know tomorrow morning.
Thanks.
Francis

No problems - how big is the database?  The repair / defrag will run at about 4-6Gb / hour, so allow plenty of time for a large database!!

Isinteg is usually much quicker.

You will have to dismount the database to run eseutil :)

Alan

The database is 12GB large and I have 60GB free on the same drive ...

Francis

That should be fine.  Won't take forever then.

Do you think I should use eseutil /r before eseutil / p  ??

Francis

No - why would you want to replay log files?

So why after eseutil /p does MS recommend running eseutil /d and isinteg?

And if you repair the database using eseutil /p, why does isinteg find and fix errors?

at the moment, I've just begun eseutil /p on the priv1.edb database ...
I unterstand from what I read above that it might be not necessary.

Is it mandatory that I do an 'eseutil /d' after the 'eseutil /p' I've just launched ?

Francis

Yes - run the eseutil /d after the /p and then run isinteg.

I don't agree with jrhelgeson's comment.

So why after eseutil /p does MS recommend running eseutil /d and isinteg?
And if you repair the database using eseutil /p, why does isinteg find and fix errors?

ESEUTIL is a generic database maintenance utility. It does not distinguish between Active Directory DB, Exchange DB, or numerous other Microsoft JET database. It is a generic utility designed for high-level structural repair.

ISINTEG is the database utility that recognizes the Exchange database as storing email messages and it ensures that all the details are in place.  If ESEUTIL is an Emergency Room Doc, ISINTEG is a neurosurgeon.   The ER Doc will get the right parts back in the right neighborhoods - but the neurosurgeon will get the nerve endings reattached and bring back full functionality.

If ISINTEG returns clean, you can rest assure that the structural components are sound. If it returns errors that it cannot fix, then you need the structural repairs that ESEUTIL provides.  ESEUTIL is also needed when you cannot mount the database or need to run an offline defrag.

ISINTEG should always be run after you use ESEUTIL for any database operation.

That being said: Based upon the information provided, I believe that we are dealing with a queue issue and not a database issue.

Well - happy to agree with you if the repair. defrag and integrity check doesn't work, but in my experience, it is usually the database that has the problem, especially when it is only just a select few messages that don't make it past the queue, but happy to be wrong.

Alan

Alan - if the DB passes ISINTEG, then it is a classic problem with messages being stuck in the queue after a DB recovery.  If it passes ISINTEG, running ESEUTIL essentially gains you nothing.

In order to get the messages flowing again, we need an error message that will tell you why the messages are not getting delivered.  I'm not sure what there is to disagree with.

Time will tell.

From what you are saying it seems that you think ALL messages are not leaving the queue, which is not what is happening.

From the question:
"I have now some troubles (a few people do not receive their mails, they are stuck in the local delivery queue)"

So the queue is fine for most emails, just not one or two users, so essentially the queue works.

I've had numerous problems like this on my own 2003 Exchange server and all have been fixed with eseutil and isinteg.

Hi Alan and J,

I have done eseutil /p, eseutil /d and isinteg twice. The pb is still the same. Doing a bit more investigation, I am now sure the stuck mails are all for the same mailbox. I have check that the MB has not reached its size limitations.
Due to the fact that the MB belongs to one of the big boss, I wonder if I could find a workaround to allow him to get at least his new mails ...

I'll keep on working on that problem tomorrow morning. It's time to go to sleep ...
Regards
Francis

Okay - any 326 / 1194 Event ID's appearing in the Application Event Log?

none

what do you think of this :
http://www.thecyberwolfe.com/blog/2008/04/26/exchange-2003-mail-stuck-in-local-delivery-queue/

?

Francis

I had seen that too and it looks like it should work, but have you tried jrhelgeson's suggestions yet?

Alan

Hi Everybody,

after modifying logging level, I get now plenty of 'Event ID 327 from MSExchangeTransport with error code -2147221240 on call = EcLocallyDeliverMsg. I also get error code -1605.

It looks more and more that this one MB is corrupted. If there is no quick way to check MBox integrity, I think I'm going to delete it and recreate a new one. Could it solve my pb?

Francis

I would implement dial-tone messaging and do a complete recovery of the old database. High-level overview of what this looks like:

1.  Shut down the Exchange Store service,  "NET STOP MSEXCHANGEIS" from the command line
2.  Move/rename the directory containing your PRIV1.edb & .stm files, then re-create that directory name/path.
3.  Start the Information Store service with those database files missing.  Exchange will not mount the missing database files, but will have a valid path to where those files should be.
4.  Manually mount the databases within Exchange System Manager - this will re-create empty databases and give you the 'dial-tone' messaging. Messages will start flowing into this newly created (clean) database.
5.  Mount the old (broken) database as a recovery storage group.
6.  Merge the mailboxes from the old database back into the new (clean) database.

I finally solved by deleting and recreating the mailbox and the first tests are OK.
I would like to know if there is a tool being capable of detecting corrupted mailbox.

Many thanks Alan and J for your availability and competence.

Last minute writing :
Although it seems OK, the old MB still appears in the list of MB in Exchange System Management. How can I remove it ?

Thanks for your time and best regards.
Francis

The old mailbox will eventually go - it just needs Exchange to run it's maintenance overnight to mark it as a deleted mailbox and then it can be purged.

For now - don't worry.

Glad the mail is flowing again and thanks for the points.

Alan

Being that this exchange database was restored, and that restored database had problems - I would highly recommend creating a new mailbox database and moving all mailboxes from the old DB into the new.

The one problem you had exhibited itself in a fashion that was quite noticeable. That problem was resolved by re-creating the user mailbox.  Additional problems likely exist for other mailboxes in that database, they just haven't become apparent yet.

Glad to see you got it working.

Regards,
Joel

Hi Joel (better than just J ),

I thank you for all your precious advices. I guess I still may have problems with that database. I plan to 'hit' the customer to change this rather old server to a new one asap and migrate to Exch2010SP2 or should I choose Exchange2013. But this is another story...

Best Regards,

Francis