Planning to deploy Office 365 and integrate with your on-premises Exchange infrastructure? Great! While running the Exchange Hybrid Configuration Wizard (HCW) will be one of the highlights it should be a boring and uneventful portion of the project. That will be true if all of the required planning, remediation and preparation was done. If not you’ll be finding out about those issues pretty soon! While we need to plan for Exchange on-premises to inter-operate with Exchange Online (EXO), the integration of Microsoft Teams should also be included and not skipped.
If we look at the current Office 365 URLs and IP address ranges article, there are a couple of things to point out. This article is focused on end user access from their workstation or device. You need to ensure that you are looking at the correct flavour of Office 365, typically this is WW commercial but if you manage a sovereign cloud instance or a US federal instance please ensure you refer to the correct article.
There is also the Other endpoints article, which is meant to facilitate the network discussion of hybrid services such as Exchange and Microsoft Teams. It is not 100% complete, hence the point about facilitating the discussion for your hybrid servers. Issues such as Teams being unable to connect to the calendar of an on-premises mailbox can happen for a multitude of reasons. Articles such as Troubleshoot Microsoft Teams and Exchange Server interaction issues and How Exchange and Microsoft Teams interact are great, but in many cases due to perimeter firewall restrictions Microsoft Teams is simply blocked.
So what IPs does Microsoft Teams use to communicate to on-premises Exchange for calendar integration? Some of the Skype for Business and Microsoft Teams articles point to Office 365 URLs and IP address ranges but that does not explicitly state what is required.
For the calendar integration traffic, this will be EWS calls to Exchange on-premises using HTTPS. We can map that to the IPs called out in the Office 365 URLs and IP address ranges article. Note that at the time of writing the IP netblocks were the same for the main TCP 443 flows. Optional and other media services are out of scope of this discussion.
So you want to see some real traffic to show the IPs used? No problem.
Prove It
The below is from an Exchange 2019 server with Classic Full hybrid deployed. Exchange on-premises is fully functional with EXO. In the below section we will look in the IIS logs for EWS traffic hitting the Exchange server. The front end logs by default are here: C:\inetpub\logs\LogFiles\W3SVC1
Note that the source IP is visible in this environment, it may not be this way for you depending on the exact implementation. See the section on load balancing later.
Looking for anything that contains “EWS” is not a great search query. This broad search term includes on-premises EWS apps, Managed Availability probes and other unwanted fluff. To illustrate this, the current IIS log is u_ex220206.log and if we search for the phrase "EWS" there are many results.
findstr.exe /i "EWS" u_ex220206.log
How about we search for the EWS client name that Microsoft Teams uses? As listed in the Teams and Exchange Interaction Issues article, we can see the EWS Client names listed as:
MicrosoftNinja/*, *Teams/*, and SkypeSpaces/*
So we can change the search term accordingly, for example:
findstr.exe /i "ninja" u_ex220206.log
Much better, and this contains what we want to look at.
If we take an example line from the above, recall that this is standard IIS logging. If you have customised your installation, check the headers listed at the top of the log. In this example we have:
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
2022-02-06 00:37:51 10.0.0.30 POST /ews/exchange.asmx &CorrelationID=<empty>;&cafeReqId=7f12fc99-3e6e-4899-a89d-3285dd87d760; 443 S-1-5-21-600719655-2052185052-986975721-3120 52.113.206.123 MicrosoftNinja/1.0+Teams/1.0+(ExchangeServicesClient/0.0.0.0)+SkypeSpaces/1.0a$*+ - 200 0 0 122
To help answer the question of what IPs Microsoft Teams is using to connect to on-premises Exchange we will focus on the two IP related fields:
S-IP – The server’s local IP – 10.0.0.30
C-IP – The remote IP as far as the Exchange server is concerned – 52.113.206.123. See the note later about load balancing and NAT though.
IP address 52.113.206.123 is part of the 52.112.0.0/14 range that is listed in the documentation. This is highlighted below":
Beware the Load Balancer
If Exchange is behind a load balancer or other device that performs SNAT, then the real client IP will not be visible. In such cases you need to move the search upstream to the device that is doing the SNAT or maybe the perimeter firewall.
Note we only see the internal NAT address in this example as it is behind a load balancer. This is a different environment where the network is 172.16.0.0/24 and the Exchange server 172.16.0.20 is on a different subnet than the load balancer 172.16.1.10. Neither of these IPs are routable on the Internet and we would need to look upstream to be able to see the true client IP.
2022-02-06 20:17:32 172.16.0.20 POST /ews/exchange.asmx &CorrelationID=<empty>;&cafeReqId=2807e47a-c19d-4d62-ad56-940eb56192c5; 443 S-1-5-21-761248450-4132719768-284217924-2106 172.16.1.10 MicrosoftNinja/1.0+Teams/1.0+(ExchangeServicesClient/0.0.0.0)+SkypeSpaces/1.0a$*+ - 200 0 0 44
PowerShell Query Instead
If you prefer to use PowerShell here is a sample query:
Select-String -Path .\u_ex220206.log -Pattern "ninja"
Old habits dictate that I use findstr.exe for efficient text file searches. For larger data sets LogParser 2.2 is great as long as you know the syntax 
Cheers,
Rhoderick
