Recently, my company implemented a new Exchange 2007 server for our email. No special changes or accommodations were made to support OS X. After a bit of searching and trial and error, I figured out the settings for Entourage to work when connected to the corporate network: email, contacts, and calendar all work.

I started with version 11.3.6 (070618) of Entourage, and added a new Exchange email account. I then tried the automatic setup, but it failed so I went into manual mode. During the setup, i found two fields that require surprising entries:
Under the Account Settings tab, the Exchange Server field. Here is what works for me:
https://my.internal.owa.server.name/exchange/username@domain.com

Be sure to use /exchange/ rather than some other directory, and include your full email address afterwards. This was surprising because to connect with Safari, the URI is:

https://my.internal.owa.server.name/owa/

On the Advanced tab, for the Public folders server, I use this URI:
https://my.internal.owa.server.name/public/username@domain.com

Once again, use /public/ not some other directory.
Evidently /exchange/and /public/ are virtual folders that Exchange 2007 creates for backward compatibility. The data for the rest of the fields was as expected.

by Daniel Petri – January 7, 2009

Exchange 2007 will only accept e-mail traffic for the e-mail domain that is identical to the name of your Active Directory domain. However, in some cases, we would like to allow our Exchange server to also receive e-mail for domains other than our own, internal domain name. On my “Configure Exchange 2000/2003 to Receive E-Mail for other Domains” article. I have explained how to configure previous versions of Exchange to receive e-mail for domains other than the ones configures as their internal Active Directory domain. In Exchange 2007 things are a bit more complex since it does not natively accept ANY sort of incoming mail from the external world, therefore we need to go through some more steps to get things rolling.

Daniel Petri’s Exchange Server RecommendationsThere are several new features included within Exchange Server 2007, which some of my articles touch on briefly. However, if you are looking for training that takes you from installation to integration with Outlook and management of Exchange Server 2007 then you need Train Signal’s training videos. The Exchange Server 2007 training videos are taught by Microsoft MVP and MCSE, David Shackelford, who teaches with a “Hands-on” approach.

Daniel Petri

You can see the Exchange Server 2007 training with video instruction here.

For example, if you have an AD domain called PETRI.LOCAL and you’ve installed Exchange 2007 on it, each recipient you have will automatically have an e-mail address of ALIAS@PETRI.LOCAL, and the Exchange organization will treat the PETRI.LOCAL SMTP domain name as an internal domain. To follow on the example, let’s say that one day you’ve decided that you’d like to have an Internet presence, so you bought PETRI.CO.IL and you’d like to begin using it on your Exchange server. Luckily, you don’t need to rename your AD domain for that, but you DO need to configure Exchange to receive e-mail for the new domain, along with any traffic you might have had for the old domain name.

This example can also be extended to instances where a company has had its Internet domain name changed, or when one Exchange server is used to host mailboxes for more than one company.

In Exchange 2007, in order to allow your Exchange servers to treat any other SMTP domain as internal, you need to configure an Accepted Domain entry for that SMTP domain name.

What are Accepted Domains

An accepted domain is any SMTP domain name for which the Exchange organization sends or receives e-mail. Accepted domains include those domains for which the Exchange organization is authoritative. An Exchange organization is authoritative when it handles mail delivery for recipients in the accepted domain. BTW, accepted domains also include domains for which the Exchange organization receives mail and then relays to an e-mail server that is outside the Active Directory forest for delivery to the recipient.

You must configure an accepted domain before that SMTP namespace can be used in an e-mail address policy. The accepted domain is automatically populated to the e-mail address policy editor. Each domain or sub-domain that you want to use as part of an e-mail address policy must have an explicit accepted domain entry. To read more about E-mail address policies please look at my “Configure Specific E-Mail Addresses for Specific Exchange 2007 Recipients” article.

Types of Accepted Domains

There are three types of accepted domains: authoritative, internal relay, and external relay.

