Member Avatar for troverman

We run Exchange 2003 as a virtual server using Hyper-V. Recently accidentally formated the drive on the host server containing the virtual servers, including this exchange server. Recovered using backup, and everything is fine, except some users are not getting any incoming e-mail. No internal mail or external mail. Cannot see the mail when logging in through OWA either. However, the affected users CAN send e-mail to anyone. In our total organization, I would say 80% of all users are totally fine with e-mail function, while the other 20% can only send but not recieve. It is not the Outlook clients. Any ideas?

  • 2 Contributors
  • 1 Reply
  • 307 Views
  • 3 Months Discussion Span
  • Latest Post Latest Post by Neil_1

Dani AI

Generated

Given the host-level restore noted by and 's NAT/telnet suggestion, focus the troubleshooting on three places: (1) whether SMTP is accepting mail at the perimeter or on the Exchange server, (2) what Exchange's message tracking and queues record after acceptance, and (3) how AD user objects are mapped to mailbox stores. Restores often leave recipient attributes out of sync (duplicate proxyAddresses, disconnected/orphaned mailboxes, or mailbox GUID mismatches), which explains why affected accounts can send but show no incoming messages in OWA.

Verify SMTP acceptance with a manual session to both the public MX and to Exchange itself. Example telnet sequence:

telnet mail.example.com 25
EHLO test.example.com
MAIL FROM:<tester@example.net>
RCPT TO:<affected@yourdomain.com>
DATA
Subject: test
This is a test
.
QUIT
  • If RCPT is rejected (550 / 5.1.1) the rejection is happening at the SMTP layer (perimeter or Exchange recipient filtering).
  • If RCPT is accepted but mail never appears in OWA, Exchange accepted the message but delivery to the mailbox failed or routed elsewhere.

Use Exchange System Manager -> Toolbox -> Message Tracking Center to search for the test message and real inbound mail. Look for RECEIVE -> ROUTE -> DELIVER events and note the target mailbox GUID/homeMDB in the DELIVER entry. Inspect SMTP/transport queues and Application/System event logs (MSExchangeIS, MSExchangeMTA/Transport) for related errors.

Finally, inspect AD attributes for affected users (Advanced view in ADUC or ADSIEdit): check E-mail Addresses (proxyAddresses), homeMDB, legacyExchangeDN and msExchMailboxGuid. Common fixes after a restore: remove duplicate proxyAddresses or contacts with the same SMTP address, reconnect an orphaned mailbox to the correct AD user, or remove unintended forwarding. Proceed cautiously: document current attributes and ensure AD replication is healthy before making changes, and reconnect mailboxes only after confirming mailbox GUIDs and store locations match.

Member Avatar for Neil_1

Has the Exchange server kept the same IP? If your firewall is routing SMTP mail from the internet, check any NAT rules.

Easy way to test is to telnet your MX record on port 25 and see if exchange responds.

I've seen some ISPs spam filter mail which can explain why some users can recieve and some can't, so best way to test is to send SMTP mails using Outlook Express or Telnet etc right into your Exchange public facing IP.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.