Outlook11 Fetching mail (POP) then destroying it -- serious problem

[///Matt]

One installation of Outlook (from Office11) has chosen to retrieve
mail from all configured accounts (6), and place it... nowhere. This
is a new behavior, exhibited on a three-month-old installation. The
result is that inbound messages are lost, and since the server did
it's job, the sender has no way of knowing the message was destroyed.
This is an alarming and expensive behavior. So far, Office11 hasn't
been a particularly buggy package, but quality seems to be making up
for quantity in that regard.

Things we have already tried:
* Deleting and recreating two test accounts -- their inbound mail was
still destroyed.
* Assuring the "deliver mail to" settings are correct (it would not
have surprised me to find an invalid Send To setting being honored
without generating an error).
* Using the installers "repair" function (not sure it did anything)
* Reviewing the mail server's logs, and even packet sniffing the POP
sessions to confirm the mail is being fetched and not eaten by the
server; this confirmed that the mail server is not the problem.
* Sending test messages, then searching the PST files for keywords
from them (using non-encrypted non-compressed PSTs of course) -- they
were not to be found. I don't know if it should, but the PST files
did not change size after test messages were eaten.
* Scanning all local hard drives at the sector level for phrases
embedded in test messages (write cache disabled) -- not fast on 0.5TB
drives -- offered no help.
* Disabling all but TCP/POP3 access off the machine, to assure the
messages weren't being saved to some network path.
* Assured there are no "macros" at all, let alone any which would
divert incoming mail (at least the UI says there aren't any, and I
know of no other way to check).

Complete removal and reinstallation of Outlook would be a last resort,
because A) it's inability to isolate and save it's settings makes
setting up this installation a multi-hour process, and B) the registry
settings are never properly cleared, and doing so manually usually
throws the rest of Office into a tizzy (a true reinstallation of
Office requires formatting the disk and rebuilding this workstation,
which is 20+ hours work -- [developer's station - hundreds of aps,
thousands of settings, etc.]).

Any ideas? Has anyone seen this new 'toss mail into a black hole'
behavior before (perhaps it's only new to us)? Assuming the prior
will be "no" and "no", does anyone have any ideas for sniffing it out?
You can imagine what kind of trouble this bug is causing -- losing
client mail is "not good". We're duplicating mail at the server as a
(hopefully) temporary workaround; it's a real nightmare. May go to
IMAP temporarily, but would rather it just worked.

Is there a debug log we can turn on? Only useful if it logs events in
such a way as to be comprehensible by someone without the source code
to Outlook.

Thanks for any help or ideas,
-///Matt

 

[neo [mvp outlook]]

The only time I have seen Outlook (any version) toss mail into the
proverbial black hole is when Outlook couldn't figure out what the default
delivery location is. What I would try is creating a new profile via the
mail applet in the control panel (don't copy the existing one) and delete
the old one. When creating this new mail profile, create a new PST while
you are at it. At the very least, you can run the Inbox Repair Tool
(scanpst.exe) against the old one to rule out minor corruption.

Outside of that, do you have any type of 3rd party applications/addins or
internet security products that can scan e-mail in real-time? If so,
consider disabling while troubleshooting. This will really help isolate if
it is an Outlook 2003 thing or something external to Outlook that is
influencing the behavior.

One installation of Outlook (from Office11) has chosen to retrieve
mail from all configured accounts (6), and place it... nowhere. This
is a new behavior, exhibited on a three-month-old installation. The
result is that inbound messages are lost, and since the server did
it's job, the sender has no way of knowing the message was destroyed.
This is an alarming and expensive behavior. So far, Office11 hasn't
been a particularly buggy package, but quality seems to be making up
for quantity in that regard.

Things we have already tried:
* Deleting and recreating two test accounts -- their inbound mail was
still destroyed.
* Assuring the "deliver mail to" settings are correct (it would not
have surprised me to find an invalid Send To setting being honored
without generating an error).
* Using the installers "repair" function (not sure it did anything)
* Reviewing the mail server's logs, and even packet sniffing the POP
sessions to confirm the mail is being fetched and not eaten by the
server; this confirmed that the mail server is not the problem.
* Sending test messages, then searching the PST files for keywords
from them (using non-encrypted non-compressed PSTs of course) -- they
were not to be found. I don't know if it should, but the PST files
did not change size after test messages were eaten.
* Scanning all local hard drives at the sector level for phrases
embedded in test messages (write cache disabled) -- not fast on 0.5TB
drives -- offered no help.
* Disabling all but TCP/POP3 access off the machine, to assure the
messages weren't being saved to some network path.
* Assured there are no "macros" at all, let alone any which would
divert incoming mail (at least the UI says there aren't any, and I
know of no other way to check).

Complete removal and reinstallation of Outlook would be a last resort,
because A) it's inability to isolate and save it's settings makes
setting up this installation a multi-hour process, and B) the registry
settings are never properly cleared, and doing so manually usually
throws the rest of Office into a tizzy (a true reinstallation of
Office requires formatting the disk and rebuilding this workstation,
which is 20+ hours work -- [developer's station - hundreds of aps,
thousands of settings, etc.]).

