Wierd mail Problem

M

Mike O.

We are experiencing some weird mail issue at our company the past two days.
We are all on Outlook 2000. We have Exchange 5.5 which is not configured
with the Internet mail service. The Outlook clients are all configured to
pull in internet email from an outside source and is stored on the user's
exchange mailbox. We don't use .pst files. So every user can send in house
email to each other which goes through exchange and send their internet
email through their Outlook client. All their email folders reside on
Exchange. This setup has worked forever, except yesterday about half of our
users started noticing some wierd activity. They weren't able to send out
internet email. They would try and immediately get an undeliverable email
back. "No transport provider was available for delivery to this recipient."
Was the message in the email.

My particualr workstation is able to send and recieve fine. But when I go to
another computer and set it's Outlook client up exactly like my station, the
outgoing email comes back undeliverable. Both computers are pointing to the
same internet email ip address and mailbox, and both are pointing to the
same inhouse exchange server and mailbox. I had two computers setup like
this before and they both were able to send fine. Just ever since
yesterday, we started to see this weird behavior.
All DNS and Gateway settings are fine on every computer and no changes were
done to the Exchange server.
ANy insight would be greatly appreciated.
 
M

Matt

Mike O. said:
We are experiencing some weird mail issue at our company the past two days.
We are all on Outlook 2000. We have Exchange 5.5 which is not configured
with the Internet mail service. The Outlook clients are all configured to
pull in internet email from an outside source and is stored on the user's
exchange mailbox. We don't use .pst files. So every user can send in house
email to each other which goes through exchange and send their internet
email through their Outlook client. All their email folders reside on
Exchange. This setup has worked forever, except yesterday about half of our
users started noticing some wierd activity. They weren't able to send out
internet email. They would try and immediately get an undeliverable email
back. "No transport provider was available for delivery to this recipient."
Was the message in the email.

It sounds like you have the Outlook clients setup with the outgoing (smtp)
server set to something outside of the company, like maybe an ISP's mail
server?

Can you telnet to that IP address's port 25 from the affected machines?

How is the outside mail server resolving DNS for your internal machines?

When you say "weird activity" do you mean that only some of the outgoing
mail are undeliverable? Or do you mean that for some users outgoing mail is
completely, utterly non-functioning? Which is more in the realm of
"unexplained cessation of function" rather than "wierd activity."
 
M

Mike O.

This has to do with all of our email being stored on our exchange server
(internal & external) instead of a .pst file. Those users that are having
the problems can receive email just fine internally and from external
sources. They can send internal mail fine, just sending any piece of email
outside of the company comes back as undeliverable.
I tested this out on a test workstation with a new exchange mailbox (John
Doe) with an internet email account. So his and everyone elses internet
email points to our external ISP for mail. All his mail is configured to be
stored on the exchange server and not a .pst file, just like the rest of the
users. But trying to send out external email, it comes back undeliverable
with the message "No transport provider was available for delivery to this
recipient."
So when I created a mailbox on a recovery exchange server we have with his
same name, and sent out an external email, it sent fine with no
undeliverable message. This tells me that all of our Outlook clients, who
store all their External and Internal email on our production exchange
server, are somehow looking to exchange for resolution of these outside
email address we are sending to. Internet mail is not install on our
production server, and this configuration has worked for a long time, just
since yesterday this problem popped up.
 
M

Matt

Mike O. said:
This has to do with all of our email being stored on our exchange server
(internal & external) instead of a .pst file. Those users that are having
the problems can receive email just fine internally and from external
sources. They can send internal mail fine, just sending any piece of email
outside of the company comes back as undeliverable.
I tested this out on a test workstation with a new exchange mailbox (John
Doe) with an internet email account. So his and everyone elses internet
email points to our external ISP for mail. All his mail is configured to be
stored on the exchange server and not a .pst file, just like the rest of the
users. But trying to send out external email, it comes back undeliverable
with the message "No transport provider was available for delivery to this
So when I created a mailbox on a recovery exchange server we have with his
same name, and sent out an external email, it sent fine with no
undeliverable message. This tells me that all of our Outlook clients, who
store all their External and Internal email on our production exchange
server, are somehow looking to exchange for resolution of these outside
email address we are sending to. Internet mail is not install on our
production server, and this configuration has worked for a long time, just
since yesterday this problem popped up.

This may be unhelpful, but does the order of the accounts be making any
difference? Do you have the clients set up with two accounts one for
exchange and one for the ISP?

So if you setup one with:
Production exchange server
ISP server

which didn't work, but then you deleted the production server account and
added the recovery server:
ISP server
Recovery exchange server

So now the ISP gets checked first. Could that account for the problem? So
machines that check the exchange server first are being told that the email
cannot be sent. I don't know why that would suddenly cause a problem,
though. So that may be unlikely.

Have there been any automatic security updates installed or service packs
which might have changed default behaviors?

That may be my last idea. I am curious to know what the resolution to this
problem will be.
 
M

Matt

Mike O. said:
This has to do with all of our email being stored on our exchange server
(internal & external) instead of a .pst file. Those users that are having
the problems can receive email just fine internally and from external
sources. They can send internal mail fine, just sending any piece of email
outside of the company comes back as undeliverable.
I tested this out on a test workstation with a new exchange mailbox (John
Doe) with an internet email account. So his and everyone elses internet
email points to our external ISP for mail. All his mail is configured to be
stored on the exchange server and not a .pst file, just like the rest of the
users. But trying to send out external email, it comes back undeliverable
with the message "No transport provider was available for delivery to this
So when I created a mailbox on a recovery exchange server we have with his
same name, and sent out an external email, it sent fine with no
undeliverable message. This tells me that all of our Outlook clients, who
store all their External and Internal email on our production exchange
server, are somehow looking to exchange for resolution of these outside
email address we are sending to. Internet mail is not install on our
production server, and this configuration has worked for a long time, just
since yesterday this problem popped up.

You should probably try this post in microsoft.public.exchange.admin , too.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top