Microsoft Dynamics 365 and ExpressRoute

Microsoft Dynamics 365
Microsoft Dynamics
365 and ExpressRoute
July 2017
Microsoft Dynamics 365 and ExpressRoute
Table of Contents
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
. . . . . . . . . . . . . . . . . . .
What are the challenges? . . . . . . . . . . . . . . . . . . . . . . . . . . 7

. . . . . . . . . . . . . . . . . . .
LAN Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Poor WAN Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Poor Internet Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Security: Protection in Transit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
What is Azure ExpressRoute? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Structure of ExpressRoute Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
ExpressRoute Circuits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Microsoft Peering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Public Peering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Private Peering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Direct Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Routing Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
BGP Communities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Configuring ExpressRoute for distributed user bases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Asymmetric Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Azure ExpressRoute Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Where can ExpressRoute help with Dynamics 365? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 7
Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Predictability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Implementing ExpressRoute with Dynamics 365 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 0
Pre-requisites for ExpressRoute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
External pre-requisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Microsoft pre-requisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Office 365 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Routing Dynamics 365 traffic across ExpressRoute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
External Connectivity to/from Dynamics 365 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Internal Cloud Connectivity within Dynamics 365 Customer Engagement applications . . . . . . . . . 36
Customer PaaS/IaaS Cloud Connectivity to/from Dynamics 365 . . . . . . . . . . . . . . . . . . . . . 38
Setting up ExpressRoute for Dynamics 365 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Server traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Client traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Considerations with ExpressRoute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Reusing ExpressRoute across multiple Online Services . . . . . . . . . . . . . . . . . . . . . . . . . 43
Microsoft Peering covers Dynamics 365 Customer Engagement applications and Office 365 . . . . . . 44
Configuration of customer network routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Routing between Dynamics 365 and other Azure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
ExpressRoute controls traffic to the Microsoft network, not within it . . . . . . . . . . . . . . . . . . 45
ExpressRoute is not enforced as the ONLY route to Dynamics 365 . . . . . . . . . . . . . . . . . . . 46
Outbound Traffic from Dynamics 365 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
ExpressRoute does not make public cloud services part of customer on-premises domain . . . . . . . 48
Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Data Load Throughput to Dynamics 365 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
ExpressRoute Readiness Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2
Client Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
WAN Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Peering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Asymmetric Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Geographical distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
On-Premises Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2
Contents
Overview
Overview What are the What is Azure Where can Implementing ExpressRoute
challenges? ExpressRoute? ExpressRoute help ExpressRoute with Readiness
with Dynamics 365? Dynamics 365 Checklist
3
Overview
Overview
When deploying new systems, the changes can expose challenges in connectivity
that are often amplified when users connect to Online services for the first time. This
can be a problem customers experience when initially deploying Microsoft Dynamics
Overview 365 services.
For many organizations, this can highlight one or more of the following concerns:
• Ability of their network or Internet connection to handle the additional traffic of a
rich business application
• Because Dynamics 365 is often a business-critical application, managing the pre-
dictability of the traffic supporting that service as opposed to other less critical
Internet traffic is important to ensure performance for the user and the business
• Ensuring compliance with regulations from a security and privacy policy perspec-
tive
Microsoft Azure ExpressRoute is an option that is often considered to mitigate these
concerns but it is important to understand the real benefits this brings so that you can
accurately judge the value for the situation.
ExpressRoute adds the most value when used with Dynamics 365 in providing com-
pliance with a regulatory need for data to never transit across the public Internet. It
can also assist in scenarios where routing Dynamics 365 traffic separately from gen-
eral Internet traffic can help with predictability of performance to a business-critical
applications such as those offered with Dynamics 365.
One critical factor to consider however though is that ExpressRoute does not cur-
rently allow you to directly configure specific services to be transported across the
ExpressRoute circuit but rather allows you to enable groups of services called peer-
ings. The choice of Dynamics 365 services you wish to use will affect which peerings
you need to enable:
Microsoft peering
• Configuring ExpressRoute for Dynamics 365 Customer Engagement (formerly Dy-
namics CRM) applications requires Microsoft Peering which by default will jointly
route both Dynamics 365 Customer Engagement applications and Office 365 via
ExpressRoute.
• It is possible using BGP Communities to configure the network to only route
traffic for certain services, such as only Skype for Business, or only Dynamics
365 Customer Engagement applications, through an ExpressRoute Microsoft
Peering circuit.
Public Peering
• All Dynamics 365 for Finance and Operations, Enterprise edition services require
Public Peering to be enabled
• Some Dynamics 365 Customer Engagement applications services require Public
Peering to be enabled (e.g. Learning Path, Voice of the Customer) 4
Overview
Private Peering
• Used for Azure IaaS services private to the customer and not directly used by the
Dynamics 365 services
The process of setting up ExpressRoute is often underestimated, in particular several
Overview actions and implications for the customer are often missed either in planning or ex-
ecution including:
• Configuration of the customer network to route traffic to the subnet connected to
ExpressRoute
• Avoiding asymmetric routing of traffic directly to Dynamics 365 across the Internet
but returned by ExpressRoute to the corporate network triggering firewall rejection
of the traffic
• The overall costs of provisioning ExpressRoute including Microsoft Azure services,
connectivity provider provisioning and ongoing service and internal IT network
routing configuration
• Determining whether multiple ExpressRoute circuits should be established for dis-
tributed deployments
ExpressRoute is a valuable technology, particularly with Azure IaaS, but one whose
deployment should not be undertaken lightly particularly for use with Dynamics 365
and Office 365 services. It should only be considered for these after a comprehensive
review of the business justification and planned configuration of its use.
5
Contents
What are the

challenges?
LAN Connectivity
Poor WAN Connectivity
Poor Internet Connectivity
Security: Protection in Transit
6
What are the challenges?

When connecting to Online services, there are common challenges customers may
face. Breaking these down not just into the underlying issue but where in the connec-
tivity path between client and server that they occur can highlight approaches that
can be used to address them.
What are the

challenges?
LAN Connectivity
Often the issue a user faces is that the connectivity within their local network is al-
ready saturated before including a rich browser application into the mix, or Dynamics
365 is replacing and being compared with a thick client application that was used
previously where only the data was transmitted across the network rather than both
data and presentation information.
It is often missed that a browser application, while requiring less in terms of client
side deployment administration, does require higher bandwidth than a thick client
application and therefore an already saturated local network will suffer further with
the addition of new services.
Dublin
LAN Latency/
Saturation
Frankfurt
Branch Corporate Public Microsoft Data

Offices Backbone Internet Center
The root causes and solutions to this are common and well known and typically re-
quire upgrading or improving the local area network itself as any other solutions will
typically require transiting through the LAN before they can help.
Poor WAN Connectivity

On deeper network analysis of connectivity to the Online service a common pattern
experienced is that at some point the network traffic traverses an internal network
route that adds significant latency.
7
This can often be because of conditions such as:

• Saturation of the WAN link
• Proxy processing, incurring additional latency
• Inefficient internal routing e.g. routing within the corporate network rather than
out to the Internet earlier
What are the
challenges? Dublin
Poor WAN
Frankfurt
Connectivity

If Dynamics 365 traffic suffers from those challenges, then performance at the client
can suffer.
Poor Internet Connectivity

Addition of cloud services does introduce additional load to the corporate connec-
tion to the Internet. If the Internet connection
• Is not sufficient to cater for the additional load
• Suffers from a mix of traffic which impacts on quality of connection e.g. multiple
Internet-based training or YouTube videos with traffic to a business-critical applica-
tion competing for the available bandwidth. This may be sufficient overall for the
volume of traffic but potentially impacting performance through peaks of demand
which activity like video streaming will introduce
• The sufficient overall throughput of a periodically busy network can be masked
with usage such as video streaming through buffering, and for large volume data
movement like uploading or downloading SharePoint files the average network
bandwidth may be acceptable as the overall time may still be good enough
• But the responsiveness of a critical user application requires the network to be
constantly available to process traffic quickly and any delays will be noticeable
directly to the user
• Once within the Internet provider’s network, the routing of that traffic to Microsoft’s 8
network is controlled by them; the efficiency of that routing can vary
Dublin
Regional
Connectivity
Frankfurt Inefficient
What are the Routing
challenges?

These things can be addressed through getting additional bandwidth or separate

connections through the ISP. In particular, having a separate connection dedicated
to priority traffic can help with both the performance and predictability of the traffic.
Security: Protection in Transit

By default, all traffic to Dynamics 365 is encrypted giving good protection to the data
while in transit.
For some customers, there is the need to show for regulatory purposes that data is
never passed through the public Internet.
Dublin
Security in
Transition
Frankfurt

