Vous êtes sur la page 1sur 6

Plan, Install, Configure and

Manage Transport:

Design a Transport Solution


Design a transport solution
This objective may include but is
not limited to:
Design inter-site mail flow
Design inter-org mail flow
Plan for Domain Secure/TLS
Design Edge transport
Design message hygiene solutions
Design shared namespace solutions
Company: Replace-A-Toy
Emergent toy company based in Rhode Island
They make toys, try to find lost toys and
remake lost toys if necessary

Problem:
They want to transition to Exchange 2013
from 2010 and are concerned about mail flow
issues
Need to design Exchange to allow for mail flow
transport as the company expands to multiple
sites and establishes partnerships

Goal:
Review important transport solution features
that are essential when designing and
deploying Exchange 2013
Scenario: Replace a Toy
The Exchange 2013 Transport Pipeline
Front End Transport Service Exchange
Server
Exchange
Server
Client Access Server
Mailbox Server
Transport Service
Mailbox Transport Service
Mailbox
Transport
Submission
Service
Mailbox
Transport
Delivery
Service
Categorizer
Mailbox
Database
All routing destinations have one or more servers
(Hub Transport for 2010 or Mailbox Server for
2013) that handle delivering messages to that
destination

The type of server (Hub or Mailbox) depends on
the server holding the mailbox database
Note, if the destination is not a database but a connector or expansion
server that delivery group may include a mixture of both (keeping in
mind this is assuming you have a mixed environment to start with)
Routing Destinations
There are different types of delivery groups:
Routable DAG
Mail Delivery Group
Connector Source Servers
AD Site
Server List

The big question: How are messages routed
between delivery groups (inter-site) and between
organizations (inter-org)?
Delivery Group Types
Routing a message is based on least-cost routing
through IP site links
Note: This is not different from Exchange 2010

By default, all AD forests start with a single AD
site (called Default-First-Site-Name) that is
associated with one or more subnets
You create additional sites by establishing additional subnets and
assigning them to the new sites
Servers get assigned a site based on IP address
Exchange is a site aware application, so they use AD topology for
message routing
Message Routing
Active Directory Site Links 101
Site links are logical paths between AD sites
Costs are assigned based on network reliability, speed and bandwidth
availability (default cost is 100)
Site links are transitive (ie. A communicates with B communicates with
C and this creates a connection between A and C)
By default, Exchange uses site links to determine least-cost path but not
if two sites are directly connected (unless a hub site is configured)



IP Site Links
Site B
Site A
Site D
Site C
Site links are usually good enough and the
topology is efficient
If you need to make a change for Exchange (not necessarily the entire
Active Directory environment) you can use the Set-ADSiteLink cmdlet
to assign Exchange-specific costs
Note: You can also establish a maximum message size on an AD link



Exchange-Specific Costs
Site B
Site A
Site D
Site C
AD Cost = 30 AD Cost = 30
AD Cost = 10 AD Cost = 10
AD Cost = 10
Exchange Cost = 100
Sometimes you may want to force mail to flow a
certain way within your organization
You can manipulate Exchange costs or you can force mail to go through
specific sites by designating them hub sites
You use the Set-ADSite cmdlet to set a hub site
Hub Sites
Site B
Site A
Hub Site
Site D
Site C Site B
Site A
Hub Site
Site D
Site C
10
10
10
5
5 10
5
5
You can send mail out to the Internet and let it
find its way to a destination organization
Easy enough with a Send connector pointing off to a smart host or
using DNS records to locate receiving messaging servers (for direct
recipient outbound mail flow)

Sometimes you want to connect to another
organization for mail flow (perhaps because you
have a partner you wish to email through a more
secure channel)
This is accomplished through Connectors (typically Send and Receive)
Inter-Org Mail Flow
You can configure partnership connectors that
ensure communication is encrypted and secure
between you and your trusted partner

The connector will only accepts connections with
servers that use Transport Layer Security (TLS) to
authenticate
Secure Receive Connectors for Partners
Currently (at this time) there is no Exchange 2013
Edge Transport server role

However, you can continue to use (or install)
Exchange 2007 or 2010 Edge Transport servers
that are deployed

You subscribe the Edge to the Mailbox server role
with Exchange 2013

Note: You dont necessarily NEED Edge Transport
Edge Transport Considerations
Anti-spam is built-in to Exchange 2013
The Mailbox role has anti-spam agents that you can enable in much the
same way you enabled them in 2010
With 2010 the anti-spam agents could be configured using the GUI
console (EMC) but with 2013 you have to use PowerShell cmdlets

Anti-malware is also built-in to Exchange 2013
The features are not super robust but this is new to Exchange
Message Hygiene Design
Reasons to share an email domain
Two companies merge but maintain separate systems
Non-Exchange systems are involved in the email environment

Example: DomainA and DomainB merge with the
new email alias finalized to DomainC.com

To share a namespace you have to have it
configured as an authoritative domain your
accepted domains list
You are going to change the domain type to Internal Relay
You are going to create a Send connector to tell Exchange where to
send the emails that do not have a local recipient
Shared Namespace Solutions
Planning in this case comes down to a list of
questions that need to be answered:
Where will the additional sites planned be?
What kind of connectivity will those sites have?
Do the partnerships being planned require added security for transport
between persons within the company?
They currently use Edge Transport server with 2010. Will those be
continued with 2013? Would a hosted solution be better?
Are the built-in message hygiene options sufficient or should we start
looking at 3
rd
party options?
Are there plans to merge with other companies and if so, what kind of
namespace planning is needed?



Scenario: Planning Suggestions
Additional Research (TechNet)
Mail Routing
http://technet.microsoft.com/en-us/library/aa998825(v=exchg.150).aspx

Understanding Message Routing (Exchange 2010)
http://technet.microsoft.com/en-us/library/aa998825(v=exchg.141).aspx

Use an Edge Transport Server in Exchange 2013
http://technet.microsoft.com/en-us/library/jj150569(v=exchg.150).aspx

Exchange 2013 Client Access Server Role
http://blogs.technet.com/b/exchange/archive/2013/01/25/exchange-2013-
client-access-server-role.aspx

Vous aimerez peut-être aussi