UCMA applications and Lync paired pools

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.

Creating a backup trusted application pool

Let’s hope you had a backup pool

First, in addition to your backup Front End pool, you will also need a backup application pool. When you create a trusted application pool, you need to specify a single Front End pool as the next hop. This means that each trusted application pool must be tied to a single pool of Front End Servers. If that Front End pool fails, even if your application pool is still available, your UCMA application will be dead in the water. There’s no way to repoint it to another Front End pool. In fact, you can’t even change the next hop without recreating the application pool in the Lync topology.

So you’ll need to have another trusted application pool tied to your backup Front End pool. Note that this can be an active or a passive failover pool. What I mean by that is that you can either (for an active failover pool) have the second pool actively handling communications during normal operation, but have extra capacity in case you need to fail over, or (for a passive failover pool) have the second pool sit around doing essentially nothing, or even turned off, until you need to fail over. One advantage of using an active failover pool is that you can be confident that it’s working properly, has the latest updates, etc., because it’s actually handling real traffic all of the time, whereas it’s tempting to let a passive pool get out of date.

Create trusted application(s) for the backup pool

The backup pool should also have an instance of your trusted application associated with it.

When you create a trusted application using the New-CsTrustedApplication cmdlet in Lync Management Shell, you need to specify the TrustedApplicationPoolFqdn property. This associates that trusted application with a single trusted application pool. If you’ve created trusted applications before, you know that each trusted application has an ApplicationId to identify it, something like urn:application:mgtestapp. You might think this is a unique identifier for the trusted application, but in fact it’s NOT! However, the combination of the ApplicationId and the TrustedApplicationPoolFqdn property IS a unique identifier. So it’s possible to have two trusted applications that look like this:

1. ApplicationId: urn:application:mgtestapp     TrustedApplicationPoolFqdn: server1.greenl.ee
2. ApplicationId: urn:application:mgtestapp     TrustedApplicationPoolFqdn: server2.greenl.ee

This is exactly what you want to do for your backup pool. Create a second instance of your trusted application, with the same ApplicationId but associated with the fully-qualified domain name of your backup trusted application pool.

Failing over

The best approach for failing over the UCMA application depends on what type of communications it handles. There are really three categories to think about:

• Outbound only (like broadcast IM alerts, for example) or no communications (like presence monitoring apps)
• Inbound via PSTN
• Inbound via Lync/Skype

Outbound only

If your application does not receive any inbound communications (whether calls, IMs, conference invitations, whatever) then your job is very easy. In fact, you don’t need to make any Lync topology or config changes at all! Just start up your failover instance of the application, if it’s not already started, and make sure the logic within your application itself is configured to do whatever activities would have been done by the instance of the application that has bit the dust. For example, if the instance that failed normally sends IM alerts to all users in the Americas, you may need the instance in EMEA to start sending the alerts to those users as well.

Inbound via PSTN

If your application receives incoming calls, but only from the PSTN, then you have one small configuration change to make. You’ll need to change the settings for your trusted application endpoints.

Like the New-CsTrustedApplication cmdlet, the New-CsTrustedApplicationEndpoint cmdlet also requires you to specify a TrustedApplicationPoolFQDN parameter. Why? As you may recall from earlier in this article, to uniquely identify an instance of a trusted application, you need both the ApplicationID AND the TrustedApplicationPoolFQDN property. This way, when a request comes in for a certain SIP URI, Lync Server knows which pool of servers to send that request to, based on which instance of the trusted application it belongs to.

Each trusted application endpoint also has a LineURI property. This tells Lync Server what phone number belongs to this endpoint, and only ONE endpoint can own a phone number.

If you put these two facts together – (1) a trusted app endpoint is associated with a specific trusted app pool FQDN, and (2) a SINGLE trusted app endpoint owns a phone number – you can see that if a server goes down, any calls coming to that server’s trusted application endpoints, AND to any phone numbers associated with those endpoints, will start failing.

So, if you’re failing over, you need to REMOVE the phone numbers from the trusted app endpoints that belong to the failed server, and ADD them to trusted app endpoints that belong to the backup server.

You can do this using the Set-CsTrustedApplicationEndpoint cmdlet.

What if the endpoint already has a LineURI?

Uh oh! We have a small problem. If your backup application pool is an active pool, meaning that it is already taking some calls during normal operations, the trusted application endpoint you created for that instance of the application might already have its own phone number (and LineURI) – let’s say a UK phone number for your office in London. You can’t assign two LineURIs to one endpoint, so what do you do now?

The best solution is to have your UCMA application use a default routing endpoint for incoming calls. The linked article has more details, but in a nutshell you designate an endpoint in the application that will handle incoming SIP traffic regardless of what SIP URI the message is supposed to be for. Once you’ve done this, you can add more trusted application endpoints, associate them with the same trusted application, and your application will pick up those calls even though they don’t match the SIP URI owned by the primary endpoint used in your application.

So you can add a completely new trusted application endpoint, assign it the LineURI from your failed instance, and point it to your backup trusted application. Without changing anything else in configuration (assuming you have your default routing endpoint designated correctly in your code, and your application is designed to handle those new calls) the calls for the additional number will just start working.

If you don’t want to go messing around with your code, an alternative is to create a new placeholder UCMA app that receives calls for the LineURI you’re moving, and forwards them to the SIP URI used by your backup trusted application instance.

Inbound via Lync and Skype

If your application receives inbound communications (calls, IMs, etc.) directly to a SIP URI, your options are a bit more limited. You can’t “move” a SIP URI the way you can a LineURI, because it’s an inherent part of the identity of the trusted application endpoint.

Instead, you’ll have to delete the trusted application endpoint that belongs to the failed application, and recreate it, with the same SIP URI, but now pointing to the FQDN of the backup trusted application pool. You would do this using the Remove-CsTrustedApplicationEndpoint and New-CsTrustedApplicationEndpoint cmdlets.

Failing back

There are no special considerations for rolling back once your original server is functioning again; just reverse the steps above. Make sure the application is running again and able to take calls before you undo the changes, or you may have some downtime while you make the switch.

Conclusion

While UCMA applications do not automatically follow suit when you fail over to a backup pool, it’s relatively straightforward with a few extra steps to allow your UCMA applications to mirror the paired pool failover process. Because UCMA applications integrate so smoothly with Lync Server’s own failover architecture, there are a lot of things you don’t need to worry about, like where the users are homed.

If you have any questions about UCMA application failover or DR architectures, feel free to post comments below.