In these situations, utilizing standard connections via the public Internet to cloud
services may not be acceptable. This is rare however, most regulations do not specify
that the Internet cannot be used, but rather that the data must be protected in transit
and typically by encryption at the level of 256 bit AES encryption which the SSL en- 9
cryption used by Dynamics 365 meets.
Contents
What is Azure
ExpressRoute?
Structure of ExpressRoute Connections
Configuring ExpressRoute for distributed user bases
Azure ExpressRoute Costs
10
What is Azure ExpressRoute?
What is Azure ExpressRoute

Azure ExpressRoute is a way to create private connections between Microsoft’s data
centers and infrastructure on customer premises or in a colocation environment.
ExpressRoute was initially introduced to connect customers' networks to Azure Vir-
tual Machines (a.k.a., IaaS) and Azure Public services (a.k.a. PaaS) without transiting
the public Internet. An additional advantage with private virtual machines is that the
connection can be extended as if the machines are part of the corporate domain
network.
What is Azure
ExpressRoute? For shared services where multiple customers are served by the same infrastructure,
the connection is not made directly at the machine level but at the higher service
level. As the machines providing the service are not private to a particular customer,
joining the machine providing the shared service onto a customer domain network
does not make sense for either the customer or Microsoft therefore private connec-
tions to the end machine is not available with any public shared services.
This capability has been extended to include support for online public services like
Office365 and Dynamics 365, enabling private connections to those services from
the customer environment.
The connection can be established by the customer’s connectivity provider in several
ways as described in the following article:
For more details see
• Co-location at a cloud exchange
the following article
• Point to point Ethernet connection
Support Article
• Any to Any (IPVPN) networks, typically an MPLS VPN
Cloud Exchange Point-to-point Any-to-any (IPVPN)

Co-location Ethernet Connection Connection
ExpressRoute
ExpressRoute
ExpressRoute
WAN
11
By utilizing a private connection, separate from other traffic to the public Internet, a
more controlled and predictable connection can be established to business-critical
services like Azure, Office 365 and Dynamics 365 avoiding issues like bandwidth sat-
uration by other Internet traffic.
Traffic between the customer environment and the Microsoft data center does not
transit the public network giving additional confidence in privacy of the traffic.
When ExpressRoute is enabled the connection is made between the customer and
Microsoft data centers and all traffic for designated subnets route via the Express-
Route dedicated connection. When it reaches the Microsoft data center peering rules
What is Azure
ExpressRoute? are applied to determine how to route the requests to the relevant service:
Microsoft Peering
Office 365, Dynamics 365
Customer's
network
Partner ExpressRoute Microsoft

Edge Circuit Edge Public Peering
Azure PaaS
Traffic to Office 365 Services and Dynamics 365

Customer Engagement Online
Traffic to public IP addresses in Azure Private Peering
Traffic to Virtual Networks Azure IaaS
The benefit that ExpressRoute brings is to enable a private connection between the
online services hosted in Microsoft’s data centers and the customer’s on-premises
connection, the benefits come from that private connection and the network routing
of traffic across that, it does not provide additional encryption or filtering of the traffic
itself.
Structure of ExpressRoute Connections

An ExpressRoute connection is made up of several constituent elements.
ExpressRoute Circuits
A customer can order and configure one or more ExpressRoute Circuits. Each circuit 12
can be in the same or different regions, and can be connected to the customer prem-
ises through different connectivity providers.
An ExpressRoute circuit does not map to any physical entities and is identified by a
standard GUID called a service key (s-key).
Use of an ExpressRoute circuit can offer performance advantages when with the con-
nectivity provider a dedicated and optimized connection is set up directly through
their infrastructure to the edge of the Microsoft network. This connection could
be optimized without ExpressRoute but Internet connectivity is typically provided
through a series of partnerships and relationships between telecommunications pro-
viders which can lead to sub-optimal connectivity paths being taken to delivering
a customer’s network traffic to a specific destination. The agreement to provide a
What is Azure dedicated and private connection with a connectivity provider ensures that there is
ExpressRoute? a direct responsibility for the connectivity provider to setup an optimized connection
direct to the Microsoft network, and this ownership is often what leads to the opti-
mized experience.
Each circuit has fixed bandwidth and is mapped to a connectivity provider and a
peering location, the available bandwidth shared across the peerings for the circuit.
A circuit can have up to three separate peerings. These peerings represent different
routings used depending on which kind of service is being requested
• Microsoft peering: routes requests to Microsoft public services such as Office365
or Dynamics 365 Customer Engagement applications
• Public Peering: routes requests to the appropriate Azure public services e.g. Web
Roles, Storage.
• Some Dynamics 365 services and capabilities (Dynamics 365 for Finance and
Operation, Voice of the Customer and Learning Path) are hosted within Public
Peering services, whether a customer needs Public Peering will depend on
whether they require one of these services.
• Private Peering: routes requests to the customers private Azure services e.g. IaaS
Virtual Machines
Each peering is a pair of independent Border Gateway Protocol (BGP) sessions each
of them configured redundantly for high availability. To ensure true resilience though
it is important to ensure that they do transit over physically different connections.
Microsoft advertises the IP subnets or prefixes of the cloud services generally to the
public Internet. Microsoft would also advertise the IP prefixes for the relevant services
through the ExpressRoute BGP connection for the services specified in the peerings
defined for that circuit.
13
Customer Microsoft
Network Network
Internal Router configuration, routes
traffic for Microsoft Online Services
to ExpressRoute connected subnet
Internal routing
Router configuration routes configuration routes traffic
traffic via BGP session to appropriate service
What is Azure Partner ExpressRoute Microsoft

ExpressRoute? Edge Circuit Edge
ExpressRoute Microsoft Peering

Connected Subnet
Traffic to Office 365 Services and Dynamics 365 Online
For traffic to Microsoft, internal routing configuration within the customer network
needs to set up and is responsible for:
• Prioritizing the route for Microsoft Online Services traffic via the subnet connected
to ExpressRoute as opposed to through the public Internet connection
• Routing the Microsoft Online Services traffic from the connected subnet through
the BGP session established through ExpressRoute
At the other side, Microsoft is then responsible for routing the traffic to the appropri-
ate service within the Microsoft data center.
For traffic routed from Microsoft Online Services to an external service:
Customer Microsoft
Network Network
Connection Public
made to the Internet
internal service
Requests to external
services looked up against
Router configuration routes DNS; then if IP registered
traffic internally as appropriate against an ExpressRoute
either using public IP or NAT IP circuit, routes it internally
Traffic to IP registered
against ExpressRoute
Partner ExpressRoute Microsoft routed over the BGP
Edge Circuit Edge Session through the
customer private circuit
Connected Subnet
14
When the request is made:

• It must be made through a public URL, which must first be resolved to a public IP
address
• The routing configuration within the Online Service will:
• If the IP address is not registered against an ExpressRoute peering:
• Route the traffic out to the public Internet
• If the IP address is registered against an ExpressRoute peering:
What is Azure
ExpressRoute? • Route the traffic internally to be sent via the appropriate ExpressRoute
circuit
• Once the traffic arrives at the customer network, internal routing within the cus-
tomer network will be responsible for routing it to the final destination either
through direct routing of the IP or through NAT first.
You must connect to Microsoft cloud services only from a subnet that uses public IP
addresses that are owned by you or your connectivity provider. If you are using pri-
vate IP addresses in your on-premises network, you or your provider need to trans-
late the private IP addresses to the public IP addresses using NAT before connecting
to ExpressRoute. This enables requests from Microsoft services to resolve to the ser-
vice endpoint and route through the network across shared network segments.
Microsoft Peering
Connectivity to Microsoft online services such as Office 365 and Customer Engage-
ment services will be routed through the Microsoft peering. Microsoft assigns the
URLs and IPs for Dynamics 365 Customer Engagement applications and Office 365
services to the Microsoft Peering, so any traffic routed to them will be advertised
and enabled through the Microsoft Peering, (although note that there are some an-
cillary services of Dynamics 365 Customer Engagement applications that are routed
through Public Peering).
Customer Microsoft
Network Network
Internal Router configuration, routes
traffic for Microsoft Online Services
to ExpressRoute connected subnet
Internal routing
Router configuration routes configuration routes traffic
traffic via BGP session to appropriate service
Partner ExpressRoute Microsoft

Edge Circuit Edge

Connected Subnet

