Understanding Cloud networking planning and troubleshooting with Office 365

All right, I’m gonna go ahead and
get started. First of all, thank you to
everyone for hanging out for the last session of the day. My name is Jeff Mealiffe, and I’m a Principal Program Manager
in the Office 365 team. And we’re gonna be talking about
cloud network planning and troubleshooting today. Hopefully you’re all here to
actually [LAUGH] here for this session, we kinda moved
it at the last minute. Which is great because
the original room that it was in, I don’t think would’ve
held all of you. I assume that’s why
we made the switch, looked like the other room had
space for about 20 people. So, just quick little bit of
introduction for myself and then we’ll dig into the content I
am a long time Microsoft employee. I’ve been at the company for
about 17 years. And in my current role, I work in
the Office 365 customer experience team, specifically in
the Fast Track team. It focuses on deployment and
architecture for Office 365 customers
really of all sizes. But the vast majority of
issues that ideal with tend to be more around the enterprise
space, very large organizations. And I deal with sort of a broad set
of escalations that come into my team around both major
problems that have occurred. So if you have a problem with Office
365 and your CEO picks up the phone and calls Satya Nadella and starts
yelling at him, there’s a very good chance that you’re gonna end up on
the phone with me at some point. And I also deal with issues
primarily around identity and cloud networking that are sort
of more run state issues. So customers who are interested in
deploying and talking to them and making sure that the right
things are being done, the right architecture
choices are being made. So you’ll have a successful
experience with our products, and that’s why here today. And actually, as I mentioned in the
previous session that I did earlier this afternoon, I love coming to
events like this because it means, in general, I get to talk to happy customers as
opposed to the ones that yell at me. So, hopefully you’re all happy today
and you won’t be yelling at me. If you do have questions as we
go through the content today, feel free to raise your hand. You may have to raise it really high
and swing it around, cuz I have some very bright lights in my face
for the video recording today. But I am happy to take
questions where I can. And if we can’t get to everything,
come, let me buy you a drink at
the Ask The Experts Session, which is actually right
after this in hall D1. So let’s start off by
talking about some common problems that people run into around
cloud connectivity and performance. Then we’ll drive into some
best practices to try and avoid some of these problems. So common reasons that we see that results in bad
experiences with Office 365, typically include things like
poor connectivity to our network. I mean,
that’s fairly straightforward. If you have poor connectivity
to Microsoft’s network, you’re not gonna have
a great experience accessing data applications
that live on our network. Same thing would be true for
your on-premises system. If you were deploying things and exposing your managed
services to the Internet. If your Internet
connectivity is bad, your users are not gonna be happy. Latency is also a huge problem. There’s a lot of magic that we
can do in software to try and overcome latency issues. Outlook cache mode is a great
example of some magic that we can do in software to try and
avoid issues around latency. But, at the end of the day, there
are always going to be challenges associated with accessing
applications remotely if you have significant latency between your
user and where those applications or the data used within those
applications is hosted. We start talking about physics
problems at that point and there’s only so much we can do with
software to solve physics problems. We also see a lot of issues
around egress configuration. What I mean there is, where you’re
connecting to Microsoft’s network. How many of you work for organizations that have
multiple locations? Okay, we’re gonna be talking quite
a bit about egress configuration and that’s gonna be very
applicable to you. In terms of how you route traffic
between those locations and where you are going to to peer
with Microsoft’s network. In other words where that traffic
is going to connect into Microsoft from those different locations for
an optimal configuration. Bandwidth, another huge problem,
or huge potential problem area. Moving to software as a service
requires that you think about Internet bandwidth or
dedicated bandwidth to Microsoft, a little bit differently than
you may have in the past. If you’ve sized your
Internet connectivity for your organization with the idea
of inbound and outbound SMTP, maybe some external publishing of
Exchange through SharePoint for users that are mobile, with mobile
devices, or working from home. Maybe the occasional VPN use. And now you look at
moving to Office 365 and using that same infrastructure
to allow your users to access services that you had deployed
internally historically. You may need to do some serious
planning around bandwidth utilization for
that internet connectivity. It’s a very common mistake. People make assumptions that
even though they’re using 50% of their internet connectivity
bandwidth today, that they’ll be fine
moving to Office 365. It’s not necessarily true
that whatever buffer you’ve allocated will be enough to
actually support your users. Then we also see issues with
client misconfiguration. And we’ll talk a little bit about
that, both in terms of settings within applications through used to
access services within Office 365, but also operating
system configuration. Network driver configuration has
lots of different places that mistakes can be made that will
result in really painful performance problems when using office 365. So before we go on some details
around, all of these topics, I want to spend a few minutes
talking about, at a high level, what we’re trying to build and
how we’re building it. Cuz that will help to explain some
of the decisions that we’ve made and some of the choices that you have, that you have to make around how
you actually connect to Microsoft. So in general, we make an assumption
that the services that we’re building for Office 365 are going
to be accessed over the internet. We do have alternatives for that, that we’ll talk about
in a little bit. But in general, we’re assuming most
of that access is going to come across the internet. And we want to provide
a fantastic experience with those applications that we’re
building, regardless of where the data associated with
your tenant actually exists. So how many of you are from
outside of the US, and traveled to the US for
this conference? Anybody from Canada? No, okay, so
I can skip over the comments about Office 365 in Canada
in a few slides. That’s good to know. In general,
connectivity in the US is fantastic. Little bit different than some of
the other places that I go and talk to customers. I was in the Middle East in
December and doing some traceroutes there as part of some of the
demonstrations that I typically do. I got some very different
results from what we’ll see when I do those demonstrations here. So connectivity is great, but what
we consider our North America region for Office 365 cuz essentially
the US and Canada today. We don’t have data
centers in Mexico. When you think about that region, it’s actually extremely
large geographically. And when you create
an Office 365 tenant, we’ll just talk about
Exchange Online here for a moment. We’re going to spread out the
mailbox servers that are responsible for your exchange data
across that region. And at any given moment in time,
there may be four different data centers spread out across the US
that are actually proving service to your users in terms of
where that data is located. What we wanna do is make sure
that that doesn’t matter. So from a network connectivity
perspective, we do a lot of work to ensure that those data centers
are well-connected to each other and to you, the best possible
job that we can do. Let’s talk about how we do that. So in terms of Microsoft’s
datacenter infrastructure, I suspect you probably know something about
our data center infrastructure. We typically show some videos and
key notes that show lots and lots of servers racks and
really cool pictures of cooling equipment and
diesel generators and things. In general, we spend a huge
amount amount of money on data center infrastructure as
part of growing our cloud business, both Azure, Office 365, the other
cloud services that we’re offering. We have over 100 data
centers worldwide. So that includes data
centers as well as facilities where we have network
edge components. So not necessarily data centers with
servers that contain customer data, but physical locations where
our network has a presence or where we are storing data. We spend a lot on compliance and
ensuring that we’re doing the right things to ensure that
you can trust us with your data. And with the network traffic
that’s entering our network. And I’m not gonna go into
much more detail on this. We have lots of content out
there around our data center infrastructure and trust components. With multiple global regions,
if you’re in the US and you create a tenant in Office 365 with a
billing address that’s a US address, and your tenant is going to be
created in the North America region. And that has some implications in
terms of where that data is going to be stored. The same would be true if you
were outside of the US and created a tenant in
the United Kingdom. We would make assumptions based on
that billing address in terms of where that data gets located. We have a couple of
sovereign regions, actually three that we’ve announced,
two that are live today. Anyone here works for
the US government? Okay. So we have a US government sovereign region that’s essentially
an isolated self=contained version of Office 365, and we have
one of those for China as well. We’ve announced one in Germany
that has not yet launched but will be available soon. We provide quite a bit of data
about customer data at rest, so we actually show you where
the physical data centers are that could contain your data. We don’t tell you that at
any given moment in time, the active copy of your data
is in insert city name here. But if you go to the URL
that’s up there in the slide, you can actually see a map. You select the region
that you’re in. You’d select North America. And this will actually
show you an image of, or a map of the North America region,
and specifically where the data
centers are that will contain your data for Exchange, SharePoint,
and Skype, customer data rest. So in terms of, I’m actually gonna
skip forward a little bit here. So in terms of data centers in the
US, these locations are the primary locations where we store data today,
and where we have our major
connectivity interchanges. We have data centers in Quebec and
Toronto for Canada, but since we’re not from Canada I’m
not gonna go into that. And I will just keep
pushing forward here. All right, so Office 365 in the US. So if you create your tenant and
specify that you have a US billing address, we make some commitments
around in-country data residency. Essentially what we’re saying
here is even though within the North America region we do
actually have data centers in Canada, we are making
a commitment that we’re going to store your data at rest in
data centers in the US. We make the same commitment
in Canada for tenants that were created after we launched those
Canadian data centers, or tenants that opt in to have their data moved
that will store that in Canada. This is not a guarantee
about data in transit. I’ll just call that out. It is a guarantee about data
at rest, so be aware of that. I’ll skip over Canada. So, talked about data at rest. Let’s talk about
network infrastructure, cuz that’s a little more
relevant to today’s session. So Microsoft’s global network is a
pretty massive feat of engineering. Microsoft’s Global Network should
not be confused with the Internet, though when we look at maps of
it and the level of connectivity around it, it [LAUGH] might
seem sort of like the Internet. This map actually shows the major
locations where we have Microsoft network equipment and the connectivity in
between those locations. And noticed a couple of people
taking pictures of the slides. I’m 100% sure you’re gonna
get access to the slides as well as a full video
recording of today’s sessions, so don’t worry about doing
that unless you want to. I’m totally cool if you want to. So, our network has actually been
recognized as one of the top three networks in the world, both in
terms of the amount of bandwidth that we have within
our network as well as the connectivity locations where
you can peer with our network. You can imagine who those other
two might potentially be. I’m not gonna name any competitors’
names here, but folks who are in the same business that we are,
providing infrastructure services to everyone in the world, tend to have
networks of this size and magnitude. It’s actually kind of fascinating
to think about where we were a decade ago. And look at the size of the network
links that we’re deploying today. But we’re not talking
about megabits. You know, 20 years ago when
you were deploying T1 lines, you were looking at 1.5 megabits for
wide area network clients. We’re not talking about gigabits,
we’re actually talking about terabits of bandwidth now
between our network locations. And when you think about why we’re
allocating amounts of bandwidth like that, it’s for many reasons,
one of which is obviously, we wanna make sure that we
have the right level of resource allocation to be able to
meet your needs for inbound requests from your end users hitting those
services that you’re paying for. But we also have our
own internal needs. You think about, you know I
mentioned with Exchange Online, we might be serving your requests from up to four different
locations simultaneously. Well, we’re actually storing
four copies of your data in those four locations and we’re constantly replicating that
data between all those locations. Additionally, [LAUGH] we
occasionally have the need to say, get out of a data center. It might be a leased facility
in some part of the world. All of a sudden we decide that,
you know, we want to build our own. We actually have to make sure that
we have enough network bandwidth behind the scenes that we can
actually move everybody’s mailboxes in that entire data
center to a new location. We have done this and we do do this. I won’t say on a regular basis
in that particular scenario. That’s not a regular thing but it
happens and we have to support that. So we have a massive investment
in this infrastructure. We pair with over 2,000
ISPs globally and that number continues to grow. And if you do some traceroutes,
actually, into our network, and I’ll give you an example of how
to do this in a few minutes, you can actually kinda start to see
some of that network infrastructure. The DNS names of many of our routers
is associated with airport names or other abbreviations that
are fairly obvious. So you can start to get a sense
of where we are from a network perspective and how traffic
routes through our network. If there’s one thing that you take
away today from this session, it’s that from an Office
365 perspective, we believe in very strongly in something
that we call hot potato routing. And what that means is that we
very strongly believe that for the best possible end user
experience with our services, we want you to get your traffic onto
our network as quickly as possible. That’s not to say that we don’t
trust internet service providers to route traffic appropriately. But from an incentives perspective,
we are very incented to make sure you have the best end user
experience with our applications and services. It’s not necessarily true of
everyone else that you might send your traffic through. So when you think about different
choices that you can make about how to route your traffic,
how to peer with Microsoft, particularly if you have multiple
locations, getting your traffic onto our network as quickly as possible
should always be the goal. So that’s the one most important
thing I want you to take away today. We’ll talk a little bit about how
to do that in a few minutes, but I wanna make sure you
heard that up front. This is a list that
one of my colleagues dumped out of all the different
major peering locations where we peer with ISPs today. And this is actually accessible to
anyone if you wanna go take a look. Anyone here actually ever
looked at peeringdb.org? One, two, okay. For the true internet
networking geeks in the room, you’ll be familiar with this. But it’s a public database of ISPs,
network service providers, folks who build what I’ve been
describing in terms of Microsoft’s network, that will actually
show you both public and private peering locations that
a given network is connected to. And networks on the Internet
are associated what are called autonomous system numbers. Microsoft’s number is 8075. The Microsoft Global Network
is AS8075. So if you go to peering.org and search for AS8075, you’ll get
the entry for Microsoft’s network. And you can actually scroll through
and see all the locations and all the different ISPs that we peer
with and get a sense of whether or not the ISP that you’re using, or the interconnection points where
your network equipment lives are optimal for
connectivity to Microsoft. And if not,
what some of your options might be if you wanted to try and
improve that. So a key task around trying to
make sure that you’re getting onto Microsoft’s network as quickly
as possible is performing a little bit of a network assessment
with Traceroute. Everyone here familiar with
the Traceroute tool, I hope? Yeah? Most of you? Okay. For those of you that aren’t, go do a big search for Traceroute. Very useful tool. It’ll essentially show you the path
that your packets are taking through routers to get to
the intended destination, and the latency associated with
each step in that path. Very, very useful tool for
troubleshooting. So, one of my colleagues on
my team put this together. Three different examples, essentially going to
the same location. The target is his personal
SharePoint site in Office 365. He happens to live in London,
or just outside of London. And as a result his SharePoint
service is hosted in, well, one of two locations,
we do failovers. It’s either in on of our
Dublin data centers or in one of our
Amsterdam data centers. And so the traceroutes
that I’ll show you here are either directed towards
Dublin or Amsterdam. You’ll actually see in this
particular example db3 here, that’s Dublin 3. And that’s the point at
which the traffic is hitting the last data center. And then this is likely
the load balancer sitting in front of the server
that he’s actually using. But, key point here, so this is taken from a machine
in the United Kingdom. It’s peering onto Microsoft’s
network in London, and it’s getting there in somewhere
between 26 and 35 milliseconds. That’s pretty good. Same thing done from
a location in France. I think he was presenting at
a conference like this in Paris. And in this particular case, peering with Microsoft’s network
in Paris in 8 milliseconds. Can’t complain about that,
that’s great connectivity. Similar thing in Florida, I believe
this was when he was in Miami for this same, I think we called
it the Cloud Roadshow then, but essentially the same event. Peering in Miami in 24 milliseconds, not quite as good as the Paris
example, but still, not bad. Certainly would provide
some great experience. You’ll notice from Miami, we’re then crossing the network
once we hit New York City there, we’re going over to London,
and then on to Dublin. And this one’s interesting,
this was taken from Scotland. And you’ll notice that
there’s a problem here. Now, we’ve hidden the names [LAUGH],
or a particular name, because we didn’t really wanna call
somebody out in a public session like this, particularly
since we’re being recorded. So, we’re going from a desktop in
Scotland, and we’re attempting to access a SharePoint site that’s
actually active in Amsterdam. I know that because of the AMS, and the last entry down
there at the end. So we go from London to New York. Still over that ISP’s, whatever
the ISP is that we’re connected to where the desktop exists. And so we go over to New York, and then we actually peer with
Microsoft’s network in New York. And then we come back across
the ocean [LAUGH] and get to Amsterdam eventually. That’s really bad, so
if you see something like this that makes absolutely no
sense geographically, and we do see this more
often than you would think. It’s actually possible to create
routing configurations that take multiple hops across oceans,
more than two. It’s possible to create
interesting routing configurations that go around the world,
potentially more than once. That’s a good opportunity to
have a conversation with your internal network team, as well as
your Internet service provider about how things could
potentially be optimized. Sometimes this is the result
of architectural choices made by a customer, more often than
not when ExpressRoute is in play. We’ll talk about that
in a few minutes. But I would say more often tends
to be a problem at the ISP level. And it can usually pretty
quickly be corrected with a discussion with the ISP. So, this is a very good
thing to take a look at. Takes about ten seconds to do, and gives you a great idea
of how you’re connected. So, just as an example, I always
like to take a quick look at what things look like from here. So I’m actually gonna do a trace
route to my personal SharePoint site from our location here. I did this earlier actually,
both from the demo podium here connected over ethernet, as well as
over Wi-Fi from the speaker room. I found that things are actually
pretty well connected [LAUGH] here. So we’re all in the one
millisecond range, and we’re already on Microsoft’s
network in Chicago, right there,
still with one millisecond latency. Fiber’s wonderful isn’t it? [LAUGH]
>>[LAUGH]>>And so once we go there, we’re actually, at this point, you
can sort of think of this as MPLS. We’re starting to go
elsewhere in the country. And we end up in bn3, which is one
of our data centers in Virginia where the active server for
my SharePoint site is hosted. But the fact that we’re actually
peering with Microsoft’s network in one millisecond is awesome. [LAUGH] There are few locations
outside of the US where we see that kind of connectivity. There are a few, but not many. So hopefully you have
a similar experience. All right, let’s jump back in here. So you have a few different options
when you think about connecting your corporate network infrastructure to
Microsoft’s network infrastructure. There’s really two primary options
that you need to think about, whether you’re gonna use proxies or
direct routing. We’ll talk about pros and
cons of both. In general we like direct routing
better, I’ll explain why. But, we also understand that
proxies are a necessity of life for many of you. How many of you have
a business requirement, either inflicted on you by
your security people or risk management people or
you actually have, potentially, a very legitimate technical reason
from a routing perspective to have all Internet traffic
egress through a proxy today. Come on, there’s gotta more of you. Really? Okay, that’s fantastic, it’s
typically a larger number than that. So you might be tired, we’ll see,
tired or not raising your hands, I don’t know. We’ll get into ExpressRoute
in a little more detail, but I do wanna call out here that if you
do chose the ExpressRoute method of connecting to, actually, I haven’t
even explained what ExpressRoute is. Does everyone here know
what ExpressRoute is? Yeah, a few, okay. Most of you, that’s good. ExpressRoute is our dedicated
connectivity option for both Azure, as well as Office 365. Essentially, all of the cloud
services that Microsoft provides. Think of it as a dedicated
circuit of some type that peers with Microsoft’s network. It is not a dedicated circuit into a Microsoft data center
where your data lives. So just to make sure
you understand that. Many people have that misconception
that my data is in bn3 data center, so if I buy ExpressRoute, I’m gonna
buy it between my data center, or my corporate network,
and the bn3 data center. That’s not what ExpressRoute is, it’s a direct path between your
network and Microsoft’s network. Important to call out for Office 365
that if you do use ExpressRoute, if you choose to go down that path,
we do still require Internet connectivity for
Office 365 to work properly. There are some things that
still utilize the Internet. So visually, how does this look? If we use the proxy method, which
is the top connection method there. You’ve got your internal LAN,
potentially a wide area network, or certainly a wide area network for those of you that have
multiple locations. And you have a proxy somewhere
around your Internet egress where all that traffic is being examined
and proxied out to the Internet. With the direct method, slightly
different, different type of device, or devices,
that are managing that traffic. And instead of proxying, instead of
terminating the session at a proxy, where you can do all kinds of good,
and potentially bad, things with it, you’re just going
through a NAT and PAT device where you’re doing a little bit of
manipulation with network addresses. And the traffic itself
just continues to flow out to the Internet. You can still block things
with devices at that point. But you’re not actually
terminating connections and reestablishing new connections
as you would with a proxy. And then with the ExpressRoute
option, what you’re doing there is defining
a connection between your LAN or WAN and Microsoft’s Global Network, essentially having a dedicated
path for that purpose. And that traffic will also
still have to go out and reach the Internet. This diagram’s
actually not the best. I’d probably call out that
Public Internet line slightly differently there. But, keep in mind that if you
do pick the Internet route, you also still have to manage either
a proxy connection to the Internet or a NATed, PATed connection to
the Internet for Office 356. And that’s for things like DNS. Connections to content distribution
networks that manage static content for all SharePoint websites. There are a few services that do not
operate over ExpressRoute that still require the internet. So if you’re connecting
via a proxy server, what do we need to think about? So as I mentioned, proxy servers will actually
terminate TCP connections and reestablish new ones outbound
to the target on the internet. You can do a couple
of different things. You can intercept the traffic. Make decisions about whether or not
you’re going to allow it through. And you can potentially
inspect it as well, and make some more informed decisions. Now typically, when you’re
actually inspecting traffic, you’re actually breaking SSL. In other words,
you’re allowing the proxy server to sort of impersonate
Microsoft Services via the certificate
configuration on the proxy. And allowing that proxy to
effectively become a man in the middle. You’re doing a man in the middle
attack on all the traffic going out to Office 356. There are products in the proxy or cloud access security broker
space that perform sort of a rudimentary DLP type of
functionality by doing that. We actually run into a lot of
challenges around both performance and functionality with Office
365 if you choose to do that. So we actually pretty
strongly recommend that, if you’re going to use a proxy,
that you avoid terminating SSL connections at the proxy and
that you’re passing things through. You can still make decisions
about whether or not to allow or block a particular destination based
on things like IP ranges or URLs. But we essentially don’t
want the payload of that, that never request
exposed to the proxy or, even more importantly,
manipulated by the proxy. Really important to understand that. So, pros around proxied connections,
good things. If your using proxies to today to
get to the internet, well, it’s gonna be really easy to continue to
use those proxies for Office 365. Since whatever devices you have
on your network internally are already getting out to the
internet through a proxy, this is gonna be very straight forward to
continue to use them for O 365. In terms of firewall configuration,
typically you already have a process whereby the ad band traffic for
those proxies is allowed. So you don’t need to think
through that any more. You’ve likely already
got an auditing or monitoring solution set up. But if you don’t and you’re adding proxies, you now have
a choke point where you have some visibility into this traffic and
you can perform those functions. There’s also a perception, it’s important to use
the word perception, of a security barrier there between
the client and the internet. It’s arguable whether or not you’re
actually gonna see a security benefit by routing your
traffic through a proxy. As opposed to other types of devices
that are gonna be less intrusive in terms of the traffic in that path. One of the biggest problems that
we have with proxies is that, in general,
they manage TCP traffic only. They don’t deal with UDP traffic. UDP is really important for
Skype, particularly Skype media. If Skype Is unable to make
connections over UDP, it will fail over to TCP. But there are performance, and we’ll say end user experience,
implications of doing so. Skype is not going to perform nearly
as well if it cannot utilize that UDP path. And so the Skype team actually has
a fairly specific stance on this, which is that all Skype media
traffic should bypass proxies, just period. Which I strongly agree with. We see this on a regular basis,
so be aware of that. If you have to use proxies,
you may, and well, if you’re going to use Skype,
you will almost certainly need to consider ways to allow that Skype
media traffic to bypass the proxy. And I’ll just leave it there. We have a number of potential
performance issues that could come up, primarily because you’re
adding an additional hop. Where that hop can be more or less intrusive in terms of both the
time taken to process that traffic as well as potentially the ways in
which traffic could be manipulated. So we’re not huge fans of proxies. I kinda like this graph. So this is an example of some
testing that was done with a customer that has five
different locations. Doing a 30MB file download
from Office 365 via proxy connections and
via direct connections. Now, you actually can’t
read the numbers, but you at least have the scale. So in the Houston example here,
there’s a difference of 89 seconds going through a proxy to
download that file versus 15.6, we’ll call it 16 seconds,
in the direct example. Now, this is not due to distance or
anything like that. What this is due to is the fact
that, in all of the cases other than the middle case, the machines
that were in the Leeds office. All the machines in the other
four locations were directed to a particular proxy or
set of proxies that were undersized. Extremely overloaded. And as a result,
there were these significant delays. In Leeds, it’s actually
a slightly better download time. Which is likely due to the fact that
this was just a file downloaded and it had probably been
cached in the proxy. It’s actually faster to download
from the proxy, because that particular proxy or set of proxies
was not overloaded at the time. But this really is just designed to
point out that adding proxies adds additional complexity, additional
things to troubleshoot, and additional space for
problems to occur. So, if a proxy must be used, absolutely make sure that
it’s scaled properly. One of the biggest discussions that
we get into with customers that have proxies is typically around
the massive expenditure they’re going to have to make to scale up
their proxy infrastructure to manage all of these additional connections
going through that infrastructure. And you think about Outlook and
the number of connections that Outlook makes to get to Exchange or
to Office 365. It’s a lot of potentially long-lived
TCP connections that now have to be managed by that proxy. You think about the bandwidth
increase of the requests that are gonna be going through
that proxy as you migrate the services that you’re running
on-premises today to exist within a cloud provider. So scalability is really key there,
as well as NAT capability. And what I’m referring to there is
simply the number of connections going through that infrastructure is
likely to, well, I’ll say likely. Is likely to exhaust existing
NAT pools associated with that infrastructure. In other words, the number
of connections that you can make outbound from a single IP
address is limited by the maximum number of source port numbers that
can be associated with that address. So you typically have to add more
public facing IP addresses to this infrastructure to be able to
support that kind of activity. Same thing is obviously true
in the non-proxy scenario with connections going directly
out from NAT devices. But important to remember
that it matters here, too. And the only other main point that
I’ll make here again is Skype for Business. You need to figure out a way
to move that media traffic such that it’s not going
through the proxy. So direct connectivity. This is what we think of this as
a best practice if you can do it. What we’re talking about here is,
In many of our customers essentially defining a
default route on their network that goes out to the internet. It’s not the only way to do it, but it’s typically the most
straightforward that takes traffic out through a firewall device or
some other type of device that’s going to do network
address translation. Network address translation and
port address translation such that you can make those
outbound connections to Office 365. I did mention earlier that
you can block traffic using these types of solutions. It’s typically not the same level of
granularity that you could perform blocking behavior with a proxy. Usually you’re looking at IP
ranges that you will allow or deny, similar to what you
might do on a firewall. In fact, your firewall may
be your NAT and PAT device, depending on what sort of
scale you are looking at. But you can do that if you
have the need to specifically block certain types of traffic or
only allow traffic to Office 365. That ability exists. So in terms of the positives here, we don’t have the concern
about Skype traffic. So you can certainly run UDP
traffic out through these devices without issue. In general, you have no ability to
do any sort of packet manipulation with these types of devices. So we don’t run to those
type of problems that I mentioned earlier around proxies
with this connectivity model. Additionally since you’re
not going through what could be a centralized set
of proxy infrastructure. With many of the customers
that we talk to, that choose to go with this model,
you often have regional or potentially per location internet
egress And so you’re actually able to do what I was describing
around hot potato routing,. Getting onto our network as close to
the physical location as possible, as opposed to the proxy case where
you may have a single scaled up set of proxy infrastructure and
you end up back-hauling traffic from one location to a central location,
out through a proxy and Effectively carrying all of your traffic with
Microsoft in that central location. Now, if your internet service
provider routing is poor shall we say, I’ll use a nice term, this
may not always be the best method. But if we’ve eliminated that
as a potential problem. We, think this is almost
always the best way to go. So, since you are just passing
traffic directly and there will typically be some restrictions
on where your users can connect to. You do have to manage those The IP addresses that can be
accessed or the URLs, if your devices have the ability to look
at URLs that are being requested. We do publish a list that’s
updated on a regular basis, of all of the IP ranges that
are associated with our services. It’s a fairly complex list. We publish in our SS feeds,
so you can see updates and we publish it in an XML file, so you
can build automation that actually maintains the list within
your firewall roles. There are some partners
in the network connectivity space that
actually have components within their management tools that will
ingest that XML file from us and allow you to automatically consume
it for configuration purposes. But important to just keep in mind
that that is a constantly changing set of IP addresses and if you don’t stay up-to-date with
it you’re going to experience strange outages, let me just say
that, hard to troubleshoot outages. So ExpressRoute is sort of a little bit of a pivot on
the direct connectivity method. So it’s private peering
with the Microsoft network. And it’s connectivity, both for
Azure as well as Office 365 or any other cloud service
that’s being delivered over the Microsoft network
Microsoft global network. I mention and then in that list of
IP ranges we have,we usually break things up by service and we show
whether or not a particular IP range is also exposed over exposed
route.So you can get sense on,it’s on supportoffice.com
if you just search for IP range list or anything like
that you’ll find it very easily. You can get a sense what is and
is not exposed via ExpressRoute. And in a nutshell it’s simply
another way to get to the same endpoints that we provide on the
Internet in a more specific path. In other words you’re still
accessing the exact same Internet endpoints, the same IP addresses that you will
see if you do a DNS Lookup for outlook.office365.com, and
you’re connecting over the Internet. Those are the exact same IP
addresses you’re gonna connect to if you use Express Route. The only difference is that
from a routing perspective we are pushing down route into
your network that say All of these ranges are Microsoft’s
global network. And if you see a packet destined for one of those IP address within those
ranges, send it over the circuit. That’s all it is. Think, about it as another
path to the Internet for a very limited portion
of the Internet. Maybe, that’s a better
way to think about it. So visually this is how we
think about ExpressRoute. You’ll notice, that from
the customer’s network we have ExpressRoute taking it into
Microsoft’s global network. And we also have that path out to
the public Internet which is also connected to Microsoft’s global
network.So everything is reachable both from The internet as well
as via that ExpressRoute path. ExpressRoute has an SLA. So, we certainly do see
customers that are interested in using ExpressRoute in
order to get that SLA. It’s important,
to understand what that SLA means. Because there is an SLA for
Microsoft’s Connectivity, from the ExpressRoute perspective
is likely a different SLA from your network provider to the
point that they peer with Microsoft. So beware of that. It does,
provide predictable performance. If you look at ExpressRoute for
Azure as an example for what we call Azure private peering
which is the way in which you can extend your network infrastructure
into Azure network infrastructure and actually see that as sort
of one fully connected network. Such that virtual machines
you have deployed in Azure are effectively on your network. In that sense, we do talk about the
potential for increased performance. And the alternative there
is Azure Site-to-Site VPN. You can certainly get better
performance over ExpressRoute, than Azure Site-to-Site VPN. No question about that. There are also some other advantages
that are often touted around express route, around security,
reliability, these types of things. In general we associate
those much more with that Azure private pairing. Connectivity to Virtual Machines and other Azure infrastructure
as opposed to Office 365. You can get predictable performance. Now, what I mean by that is the path
that your network traffic takes to reach Microsoft’s network, because
it’s not going through the internet, will be more predictable
in terms of performance. In a given session with one of our
services, your network traffic could be going from Chicago to New York
to Florida to San Francisco and in one instant and in the next
instance it’s going to Canada and Seattle and somewhere else such as
the performance varies from moment to moment, depending on the way
the ISP is configured their routing, with express route you don’t
have the problem With Skype for Business you also have the ability
to actually maintain QoS tagging, code and service tagging into our
network, which has lots of potential benefits particularly if you’re
thinking about cloud PBX and actually using Skype for Business hosted in Microsoft
data centers for phone calls. Very important in many cases for
that. And we do also run into many
customers that have a regulatory requirement around
direct connectivity. This is direct connectivity so
this satisfies that. There are a lot of negatives
that aren’t expressed right now. Actually I spend a fair amount
of my time these days on phone calls trying to talk customers
out of deploying ExpressRoute. ExpressRoute can be
extremely complex. It makes it very difficult to
troubleshoot problems that occur with Office 365 services to
determine whether or not the problem is a networking problem or a problem
actually with the given workload on the service Or with authentication
or with any potential component. Once ExpressRoute is
thrown into the mix, problems with ExpressRoute can
manifest in some many different ways that it makes solving those
escalations very difficult. It doesn’t necessarily
provide better performance. We certainly see cases
Where customers have experienced reduced
performance with ExpressRoute, in the way that their
routing has been configured. Particularly customers that have
multiple physical locations. I’ll give you a specific example
of that in just a moment. Requires a lot of time to
actually get this right. We recommend up to a six month
planning cycle in order to actually make it work properly. And it’s expensive so,
there are reasons to do it, but we wanna make sure that people
go in eyes wide open, understand the pros and cons and are really
doing it for the right reason. We actually have some limitations
now in the deployment process that try and enforce that. You can’t actually, just today,
go buy ExpressRoute for Office 365 and turn it on. That option no longer exists. You actually have to go through a
review process that makes sure that you’re doing it for
an acceptable reason. And you typically end up
on the phone with me or one of my colleagues. To walk through that process before it becomes an option
that’s actually achievable. So why do we say a six month
implementation project is required? So we’re talking about
adding a direct pipe or direct network path between your
network and Microsoft’s network. Seems pretty straight forward and
it is for Azure private peering. When you’re just taking a virtual
network that you have in an Azure datacenter and making that
accessible to your On-Premises network and your datacenter. It’s really, basically one change
that you need to be concerned with and that’s what your network
edge And making sure that at that point where you’re doing your
Express Route pairing, that you are accepting the routes that
are coming down the Express Route so that you’re On-premises network
understands how to get to that virtual network, and potentially
a firewall change there as well, to make sure that that
traffic is allowed. But that’s pretty straightforward,
not that big of a deal. Now when you think about Office 365,
you’re now talking about a whole bunch of different services that
we sell as a suite, Office 365. But are all different in many ways,
including connectivity method, and the endpoints that you’re connecting
to, and how those are accessed, and how clients resolve which
endpoint to connect to. You also have to now
worry about proxies, you have to worry about
firewall configuration in a much in-depth way than you likely
had to with Azure private peering. All of these different points add
up to additional planning time, and additional testing time,
additional implementation time. So that’s what we’re talking about
with that implementation project. And it typically involves, for
large enterprises, a lot of people. I’m not gonna go into all this, you
can see all the stuff on the slide, but there are a lot of people and a
lot of different potential areas of concern that need to be dealt with. So our guidance for
ExpressRoute is that, in general, we think the internet is
the right way to get to Office 365. ExpressRoute is an option. And, in general, we approve
ExpressRoute deployments for Office 365 in a specific
set of reasons. A regulatory requirement that
says you need to have this direct connectivity method. If it will provide a required
benefit for Skype for business, particularly around
media and voice traffic. Or, if we actually see
a real tangible benefit, as opposed to all of your
other connectivity methods. And as I mentioned, there’s a
process that we go through that your Microsoft account team manages
internally within Microsoft. Where a request goes in,
we review it, we potentially have some discussions
directly with you to make sure that the right things
are happening there. But we have a technical block in
place where you can no longer go into your Azure configuration and
just say okay, enable Microsoft peering, which is the Azure name for
Office 365 ExpressRoute. You actually have to have that Azure
subscription ID put on a list that says it’s okay. And that’s the outcome
of the review process. Anybody here still wanna deploy
ExpressRoute after hearing that? [LAUGH] Okay, good. Nobody has to stay after class.>>[LAUGH]
>>You all got the message, great. All right, so You have multiple options in terms
of connectivity to Office 365. From a best practices perspective,
we think direct connectivity to the Internet from physical locations
is really the best choice. Proxies absolutely work. And we certainly accept the fact
that many deployments are going to involve proxy servers because
there’s legitimate business requirements that will result in
practice servers being in the path. But if you’re going to use proxies
the less intrusive you can be with that traffic, the better experience
you’re gonna have with Office 365. So in the connectivity for remote
sites, or if you’re a distributed organization, any company that
has multiple physical sites. There’s some things you need
to think about in terms of how that traffic gets routed. And latency and availability are the
two things that we want to try and optimize for. We wanna try and minimize the latency at Office 365
as much as possible, obviously. And we wanna make sure that from
an availability perspective, you have alternate paths
that the traffic can take. We recommend that you spend
some time trying to assess this a little bit before
you deploy Office 365. Microsoft Premier Services
also has something called the Premier Network Assessment. It’s an offering for any of you that have Microsoft
Premier Contract and you have hours you wanna burn as you’re getting
towards the end of the year. It’s actually a great way to
use up some of those Premier resources without letting
them go to waste. It is a very popular offering for
Premier, so sometimes there’s a little bit of a wait to get one of
the engineers to come do it for you. But, highly recommended, so take a
look at that if you’re interested in digging into this a bit more. Let’s do a brief example of
a customer with multiple sites in the US. So this particular customer
has three physical locations. They’re in San Francisco,
Chicago and New York. You may not be able to read all
the things inside the blue dots. They’re a couple things,
in most cases they’re airport codes. But in all cases they are the
internal identifiers that we use for labeling our network equipment. So when you do a trace route, those
are typically the things that you would see associated
with router names and as you’re looking at those
different hops in the path. So, over here the customer
in San Fransisco is close to the SFO node, etc. The red line indicates
the customer’s managed network. In this case we’ll just
say it’s an MPLS network, they have connectivity for
all of their offices. Those of you who are not asleep will
notice that there’s a missing line to the Chicago office. That is unintentional. I just noticed that, sorry. But just assume there’s another red
dotted line between the customer’s managed network and
their Chicago location. The yellow lines, hopefully,
none of you are color blind. I’m sure that’s the case.>>[LAUGH]
>>I’ll highlight them for you because that’s a bad assumption. So there’s a line here in San
Francisco, a line here in Chicago, and a line here in
in New York as well. Those represent
Internet connectivity. So these customers have Internet egress at each one
of their physical locations. So this is actually great. This customer has followed our
recommendations very nicely. They have Internet egress that’s
physically close to each one of their offices, and they’re using
that to get to Office 365. For the purposes of
this conversation, we’ll say that this customer is
using Exchange Online and all of their mail boxes are currently
somewhere close to Des Moines, Iowa. We actually happen to have
a datacenter in Des Moines, Iowa so could actually be at that same location where we do
network peering in Des Moines. So, they’re going to, let’s say,
we have a user in New York, they’re going to jump out to the Internet
from that location in New York. We’re going to assume that they
have good ISP peering into Microsoft’s network. So they’re likely gonna have
a couple milliseconds to make that hop through their ISP
network into Microsoft’s network at our location
physically in New York. And then they’re going to traverse
Microsoft’s network to get to Des Moines and access their data. That should be a very nice route for
them. Now let’s say this customer says,
I want ExpressRoute, cuz ExpressRoute is the best. It has the word express in it,
therefore it’s faster.>>[LAUGH]
>>You laugh, I hear this often. We’re very good at marketing things. So it’s a good name for it,
unfortunately it’s not always true. So we’re gonna deploy ExpressRoute
with a single circuit in Chicago, cuz we’re cheap. But it’s gonna make things faster
because it has express in the name. So this new wide green line
here in Chicago is going to be an ExpressRoute connection that
peers in our Chicago location. Fantastic for
users that are in Chicago. Well, what this now means is
that the customer has a choice about how they’re going
to route traffic. They’re either going to continue
with the regional Internet egress for users in New York and
San Francisco. Or they’re going to back all their
traffic across their own internal managed network,
potentially an MPLS network, and egress out through their
Chicago office via that ExpressRoute circuit and
onto Microsoft’s network. Well, it’s probably not that big of
a deal if they chose to back all their traffic across
their MPLS network, assuming that they had
the bandwidth to do that. Not always true, but assuming that
they have the bandwidth to do that, because they’re accessing
their data in Iowa. And when you think about
where these locations are, relative, that’s not too bad,
that’s a relatively direct path. But what happens if we change
the equation a little bit? And we also magically add in that
red line that should have been in there previously. And we moved their mail boxes. Mail boxes are now active in our
Columbia datacenter in eastern Washington. And these users in San Francisco,
because the customer decided to back all their traffic, is now accessing
their mailboxes by jumping on to their MPLS network or
their managed network. Heading over here to Chicago,
jumping on to ExpressRoute. Not so express now. Peering with Microsoft’s
network in Chicago and then coming back up here
to eastern Washington. Not optimal. Now, having said that,
this is the US. Those latencies are probably
still pretty low. So, if there was a good business
requirement to do this, it might be okay. You’d have to evaluate that, and
do some trace routes, and make sure that those latencies were all okay,
but certainly not optimal, right? So, what can we do? Well, we could be less cheap. And deploy another ExpressRoute
circuit here in San Fransisco. Now my San Fransisco users
have the ability to egress to ExpressRoute in San Fransisco,
and jump up there quickly. That helps, doesn’t make much
of a difference for New York. But hypothetically, this customer
has their data in four locations, one of which could be
down here in Virginia. There are multiple potential
locations on the east coast where that data could
suddenly become active. So now we’re talking about it, other ExpressRoute
connection in New York, etc. Key point there is that there
is no one size fits all answer. You need to actually
model connectivity, figure out what the best choices
are, given physically where you are, what your ISP route even looks like,
if you’re gonna use ExpressRoute, figuring out where those egress
points are is really critical. And balancing the potential cost of
those, versus using Internet access, is certainly going to be key. So let’s briefly talk about
latency and bandwidth, and then hopefully we’ll have time for
a few questions. So when we think about latency,
the thing you need to be aware of is where you’re connecting to,
obviously. [LAUGH] Now I’m gonna be connecting
from my laptop to my mailbox somewhere. I need to figure where
that somewhere is. Now this is challenging
in different ways, depending on which workload
we’re talking about. So with SharePoint today,
there’s a big asterisk beside this, it’s fairly straightforward. If I do a traceroute to
tenantname.SharePoint.com, my case it’s Melif.SharePoint.com, because that’s the name
of my Office365 tenant. That’s actually going to take me
to the data center that’s hosting SharePoint for me right now. Not so easy with Exchange Online. With Exchange Online, your clients
connect to outlook.office365.com. Has anybody actually ever done
a DNS resolution of that name? That’s useful. [LAUGH] So
we get a bunch of IPv6 addresses, a bunch of IPv4 addresses
associated with that. What that is is a result of a geo
DNS query done by our infrastructure based on the originating IP
address of the DNS query. So, we’ll look at the fact that
identity DNS query from Chicago. We made a decision based on that. And that decision was, which, for those you that understand Exchange,
which cache servers, which will be the first hop of that connectivity
we’re gonna direct that traffic to. And that decision is made for
a couple of reasons. One of them is latency. The other is availability. So some of these
are very close to me. Some of these are not very close
to me, in case there is a natural disaster and I need to failover
to some other servers. Or in case there is some sort of
software issue in that data center. Or we lose power within a data
center, whatever the issue is. These are all in
different locations. Additionally, you have no idea
which locations they are. If you try and do a reverse DNS lookup on those,
you’re not going to get an answer. So you can’t really
do much with that. What we recommend is to
use the SharePoint result as your best option. There really is no good way for
you today to run a traceroute and say, okay,
this trace route is from my machine to wherever my data
is on Exchange Online. It doesn’t exist. So just be aware of that. From a Skype perspective,
it’s also different. So Skype actually
has something called the Skype Operations Framework, not
the Skype for Business Framework, the Skype Operations Framework that
I believe there’s some sessions at this event talking
specifically about it. Part of that includes some details
about their internal deployment, the media relay components that
are used as that first hop. And they also have some
tools that are part of that framework that allow you
to actually estimate your latency between your internal network
environment and Skype for Business. Use those tools in order to figure
out what that latency looks like for Skype, traceroute is not
the right tool for that. The big asterisk around SharePoint
is that we’re also in the process of making some changes in SharePoint
to try and minimize latency issues. And so that’s gonna result
in your first hop for some of your SharePoint traffic,
not necessarily been to the data center where
your SharePoint data is. So, at the moment, tenantname.sharepoint.com with
traceroute is a great way to go. It may, or will, change at
some point in the future, and we’ll have to figure out, we’ll have to publish the new
best practices on how to do this. But for the moment
tenantname.sharepoint.com is the way to go. Important to be aware that there
are multiple factors in latency. There is desktop machine
to the customer egress, essentially the point
that you manage. There is the point
that the ISP manages, where you connect to your ISP and
where your ISP pairs with Microsoft. And then there’s the part that
we manage, within our network. So, I’m not gonna go into much
detail here other than to say, in terms of customer to egress, one really important thing
to be aware of is proxies. So obviously if I wanted
to do a traceroute, and all my connectivity is
going through a proxy, I’m not going to be able
to do that trace route. Proxies don’t allow typically
mange ICMP traffic. So I’m gonna have to actually
run a ping test to figure out latency between my desktops and
my proxy, and then do the same thing between my proxy and the target, and
add up those different components. Also important to be aware, that I mentioned that ExpressRoute
is not always express as you think about all these different paths the
traffic’s taking, this is actually just a different way of looking
at one of the problems that I was describing with that customer
scenario with the three sites. At site A, I have 10 milliseconds
after my proxy server, and I jump onto the Internet and
the latency between my egress from site A to Microsoft’s
network is 30 milliseconds. So, desktop to Microsoft’s
network 40 milliseconds. Not bad. Customer site B,
I’ve got my ExpressRoute pairing. Now if I wanted to use that for
my Office365 connectivity, I’ve got 40 millisecond latency
between Site A and Site B. My ExpressRoute latency
is 20 milliseconds. It’s less than that Internet
latency, which is frequently true. I would expect that
to be normally true. But, because I’m now backhauling
traffic between Site A and Site B, my actually latency to
get to Microsoft’s global network Is now higher. I’m looking at 60 milliseconds
there versus 40 milliseconds. In that particular example, that
latency difference may not matter. But if you are in an area where
those numbers are larger and the difference is larger, then things start to get
really interesting quickly. So what’s a good latency number? In North America, it shouldn’t really be looking
at latencies total, and then latencies of anything more than
like a 100 or a 150 milliseconds. You’ll see that that number is
higher than the number that we claimed for EMEA, or
Middle East and Africa. I would argue that in general,
that’s because the vast majority of those customers that we
work with are in Europe, and Europe is physically
much smaller, and so latencies there
are typically smaller. You’re not looking at
potential cross continent links that we see here
in North America. One other point there. For Skype, it is possible to deal
with latency up to 400 milliseconds. I would hope that given where you are located you are not going to be
seeing those, but it can be managed. 350 milliseconds tends to be where
we start calling out problems. And if you are a customer that’s
using Exchange in online mode, we typically see this if
you’re doing VDI desktops. You typically need to have less than
100 millisecond latency between that VDI infrastructure and
Exchange Online. Otherwise, Outlook starts to get, activity Outlook starts
to get very painful. In terms of actually measuring this
with ping, you generally can not ping services directly in Office 365
with block ICMP at various points. There’s a tool called ps PSPing, that’s a system’s terminal tool you
can find very easily on the Internet that actually performs a ping
using a TCP session, so you can tell it use port 443 and the
HTTPS port to perform the action. And that’ll get through all the way
to an Exchange cache server or the SharePoint or whatever infrastructure
you’re trying to ping. it makes it much easier to do or
possible to do. For a bandwidth perspective, I mentioned bandwidth
planning is important. We do have bandwidth calculators
that are available for Outlook and Skype for Business. Those are fantastic if you actually
have the right inputs, all right? Anytime we calculate something,
particularly when there’s a lot of big numbers involved, the results
are gonna vary pretty dramatically. And, The better the input
obviously the better the output. So we recommend in general using
this approach to estimate bandwidth. Take a look at what you’re currently
using for Exchange bandwidth today. You can go look at network
counters and Perfmon on your Exchange Servers, it’s
fairly straightforward to do that. Monitor over a week so
you can look at peaks. And use that as an input
from a sizing perspective. Consider the impact of SMTP traffic. Obviously, the way you’re gonna
route SMTP, whether your inbound traffic from the Internet is going
to go directly to Office 365. Or whether it’s going to come to
your on premises system first and then get routed up. Those types of choices will have
an impact on how your Internet bandwidth will change
as you move users. If you have SharePoint deployed
today on premises, same thing. You can take a look at
your bandwidth utilization with network counters and
Perfmon on those servers. With OneDrive for Business and Skype for Business Online,
you have some control here. And you also have a calculator for
Skype for Business that’ll help
you figure this out. With OneDrive for Business, you have the ability with group
policies to actually put some throttling into place, essentially,
for that initial upload where we typically see bandwidth problems
in this space, and then round up. When you’re planning for
bandwidth, always round up. You always will end up consuming
more than you need today. So having that extra
is a good way to go. I don’t like showing the,
oops, showing the MSIT number. Microsoft is not like any other
customer that I’ve ever met. So trying to compare yourselves
to what we use is, I mean, you’ll either be above this or
below it or the same. So not much value in showing
that number, but there it is. The other way to deal with this
is to do a pilot, obviously. And that is, move some users to
Office 365, see what that impact is. You have to be careful
how you pick these users, they need to be a cross-section
of your user population. And figure out exactly what
the impact is of moving those users, and then extrapolate linearly
based on those numbers. We actually have a whole
bunch of content that we have done typically at the Ignite
conference around troubleshooting. And this is a conglomeration of topics that we go
into in detail there. If you’re interested,
go to ignite.microsoft.com, do a search for
network troubleshooting. And I believe there’s a session by
Paul who’s one of my coworkers. He goes into great detail on all of
these topics that are listed here and how these can influence
Office 365 performance. I’m not gonna go into specifics on
all of these other than to say that the two that you really need to
spend a little bit of time thinking about and making sure you get
right are TCP window scaling and DNS lookups. Because of the way for Exchange
Online that we do GeoDNS lookups to decide where to
send your traffic, this tends to be less of an issue
in North America than elsewhere in the world, but
important nonetheless here. If you are doing DNS resolution in
locations that are not the same as where your Internet
egress points are. You can end up getting sent to
Exchange Servers that are very different from where you
would expect them to be sent. As an example, I don’t know
why you would do this, but if your desktop machines were
in some way pointed at DNS infrastructure that was in Japan. That means when your users do
a query for outlook.office365.com, we will see that query
come from Japan. And we will send your users
to CAS servers in Japan. [LAUGH] Happy to do that, because we
think that’s the right thing to do to ensure that you have
the best performance. So you can see problems
because of that. TCP window scaling is another area, particularly around SharePoint
where you can run into issues. It refers to the ability of
the network stack in Windows or any other operating system
to change the amount of data that can be sent in a TCP, well, in a TCP transaction, essentially,
without having to receive acknowledgement from the server
before it’ll continue on. And that means that
the scalability of that session or the amount of bandwidth that can
be consumed as latency increases, the amount of bandwidth that
can be consumed decreases. So if you’re accessing
a SharePoint site that’s on the other side of the world,
so latency is high. If TCP window scaling is not
configured properly on your desktop machine as well as all
the infrastructure components in the path, you can actually end
up having very bad performance as opposed to enabling
TCP window scaling and seeing a 60x increase in
performance, potentially. So something to look at there. Other than that, aka.ms/tune
has some great resources. So you’re gonna get this slide deck. There is a set of links at the end that include some of the recorded
sessions that I mentioned. Some of the guidance
pieces that I mentioned, further details on ExpressRoute,
lots of things for you to read. If you need help going to sleep, take a look at some
of these materials. No, I shouldn’t say that, some of
the recordings are actually great. And with that, hopefully all
of you are about to get up and walk out of here with me, and let me
buy you a tasty beverage in hall D1. If you don’t have an opportunity to
ask me a question, either here while I’m packing up, hall D1 at the ask
the experts, feel free to reach out. Here’s my email address and my Twitter handle,
I’m happy to engage where I can. Just be aware that I can’t personally replace
Microsoft support. So [LAUGH] there are occasionally
things that I have to say sorry, call support. But in general, I will be as
helpful as I possibly can. So thank you for coming in and
staying until the end.>>[APPLAUSE]

Bernard Jenkins

Leave a Reply

Your email address will not be published. Required fields are marked *