• Authoritative Domains – As noted in the example above, an organization might have more than one SMTP domain. These are the authoritative domains. In Exchange 2007, an accepted domain is considered authoritative when the Exchange organization hosts mailboxes for recipients in this SMTP domain. Meaning, Exchange 2007 will treat any incoming mail destined for a recipient on an authoritative domain as internal, and will “expect” to find a recipient with that SMTP address. If no such recipient exists, Exchange will return an NDR. By default, when the first Hub Transport server role is installed, one accepted domain is configured as authoritative for the Exchange organization. The default accepted domain is the fully qualified domain name (FQDN) for your forest root domain. The Edge Transport servers should always accept e-mail that is addressed to any of the organization’s authoritative domains, and by default, no accepted domains are configured on the Edge Transport server role.

When dealing with e-mail destined for external SMTP domain names, we must configure the Exchange servers to “know” that they should accept incoming e-mail for these external domains, and perform a relay action on them. Needless to say, if we allow relaying of ALL external SMTP domains, spammers will soon find this out and begin using our servers as open relays, spamming the world through our servers. We can prevent this open relay by rejecting all e-mail that is not addressed to a recipient in the organization’s authoritative domains. However, there are scenarios where an organization wants to let partners or subsidiaries relay e-mail through the Exchange servers. You can allow this by configuring accepted domains as relay domains. The Exchange organization receives the e-mail and then relays the messages to another e-mail server.

There are 2 options for configuring external domains: Either as an internal relay domain or as an external relay domain.

• Internal Relay Domain – When configuring an internal relay domain, the recipients in this domain do not have mailboxes in this Exchange organization but do have contacts in the global address list (GAL). Mail from the Internet is relayed for this domain through Hub Transport servers in this Exchange organization. In this scenario, the MX resource record for the external relay domain references a public IP address the Exchange 2007 organization that is relaying messages. The Edge Transport server receives the messages for recipients in the external relay domain and then looks for contacts in the GAL for those recipients. If it finds such a recipient, it will route the message to the e-mail system for the internal relay domain. The connector configuration of your organization determines how messages are routed. To read more about that please read my “Configure MX Records for Incoming SMTP E-Mail Traffic” article.
• External Relay Domain – When you configure an external relay domain, messages are relayed to an e-mail server that is outside the Exchange organization and outside the organization’s network perimeter. The messages are relayed by the Edge Transport server. In this scenario, the MX resource record for the external relay domain references a public IP address the Exchange 2007 organization that is relaying messages. The Edge Transport server receives the messages for recipients in the external relay domain and then routes the messages to the e-mail system for the external relay domain. A Send connector from the Edge Transport server to the external relay domain is required in this scenario.

Working with Sub-domains

When you create an accepted domain, you can use a wildcard character in the address space to indicate that all sub-domains of the SMTP address space are also accepted by the Exchange organization. For example, to configure PETRI.CO.IL and all its sub-domains as accepted domains, you will need to enter *.PETRI.CO.IL as the SMTP address space.

Where to configure Accepted Domains

Accepted domains are configured on the Organization level, on Exchange servers that have the Hub Transport server role installed, or on servers that have the Edge Transport server role installed on them. When working with Edge servers, the best approach towards Accepted Domains would be to configure them only on the Hub Transport server role, and then populate that data on the Edge Transport server by using the Edge Subscription process. When the Edge Subscription process runs, the accepted domain configuration information is replicated to the subscribed Edge Transport server.

Note: To configure Accepted Domains you use must be delegated the with an Exchange Organization Administrator role. To perform the task on servers that have the Edge Transport server role installed, you must log on by using an account that is a member of the local Administrators group on that computer.

Creating Accepted Domains

As always, you can do this in one of two ways:

Using Exchange Management Console (EMC):

1. 1. Open the Exchange Management Console. Perform one of the following steps:
   • On an Edge Transport server: Select Edge Transport, and then in the work pane, click the Accepted Domains tab.
   • On a Hub Transport server: Expand Organization Configuration, select Hub Transport, and then in the work pane, click the Accepted Domains tab.
