[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 431
  • Last Modified:

Exchange Server 2003 - Removing second E-mail Domain

We have a Client wth the following conditions:

Three (3) Servers, all Wndows Server 2003 Enterprise.
Server A: PDC and GC
Server B: BDC, GC and Exchange 2003 Ent.
Server B: ERP and SQL

Recently, a consultant performed the following, in this exact order:
Installed Exchange 2003 Ent on Server A in preparation of decommissioning Server B entirely.
Demoted Server B, leaving Exchange intact.
Replicated "some" objects, but others apparently displayed as "local modified" on for Server A.
Moved all the mailboxes and Public folders (only had two), then closed down Server B. They did a few internal testing, and were satisfied. They then uninstalled Exchange 2003 from Server B and pulled the plug.
Problem:
At one point in time, Server B hosted mail for two Domains: Domain A and Domain B. Domain B was purchased by an outside Company, and references on Server B were removed. They did have problems sending to recipients at Domain B for some time, but apparently got that corrected. Now, with only Server A running Exchange, they are again having problems sending to Users at Domain B. The error is as follows:


      real.user@DomainB.com on 10/24/2011 1:23 PM
            The e-mail account does not exist at the organization this message was sent to.  Check the e-mail address, or contact the recipient directly to find out the correct address.
            <mail.DomainA.com #5.1.1>

As you can see, Server A is trying to locate the recipient that "use" to reside in this organization, but fails. The Recipient list looks ok, and the Domain only hosts mail for Domain A. Domain B is no longer there. However, we do "see" references in various public folder locations for Domain B. How do we remove those, get mail working again through to Domain B and clean up this mess in Exchange?

0
TPAMisfit
Asked:
TPAMisfit
  • 2
1 Solution
 
wolfcamelCommented:
typically you need to rebuild the address books - on the server - and make sure they have been updated on the client.
this can happen - even without the complications of the server move.

for testing I prefer to use OWA, as this eliminates issues with my local address book not being updated. when OWA works then I move to the workstations.
0
 
Praveen BalanSolution ArchitectCommented:
From your explanation, it looks like you have the Domain B hosted somewhere outside. If that the case, try creating an SMTP connector explicitly for domainB.com and use external DNS to deliver the email. Ensure that the new server(Server A) is part of source server list.

Also ensure that you Exchange Org is not responsible for email delivery of DomainB.com.

Under Recipients -> Recipient Policies -> properties of Default Policy(your email policy). check if the domainb.com is there, then disable it and remove the authority for domainb and test the mail-flow.

Also search in your AD for domainb.com address, as you said it was working before AD should be fine.

Keep a track of all changes you make, for an easy roll back..

-Praveen
0
 
TPAMisfitAuthor Commented:
There do not appear to be any references to Domain B anywhere in the organization - not even for any deleted mailboxes, Recipient Policies, etc. But that is certainly how the system is responding to mail being sent to Domain B. It is as if it is looking "somewhere" and thnking it should be authoritative.

Not sure how to rebuild the OAB using OWA. I can use OWA on the Server and use the "To" button and have it locate Users in the GAL. The GAL does not have any Users with an address from Domain B.
Perplexing.

0
 
TPAMisfitAuthor Commented:
The E-mail Address tab was inexplicably "missing" in the Recipient Policy settings. Once we re-enable those pages, the reference to Domain B was located. Thanks a TON for the help.
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now