UCMA 3.0 and Lync Server 2013

With the Lync Server 2013 Preview available, you may be starting to give some serious thought to upgrade paths from Lync Server 2010. You may be getting questions from eager customers. What will happen to UCMA 3.0 applications when you move to Lync Server 2013? This post outlines three options to consider: running your application in a 2010/2013 coexistence environment, running your application against Lync 2013 directly, or converting it to UCMA 4.0.

(Disclaimer: everything in this post is based on Lync Server 2013 Preview, and on my own experiences getting UCMA 3.0 applications to work with it. Since a good deal of the documentation has not yet been released for the APIs in Lync Server 2013, there is not much official guidance to rely on at this point.)

Coexistence Environment with Lync Server 2010

Let’s start with the easiest scenario, or at least the easiest from the perspective of what you need to do with the UCMA application. In an environment where you already have Lync Server 2010 installed, you can deploy Lync Server 2013 alongside it. You can then have users homed on either your Lync Server 2010 pools or the new Lync Server 2013 pools. Your UCMA 3.0 applications can remain where they already are, on trusted application servers provisioned in the Lync Server 2010 portion of your topology. In this case, they will communicate with the Lync 2010 Front End Servers, not the Lync 2013 ones, but they will be able to reach Lync 2013 users indirectly through the Lync 2010 Front Ends. The diagram below illustrates this arrangement.

Getting this working doesn’t really involve any special steps. Just install Lync Server 2013 alongside Lync Server 2010 in your environment, and your UCMA 3.0 applications will continue to work. The only difference is that they’ll now be able to interact with users homed on Lync Server 2013 in your environment. It’s hard to beat the straightforwardness of this method, but the downside is that you have to continue maintaining your Lync Server 2010 infrastructure, or at least enough of it to support the UCMA 3.0 application. If you already have Lync Server 2010 in place, you may be planning to do this anyway, but if you want to make a clean cutover, or if you are deploying a UCMA 3.0 application in a brand new Lync Server 2013 environment, this may not be ideal. On that note, let’s have a look at option two.

Working Directly with Lync Server 2013

If you don’t want to keep an entire set of Lync 2010 servers in your environment, but you do want to keep your UCMA 3.0 application, it is possible to have the application run directly against Lync Server 2013. Setting this up from a provisioning perspective is a bit more complicated, but doesn’t require any changes to your actual application (i.e., no need to recompile).

In this configuration, as you can see in the diagram below, all of the Lync 2010 servers go away, except for your trusted application server, which is still a Lync 2010 server but connects directly to your Lync 2013 Front End Pool. Note that you don’t NEED to remove the Lync 2010 servers to do this – you can, if you like, just point the trusted application server to the Lync 2013 pool and leave the Lync 2010 servers alone – but it’s an option if you don’t want to keep an extra set of servers around indefinitely.

Getting the trusted application servers set up in this way, in my experience, is a bit of a convoluted process. I’ll walk through the steps that worked for me here.

First of all, your trusted application servers need to be added to the topology as a Lync 2010 trusted application pool. You can do this in the Lync Topology Builder by expanding the Lync Server 2010 node within your site, and right-clicking on Trusted application servers, then selecting New Trusted Application Pool from the context menu, as you can see in the screen shot below.

Specify the FQDN of your trusted application pool, and for the next hop server select a Lync Server 2013 Standard Edition server or Front End pool.

Once your pool is added to the topology, and you’ve published the modified topology, you can run the Lync Server 2010 installer on each server to set it up as an application server. It’s important that you run the Lync Server 2010 installer, not the 2013 one. Although it will be interacting with Lync 2013 servers, your application server will still have the Lync Server 2010 Core Components on it as well as UCMA 3.0. Note that if you already have a server set up, you don’t need to redo the installation piece.

The next step is where things get a little dicey. If you try to run the New-CsTrustedApplication commandlet in Lync Management Shell on your trusted app server, Lync Management Shell will get very upset. You’ll get an error like the following:

New-CsTrustedApplication : ServiceId
"UserServer:lync2013se.lab.internal" is of RoleId "UserServices:2",
where RoleId "UserServices:2" is not defined.
At line:1 char:1

along with a whole lot of other red text. Basically the Lync 2010 version of Management Shell doesn’t know what to do with the new Lync 2013 server roles.

So, switch over to a Lync 2013 Front End server, and run the Lync 2013 version of Management Shell from there. Use New-CsTrustedApplication to create your trusted application and associate it with your Lync 2010 trusted application pool.

You might think you can just go ahead and run New-CsTrustedApplicationEndpoint to create an endpoint or two for your application. Nope! Trying to do that on the Lync 2013 server will get you another stern rebuke:

New-CsTrustedApplicationEndpoint: Cannot add, remove, or modify endpoints on a legacy pool.
At line:1 char:1 

That’s right, you need to switch back to your Lync 2010 trusted application server to run New-CsTrustedApplicationEndpoint on there.

Once you’ve completed this little PowerShell dance, though, you should have a functional application server with UCMA 3.0 pointed to a Lync 2013 pool.

Converting to UCMA 4.0

As long as you don’t mind the slightly more confusing provisioning process, there’s nothing stopping you from running your UCMA 3.0 applications against Lync Server 2013 for the foreseeable future. But if you want to remove all vestiges of Lync Server 2010 from your environment, the ultimate step is to convert your UCMA 3.0 application to use UCMA 4.0. I think it’s worth mentioning this here as an option because the upgrade path is really pretty painless apart from the need to recompile your application (and presumably retest it and so forth). I can’t by any means guarantee that nothing will break, but there are very few (if any) public API changes between UCMA 3.0 and 4.0. As a bonus, switching to UCMA 4.0 allows you to target .NET 4.5, which might be an advantage for other reasons.

So, to sum up, you have three ways to get your UCMA 3.0 applications ready for Lync 2013: keep a Lync 2010 Front End around, point the applications to Lync Server 2013, or upgrade them to UCMA 4.0. If you have questions, or have another approach to suggest, feel free to post a comment.