15
Using Microsoft peering, the connections are to shared services at Microsoft so once
they arrive at the Microsoft data center the ongoing connection is across an internal
shared network, the private connection provided by ExpressRoute does not extend
all the way to the destination service endpoint itself.
Public Peering
Depending on which Dynamics 365 applications are being used, public peering may
also be required.
Dynamics 365 Customer Engagement applications
What is Azure
ExpressRoute? Dynamics 365 Customer Engagement applications also use several Azure public ser-
vices as part of the broader offering. These break down into three categories that are
relevant to the discussion around ExpressRoute:
• Directly accessed services from outside of the corporate network. This can be ex-
ternal parties such as customers or partners, or internal users for whom their use
or location does not require their network traffic to be kept within the corporate
network or off the public Internet
• As these connections are made directly across the Internet then peering is not
relevant to these connections
• This would include capabilities like Portals and Voice of the Customer surveys.
• There are scenarios where although these are targeted at public Internet audi-
ences, may also be delivered to an internal audience where it may be relevant
to a customer to route the traffic to these for internal users through Express-
Route
• Directly accessed services such as Learning Path and Dynamics 365 for Tablet of-
fline sync
• As the connection to these services is directly from the client application e.g.
browser, Outlook client or tablet/phone app, then Public Peering to these
services needs to be configured to route this traffic if it is to utilize the Express-
Route connection and avoid public Internet routing
• Indirectly accessed services such as Azure Search, and Service Bus queues for
Dynamics Marketing
• As the connections to these services is indirectly managed within the Dynam-
ics 365 Customer Engagement applications service and would not be made
from the client applications, this traffic should never need to be considered by
the customer as the routing would be handled internally by the Dynamics 365
Customer Engagement applications service itself
Dynamics 365 Customer Engagement applications, while mostly routed through Mic-
rosoft Peering, therefore also requires Public Peering for certain capabilities.
Dynamics 365 for Finance and Operation
Dynamics 365 for Finance and Operations is hosted within Azure Public Services and
16
therefore would be routed using Azure Public Peering.
Private Peering
Microsoft does not utilize private services for Dynamics 365 that would be directly
accessible by the customer. It is not necessary for Dynamics 365 purposes to config-
ure Private peering for ExpressRoute. If the customer separately utilizes Azure private
services though, configuring Private peering is not harmful other than where the
introduction of additional workloads can cause the connection to be saturated.
Direct Internet
It is also important to realize that not all traffic to Dynamics 365 would be possible to
What is Azure
ExpressRoute? route across ExpressRoute, therefore direct Internet connections will also be required.
Dynamics 365 Customer Engagement applications
To gain performance benefit, where there is static content we can gain an advantage
by utilizing Azure Content Delivery Network (CDN) which is deployed as close as
possible to the edge of the Microsoft network. In many cases that location will be
closer to the user than the ExpressRoute circuit connection and therefore bypasses
ExpressRoute.
The content hosted within CDN does not contain any customer information, it would
only contain static content shared across all users rather than any dynamically gen-
erated and retrieved customer data which is always retrieved from the Dynamics 365
servers on demand.
Currently Azure CDN is used for the Learning Path feature, but other uses are under
consideration for future releases.
It is important to realize therefore, that a direct Internet connection from the client
to the Microsoft cloud service is required for Dynamics 365 Customer Engagement
applications.
Dynamics 365 for Finance and Operations, Enterprise edition
While client traffic into Dynamics 365 for Finance and Operation would be possible
to route via ExpressRoute, requests made from Dynamics 365 for Finance and Oper-
ation out to on-premises services, cannot be initiated at the service side and routed
through ExpressRoute Public Peering. Where connections back to the on-premises
services are needed from Dynamics 365 for Finance and Operation, those services
would need to be accessible from the public Internet.
Routing Configuration
The routing configuration is either done by the connectivity provider or the customer
depending on the connection type provided.
A characteristic when considering ExpressRoute for Dynamics 365 compared to some
other Azure services is that although the ExpressRoute connection itself is between
data centers, the actual network connection is mostly from the end user client de-
vices which will often be distributed across a broader WAN such as distributed bank
branches for example. This therefore means that the routing of connections from the
location of the client device through the WAN to the data center and then across the 17
ExpressRoute needs to be considered and configured correctly. As the target of the

Dynamics 365 client is publicly available across the Internet, the WAN must be setup
in such a way that the route via the network subnet configured for ExpressRoute, or
the failover circuit, must be chosen in preference to the public Internet connection.
Identifying which subnets within the customer network should be the targets for the
main and fallback BGS session connections is therefore important and making sure
that the Dynamics 365 prefixes prefer that route. It is not necessary to configure
specifically the services at each end as the configuration is done by advertising the
IP subnets/prefixes through this connection. When a request is initiated, the routing
What is Azure algorithm would see that direct BGP connection as the preferred route for traffic to
ExpressRoute? the subnet connected to the ExpressRoute circuit and direct the traffic that way.
This also leads to a need for the appreciation around security control. ExpressRoute
itself does not encrypt or filter traffic natively, it simply establishes a private, rather
than shared, connection directly between the Microsoft and customer data centers
through their connectivity provider.
Any request from any Microsoft Online Service to the subnet advertised through an
ExpressRoute circuit will be routed via that circuit no matter which service makes the
request or which customer is using that service. As the request is routed at the net-
work layer, there is not the application level control to determine whether that is an
appropriate requester for that destination service or not.
For traffic to Microsoft services, these are public shared services anyway, so can be
accessed directly across the public Internet. Access control to these services is han-
dled through application level authentication and authorization services. They are
further protected at an infrastructure level against intrusion and threats like Denial of
Service attacks.
For traffic from Microsoft services to on-premises hosted services, the customer is
responsible for providing similar protection to their own services when traffic is re-
ceived across an ExpressRoute connection.
BGP Communities
One of the challenges faced by customers is wanting to use ExpressRoute for a par-
ticular Microsoft cloud service but not for others. While the different peering options
provide some level of control here, the ability for example to enable only routing to
Azure IaaS machines but not to Office 365, the peering itself does not provide gran-
ular control within services of the same peering type. It is possible though to use BGP
communities to configure traffic for specific services only.
This is particularly relevant for Dynamics 365 Customer Engagement applications with
Office 365 where routing via ExpressRoute may be desirable for one service but not
for both or only for certain individual services of Office 365 such as Skype for Business.
ExpressRoute itself does not currently offer the ability to directly configure services
to be routed via a specific ExpressRoute circuit at this level of service granularity, but
BGP communities can be used to control this.
Microsoft will advertise routes in the Microsoft peering paths with routes tagged with 18
appropriate BGP community values for geographical locations and service types.
These can then be configured in the customer’s routers to route traffic for those
services through the ExpressRoute circuit.
Both Dynamics 365 Customer Engagement applications and the different Office 365
services will be tagged and these tags can be used to decide to route traffic only for
those services through the ExpressRoute circuit and the rest across either a different
ExpressRoute circuit or the public Internet.
What is Azure
ExpressRoute?
Configuring ExpressRoute for distributed user
bases
ExpressRoute is designed to provide private, dedicated and therefore predictable
connections from a customer’s environment to the Microsoft network. By having a
dedicated and direct connection through the connectivity provider to Microsoft this
will reduce the potential for contention from other traffic on shared connections
through the connectivity provider’s network. It should not be necessary however
to utilize ExpressRoute to achieve that quality of connection through a connectivity
provider, but is a way to ensure it.
In the following example, it shows how a user in a branch location would have their
connection routed via the WAN to the customer data center connection to Express-
Route.
Branch Network Customer Data

in Holland Center
Partner ExpressRoute
WAN Connection
Edge Circuit
ExpressRoute
Connected Subnet
Customer Operations in Holland
Where a customer has a highly distributed network of users, such as a branch net-
work of a bank distributed around a country, the network traffic now needs to be
connected efficiently from multiple, highly geographically distributed locations.
The typical pattern for this then would be to route things through the WAN to the
local network connected to ExpressRoute as the following diagram shows:
19

in Holland Center
WAN Connection
WAN Connection Partner ExpressRoute

WAN Connection Edge Circuit
ExpressRoute
Connected Subnet
What is Azure Customer Operations in Holland

ExpressRoute?
If the connection between the client and ExpressRoute is too poor or is saturated or
inefficient in some other way, then ExpressRoute will not solve this as the connection
problems in getting to the ExpressRoute entry point would still impact the user ex-
perience.
Branch Network Customer Data Using ExpressRoute will

not overcome slow WAN
in Holland Center network connections
WAN Connection

ExpressRoute
Connected Subnet
When connecting to cloud services and being constrained by challenges in the WAN
connections, establishing local Internet breakouts from local branches can often be
extremely beneficial to performance, avoiding the slower WAN connection and uti-
lizing the reach of the connectivity provider to achieve a more direct connection to
the cloud service.
20
Partner
Edge
Connection to Microsoft
n
ctio
nne
Co
in Holland Center
N
WA
What is Azure WAN Connection
ExpressRoute?
ExpressRoute
Connected Subnet
It is possible to setup ExpressRoute circuits from multiple locations and even out to
individual branch locations through a local Internet breakout as shown in the follow-
ing diagram:
Edge Circuit
n
ctio

