UCMA and Office 365
Posted: January 15th, 2015 | Author: Michael | Filed under: UCMA 4.0 | Tags: Lync Online, Office 365 | 2 Comments »A question I’ve been getting more and more often recently is whether UCMA applications can be made to work with Office 365 (Lync Online), and, if so, how. The short answer is no: a UCMA application can’t register against Lync Online. But if you need to get a UCMA application working with users on Lync Online, it’s worth looking at a couple of alternatives that may be palatable.
Background
First, let’s talk about why you can’t just point your UCMA application at Lync Online. UCMA, as a middle-tier API, is meant for applications that run on servers that are, in most cases, effectively part of the Lync topology. The majority of UCMA applications run on servers that have been configured as part of a “trusted application pool,” are part of the same network as the Lync Front End Servers, and authenticate directly with those Front Ends via mutual TLS.
In any case, UCMA is designed to host endpoints that register directly with the Front End pool, not via the Edge. This poses an obvious problem for Lync Online, where effectively ALL endpoints are external. With Office 365, there is no way to point a UCMA application directly to a Front End. You can’t deploy anything in the Office 365 data centers, and can’t make Lync Online treat servers in your own environment as a trusted application pool.
For all these reasons, the idea of deploying a UCMA application against Office 365 is a non-starter.
So what can you do if you need a UCMA application to serve Office 365 users?
Delivering services via federation
One of the roadblocks to having a UCMA application register against Lync Online, as I mentioned earlier, is that with Lync Online every endpoint is external; every registration comes from a network that is external to Office 365. And UCMA can’t REGISTER through the Edge Server. But what it CAN do is communicate across the Edge using federation. If you can get your UCMA application set up in a separate, on-premise environment, and enable federation between that environment and Office 365, the application can communicate easily with Office 365 users!
The diagram below shows an overview of how this works.
It’s important to be aware of some limitations that exist on what UCMA applications can do with users in a federated environment. You can’t register as a user in the federated environment (using a UserEndpoint), so it’s not possible to publish presence, modify contact lists, or receive calls/IMs on behalf of a federated user. In addition, impersonation doesn’t work in quite the same way; if you use impersonation while starting a conversation with a federated user, the SIP URI will go through but the display name won’t. Still, this can be a very useful method of getting UCMA applications working with Lync Online users in some situations.
Hybrid deployments
Everything above applies equally to hybrid deployments, where there is on-premises Lync Server infrastructure but some Lync users on the same domain are in the cloud. Because the two environments in a hybrid architecture, while they share the same SIP domain(s), are connected via a federation relationship, the same possibilities and same limitations apply with UCMA applications hosted in the on-premises portion of those environments.
Thanks for the article Michael just a few points for my own understanding:
1. When you say you “can’t register as a user in the federated environment” do you mean an O365 user or a user registered on the On-Premise Front End Pool ? Could UCMA running On-Premise register as an O365 user and receive presence updates for O365 users ?
2. If not then do you know how to publish presence information from O365 ? We currently have a Lync integration which uses UCMA to get presence out and I need to understand if something similar is possible for O365.
Thanks for your help.
Ed James
It was my understanding that the trust association with the on-premise Hybrid server is not transitive to the Office 365 environment. In other words, while the on-premise Front End Pool may trust the locally deployed app, but the shared tenant pools on the Office 365 would not share that trust across the hybrid federation even if it is a split domain.
Your last paragraph seems to suggest otherwise. Has this changed in the last year or so?