• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 335
  • Last Modified:

SBS 2003 Server won't send to Exchange 2003 Standalone with same domain name as one listed in the Recipient Policy

Good morning,

I have a very interesting connundrum. I have a single SBS2003 server behind a Zywall 5 and about 15 users.
We are running Exchange with this network.
Our domain locally is companyname.com
Our local live internet domain is companycity.com
Then, in the recipient policies,  we have setup the three domains that we send to.

We have the default policy set to companygroup.com, a external domain hosted in another city. Each user in the local city has to send email as this domain for compliance and simplicity purposes. So, users in Chicago for instance send emails out as user@companygroup.com. Users in another city are members of another domain but we added a recipient policy to allow all internal users to send as user@companygroup.com

The recipient policy is setup as follows:

Default Policy
@companygroup.com - default (Not responsible for this organization so the check box is unchecked inside the properties of this selection)
@companycity.com
@companyname.com

CompanyCity Policy
This is a second policy that is weighted higher.

This policy is at the top of the list while the default policy is at the bottom of the list.

@companygroup.com
@companycity.com - default (Responsible for sending mail to this organization) This domain is the domain that the local SBS server manages. Emails do not go out using this addressing.
@companyname.com

For a while, I was having issues where the mail.companyname.com domain was listing at the bottom of each of the emails that came back as NDR's to domains like comcast, aol, and others.
I checked in the SMTP Virtual Server Properties, then the advanced button and found that instead of companycity.com, companyname.com was being used. companyname.com is a LOCAL domain like I mentioned. It does not resolve DNS wise to any external one to one NAT'd address where as mail.companycity.com does. So, domains that do reverse lookups where failing those messages.

We altered the setting to be mail.companycity.com and that worked for that issue.

The email domain :companygroup.com is hosted on a Exchange 2003 server in Chicago.
It is 3rd party hosted exchange.
We added a recipient policy to our SBS Exchange box to allow users to send emails out as if they were sending from @companygroup.com just like the users on the hosted exchange solution. The problem is, when we send emails to these users from the @companycity.com domain, they come back with the following error:

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.companycity.com #5.1.1>


Does having a recipient policy set for @companygroup.com here in our office in a different city on a different server cause issues in this solution?
Do I need to enter a DNS entry for the mail.companygroup.com server in Chicago so that if the Exchange box can't do a directory look up for a user in the Chicago office locally it will forward mail there?


Basically, I need to be able to email people in our chicago office.


Since they host the companygroup.com domain, and I have companygroup.com as a recipient policy setting that has all outbound mail tagged with that domain, and it can't find them locally on the SBS server, it is failing when we try to send.

Any help would be appreciated!




0
PatrickDoman
Asked:
PatrickDoman
  • 4
  • 3
  • 2
2 Solutions
 
SembeeCommented:
What you are trying to do is share the SMTP name space.
This article goes through your options on how to share it.

http://support.microsoft.com/default.aspx?kbid=321721

The problem will be the other side. It depends on how much freedom the hosting company has allowed. If they can add the second domain name, then that makes deployment much easier.

The other option would be to use the send unknown recipients to server feature. However that would mean you cannot have anyone in the other office listed in the GAL, so no members of the distribution groups etc. When they are shown in the GAL that means the object is local and messages to that object would not be sent out.

Simon.
0
 
PatrickDomanAuthor Commented:
Where is this send unknown recipients to server feature? I saw a filter unknown recipients check box option...
0
 
SembeeCommented:
It is on the SMTP Virtual Server.

ESM, Servers, <your server>, Protocols, SMTP. Right click on the default SMTP VS and choose Properties. Click on the tab Messages. The box is at the bottom.

Simon.
0
Get free NFR key for Veeam Availability Suite 9.5

Veeam is happy to provide a free NFR license (1 year, 2 sockets) to all certified IT Pros. The license allows for the non-production use of Veeam Availability Suite v9.5 in your home lab, without any feature limitations. It works for both VMware and Hyper-V environments

 
Jeffrey Kane - TechSoEasyPrincipal ConsultantCommented:
Actually this problem can be resolved quite easily (even though your configuration is a nightmare) by adding a FQDN to your Exchange Configuration.  

In your Server Management Console, navigate to:
Advanced Management > First Organization (Exchange) > Servers > Servername > Protocols > SMTP > Default SMTP Virtual Server.  Right click that and select Properties.

Then select the MESSAGES TAB and at the very bottom you'll see "Forward all mail with unresolved recipients to host"
In this box enter mail.companygroup.com.