nne
Co
in Holland Center
N
WA

ExpressRoute
Connected Subnet
The WAN approach from branch locations to a central data center and ExpressRoute
circuits between the customer and Microsoft data centers is typically preferable and
more practical though than trying to establish an ExpressRoute connection from each
branch office location which is both relatively expensive and complicated to setup
and maintain if this was required from large numbers of locations
An alternative approach is to connect all the branch offices and customer data center
on the same IP VPN and have the IP VPN service provider connect to Microsoft at an
ExpressRoute location.
If there are challenges with a local WAN connection then it is typically better to op-
timize that, such as gaining additional bandwidth or optimizing the routing, rather
than trying to establish an ExpressRoute connection from each location. 21
For more physically distributed networks, it may be valuable to have several hubs
connected to ExpressRoute to minimize the number of ExpressRoute connections
needed while still offering a more local connection point. In this case it is important
to ensure that unique public IPs are published via each ExpressRoute circuit. This has
the implication that each of these subnets must be distinct, requiring as many publicly
facing subnets as ExpressRoute connections.

What is Azure in France Center
ExpressRoute?
WAN Connection

ExpressRoute
Connected Subnet
Customer Operations in France

in Holland Center
WAN Connection

ExpressRoute
Connected Subnet
This is particularly beneficial if the different operational areas are in vastly different
areas or if the network connectivity between the areas is limited but a more direct
connection to Microsoft can be established.
It is also possible that different regions have different privacy requirements, and it is
not necessary that every region uses ExpressRoute simply because one does. It may
be possible for some connections to be routed directly through the Internet and
others through ExpressRoute:
22

in France Center
WAN Connection
Route via Internet Connection to Microsoft
WAN Connection
WAN Connection
ExpressRoute
Connected Subnet
What is Azure Customer Operations in France

ExpressRoute?

in Holland Center
WAN Connection

ExpressRoute
Connected Subnet
ExpressRoute as standard only offers connectivity within a specific geographic region,

ExpressRoute Premium is required to offer multi-geo access from a single Express-
Route connection point. This would be relevant if for example a customer had US
based branch offices as well as European offices to a single Dynamics 365 instance. If
the customer’s Dynamics 365 tenant is deployed in the US, their ER circuit in Europe
needs to be the Premium SKU. If their Dynamics 365 tenant is in Europe, their US
circuit would need to be Premium.
Asymmetric Routing
One challenge to watch for is asymmetric routing, where routing configuration within
the customer network could route traffic to the Microsoft data center directly across
the Internet but then the return traffic determines that the responses should be rout-
ed via an ExpressRoute circuit. This can often trigger firewalls to reject the traffic as
it would receive response packets without having sent the request packets so rejects
them as it is not aware of the request origination.
23
2. Request routed via Internet direct to Microsoft

1. Request
to Microsoft
via Internet Connection to Microsoft
n
ctio
Branch Network Customer Data 4. Response 3. Response
nne
rejected by routed via

Co
in Holland Center firewall ExpressRoute

N
WA
What is Azure WAN Connection
ExpressRoute?
ExpressRoute
Connected Subnet
Microsoft
Customer Operations in Holland Cloud
Where this can happen is if the local network for a client perceives that the most
efficient routing to Microsoft’s cloud services is across the public Internet rather than
through the WAN to the private ExpressRoute circuit. But if in that case the client
IP address is either a public IP address or is translated through NAT mappings to a
public IP address that is advertised through ExpressRoute, then when the Microsoft
service comes to route the reply, the most efficient route back to that IP would likely
be through the BGP session over ExpressRoute. A customer can use different NAT
IPs on the customer’s Internet edge and ExpressRoute edge. With distinct source
address, return traffic will unambiguously come back to the same edge.
This can also happen where there are multiple ExpressRoute circuits configured for
the same customer with outbound traffic routing via one circuit but return rout-
ing through another where the same firewall checks could block unsolicited traffic
through the return path. To avoid asymmetric routing across a different ExpressRoute
circuit for the outbound and inbound paths, it is equally important to ensure that
unique public IPs are published across each circuit.
As this shows, it is important to determine how the routing is managed within the
customer’s WAN and ensure that the paths to and from Microsoft’s cloud services are
carefully considered.
Azure ExpressRoute Costs

When estimating the costs for ExpressRoute, it is necessary to consider several con-
stituent elements:
Azure costs
• Azure ExpressRoute can be purchased in different models
• Billing Type
• Metered: a base subscription cost per month with unlimited inbound
traffic but a per Gb charge for outbound traffic 24
• Unlimited: a base subscription cost per month with unlimited inbound

and outbound traffic
• SKU
• Standard
• Basic connection using ExpressRoute
• Offering access to services within a single geographical region
• Premium
What is Azure
ExpressRoute? • Offers access to worldwide geographical services from wherever the
connection is made
• For Dynamics 365 Customer Engagement applications.
• If the ExpressRoute circuit is within the same region as the Dy-
namics 365 instance that users are connecting to then only Ex-
pressRoute standard is required for that circuit
• If a user connects through an ExpressRoute circuit from a differ-
ent region than their end service, they would require Express-
Route Premium for that ExpressRoute circuit.
Connectivity Provider costs
• The costs of establishing the connection with the Connectivity Provider in some
cases can be significant and are separate from the Microsoft Azure costs for Ex-
pressRoute
Internal customer effort to configure the network routing
• To enable ExpressRoute, the network routing must be setup internally
• For many customers there is an internal cross charge to the network team or an
external cost to an IT outsourcing provider for this or at least opportunity cost for
the effort of internal staff focusing on this
In determining the business case accurately, it is important to consider all these costs
when evaluating ExpressRoute for Dynamics 365.
25
Contents
Where can
ExpressRoute help
with Dynamics 365?
Compliance
Predictability
26
Where can ExpressRoute help

with Dynamics 365?
Where can ExpressRoute help with Dynamics 365?

The GDPR is a single, binding legislative act that reflects the implementation of the
Digital Single Market Strategy. It is a complex regulation that may require significant
changes in how you gather, use and manage data. Microsoft has a long history of
helping our customers comply with complex regulations, and when it comes to pre-
paring for the GDPR, we are your partner on this journey.
Dublin Dynamics 365
Azure PaaS
Where can ExpressRoute Express Route
help with Dynamics 365?
Frankfurt
Azure IaaS
Dedicated Connection
Circuit VPN Options

The primary areas therefore that this provides direct benefits to are:
• Compliance: not routing customer information via the public Internet
• Predictability: dedicated connection avoiding conflict with other Internet traffic
Compliance
By routing the traffic to Dynamics 365 via a private connection, this avoids routing of
customer data over the public Internet.
It is important to note though, that ExpressRoute does not actually encrypt the traffic
itself, so the encryption used to connect to Dynamics 365 is that provided by the
underlying services themselves. The Dynamics 365 services support AES 256-bit en-
cryption.
The primary benefit to routing Dynamics 365 traffic via ExpressRoute is to meet com-
pliance needs where regulatory requirements state that customer data cannot be
transferred over the public Internet. This is not a common regulatory requirement
however, most regulations state that the data transfer must be adequately protected
but make no specific calls for a private connection to a cloud service.
As described earlier, static content served by the Azure CDN service for Dynamics
365 Customer Engagement applications cannot be routed via ExpressRoute so would 27
be routed directly across the public Internet.
Where can ExpressRoute help

with Dynamics 365?
Dynamics 365 for Finance and Operation would also require direct Internet con-
nections for any communications initiated from the cloud service to on-premises
services.
Predictability
The Internet connection of most organizations is shared with many other uses. This
can lead to contention for bandwidth. The connection within the connectivity provid-
er may also suffer from contention from other customers.
ExpressRoute can establish a private and direct connection to the Microsoft data cen-
ters. If the main issue is just within the bandwidth available, internal routing through
Where can ExpressRoute the connectivity provider or traffic in the connection between the customer and the
help with Dynamics 365?
network provider, then this can be resolved through either higher bandwidth and
more reliable or better optimized connections without the need for ExpressRoute.
These would in fact be pre-requisites to ExpressRoute anyway, so if the problem can
be resolved directly through better Internet connections then ExpressRoute may not
drive value.
Providing a connection directly through to the Microsoft’s data centers minimizes
the chances of any contention with other traffic either from the same organization
or any other.
28
Contents
Implementing
ExpressRoute with
Dynamics 365
Pre-requisites for ExpressRoute
Routing Dynamics 365 traffic across ExpressRoute
Setting up ExpressRoute for Dynamics 365
Considerations with ExpressRoute
29
Implementing ExpressRoute
with Dynamics 365
Implementing ExpressRoute with Dynamics 365

