Lync Development on Office 365: What’s Possible, What’s Not
There’s a lot of buzz around Lync running on Office 365 at the moment. Office 365 is getting the latest features before traditional on-premise installations, and it’s clear that Microsoft see a big future in hosted Lync.
But what about Lync Development? Is it even possible in the cloud? What are the limitations?
Here’s a guide to what you can and can’t do with Office 365:
Client-Side Development
Yes! You can happily create applications which sit on user’s desktop machines and interact with Lync to automate certain functions. You can embed Lync into your line-of-business applications, and write CWEs to show them contextual information. The experience will be identical to a traditional on-premise Lync deployment.
The reason for this is that the Lync Client SDK only interacts with the local Lync process on the user’s machine. That’s why Lync has to be installed for any applications written with the SDK to work. Because the interaction is only with the client, the back-end infrastructure is of no concern to the SDK.
UCMA Application Development
Well, it depends. It depends on whether you want to write applications which use User Endpoints or Application Endpoints. Not sure? See my post Choosing between User and Application Endpoints.
Applications written using User Endpoints should work just fine. Obviously, the user which you’re signing in as should be set up and recognized by Office 365, but after that you should be good to go. I don’t know if this was possible, or whether my original testing was wrong, but you currently can’t do this. It’s a certificate problem, and I hope they update UCMA in the next version to support this – but as of now you can’t. More details when I can pull them together.
However, if it’s Application Endpoints you want to use, at the moment, you’re out of luck. Today, there’s no way of creating Trusted Applications which run on Office 365. Traditionally, UCMA applications require an Application Server, and you don’t get one of those with Office 365. If this situation changes then you’ll be the first to know, but that’s how it is at the moment.
Microsoft SIP Processing Language (MSPL)
Absolutely not! MSPL scripts sit on the core Lync servers and can be used to alter, refuse or re-route traffic. They require direct access to the server, and if incorrectly written can destabilize a Lync instance. For those reasons, and also because Office365 is a multi-tenant infrastructure, MSPL scripts are not supported. It’s unlikely that this restriction will be lifted in the near future.
Unified Communication Web API (UCWA)
Not so fast! As of today (July 2014) UCWA is only available on-premises. This may change in the future though, and if so – I’ll be sure to update this post. Of all the technologies which aren’t yet available on Office365, this one feels like the one that will move first (though I have no information to back that up), and Microsoft have already said that it WILL happen (though they didn’t say when).
So now you’re all set and you know what’s possible. It’s worth remembering that this is an area that could change quickly: it’s clear that Microsoft see a big future in Lync Online, and I don’t think they’d intentionally leave any of the APIs behind – it’s just a matter of resourcing and timing. I’ll be sure to keep this page updated if/when things change.
If you haven’t already, make sure you pick the right API and have all the right tools, before you start developing your applications.
Written by Tom Morgan
Tom is a Microsoft Teams Platform developer and Microsoft MVP who has been blogging for over a decade. Find out more.
>>Applications written using User Endpoints should work just fine. Obviously, the user >>which you’re signing in as should be set up and recognized by Office 365, but after >>that you should be good to go.
Tom – would you be so kind to post a code sample that demonstrates this? Not having any luck getting authenticated to the Office 365 environment.
>>Applications written using User Endpoints should work just fine. Obviously, the user >>which you’re signing in as should be set up and recognized by Office 365, but after >>that you should be good to go.
Unfortunately this is not the case. I spent quite a while last summer futzing around with this, trying to get the right voodoo in place to allow a UserEndpoint to sign into Office365. If you spoof the User-Agent string that is used by the official Lync client when creating your CollaborationPlatform, you can almost get it to work. However, Office365 only allows TLS-DSK authentication (see guides on setting up Pidgin with the SipE Lync plugin on Office365), whereas UCMA only exposes None, NTLM and Kerberos authentication.
I say exposes, because if you decompile Microsoft.Rtc.Collaboration, and start poking around, you’ll come across the internal enum SipAuthenticationProtocolsInternal, which the public-facing SipAuthenticationProtocols enum is mapped to within the UCMA library. In addition to the None, NTLM and Kerberos options, there are also TlsDsk and Digest options here. I went so far as to dump Microsoft.Rtc.Collaboration to IL, and hacked in support to add TlsDsk to the public SipAuthenticationProtocols, patching in the various validation code to allow the recompiled library to start connecting the CollaborationPlatform to Office365 using Tls-Dsk. Unfortunately, that’s where I had to stop, because, although there were stubbed-in methods to theoretically do the certificate handshakes, they were not operable – a fair number of the methods threw NotImplementedExceptions.
So UCMA was either finalized before they had time to implement the authentication scheme that Office 365 ended up using, or it was pulled. Either way, I am not optimistic about ever having UCMA support in any reasonable fashion for Office 365.
That’s a great nugget of information – thanks for sharing. Hopefully one day we’ll be able to do this! 🙂
You cant use UCMA ( UserEndpoint / ApplicationEndpoint ) on Office 365/Lync Online environment ( yet )
You’re totally right, and I’ve been meaning to update this post with the reasons why. Thanks for reminding me.