Some meeting requests stuck in queue, won't deliver
I have identified at least 2 users who cannot send meeting requests to external addresses. The message sits in the queue and ESM says 'unable to open message for delivery'. I have disabled NAV from email scanning and it still happens.
In Exchange, I see the message coming in....
Event Type: Information
Event Source: MSExchangeTransport
Event Category: Routing Engine/Service
Event ID: 984
Date: 4/7/2010
Time: 9:33:00 AM
User: N/A
Computer: xchserver
Description:
SMTP GetNextHop returned hr=0x0 in 0ms.
DestAddr=<domain.com>, Type=<SMTP>
MsgType=0x5, NextHopType=OTHER_ROUTING_
Type=<SMTP>, Class=<domain.com>, SchedId=0xffffffff
RouteAddr=<domain.com>
Connector=<DNS>
But then get this....
Event Type: Warning
Event Source: MSExchangeTransport
Event Category: Exchange Store Driver
Event ID: 327
Date: 4/7/2010
Time: 9:33:03 AM
User: N/A
Computer: xchserver
Description:
The following call : EcGetMime to the store failed. Error code : -2147467259. MDB : 4510f7d3-a86d-4994-b39a-d3
I have looked at 908062 and 938650 and neither apply. The hotfix for 938650 has file versions as 6.5.7653.5; my server is 6.5.7654.12
Server is Windows 2003 SP2 / Exchange 2003 SP2; clients are Outlook 2007.
In Exchange, I see the message coming in....
Event Type: Information
Event Source: MSExchangeTransport
Event Category: Routing Engine/Service
Event ID: 984
Date: 4/7/2010
Time: 9:33:00 AM
User: N/A
Computer: xchserver
Description:
SMTP GetNextHop returned hr=0x0 in 0ms.
DestAddr=<domain.com>, Type=<SMTP>
MsgType=0x5, NextHopType=OTHER_ROUTING_
Type=<SMTP>, Class=<domain.com>, SchedId=0xffffffff
RouteAddr=<domain.com>
Connector=<DNS>
But then get this....
Event Type: Warning
Event Source: MSExchangeTransport
Event Category: Exchange Store Driver
Event ID: 327
Date: 4/7/2010
Time: 9:33:03 AM
User: N/A
Computer: xchserver
Description:
The following call : EcGetMime to the store failed. Error code : -2147467259. MDB : 4510f7d3-a86d-4994-b39a-d3
I have looked at 908062 and 938650 and neither apply. The hotfix for 938650 has file versions as 6.5.7653.5; my server is 6.5.7654.12
Server is Windows 2003 SP2 / Exchange 2003 SP2; clients are Outlook 2007.
kblumen
Try to disable any server-side rules that the user may have setup within their Outlook.
ASKER
I can't see how that can be a factor. One user has 2 rules to move incoming mail from certain address into a sub-folder.
Is this a new install or a new problem that recently cropped up? Any changes recently on your Exchange/network?
Any third party add ons running on the users outlook?
Any third party add ons running on the users outlook?
ASKER
New install where, client or server? New Exchange install to replace older server, but this was happening with the old server also.
The only third party outlook add ons we use are for salesforce but these users aren't in sales and don't use it.
The only third party outlook add ons we use are for salesforce but these users aren't in sales and don't use it.
Older server hardware or software?
Do you eventually get an NDR? What does it say if so.
When were the outlook clients upgraded? Is there any correlation in time to that or any other change?
I notice the hotfix you mentioned contains a registry change. Perhaps this is the missing piece?
http://support.microsoft.com/kb/938650/en-us
I notice the hotfix you mentioned contains a registry change. Perhaps this is the missing piece?
http://support.microsoft.com/kb/938650/en-us
ASKER
Older server. Dell said they couldn't go over 5 years on the warranty so had to move to newer server. Still running 2003. The clients have been running 2007 for a while. Like some users, they might have an issue and not say anything for a long time so I don't know when this started. I just noticed a few weeks ago these messages not getting out of the queue.
The ndr is "This message was rejected due to the current administrative policy by the destination server. Please retry at a later time." The smtp error is 4.3.2
I checked the registry and that value is missing (go figure). I asked the user to try sending that meeting request again and we'll see what happens.
The ndr is "This message was rejected due to the current administrative policy by the destination server. Please retry at a later time." The smtp error is 4.3.2
I checked the registry and that value is missing (go figure). I asked the user to try sending that meeting request again and we'll see what happens.
I would double check you are not on a blacklist
use http://mxtoolbox.com - put in your domain name and then click blacklist check on your MX records.
Do you have an SPF in place for your domain?
Make sure you have public domain in exchange here:
exchange system manager -> Servers -> <servername> -> Protocols -> SMTP.
Right click Default SMTP Server and select Properties
Go to the Delivery Tab and select advanced.
Make sure that your public domain appears in both the Masquerade Domain and Fully Qualified domain name. Click Check DNS to make sure the domain is valid.
Click OK, OK
Let me know how your tests go.
ASKER
That site shows our MX records are ok. We are not using SPF.
This happens with multiple clients. I just noticed another domain that a 3rd user sent meeting request to is stuck in the queue.
I asked the first user to resend the meeting invite but he said it was scheduled for this morning.
FQDN is correct; is masquerade domain necessary? Don't need to send NDR to a different domain. Check DNS says it's valid.
This happens with multiple clients. I just noticed another domain that a 3rd user sent meeting request to is stuck in the queue.
I asked the first user to resend the meeting invite but he said it was scheduled for this morning.
FQDN is correct; is masquerade domain necessary? Don't need to send NDR to a different domain. Check DNS says it's valid.
I think you need an SPF nowadays.
The fqdn is your external .com address correct?
The fqdn is your external .com address correct?
ASKER
No, the fqdn is the internal address.
That first user received a meeting request from the client. He accepted and immediately got an NDR.
The following recipient(s) cannot be reached:
'System Administrator' on 4/8/2010 11:53 AM
The message could not be delivered because the recipient's destination email system is unknown or invalid. Please check the address and try again, or contact your system administrator to verify connectivity to the email system of the recipient.
That first user received a meeting request from the client. He accepted and immediately got an NDR.
The following recipient(s) cannot be reached:
'System Administrator' on 4/8/2010 11:53 AM
The message could not be delivered because the recipient's destination email system is unknown or invalid. Please check the address and try again, or contact your system administrator to verify connectivity to the email system of the recipient.
ASKER
Ignore that last part. Seems the user replied to the original NDR. He was confused; the NDR was from his failed meeting request sent earlier, not for the one just accepted.
I believe the FQDN needs to be the external address.
....otherwise the destination domain will reject the EHLO
...sorry scratch that.... I checked my server and it is the internal FQDN
I would look at creating a SPF
ASKER
I don't think that will fix this because the message never leaves the server. I just found a 4th user that sent a meeting request to a different client and found the same warning messages in the application log and message is gone from the queue.
When I look at message tracking, I see it was categorized and queued for routing, then routed and queued for remote delivery. It was never attempted to connect for delivery.
When I look at message tracking, I see it was categorized and queued for routing, then routed and queued for remote delivery. It was never attempted to connect for delivery.
ASKER
This 4th user just got a new notebook with Office 2007 on Windows 7.
You are getting a NDR indicating communication with the destination server. A SPF is easy to create.
Is this only meeting requests? Are
emails to the same domain also failing?
Is this only meeting requests? Are
emails to the same domain also failing?
ASKER
The issue is only with meeting requests.
can you try to send the meeting request via OWA?
Is there some sort of antivirus on the server or gateway?
have you tried rebooting the server?
I did see these however the NDR is different.. I wonder if you have more than one issue..
Is the destination server exchange 2007?
How many domains are effected?
Is the destination server exchange 2007?
How many domains are effected?
.... forgot the link .... http://support.microsoft.com/?id=938650
ASKER
I'll have the user try it tomorrow.
Would SPF work with our setup? We don't accept mail directly; we use Postini which relays to Exchange.
Would SPF work with our setup? We don't accept mail directly; we use Postini which relays to Exchange.
Yes SPF would work.
Though if email makes it and meeting requests don't then I don't know how it would help. It is a good idea nonetheless.
It seems the meeting requests become malformed in some way. I would think this is something like antivirus causing it.
I would ask the users if they can remember how far back they got these NDRs.
Also is this just one domain??
It seems the meeting requests become malformed in some way. I would think this is something like antivirus causing it.
I would ask the users if they can remember how far back they got these NDRs.
Also is this just one domain??
ASKER
Yes just one domain.
ASKER
Actually, if you mean for us, yes it's just one domain. For the destination, it's at least 4 different domains for these few users where meeting requests are not going.
so sending email to those domains works? Try sending a meeting request via Outlook Web Access.
ASKER
Still trying to get one user to try through owa. One other user, though, says even though she received that NDR, the client said they did receive it and accepted the meeting request; they are running Lotus Notes.
Take a look at this: http://support.microsoft.com/kb/909068/en-us
ASKER
The file versions are older than what I already have.
hotfix excdo.dll is 6.5.7650.14 while my server has 6.5.7654.12
hotfix excdo.dll is 6.5.7650.14 while my server has 6.5.7654.12
ASKER
I had a user try through owa and I looked at the tracking; it shows it was transferred so it went through.
Are you sure all antivirus scanning is disabled on any gateway appliance or client machine? Completely uninstall (for testing) any AV or anything that may be touching the mail on it's way out.
What do you use for AV, spam, malware?
Refresh my memory, does this occur to everyone sending invites to this domain? If not, then try another outlook client & PC with nothing on it but outlook.
Are you using anything that resides in the system tray?
What do you use for AV, spam, malware?
Refresh my memory, does this occur to everyone sending invites to this domain? If not, then try another outlook client & PC with nothing on it but outlook.
Are you using anything that resides in the system tray?
ASKER
I disabled NAV mail scanning from the server console for all clients. There are no gateway appliances in place. Overall I've identified 3 Outlook 2007 users to a few domains. They have their own clients so it's not a case of several people normally communicating with the same one. I did notice some of these meeting invites are done manually each week. If I notice one that gets stuck in the queue again, I'll remove NAV entirely and try again.
ASKER
Just found another user having this issue. Outlook 2007 sending meeting request to a gmail account. I see in ESM queue with the same error and same messages in the application log regarding exchange store driver.
does this occur to everyone sending invites to this domain?
is it 2007 or 2003 outlook specific?
is it 2007 or 2003 outlook specific?
Who can successfully send meeting invites to the domains in question?
ASKER
Almost positive others can send meeting invitations to these domains else I would likely receive more complaints. All are Outlook 2007.
To truly troubleshoot you need to find out for sure if this is limited to only certain users. If you can confirm then that points to the client side.
Can you send a screenshot of what is running in the system tray of the affected machines? Make sure that Windows is not hiding the inactive icons.
Also, please provide a list of installed add-ins including the information from the following registry hives from the affected users workstation:
• HKEY_CURRENT_USER\Software
• HKEY_LOCAL_MACHINE\Softwar
• HKEY_LOCAL_MACHINE\Softwar
Can you send a screenshot of what is running in the system tray of the affected machines? Make sure that Windows is not hiding the inactive icons.
Also, please provide a list of installed add-ins including the information from the following registry hives from the affected users workstation:
• HKEY_CURRENT_USER\Software
• HKEY_LOCAL_MACHINE\Softwar
• HKEY_LOCAL_MACHINE\Softwar
ASKER
Just thought of something. This kb article from before (938650) that didn't have the registry key-the article doesn't say anything about restarting the server or information store. I'm wondering if it didn't take affect because IS wasn't restarted.
I do know these clients are running NAV; will try to see if there is anything else. Some of these users work from home on occasion and are hard to communicate with.
We were having a similar problem. We could send meeting requests, but any update would just sit in the queue. We did the hotfix mentioned above (http://support.microsoft.com/kb/938650/en-us) , but it did not fix the problem.
The kb says, "You do not have to restart the computer after you apply this hotfix. However, the following services are automatically restarted when you apply this hotfix:
* The Microsoft Exchange System Attendant service
* The Internet Information Services (IIS) Admin Service and all dependent services"
Well after a reboot it worked consistently, so you be the judge.
The kb says, "You do not have to restart the computer after you apply this hotfix. However, the following services are automatically restarted when you apply this hotfix:
* The Microsoft Exchange System Attendant service
* The Internet Information Services (IIS) Admin Service and all dependent services"
Well after a reboot it worked consistently, so you be the judge.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
funny how nothing has changed in the environment yet i haven't seen a single meeting request sitting in the queue for some 3-4 weeks