Outlook won't connect if no default gateway on NIC

Outlook won't connect to the Exchange server if you don't have a default gateway on your network card. Why would you have this problem? I didn't have a default gateway because I was temporarily using the PC as dual homed (two network cards). I wanted the default gateway to be set on one card and not the other. Then I repurposed the machine without checking and using the NIC that didn't have the gateway. Outlook balked, and I panicked a slight bit. How is it possible that I have every network (Internet, files, database, etc.) and no Exchange connectivity? Especially since my other box is chugging away perfectly on Exchange. Exchange error messages actually said this, and sure enough, it was correct.

Phantom Recipient in Outlook Meeting Request

A user emailed me that she was sending a meeting request to another user via Outlook but it bounced because it was also being sent to a user who was no longer in our system.

It turned out that the recipient's Outlook client Tools, Options, Delegates still had that old user listed, which was then removed.

Microsoft Outlook won't connect to Exchange Server

I was troubleshooting an issue where the Outlook client wouldn't connect to Exchange Server. It wasn't a ping issue (I could ping the server) and it wasn't domain resolution. I also could view the one user's Outlook Web Access Account. It simply wouldn't connect Outlook to Exchange, either hanging on profile creation, or giving an error on connect.

To fix this, I went to c:\documents and settings\username\local settings\application data\microsoft\outlook and added a new folder "old" and moved the stuff in outlook folder to "old" and tried again. This apparently cleaned itself up.

ASSP - forwarding spam adds to whitelist

I have a specific issue where CompanyA.com split off with SubCompanyA.com and in the process, SubCompanyA.com's users still wanted to forever be reached by their old @CompanyA.com email address. Inside Exchange, I added quite a few Contact efwd emails which worked quite nicely. I have another post ... somewhere about using the exchange-to-csv export and import to help automate this process.

In any case, I noticed a LOT of spam that was resulting from whitelisted email addresses from spammers. It appears that my spam filter, ASSP, figured that all email coming from my Exchange Server is whitelisted mail, no matter how I tried to redlist the domains or users or anything. Why did my Exchange Server whitelist spam?

It turns out that the Exchange Server Contacts forwarded out through my spam filter to SubCompanyA.com. The question comes: how to avoid using my spam filter for SubCompanyA.com bounces? (of course, the other question is why the spam filter isn't kicking these out in the first place, but that's likely because of the whitelist=valid email issue. OK, it's circular reasoning, but let's stop the whitelisting)

This site Configuring and Using an SMTP Connector shows how to add an SMTP connector for problem domains. Ah! a solution! I set one up for the new SMTP server (actually the new SMTP server's spam front end) and now @CompanyA.com's forwardings to SubCompanyA.com's email addresses never touch (read: don't add to the whitelist of) my spam filter. This may cost my Bayesian filter to stop understanding valid emails between CompanyA.com and SubCompanyA.com, but then again, whitelisting between the two companies should already have occurred and the further CompanyA.com/SubCompanyA.com whitelisting is trivial.

Edited to add: Well, maybe not trivial, per se. After realizing what will happen (whitelist expiration of emails@SubCompanyA.com after 90 days), SubCompanyA.com's inbound emails will possibly need to be vetted each inbound time. Well... at least I can noprocess SubCompanyA.com inbound from the spam filter, so that seems to fix that.

Exchange 2003 Outlook Mobile Access 1801 error

OK, There is absolutely almost no answer on the web for the MSExchangeOMA 1801 error. That’s because stock users of Exchange and IIS won’t have the issue that I had.

The very short answer: WebDav defaults to checking for stuff via IIS http on port 80.

If your IIS has another HTTP (not SSL/HTTPS) port as all it’s listening on, OMA/Outlook Mobile Access will not work. Make sure port 80 is listened to by IIS.

Why I had Internet Information Server on another port:

It was a legacy issue. I had OWA/Outlook Web Access through a firewall on a non-standard port. OWA does NOT like firewall port not matching IIS port. So HTTP port on IIS was chosen to match the firewall port for IIS for NON-SSL traffic. Later, I didn’t need non-SSL traffic for OWA and didn’t bother to change the IIS port. When OMA came up with

Unable to connect to your mailbox on server Servername. Please try again later. If the problem persists contact your administrator.

It was because it was attempting to contact internally via WebDAV on WebDAV’s default connection: http://Servername:80/Exchange/mailbox

the :80 (hidden, but the default port for web) was not accessible because my default http port on IIS wasn’t listening on port 80. This caused the same error from outside my firewall all the way to trying the OMA connection at localhost on my exchange server.

Thanks to
http://www.petri.co.il/configure_oma.htm
http://www.petri.co.il/configure_ssl_on_oma.htm
http://www.petri.co.il/test_oma_in_exchange_2003.htm

for knocking me in the head about things I didn’t realize I hadn’t done.