Microsoft Lync and Skype for Business have a rich set of .NET APIs which make it easy to extend the platform and integrate it with other applications. This blog helps explain how to use those APIs.

What You Can and Can’t Do With Federation

Posted: November 18th, 2016 | Author: | Filed under: Uncategorized | No Comments »

With federation and hybrid deployments currently being the only way to get UCMA applications communicating with Skype for Business Online tenants, federation is even more important than before. This post details what a UCMA application can and can’t do when communicating across a federation boundary. Continue reading “What You Can and Can’t Do With Federation” »


UCMA and Office 365: Updates

Posted: November 12th, 2016 | Author: | Filed under: Uncategorized | No Comments »

In an earlier post, I talked about how UCMA applications work with Office 365 users. Since some time has passed, I thought I’d post an update outlining what has changed and what hasn’t when it comes to UCMA compatibility with Office 365 and Skype for Business Online. Continue reading “UCMA and Office 365: Updates” »


Why is my MSPL application not seeing some messages?

Posted: January 19th, 2015 | Author: | Filed under: MSPL | Tags: | 1 Comment »

MSPL (and its managed cousin, which goes by various names) is an extremely powerful tool for customizing Lync Server routing behavior. It can also, at times, be extremely frustrating to troubleshoot, partly because of the complexity of tinkering with the way Lync routes messages, and partly because the debugging tools we’re accustomed to for most .NET development are unavailable with MSPL. One of the most common frustrations I hear from people working with MSPL development is that messages that the script should be picking up and handling are just not going through the script at all. They’re visible in SIP logs, they’re obviously there, but your script somehow doesn’t see them. This post is my attempt to summarize a few of the most common reasons this can happen, and what you can do about it. Continue reading “Why is my MSPL application not seeing some messages?” »


UCMA and Office 365

Posted: January 15th, 2015 | Author: | Filed under: UCMA 4.0 | Tags: , | 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.

Continue reading “UCMA and Office 365” »


MSPL on the Edge Server

Posted: December 28th, 2014 | Author: | Filed under: MSPL | 4 Comments »

MSPL, and its parent SDK, the Lync Server SDK, are some of the most powerful (and complex) tools for modifying Lync Server behavior. I have a number of posts about how to use the Lync Server SDK and what useful things you can do with it. But since my examples always show MSPL scripts being deployed on the Front End Servers, I wanted to briefly talk about what you can do with MSPL on the Edge Servers. Continue reading “MSPL on the Edge Server” »


UCMA applications and Lync paired pools

Posted: November 20th, 2014 | Author: | Filed under: UCMA 4.0 | Tags: , , , , | 2 Comments »

Periodically I get a question about what happens to UCMA applications that are associated with one of the pools in a paired pool architecture when users are failed over to a backup pool. This can be very important since in some cases a UCMA application is serving a critical function for some part of the organization, and so they want to be sure that it will remain available in a failover situation.

Unfortunately, UCMA applications are not automatically failed over when you run the Invoke-CsPoolFailover cmdlet in Lync Server Management Shell. If a pool that is the next hop for a UCMA application goes down, and the users are failed over to the backup pool, the UCMA application will still be out of commission. This means that it’s not uncommon for UCMA applications to be overlooked in failover planning. People may assume they will fail over with everything else, while others may simply not know about the applications. If you want to include UCMA applications in your failover plan, you’ll need to plan for some additional manual steps to fail them over.

Continue reading “UCMA applications and Lync paired pools” »


Sending calls to a voice mail box in UCMA without a missed call notification

Posted: March 31st, 2014 | Author: | Filed under: UCMA 4.0 | Tags: , , | 4 Comments »

A while back, I wrote a post on how to call an Exchange UM voice mail box directly. The trouble with the approach described in that post is that it generates a missed call notification in the Exchange inbox of the recipient. A colleague of mine discovered a way to nix this missed call notification, and I thought I would share it.

You can get a SIP URI that goes directly to a user’s voice mail box by appending ;opaque=app:voicemail to the end of that user’s address of record. For instance, if the user has the SIP URI sip:user@example.com, you can get their voice mail box by calling sip:user@example.com;opaque=app:voicemail. However, this will lead to a missed call notification.

If you instead call sip:user@example.com;opaque=app:voicemail;local-resource-path=voicememo, you will get the user’s voice mail box but there will be no missed call notification.


SIP URI typos and the misleading errors they cause

Posted: March 20th, 2014 | Author: | Filed under: UCMA 4.0 | Tags: , , | 1 Comment »

For a development platform that abstracts away a whole lot of underlying activity, UCMA really does a pretty good job of letting you know the cause when a problem occurs. But there are a few cases where errors in UCMA applications can be utterly bewildering, and probably the most frustrating of these are the ones that result from typos in SIP URIs. Missing a character or misspelling a part of a SIP URI can lead to errors that seem to have no relationship to what is actually going wrong. I wanted to cover a couple of those errors here in the hope of preventing others from tearing their hair out for multiple days trying to troubleshoot these sneaky problems. Continue reading “SIP URI typos and the misleading errors they cause” »


Determining whether a user has Enterprise Voice

Posted: February 16th, 2014 | Author: | Filed under: UCMA 4.0 | Tags: , , , | No Comments »

How can your UCMA application determine whether a Lync user is enabled for Enterprise Voice? The answer is a bit more complex than you might think. In short, the best way appears to be establishing a UserEndpoint for the user in question, subscribing to local owner presence, and checking the information in the userProperties presence category. The rest of this post describes how to do this. Continue reading “Determining whether a user has Enterprise Voice” »


Getting rerouted messages to the right UCMA endpoint

Posted: January 8th, 2014 | Author: | Filed under: MSPL, UCMA 4.0 | 2 Comments »

One of the great things you can do with the Lync Server SDK is reroute calls to a UCMA application. Your MSPL script or managed SIP application can intercept any call that goes through the Front End Server (or any SIP request or response, more generally) and send it to a UCMA application you’ve written, rather than the originally intended recipient. Your application can then handle the request, and proxy it through to the destination, or block it, or do something else entirely. There are more uses for this than I can possibly describe here: recording, call filtering, auto-attendants, compliance, call billing, you name it.

Typically in a case like this the UCMA application has a default routing endpoint so that it will answer all of these calls that have a To SIP URI that doesn’t belong to the application. But what if you don’t want all rerouted calls to go to a single endpoint? What if you need to have a number of endpoints in your application – let’s say one for recording and another for call filtering – and your Lync Server SDK application needs to somehow specify which of the endpoints the rerouted call should go to? Continue reading “Getting rerouted messages to the right UCMA endpoint” »