There's a good little overview about how this works if you click help on that particular window.

This is yet another reason that you should not use a .com for your local domain and instead use the recommended .local (or any other non-resolving TLD).

Jeff
TechSoEasy
0
 
PatrickDomanAuthor Commented:
This didn't fix it, I am only out here once a month and I hate to make these changes while remote. I altered the SMTP Virtual Server like you mentioned sending all email to mail.companygroup.com that can't be resolved... I then changed the default SMTP Recipient Policy to be the @companygroup.com because email needs to show that it went out as user@companygroup.com instead of user@companycity.com.

It just sits in the queue.
0
 
Jeffrey Kane - TechSoEasyPrincipal ConsultantCommented:
Well, I'm assuming that WHATEVER the actual FQDN of your mailserver in Chicago is, that's what you put for mail.companygroup.com.  If that can't be resolved, then it sounds to me as though you've created a DNS zone file for companygroup.com on your SBS, which is not necessary at all.

Normally, your SBS wouldn't care at all that another server is hosting email for the same domain name... it doens't know because it doesn't ask.  But since you have created an EMAIL domain space of companygroup.com it would first look for the recipient in Active Directory (because your DNS is AD integrated), and then would normally FAIL if it didn't find a match.  But if you put the FQDN of an outside server with the same domain name, then it will go out to the Internet to look for that host.

So, have you manually modified the standard SBS DNS structure?

Jeff
TechSoEasy
0
 
PatrickDomanAuthor Commented:
I added the entry to the SMTP virtual server under the messages tab as instructed. It just sat in the queue.

I then went back and created a zone for companygroup.com. I added a host record in there with the external IP address for mail.companygroup.com. It still wouldn't forward. That is about where the queued email NDR'd back to the person testing it for me.
0
 
Jeffrey Kane - TechSoEasyPrincipal ConsultantCommented:
Well, does mail.companygroup.com resolve over the Internet?  Can you look it up at www.mxtoolbox.com and see if it works?  If it just sat in the queue I would wonder why it didin't go out to look for it... that would be due to something locally that's prohibiting it, or that it just doesn't exist externally.  HOWEVER, your NDR stated that the email account didn't exist... not the domain.  So it was checking your OWN server for the account and never got outside.

With all that you've apparently configured manually it will be rather difficult from this perspective to sort it all out for you.  Since SBS's configuration is handled by the wizards you need to get your basic services operating that way first, and then incrementally make changes so you know what works and what doesn't.

I'll be happy to take a look at a couple of things though... if you can first post a complet IPCONFIG /ALL from the server that would be a good place to start.  While there is nothing in an IPCONFIG that would compromise security, you may want to slightly edit it for privacy purposes.  If you choose to do that, please only replace the last two octets of a Public IP Address with ***.*** and the first part of the domain name can be replaced with *******.

Jeff
TechSoEasy
0
 
PatrickDomanAuthor Commented:
Ok, I found the actual fix to this. We were very close.


I had a recipient policy for each @company.... option before we moved to this new server, however there is a better way to do it.


Go to the Recipient policy properties.
Only use the default and make sure there is no reference to the domain you are adding.

I have @companycity.com in there now.
I have @companyolddomain.com in there as well.
I removed @companygroup.com.


From there, when the entry is removed, it will leave the SMTP address in the Active Directory "Email Addresses" tab.

So I have user@companygroup.com in there as a email address, in this case I set it to be the default as that is the address we want to send as now.
I have user@companycity.com in there as well.
I have user@companyolddomain in there as well.


So, emails from all 3 domains will go to users that have them setup there.

Having the user@companygroup.com as the default allows this to work in that the mail message is coming from @companycity.com as the default recipient policy so emails will resolve IP wise from where they leave to the domain name here in the office. We're just simply masking the identify if you catch my drift. So, setting the default SMTP Email Address to user@companygroup.com allows Exchange to send the message as user@companygroup.com while still sending and being able to resolve the @companygroup.com because it doesn't get frustrated about trying to resolve @companygroup.com as it is not local.

So it was a mixture of the Microsoft Way and Tricking the server that resolved this but I do appreciate your help.
0

Featured Post

Fill in the form and get your FREE NFR key NOW!

Veeam is happy to provide a FREE NFR server license to certified engineers, trainers, and bloggers.  It allows for the non‑production use of Veeam Agent for Microsoft Windows. This license is valid for five workstations and two servers.

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