Before taking advantage of ExpressRoute for Dynamics 365, it is important to plan the
deployment to allow for the customer’s needs and environment.
Pre-requisites for ExpressRoute

Setting up ExpressRoute requires several pre-requisites to be considered and setup.
These can lead to unexpected costs and activity which if not pre-planned can impact
on the business case and continuing operation of other services.
External Pre-requisites
ExpressRoute does not provide the physical connection itself, but the private connec-
Implementing tivity over an already established physical connection.
ExpressRoute with The physical connectivity must first be set up by a connectivity provider. There are a
Dynamics 365 number of ways this connectivity can be established with existing ExpressRoute part-
ners, the ExpressRoute documentation gives detailed explanations of the options and
the currently available partners.
ExpressRoute
documentation As part of planning the following need to be allowed for:
Geography
Documentation
• As we will discuss in more detail later, understanding geographically where one or
more connections need to be made from will impact on the overall planning
Cost
• The Connectivity Provider will charge the customer for establishing the private
connection
• This can be a significant cost, and will vary depending on the type and number of
connections needed and across different connectivity providers
Setup time
• With the need in some cases for physical hardware setup, the setup time for this
needs to be planned into implementation schedules
Configuration skills
• The majority of the configuration complexity will be in setting up the internal net-
work routing within the customer network. Ensuring availability of the skills of re-
sources to do this is essential
Microsoft Pre-requisites
Once the physical connectivity is in place, setting up the Microsoft ExpressRoute con-
nections themselves can be done.
30
with Dynamics 365
This will require:

• Azure subscription within which to provision and bill the ExpressRoute circuits
• Configuration within the Azure subscription of the ExpressRoute circuits, which is
done through the Azure tools
• Approval for enablement of Microsoft Peering is also needed by Microsoft which
will validate that there is understanding of the necessary configuration steps
Office 365
As Dynamics 365 Customer Engagement applications and Office 365 services are
both offered through the Microsoft Peering, setting up Microsoft peering would by
default advertise all Dynamics 365 Customer Engagement applications and Office
365 services across the ExpressRoute circuit.
Implementing
ExpressRoute with
The consequence of this is that enabling it to route traffic for one, would lead to
Dynamics 365 both being routed across ExpressRoute. This may be desirable or not, but can have
adverse implications. For example, if you have determined the network bandwidth
needed for Dynamics 365 and sized the ExpressRoute connection accordingly but
accidentally then discover that all your Office 365 traffic is also routing via Express-
Route then this could saturate your network and cause performance challenges.
Azure tools
If you decide to configure ExpressRoute for Dynamics 365 Customer Engagement
applications and enable it while still trailing the internal network configuration but are
already hosting your email in Office 365 and discover a problem in your configura-
tion, this could affect users’ existing access to their email service. It would be possible
to utilize BGP Communities to not route traffic for Office 365 services but this should
be considered and planned for.
As Dynamics 365 Customer Engagement applications work as part of the Office 365
service many cross over services such as the admin portal and authentication are also
required. Not all of these are possible to protect using ExpressRoute, the Office 365
Portal for example is not published across ExpressRoute.
While by default enabling ExpressRoute for Microsoft peering will route all Dynamics
365 Customer Engagement applications and Office 365 traffic through the Express-
Route connection, it is possible to use BGP Communities tags to control the routing
so that only specific services such as Dynamics 365 Customer Engagement appli-
cations, but not other Office 365 services, utilize the ExpressRoute connection. In
particular, not all Office 365 services are designed to work with ExpressRoute.
31
with Dynamics 365
Routing Dynamics 365 traffic across

ExpressRoute
When planning for routing Dynamics 365 traffic, there are various types of traffic
that may be possible depending on the use and configuration of Dynamics 365 for
a given customer.
To understand how to configure ExpressRoute for Dynamics 365, the different uses
and connections to and from Dynamics 365 need to be considered. This will vary
based on the Dynamics 365 applications and the specific features or capabilities be-
ing used by that customer.
External Connectivity to/from Dynamics 365

Implementing When making connections to Dynamics 365 Online from customer locations there
ExpressRoute with are multiple traffic types to be considered. This may lead to multiple peering types,
Dynamics 365 including Microsoft and Public Peering, but the same ExpressRoute circuit can be
used including these different peering types:
Dublin Dynamics 365
Azure PaaS
Express Route
Frankfurt
Azure IaaS
Circuit VPN Options

32
with Dynamics 365
External Connectivity to/ from Dynamics 365 Customer Engagement

applications
The following different connection types exist between Dynamics 365 Customer En-
gagement applications and an external network.
Customer's
network
Microsoft Peering
On-Premise
Exchange Server
Implementing
ExpressRoute with Partner ExpressRoute Microsoft
Dynamics 365 Edge Circuit Edge Public Peering
Azure PaaS
On-Premise
Customer System
EWS Connectivity from SSS

Web Services Connectivity from Plugins/to
Dynamics 365 endpoints Private Peering
Client PCs Azure IaaS
Https Client connectivity to Dynamics 365
Inbound Traffic
The following inbound traffic is possible to Dynamics 365 Customer Engagement
applications from the customer network.
Traffic Type and

Description Peering Type Purpose
Direction
Microsoft Peering
Https Inbound to Client requests for
Client Dynamics 365 Cus- Direct Internet con- Dynamics 365 Cus-
Connectivity tomer Engagement nection for static tomer Engagement
applications content served by applications UI
Azure CDN
Requests to
Dynamics 365
Customer Engage-
Https Inbound to ment applications
Dynamics 365 Cus- through the web
Web Services Microsoft Peering
tomer Engagement service APIs (SOAP,
applications WebAPI). Either
from a standard
or custom client 33
application
with Dynamics 365
Outbound Traffic
The following types of outbound traffic can occur directly from Dynamics 365 Cus-
tomer Engagement applications services to customer services.
For each of these it is important to note that the customer service must be publicly
addressable with a public IP that can be resolved through public DNS by the Dynam-
ics 365 Customer Engagement applications service.
This IP address would also need to be advertised to Microsoft through ExpressRoute

so that the internal network routing within Dynamics 365 Customer Engagement
applications knows to route it via that ExpressRoute connection.
There are not controls within the Dynamics 365 Customer Engagement applications
service to specify which service instance or customer organization can make requests
to which IP addresses. It is important therefore to realize that requests inbound to
Implementing the corporate network should be treated as inbound from the Internet and secured
ExpressRoute with as such.
Dynamics 365
Traffic Type and

Direction
Microsoft Peering
Web services would Custom plug ins/
need to be pub- workflow activities
Https Outbound
Web Services lished on public IP can make web
from s
addresses that are service requests to
within ExpressRoute external services
configured subnets
Exchange Web
Microsoft Peering Services requests
from Server Side
Https Outbound Web services would Synchronization
Exchange need to be pub-
from Dynamics 365 for Hybrid deploy-
Integration: lished on public IP
Customer Engage- ments (Dynamics
hybrid mode addresses that are
ment applications 365 Customer
within ExpressRoute Engagement appli-
configured subnets cations, Exchange
On-Premises)
34
with Dynamics 365
External Connectivity to/ from Dynamics 365 for Finance and Operation,
The following different connection types exist between Dynamics 365 for Finance and
Operation and an external network.
Customer's
network Microsoft Peering
On-Premise
Customer System
Implementing
ExpressRoute with Partner ExpressRoute Microsoft
Dynamics 365 Edge Circuit Edge Public Peering
Azure PaaS
Client PCs
Connectivity from Dynamics 365 for Finance and Operation

Web Services Connectivity to Dynamics 365 for Finance
and Operation
Private Peering
Https Client connectivity to Dynamics 365 for Finance Azure IaaS
and Operation
Inbound Traffic
The following inbound traffic is possible to Dynamics 365 for Finance and Operation
from the customer network.
Traffic Type and

Direction
Https Inbound Client requests
Client to Dynamics 365 for Dynamics 365
Public Peering
Connectivity for Finance and for Finance and
Operation Operation UI
Requests to
Dynamics 365
Https Inbound for Finance and
to Dynamics 365 Operation through
Web Services Public Peering
for Finance and the web service
Operation APIs. Either from a
standard or custom
client application
35
with Dynamics 365
Outbound Traffic
The following types of outbound traffic can occur directly from Dynamics 365 for
Finance and Operation services to customer services.
For each of these it is important to note that the customer service must be publicly
addressable with a public IP that can be resolved through public DNS by the Dynam-
ics 365 for Finance and Operation service.
The Dynamics 365 for Finance and Operation Service does not control or limit the
destination of outbound requests from specific customer instances. There is no con-
trol to make sure that only Organization A can make requests to resources over
Organization A’s Express Route circuit or to their published IP addresses. It is import-
ant therefore to realize that requests inbound to the corporate network should be
treated as inbound from the Internet and secured as such.
Implementing
ExpressRoute with
Traffic Type and
Dynamics 365 Description Peering Type Purpose
Direction
Cannot be routed
Https Outbound across Express- Custom code can
from Dynamics 365 Route, and would make web service
Web Services
for Finance and need to travel requests to external
Operation across the public services
Internet
Internal Cloud Connectivity within Dynamics 365 Customer Engagement applications
Internal Cloud Connectivity within Dynamics 365 Customer Engagement

