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.
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.
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.