Any ideas? Has anyone seen this new 'toss mail into a black hole'
behavior before (perhaps it's only new to us)? Assuming the prior
will be "no" and "no", does anyone have any ideas for sniffing it out?
You can imagine what kind of trouble this bug is causing -- losing
client mail is "not good". We're duplicating mail at the server as a
(hopefully) temporary workaround; it's a real nightmare. May go to
IMAP temporarily, but would rather it just worked.

Is there a debug log we can turn on? Only useful if it logs events in
such a way as to be comprehensible by someone without the source code
to Outlook.

Thanks for any help or ideas,
-///Matt

 

[///Matt]

A solid workaround - creating a from-scratch 'delivery profile' did
the trick. Now we'll pour through the server logs to see which mail
was tossed into the singularity.

Microsoft: Feature request: Check for this condition (e.g. generate
error if delivery PST cannot be resolved; generate warning if delivery
PST is not currently open). That's a very dangerous bug, and worth of
a few lines of 'checkup code.

Thanks,
-///Matt

The only time I have seen Outlook (any version) toss mail into the
proverbial black hole is when Outlook couldn't figure out what the
default delivery location is. What I would try is creating a new
profile via the mail applet in the control panel (don't copy the
existing one) and delete the old one. When creating this new mail
profile, create a new PST while you are at it. At the very least,
you can run the Inbox Repair Tool (scanpst.exe) against the old one
to rule out minor corruption.

Outside of that, do you have any type of 3rd party
applications/addins or internet security products that can scan
e-mail in real-time? If so, consider disabling while
troubleshooting. This will really help isolate if it is an Outlook
2003 thing or something external to Outlook that is influencing the
behavior.

One installation of Outlook (from Office11) has chosen to retrieve
mail from all configured accounts (6), and place it... nowhere.
This
is a new behavior, exhibited on a three-month-old installation.
The
result is that inbound messages are lost, and since the server did
it's job, the sender has no way of knowing the message was
destroyed.
This is an alarming and expensive behavior. So far, Office11
hasn't
been a particularly buggy package, but quality seems to be making
up
for quantity in that regard.

Things we have already tried:
* Deleting and recreating two test accounts -- their inbound mail
was
still destroyed.
* Assuring the "deliver mail to" settings are correct (it would not
have surprised me to find an invalid Send To setting being honored
without generating an error).
* Using the installers "repair" function (not sure it did anything)
* Reviewing the mail server's logs, and even packet sniffing the
POP
sessions to confirm the mail is being fetched and not eaten by the
server; this confirmed that the mail server is not the problem.
* Sending test messages, then searching the PST files for keywords
from them (using non-encrypted non-compressed PSTs of course) --
they
were not to be found. I don't know if it should, but the PST files
did not change size after test messages were eaten.
* Scanning all local hard drives at the sector level for phrases
embedded in test messages (write cache disabled) -- not fast on
0.5TB
drives -- offered no help.
* Disabling all but TCP/POP3 access off the machine, to assure the
messages weren't being saved to some network path.
* Assured there are no "macros" at all, let alone any which would
divert incoming mail (at least the UI says there aren't any, and I
know of no other way to check).

Complete removal and reinstallation of Outlook would be a last
resort,
because A) it's inability to isolate and save it's settings makes
setting up this installation a multi-hour process, and B) the
registry
settings are never properly cleared, and doing so manually usually
throws the rest of Office into a tizzy (a true reinstallation of
Office requires formatting the disk and rebuilding this
workstation,
which is 20+ hours work -- [developer's station - hundreds of aps,
thousands of settings, etc.]).

Any ideas? Has anyone seen this new 'toss mail into a black hole'
behavior before (perhaps it's only new to us)? Assuming the prior
will be "no" and "no", does anyone have any ideas for sniffing it
out?
You can imagine what kind of trouble this bug is causing -- losing
client mail is "not good". We're duplicating mail at the server
as a
(hopefully) temporary workaround; it's a real nightmare. May go to
IMAP temporarily, but would rather it just worked.

Is there a debug log we can turn on? Only useful if it logs events
in
such a way as to be comprehensible by someone without the source
code
to Outlook.

Thanks for any help or ideas,
-///Matt