applications
Dynamics 365 Customer Engagement applications utilize and integrate with several
other Microsoft online services hosted both in Office 365 and Azure.
Exchange Web Service Requests

Azure PaaS
EWS
Office 365, Customer

Engagement Customer Engagement Push message to/pull
messages from Service Bus
SharePoint Web Service Request Data Sync for Search/Offline/SQL Azure
Azure AD Authentication
36
with Dynamics 365
Description Traffic Type and Direction Purpose

Exchange Web Service Re-
Exchange quests to Exchange Online
Https Outbound to Office 365
Integration from Server Side Synchroni-
zation
SharePoint Web Service
SharePoint Requests to SharePoint Online
Https Outbound to Office 365
Integration from Dynamics 365 Customer
Engagement applications
Push events onto Azure
Service Bus either as standard
Https Outbound to Azure
Service Bus event registration or from
Service Bus
custom plug ins/ workflow
Implementing activities
ExpressRoute with
Dynamics 365 Inbound Change Tracking
Https Inbound from Azure requests for synchronization of
Data Sync
PaaS data services including Search/
Offline/Customer Insight
Most authentication done as
passive redirects and claims
Authentication Https Outbound to Azure AD tokens. But some synchroni-
zation of data from Azure AD
directly
The actual connectivity between these services, hosted either in Microsoft or custom-
er Azure subscriptions, is handled by Microsoft. ExpressRoute is not applicable for
connections with these services.
Where events are pushed onto the service bus, the connectivity between Dynamics
365 Customer Engagement applications and Azure is handled internally. Separately
the customer may make requests to the Service Bus to retrieve information, and this
can be managed through public peering.
Internal Cloud Connectivity within Dynamics 365 for Finance and Operation
Dynamics 365 for Finance and Operation can be integrated with a customer’s Azure
AD for Single Sign On.
This connectivity would occur through claims based authentication passing tokens
between the authentication service and the client and then the client and the Dy-
namics 365 for Finance and Operation service, so no additional traffic is required
than is required to connect to the customer’s Office 365 service. If they wish to use
the Office 365 service for authentication then that would be over Microsoft Peering if
they wish it to be routed via ExpressRoute
37
with Dynamics 365
Customer PaaS/IaaS Cloud Connectivity to/from Dynamics 365
Customer Public/ Private Cloud Connectivity to/ from Dynamics 365

Customer Engagement applications
Dynamics 365 Customer Engagement applications also allows direct integration with
public or private Azure resources:
• From external sources using the Dynamics 365 Customer Engagement applications
web services APIs
• To external sources using web service requests made
The implications of this need to be considered in the ExpressRoute routing
Customer's
Implementing
ExpressRoute with network Request to SQL Azure/Cortana Analytics Suite
Dynamics 365 Customer Push messages to/pull messages from Service Bus
Https client connectivity to Portals/Surveys
Web Service Request to customer services

Azure PaaS
Web Service Request to Customer Engagement from customer services
Web Services Request to Customer Engagement from customer services
Web Service Request to customer services

Azure IaaS
38
with Dynamics 365
Traffic Type and

Direction
Voice of the Customer is a
service that is used both
externally by customers
but also internally by staff
configuring and responding
to surveys
It is hosted on a subdomain
of the standard *.crmx,dy-
namics.com domain hosting
Dynamics 365 Customer En-
Voice of the Https inbound gagement applications. This
Public Peering
Implementing Customer to Azure is currently not published
ExpressRoute with under Microsoft Peering
Dynamics 365 although will be included in
future
There may be scenarios
where internal employees
may access these resources
with private information so
may wish traffic to travel
across ExpressRoute rather
than public Internet
Utilises Host public facing services.
Azure CDN
which is not There may be scenarios
Https Inbound supported by where internal employees
Portals may access these resources
to Azure ExpressRoute
so will travel so may wish traffic to travel
across public across ExpressRoute rather
Internet than public Internet
Utilises This is hosted on a public

Azure CDN facing service as it does not
which is not contain private customer
Https Inbound supported by data.
Learning Path
to Azure ExpressRoute For predictability purpos-
so will travel es, there may be scenarios
across public where it is desirable to route
Internet this via ExpressRoute
39
with Dynamics 365
Pull events from Azure

Service Bus that have been
Https Inbound
placed there either as
Service Bus to Azure Service Public Peering
standard event registration
Bus
or from custom plug ins/
workflow activities
Customers can host custom
applications in Azure and
Web Service Inbound from Internal to
make requests of Dynamics
Requests Azure IaaS/PaaS Data Center
365 Customer Engagement
applications web services
Customers can implement
Web Service Outbound to Internal to custom plug ins/workflow
Implementing Requests Azure IaaS/PaaS Data Center activities that make requests
ExpressRoute with of Azure hosted services
Dynamics 365
With capabilities such as
Export to Data Warehouse,
the use of a SQL Azure
instance to hold replicas of
Dynamics 365 Customer
Engagement applications
data either for reporting
or replication purposes will
increase.
Data connec- It may be valuable to pro-
SQL Azure tions to SQL Public Peering tect connections to these
Azure resources over ExpressRoute
They would be across public
peering rather than Mic-
rosoft Peering because the
instances would be host-
ed within the customer’s
private subscription rather
than a shared Dynamics
applications subscription
40
with Dynamics 365
Providing analytics capa-

bilities through Cortana
Analytics Suite will allow
access to big data solutions
incorporating data from
both Dynamics 365 Cus-
tomer Engagement applica-
tions and other sources as
Cortana well as the resulting insight
Analytics Suite/ Various connec- from the analytics
Public Peering
Azure Data tions to Azure
Lake They would be across public
peering rather than Mic-
rosoft Peering because the
Implementing
instances would be host-
ExpressRoute with ed within the customer’s
Dynamics 365 private subscription rather
than a shared Dynamics
applications subscription
There may be other public services in the future that also require public peering as
other Azure capabilities are utilized.
Customer Public/Private Cloud Connectivity to/from Dynamics 365 for Finance and
Operation Engagement
Dynamics 365 Customer Engagement applications also allow direct integration with
public or private Azure resources:
• From external sources using the Dynamics 365 for Finance and Operation web
services APIs
• To external sources using web service requests made
41
with Dynamics 365
The implications of this need to be considered in the ExpressRoute routing.
Traffic Type and

Direction
Customers can host
custom applications
in Azure and make
Web Service Inbound from Internal to Data requests of Dynam-
Requests Azure IaaS/PaaS Center ics 365 Custom-
er Engagement
applications web
services
Customers can
Implementing implement custom
ExpressRoute with Web Service Outbound to Azure Internal to Data plug ins/workflow
Dynamics 365 Requests IaaS/PaaS Center activities that make
requests of Azure
hosted services
Setting up ExpressRoute for Dynamics 365

Dynamics 365 itself does not need to be configured specifically for ExpressRoute.
Dynamics 365 as a service has been onboarded to support use with ExpressRoute.
There is no specific configuration of the Dynamics 365 instances themselves that
need to specify that ExpressRoute is being used.
Within the Microsoft network ExpressRoute handles traffic by advertising routing
for specific IP subnets to the specific ExpressRoute circuit against which they have
been configured and as that routing would be advertised across a BGP connection, it
would typically be chosen as the lowest cost connection to reach that destination in
preference to routing via the Internet.
At the customer side, the BGP connection would advertise the IP prefixes for the
services for each peering type configured for that ExpressRoute circuit.
Determining what further network configuration would be needed will depend on
what interactions you wish to route via ExpressRoute.
Server traffic
Inbound traffic
Configuring for inbound traffic will require establishing internal routing within the
data center to prefer connections through the ExpressRoute circuit for traffic to
Microsoft services.
Outbound traffic
Outbound traffic from a Dynamics 365 resource will need the target IP address to
be a public IP address and advertised through an ExpressRoute circuit.
All traffic should be treated as from the Internet though due to the shared nature 42
with Dynamics 365
of the Microsoft cloud services. So typically, a reverse proxy or application gateway

should be used to inspect and control inbound traffic from ExpressRoute.
Client traffic
Client traffic would typically be inbound to the Microsoft services rather than
outbound back to the client.
Inbound traffic
Traffic from users who may be on a variety of clients such as corporate network
attached PCs or in mobile scenarios such as tablet users either on the corporate
network or on public connections.
In these scenarios, if this traffic is to be routed across the ExpressRoute circuit