2. In the action pane, click New Accepted Domain. The New Accepted Domain wizard appears.
3. On the New Accepted Domain page, enter the name of the new accepted domain. Use this field to identify the accepted domain in the user interface. You can type any name that you want, but you should select a meaningful name that helps you easily identify the purpose of this accepted domain.
4. Next, enter the Accepted Domain itself. Use this field to identify the SMTP domain name for which the Exchange organization will accept e-mail messages. You can use a wildcard character to accept messages for a domain and all its sub-domains.
5. Next, select one of the following options to set the accepted domain type:
6. Authoritative Domain, Internal Relay Domain, or External Relay Domain.
7. Click New then on the Completion page, click Finish.

Using Exchange Management Shell (PowerShell prompt):

Open the Exchange Management Shell prompt, then type:

New-AcceptedDomain -Name "Petri.co.il" -DomainName petri.co.il -DomainType Authoritative

To create an internal relay domain type:

New-AcceptedDomain -Name "Dpetri.net" -DomainName dpetri.net -DomainType InternalRelay

To create an external relay domain type:

New-AcceptedDomain -Name "Message-Pro.com" -DomainName message-pro.com -DomainType ExternalRelay

Changing the Default Accepted Domain

You cannot modify the default accepted domain. To change which accepted domain is the default accepted domain, you must create a new accepted domain, and then set the new accepted domain as the default by using the Exchange Management Shell.

If you try to remove the default accepted domain from the list without configuring a different default accepted domain you will get an error:

In order to find out which of the accepted domains is the default one, you MUST use the Management Shell (PowerShell prompt) and run the following command:

Get-AcceptedDomain

For example, in case you would like to totally remove the PETRI.LOCAL domain from the list of accepted domains, you will first need to create the PETRI.CO.IL accepted domain (see above example), then run the following command in the PowerShell prompt:

Set-AcceptedDomain -Identity petri.co.il -MakeDefault:$true

Deleting an Accepted Domain

Next, if you want to, you need to delete the old accepted domain from the list of accepted domains:

Using Exchange Management Console (EMC):

1. Open the Exchange Management Console. Perform one of the following steps:
   • On an Edge Transport server: Select Edge Transport, and then in the work pane, click the Accepted Domains tab.
   • On a Hub Transport server: Expand Organization Configuration, select Hub Transport, and then in the work pane, click the Accepted Domains tab.
2. Click on the accepted domain you wish to remove. In the action pane, click Remove.
3. Click Yes on the prompt.

Using Exchange Management Shell (PowerShell prompt):

Open the Exchange Management Shell prompt, then type:

Remove-AcceptedDomain –Identity petri.local

Summary

Accepted Domains are Exchange 2007’s implementation of Recipient Policies meaning they allow the Exchange organization to “know” which SMTP domains should be accepted by the Exchange servers (either the Edge Transport role holders, or the Hub role holders), and what they should do with them after receiving them. We need to create additional accepted domains in order to allow usage of additional SMTP domain names that we own and want to use in addition the the defauld accepted domain.

Related Articles

Instalación básica de Exchange 2007.

Exchange 2007 es la nueva versión del servidor de correo de Microsoft, aunque en realidad Exchange es mucho mas que un servidor de correo.

* El servidor tiene que tener el IIS funcionando pero no el SMTP ni el NNTP.

Bien, ya tenemos Exchange instalado, el siguiente paso será crear el primer buzón de correo.

El paso siguiente sera indicarle a Exchange que acepte correo del domino publico que tengamos.

Por defecto Exchange 2007 aceptaría correo del dominio DNS del AD a través de un servidor de Exchange con el rol de Edge.

En esta instalación no tendremos un servidor Edge y nuestro domino interno no es igual que el externo, asi que hay que realizar algunos cambios.

Añadimos el dominio:

Nos conectamos por telnet y lo probamos:

Ops, no nos deja, el servidor que estamos usando no es un Edge, nos estamos conectando al SMTP del rol de Hub Transport, este rol esta preparado para que otros servidores de nuestra organización se conecten para enviar correo, por lo tanto exige que estos servidores se validen.

Tendremos que modificar el conector de recepción de correo para que acepte validación anonima.

Para hacer esto correremos otro script de powershell.

set-ReceiveConnector -identity "Default w2k3srv" -PermissionGroups AnonymousUsers

Y probamos de nuevo

Y con el domino externo también