some messages staying in local delivery queue

Probably due to a restoration of an exchange 2003 database that has been backed up with block mode software (Shadowprotect), I have now some troubles (a few people do not receive their mails, they are stuck in the local delivery queue). Trying to force connection does not work.
I guess the priv database may be inconsistent.
From what I've read, I think I shoud use the following commands :
- chkdsk /f d:
- eseutil /p
- eseutil /d
- isinteg -s myserver -fix -test alltests

Do I have any alternative ? What are your recommandations ?

Regards.
Francis
bbn35bzhAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
Advertise Here
 
Alan HardistyConnect With a Mentor Co-OwnerCommented:
Try the hotfix here first:

http://support.microsoft.com/kb/823494

If that doesn't work, export to .pst, splat the mailbox and follow the link you posted earlier.

Alan
0
 
jrhelgesonCommented:
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.
0
 
bbn35bzhAuthor Commented:
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
0
Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

More Information
 
Alan HardistyCo-OwnerCommented:
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
0
 
bbn35bzhAuthor Commented:
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
0
 
bbn35bzhAuthor Commented:
Is there any log where I could find clues regarding local delivery problems?
Regards.
Francis
0
 
Alan HardistyCo-OwnerCommented:
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
0
 
bbn35bzhAuthor Commented:
Ok, I'm going to schedule these 3 commands at 17h30 today. I let you know tomorrow morning.
Thanks.
Francis
0
 
Alan HardistyCo-OwnerCommented:
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
0
 
bbn35bzhAuthor Commented:
The database is 12GB large and I have 60GB free on the same drive ...

Francis
0
 
Alan HardistyCo-OwnerCommented:
That should be fine.  Won't take forever then.
0
 
bbn35bzhAuthor Commented:
Do you think I should use eseutil /r before eseutil / p  ??

Francis
0
 
Alan HardistyCo-OwnerCommented:
No - why would you want to replay log files?
0
 
jrhelgesonConnect With a Mentor Commented:
I disagree - if he runs ISINTEG and it comes back clean after the second pass, then that indicates that the database is in good shape. If the ISINTEG does not come back clean, or the database doesn't mount - that is when you need to take the DB offline and run ESEUTIL.

The problem is with the local delivery queue.

Are you having any event log errors from "MSExchangeTransport" or "MSExchangeIS Mailbox" or similar? If so, post any that appear relevant to the situation.  If there are no errors, or the errors are not descriptive enough then we'll need to turn up MTA Debugging to get relevant error messages:

To modify logging settings for MSExchangeTransport

1.      Click Start, point to Programs, point to Microsoft Exchange, and then click System Manager.
2.      In the console tree, expand Servers, right-click <Server Name>, and then click Properties.
3.      Click the Diagnostics Logging tab.
4.      Under Services, click MSExchangeTransport.
5.      Under Categories, click the category for which you want to configure the logging level:
Select Routing Engine/Service to troubleshoot routing issues. Increase the logging level for this component if messages are accumulating in the Messages waiting to be routed SMTP queue.
Select Categorizer to troubleshoot problems with address resolution in Active Directory, distribution list expansion, and other categorizer issues. Increase the logging level for this component if messages are accumulating in the Messages awaiting directory lookup SMTP queue.
Select Queuing Engine to troubleshoot problems with the queuing engine. Increase the logging level for this component if you are experiencing mail flow problems, and mail is not accumulating in any of the queues.
Select Exchange Store Driver to troubleshoot issues with the Exchange store driver. Increase the logging level for this component if messages are accumulating in the local delivery SMTP queue, the X.400 queues, or if you have problems receiving mail from Exchange 5.x servers or other mail systems.
Select SMTP Protocol to troubleshoot general SMTP issues. Increase the logging level for this component if messages are accumulating in the Remote delivery SMTP queue to determine if SMTP errors are causing the bottleneck.
Select NTFS store driver to troubleshoot issues with the NTFS store driver. Increase the logging level for this category if messages are accumulating in the Queue folder of your SMTP virtual server and are being processed slowly or not being processed at all.
Under Logging level, click None, Minimum, Medium, or Maximum. Click Maximum for troubleshooting purposes.
http://technet.microsoft.com/en-us/library/bb124596(v=exchg.65).aspx
0
 
Alan HardistyCo-OwnerCommented:
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?
0
 
bbn35bzhAuthor Commented:
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
0
 
Alan HardistyCo-OwnerCommented:
Yes - run the eseutil /d after the /p and then run isinteg.

I don't agree with jrhelgeson's comment.
0
 
jrhelgesonCommented:
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.
0
 
Alan HardistyCo-OwnerCommented:
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
0
 
jrhelgesonCommented:
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.
0
 
Alan HardistyCo-OwnerCommented:
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.
0
 
bbn35bzhAuthor Commented:
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
0
 
Alan HardistyCo-OwnerCommented:
Okay - any 326 / 1194 Event ID's appearing in the Application Event Log?
0
 
bbn35bzhAuthor Commented:
none
0
 
bbn35bzhAuthor Commented:
0
 
Alan HardistyCo-OwnerCommented:
I had seen that too and it looks like it should work, but have you tried jrhelgeson's suggestions yet?

Alan
0
 
bbn35bzhAuthor Commented:
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
0
 
jrhelgesonCommented:
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.
0
 
bbn35bzhAuthor Commented:
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
0
 
Alan HardistyCo-OwnerCommented:
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
0
 
jrhelgesonCommented:
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
0
 
bbn35bzhAuthor Commented:
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
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.