then the challenge of routing the traffic internally first from the client through the
Implementing LAN or WAN to the subnet connected to ExpressRoute is one for the customer’s
ExpressRoute with network team to perform. It is also their responsibility to ensure that this traffic
Dynamics 365 does not accidentally leak out and connect via the public Internet, Dynamics
365 does not block traffic that is received directly from the Internet. Neither will
ExpressRoute block responses from traffic that was originally received directly from
the Internet. The Dynamics 365 Customer Engagement applications service will still
be advertised publicly on the Internet, so there will be routing paths to the service
available separately from ExpressRoute.
This would typically be ensured through use of proxies within the corporate network
and for mobile devices potentially the additional use of VPN to connect back
into the corporate network first, ensuring that traffic is routed via the corporate
ExpressRoute circuit. Note however, that this could incur overheads compared to
directly accessing the cloud services through a local Internet breakout.
Considerations with ExpressRoute

When implementing ExpressRoute it is as important to understand what it does not
do as what it does. In this section we will explore some common questions and sce-
narios to be considered.
Reusing ExpressRoute across multiple Online Services

A single ExpressRoute connection can be used to access multiple Online Services e.g.
Dynamics 365, Office 365, Azure
43
with Dynamics 365
Dynamics 365
Dublin for Customer Engagement
Azure PaaS
Express Route
Frankfurt
Can reuse same ExpressRoute Azure IaaS
connection across Dynamics
365 and other Online Services.

Implementing
ExpressRoute with
Dynamics 365
Note that ExpressRoute itself does not separate different types of Microsoft services
from a particular subnet. It is possible to utilize BGP Community tags to control the
routing of traffic to particular services across ExpressRoute. Note that Microsoft does
not route traffic back across ExpressRoute selectively based on BGP Communities
tags. If traffic needs to be returned differently based on service type, then it would
be necessary to make sure that the traffic comes from different public IP addresses,
And as any traffic returning to a subnet would be handled at a network level, it would
be dangerous to configure only some traffic from a subnet to utilize ExpressRoute as
this can lead to asymmetric routing.
Microsoft Peering covers Dynamics 365 Customer Engagement applications and Of-
fice 365
When Microsoft peering is enabled, this will configure traffic both Dynamics 365
Customer Engagement applications and Office 365 to be routed via ExpressRoute.
If a customer is already using either Dynamics 365 Customer Engagement appli-

cations or Office 365 without ExpressRoute, then it is important to appreciate the
impact for the existing service of enabling Microsoft Peering through ExpressRoute
which would be the default behavior. It may be necessary to configure routing using
BGP Communities to separate traffic to different services.
Configuration of customer network routing

Enabling ExpressRoute handles the configuration of network traffic within the Micro-
soft network, but does not change the routing of traffic within the customer network
itself. It is necessary to configure the network routing within the customer network to
direct traffic to Microsoft cloud services to the subnet connected to ExpressRoute and
then across the ExpressRoute circuit. 44
with Dynamics 365
We advertise more specific routes for Office 365 and Dynamics 365 over Express-
Route than the routes we advertise on the public Internet. If the customer propagates
the specific routes from us to their network, their user traffic will be routed to Express-
Route because of Longest Prefix Matching (LPM).
A key reason customers run into challenges when configuring ExpressRoute is either
because:
• Their internal network routing is incorrectly setup to route traffic to the Express-
Route connection point
• Or because they have asymmetric routing, where request and response traffic is
routed differently.
• For example, where traffic is routed directly to Microsoft cloud services across
the Internet but then returns via ExpressRoute, triggering firewall exceptions
blocking the return traffic.
Implementing
ExpressRoute with
Dynamics 365 Routing between Dynamics 365 and other Azure
Traffic between services in Microsoft’s data centers would route within the Microsoft
network rather than via the public Internet.
Dynamics 365
Dublin
Express Route
Frankfurt
Azure IaaS
No direct link between Azure IaaS and
Dynamics 365 servers. Within same data
center, these would route normally.

ExpressRoute controls traffic to the Microsoft network, not within it

When connections are made to a private Azure resource such as an IaaS VM, Ex-
pressRoute links the connection made from the customer directly to the customer’s
private Azure resources.
For Public and Microsoft peering, ExpressRoute is a dedicated connection between

the customer network and the edge of the Microsoft network. It is not a dedicated
connection all the way to the specific Dynamics 365 instance for the customer. Once
the traffic reaches the Microsoft network and is identified through the peering rules
as targeting a public resource, either Azure or a Microsoft service like Office 365 or 45
with Dynamics 365
Dynamics 365, the end target is a shared service so the network connection to it is
also shared within the Microsoft network.
ExpressRoute is not enforced as the ONLY route to Dynamics 365

While ExpressRoute can be configured for use connecting to/from Dynamics 365, it
is important to realize that ExpressRoute
• Does not ensure that traffic from within the corporate network uses ExpressRoute.
To ensure that requests from within the corporate network utilize ExpressRoute, the
proxy/routing rules within the corporate network determine this and must be set
up by the customer
• Does not prevent other connections (e.g. users on the Internet) from going directly
to Dynamics 365.
Implementing
ExpressRoute with Doesn't prevent direct access
Dynamics 365 Dublin
Express Route
Frankfurt
Circuit VPN Options

The issue of external connectivity is particularly a concern where mobile users are
involved, especially from mobile devices such as laptops, tablets and phones.
Where this is a concern, there are a number of approaches that can be used to man-
age this
• Where federated authentication is used, ensuring that access to ADFS is only pos-
sible once VPN connections are established to the corporate network
• Azure AD conditional access and Intune can be used to control from which devices
and locations access is allowed and to control the device configuration such as
proxies, VPN and routing
46
with Dynamics 365
Mobile Connectivity can be

Worker direct to Dynamics 365 Dynamics 365
Direct Connection
Express Route
Corporate WiFi or VPN
Frankfurt
Azure IaaS
Connectivity can also be via
corporate infrastructure, e.g.,
ADFS for authentication

Implementing
ExpressRoute with
Dynamics 365
Outbound Traffic from Dynamics 365

Where traffic is routed back out through ExpressRoute, such as to an on-premises
service or Exchange on-premises, there are no controls within ExpressRoute to lock
down the services that make connections. The routing here is all done at the network
level and therefore does not validate the particular service making the request before
routing the traffic.
It is conceivable that requests could be made from other services to a customer ser-
vice. Particularly for Dynamics 365 Customer Engagement applications, it is a shared
service so it is not possible to lock the requests down to a particular set of machines.
It is necessary to consider traffic back through ExpressRoute as coming from an
external source, as although it is coming from a Microsoft data center, Microsoft is
not controlling the source of the requests as other customer services could attempt
connections.
Any connections should be controlled as from an external gateway.
47
with Dynamics 365
Dublin
Express Route
Frankfurt Outbound traffic will route back

via ExpressRoute for Customer En-
gagement, e.g., custom web service
requests, Server Side Sync

Implementing
ExpressRoute with
Dynamics 365
In order to be routed back through ExpressRoute, any service being connected to
must have:
• A publicly discoverable URL
• A Public IP address that matches a subnet configured for an ExpressRoute circuit
peering definition
• Must be in the same region as the requesting service if ExpressRoute standard is
used, or in any region if ExpressRoute Premium is used
This approach is particularly valuable for a number of common integration scenarios
between Online and On-Premises services.
ExpressRoute does not make public cloud services part of customer on-premises
domain
Although ExpressRoute establishes private connections between the customers
on-premises domain and the cloud data center it does not make the cloud services
part of the customer on-premises domain. While this can be done now for customer
specific IaaS resources, this is not the case for public resources like Dynamics 365.
In the case of Dynamics 365 Customer Engagement applications, these are shared
resources and cannot be attached to a customer domain.
For Dynamics 365 for Finance and Operation, while the individual resources are pri-
vate to the customer, the machines are not domain joined to the customer network.
The implication of this for integrations or connections between cloud and on-prem-
ises services is that connections cannot rely on mechanisms like integrated authenti-
cation using domain credentials.
Exchange integration using hybrid mode Server Side Synchronization

Enabling connections between Dynamics 365 Customer Engagement applications
and Exchange On-Premises can be routed across ExpressRoute. 48
with Dynamics 365
While the URL and IP Address to discover the Exchange Web Services must be pub-
lished externally, the actual connection can be controlled so that it can only be ac-
cessed via ExpressRoute. Although this means that if access through ExpressRoute
is lost then connection would be lost until the access is restored. While this reduces
the threat vectors to connect to Exchange, as discussed earlier this does not actually
ensure that only the customer’s particular online service instance is making the con-
nection. Connections across ExpressRoute to Exchange On-Premises would still need
to be validated by the customer.
Microsoft
Network
Requests to Exchange On-
Premises, routed via DNS
Connections to the lookup to an ExpressRoute
Implementing On-Premises Exchange connected subnet
ExpressRoute with Customer server would need to
Dynamics 365 Network
be protected at the
customer gateway
Traffic is routed over

