Microsoft Teams Calendar is not syncing with exchange calendar through APM
Hello, I have implemented a custom APM for exchange 2016 using exchange iapp v 1.2. it is working fine but when I deployed a hybrid exchange with office 365 to use Microsoft Teams, calendar is not working. If I disable APM, Calendar is syncing and working fine. the problem is when the traffic goes through APM. we tried to bypass the APM by adding this rule to the app: priority 1 when HTTP_REQUEST { set is_disabled 0 switch -glob [string tolower [HTTP::path]] { "/ews/mrsproxy.svc" - "/ews/exchange.asmx/wssecurity" { set is_disabled 1 set path [HTTP::path] ACCESS::disable HTTP::path _disable-$path pool /Common/Exchange2016.app/Exchange2016_as_pool7 } "/autodiscover/autodiscover.svc/wssecurity" - "/autodiscover/autodiscover.svc" { set is_disabled 1 set path [HTTP::path] ACCESS::disable HTTP::path _disable-$path pool /Common/Exchange2016.app/Exchange2016_as_pool7 } } } when HTTP_REQUEST_RELEASE { if { [info exists is_disabled] && $is_disabled == 0 } { return } if { [info exists path] } { HTTP::path $path unset is_disabled unset path } } But still the calendar is not working. I appreciate any help or if anyone has run into this issue before. Regards,,,
Exchange Hybrid SMTP Through F5 (using TLS)
Troubleshooting an Exchange Hybrid mail flow issue where inbound mail is failing to route through the F5 appliance. The overall network setup is Exchange Online <-> Palo Alto NGFW <-> F5 LTM <-> Exchange Pool. By default, Exchange Online will attempt to secure the connection over TCP 25 using TLS 1.2, and it seems this is where the issue is taking place. The F5 virtual server configuration is very straightforward, and I'm attempting to configure it to support SSL Passthrough (not Bridging or Offload). The VS is listening on TCP 25 and is performing a single forward to a backend pool, which I've limited to a known good working Exchange Server. No Client/Server SSL profiles have been configured (i.e., Passthrough) on the virtual server. A traffic capture on the virtual server does not show any STARTTLS negotiation taking place, which supports the TLS error we're receiving on the Exchange Online side. As a test, I've moved the flow of traffic around the F5 to allow direct communication between Exchange Online <-> Palo Alto NGFW <-> Exchange Server, and this is operational, and I can see the TLS negotiation taking place. I've referenced the SMTP deployment guide particularly for the Passthrough configuration option, and everything (other than the port 587 not 25) is correct. Both Exchange Online and the Exchange Server will require TLS, but configuring the F5 in bridging mode will not work as we do not have the private key of Exchange Online. https://www.f5.com/pdf/deployment-guides/f5-smtp-dg.pdf Has anyone run into a similar issue where it appears the TLS negotiation is not taking place? BIG-IP Version: 14.1.2.6 BIG-IP Platform: i7800 Exchange Version: 2016 CU16adfs 3.0 and APM O365
We are in the early stages of the design of an adfs 3.0 implementation, and we would like to use APM to provide the functionality of the adfs proxy in our dmz. According to this article https://devcentral.f5.com/articles/big-ip-and-adfs-part-2-ndash-ldquoapmndashan-alternative-to-the-adfs-proxyrdquo It should work. However this document says that ssl termination is not an option: https://blogs.technet.microsoft.com/applicationproxyblog/2014/07/04/ssl-termination-with-web-application-proxy-and-ad-fs-2012-r2/ It is still unclear to me regarding the full ecosystem, but from what I gather a sticking point might be activesync, as the authentication for activesync will be proxied from the cloud to our adfs, and a client certificate of o365 might need to be passed to the backend adfs servers. Can anyone speak of replacing the wap/adfs proxy in adfs 3.0 implementation with F5 apm, and any possible sticking points that they have experienced? Terry