private connection; but
Partner ExpressRoute Microsoft the connection could
Edge Circuit Edge come from any service,
the network routing does
ExpressRoute not validate Peering
Microsoft the requesting
Connected Subnet service is authorized
to connect over that
ExpressRoute circuit
Making requests to on-premises systems exposing web services.

As for Exchange on-premises, making requests to other on-premises systems can
also utilize ExpressRoute to avoid traffic traversing the public Internet.
Only web service traffic utilizing SSL is possible directly from custom plug ins or
workflow activities, but these would then have similar characteristics as connections
to Exchange on-premises and would need to be protected in the same way.
Microsoft
Network
On-Premises Exchange connected subnet
Customer server would need to
be protected at the
Network customer gateway

to connect over that
ExpressRoute circuit
49
with Dynamics 365
Performance
ExpressRoute alone will typically not add significant advantages in performance over
an efficient network connection with available capacity. It is possible that the process
of establishing a dedicated and private connection by your connectivity provider re-
sults in a more optimized connection than your shared Internet connection.
Data Load Throughput to Dynamics 365

When performing data loads to Dynamics 365, it is rarely the network that would
be the bottleneck into Dynamics 365 for data traffic. More likely it is the application
processing that needs to be optimized.
ExpressRoute therefore is rarely a direct contributor to higher throughput of data

load into Dynamics 365. It would however, make the traffic more predictable and
ensure the data is not sent over the public Internet.
Implementing
ExpressRoute with
Dynamics 365
50
Contents
ExpressRoute
Readiness Checklist
Client Routing
WAN Performance
Peering
Asymmetric Routing
Geographical distribution
On-Premises Integration
51
ExpressRoute Readiness
Checklist
ExpressRoute Readiness Checklist

As part of determining if you are ready to implement ExpressRoute for Dynamics 365,
the following scenarios should be validated.
Client Routing
Using ExpressRoute for Dynamics 365 and Office 365 requires traffic routing from the
client via ExpressRoute circuit, rather than via the Internet
This is typically done through proxy setup. Has it been confirmed how the client con-
nectivity will be configured to make sure that appropriate traffic will be routed via the
ExpressRoute circuit?
Are the clients able to connect

via the Internet for non-private
resources, e.g., CDN? Connection to Microsoft
ExpressRoute
Are the clients connecting
Readiness Checklist from Public IP addresses or
n

ctio
hidden behind NAT?

nne
in Holland Center
Co
N
WA
Has the client been configured to use a ExpressRoute
proxy to route traffic to the ExpressRoute Connected Subnet
subnet rather than across the Internet?
WAN Performance
When using ExpressRoute, the performance from a client will only be as good as the
slowest link on the connection and as most clients will be connected to the Express-
Route circuit via a WAN, the capacity and speed of the WAN connection is critical, will
this be sufficient for the required traffic?
52
Checklist
Is the latency and bandwidth of the WAN sufficient to host

the traffic to the performance needed for Dynamics 365
and/or Office 365 as well as it's existing load?
Branch Network Customer Data Using ExpressRoute will

not overcome slow WAN
in Holland Center network connections
WAN Connection

ExpressRoute
Connected Subnet
ExpressRoute Peering
Readiness Checklist
Dynamics 365 uses a combination of Microsoft and Public Peering
Public Peering is used for Learning Path, Voice of the Customer and Tablet Offline
sync
Has the appropriate combination of Microsoft and Public Peering been configured
for your needs?
Is Microsoft and Public Peering

(if capabilities using Public
Branch Network Customer Data peering are used) configured?
in Holland Center
ExpressRoute
Connected Subnet
Asymmetric Routing
Have you configured the network and ExpressRoute to ensure you avoid asymmetric
routing?
53
Checklist
Have you avoided traffic exiting

through the Internet to Microsoft
cloud from an IP that will route back
through ER, i.e., asymmetric routing?
2. Request routed via Internet direct to Microsoft

1. Request
to Microsoft
via Internet et Connection to Microsoft
ern
Branch Network Customer Data 4. Response 3. Response

Int
rejected by routed via

via
in Holland Center
ted
firewall ExpressRoute
Rou

ExpressRoute
Connected Subnet
Microsoft
Customer Operations in Holland Cloud
ExpressRoute
Readiness Checklist
Geographical distribution
If a geographically distributed user base is to be served, has this been considered
in the ExpressRoute circuit connectivity, are multiple circuits needed distributed geo-
graphically for different areas or regions?

in France Center
WAN Connection

ExpressRoute
Connected Subnet
Customer Operations in France

Do multiple sites need their
own separate ExpressRoute
circuit, particularly if they're
Branch Network Customer Data distributed geographically?
in Holland Center
WAN Connection

ExpressRoute
Connected Subnet

54
Checklist
On-Premises Integration
Are connections back into the on-premises network from Microsoft cloud across Ex-
pressRoute protected, are they validated as if coming from the public Internet?
Are any requests incoming across Microsoft

ExpressRoute protected as if they are
from the Internet and authenticated/ Network
validated before being allowed?
On-Premises Exchange connected subnet
Customer server would need to
be protected at the
Network customer gateway

ExpressRoute to connect over that
Readiness Checklist ExpressRoute circuit
55
Microsoft Dynamics 365
This document is provided "as-is". Information and views expressed in this document, including URL and other Internet Web site references,
may change without notice. You bear the risk of using it.
Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or
should be inferred.
This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this
document for your internal, reference purposes.
© 2017 Microsoft Corporation. All rights reserved.
Microsoft, Active Directory, Excel, Hyper-V, Internet Explorer, Microsoft Dynamics, Microsoft Dynamics logo, MSDN, Outlook, Notepad,
SharePoint, Silverlight, Visual C++, Windows, Windows Azure, Windows Live, Windows PowerShell, Windows Server, and Windows Vista
are trademarks of the Microsoft group of companies.
All other trademarks are property of their respective owners.

Microsoft Dynamics 365 and ExpressRoute

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Microsoft Dynamics 365 and ExpressRoute

Enviado por

Direitos autorais:

Formatos disponíveis

Microsoft Dynamics 365

What are the challenges? . . . . . . . . . . . . . . . . . . . . . . . . . . 7

What are the

What are the challenges?

What are the challenges?

What are the

Branch Corporate Public Microsoft Data

Poor WAN Connectivity

What are the challenges?

This can often be because of conditions such as:

Branch Corporate Public Microsoft Data

Poor Internet Connectivity

What are the challenges?

Branch Corporate Public Microsoft Data

These things can be addressed through getting additional bandwidth or separate

Security: Protection in Transit

Branch Corporate Public Microsoft Data

What is Azure ExpressRoute?

What is Azure ExpressRoute

Cloud Exchange Point-to-point Any-to-any (IPVPN)

What is Azure ExpressRoute?

Partner ExpressRoute Microsoft

Traffic to Office 365 Services and Dynamics 365

Structure of ExpressRoute Connections

What is Azure ExpressRoute?

What is Azure ExpressRoute?

What is Azure Partner ExpressRoute Microsoft

ExpressRoute Microsoft Peering

Traffic to Office 365 Services and Dynamics 365 Online

Traffic to Office 365 Services and Dynamics 365 Online

What is Azure ExpressRoute?

When the request is made:

Partner ExpressRoute Microsoft

ExpressRoute Microsoft Peering

Traffic to Office 365 Services and Dynamics 365 Online

What is Azure ExpressRoute?

What is Azure ExpressRoute?

What is Azure ExpressRoute?

ExpressRoute needs to be considered and configured correctly. As the target of the

What is Azure ExpressRoute?

Branch Network Customer Data

Customer Operations in Holland

What is Azure ExpressRoute?

Branch Network Customer Data

WAN Connection Partner ExpressRoute

What is Azure Customer Operations in Holland

Branch Network Customer Data Using ExpressRoute will

WAN Connection Partner ExpressRoute

Customer Operations in Holland

What is Azure ExpressRoute?

Customer Operations in Holland

Branch Network Customer Data

WAN Connection Partner ExpressRoute

Customer Operations in Holland

What is Azure ExpressRoute?

Branch Network Customer Data

WAN Connection Partner ExpressRoute

Customer Operations in France

Branch Network Customer Data

WAN Connection Partner ExpressRoute

Customer Operations in Holland

What is Azure ExpressRoute?

Branch Network Customer Data

What is Azure Customer Operations in France