UCMA 3.0 applications and Lync 2013 RTM

Now that Lync 2013 is RTM, UCMA developers are left with a difficult choice.  Do you upgrade your existing apps to UCMA 4.0, or stick with 3.0?  The simplest answer to this question is-do you plan on supporting Lync 2010 or not?  If so, then sticking with 3.0 seems to be the safest bet, since your code will work in both places.  If you absolutely have to have async (given that .net 4.5 support is pretty much the only new feature in UCMA 4), then by all means upgrade.  It’s a painless process, since existing code should just work, but be forewarned that you’ll only be able to run against Lync 3013 pools.  This means either keeping two build configurations and sets of binaries, or not targeting anyone who hasn’t upgraded yet. 

If you do decide to stick with 3.0 for now, the question becomes what has changed from a provisioning standpoint.  Michael Greenlee already went through this exercise for the preview release, and I’m glad to say that things have gotten a little better since then.  I’ll go through a few cases here

Pure Lync 2013 environment, Auto provisioning

First, consider a case of a pure Lync 2013 environment (i.e. not an upgrade from 2010). 

  • Install the prerequisite components on your server.  This includes the UCMA 3.0 runtime, OCSCore.msi, and the TTS/ASR languages you’ll need.  The important thing here is to make sure you use the 2010 versions of these prerequisites (from the Lync 2010 iso)
  • On the application server, open the Lync management shell and run New-CsTrustedApplicationPool –Identity <ApplicationPoolFQDN> -Registrar <lync 2013 FQDN> -Site <Lync 2013 site ID> .  This is the same command you’d run for 2010. 
  • Run New-CsTrustedApplication and New-CsTrustedApplicationEndpoint, just as you would with 2010.
  • Don’t forget to run enable-csTopology to publish your changes.  Otherwise, they’ll get wiped out the next time someone else makes a change.
  • Install the rest of the prerequisites on the app server by running C:\Program Files\Microsoft Lync Server 2010\Deployment\Bootstrapper.exe /BootstrapLocalMgmt /MinCache .  This installs the local SQL express instance for auto provisioning.
  • Run Enable-CSReplica from the Lync powershell window
  • Reboot the server
  • After reboot, run Invoke-CSManagementStoreReplication
  • Verify that the replication status is $True

What’s interesting here is that if you look on the Lync server, you’ll actually see the application server under the 2010 branch in the topology builder, and not the 2013 one. 

    image

At this point, you’re good to get your certificates configured, and add more apps and endpoints to the server if you want.  I’ve found that anything you do using the 2010 PS on the app server works just fine, and keeps things in the 2010 hub.

Pure Lync 2013 environment, Manual provisioning

This case is actually quite similar to the one above, except that instead of creating an entire replica database, you’ll just provide some extra information to the UCMA platform startup.  This has the disadvantage of having to copy over a GRUU, but also means that you don’t have to join the app server to the Lync domain, and don’t have to hope that the replica DB comes up the first time you try.  The steps:

  • Install the prerequisite components on your server.  This includes the UCMA 3.0 runtime, OCSCore.msi, and the TTS/ASR languages you’ll need.  The important thing here is to make sure you use the 2010 versions of these prerequisites (from the Lync 2010 iso)
  • On the application server, open the Lync management shell and run New-CsTrustedApplicationPool –Identity <ApplicationPoolFQDN> -Registrar <lync 2013 FQDN> -Site <Lync 2013 site ID> –RequiresReplication $False .  Note that you’re disabling replication here.
  • Run New-CsTrustedApplication and New-CsTrustedApplicationEndpoint, just as you would with 2010.
  • Don’t forget to run enable-csTopology to publish your changes.  Otherwise, they’ll get wiped out the next time someone else makes a change.
  • Grab the GRUU (and other provisioning parameters) that you need for your app

Now, just to try it out, I ran these cmdlets from the 2013 powershell window instead of the application server, which meant that the app server appeared in the list of Lync 2013 application servers.  When I tried my apps though, everything seemed to work, so it appears that the issues that others were having in the beta about not being able to manage legacy objects from the 2013 PS have been resolved.  I don’t know if there are any long term implications for having the server appear under the 2013 branch though, so if anyone knows of any, please let me know. 

Upgrades

Probably the most common case, here is where you’ll have a 2010 environment, deploy 2013 alongside it, and want to move an application from one server to another.  Unfortunately, this is easier said than done-there is no way to easily move an app from one registrar to another.  Set-CSTrustedApplicationPool fails when you try to change the registrar, even after warning you that applications and endpoints will be orphaned.  The only way to upgrade is to manually re-provision your application…or to write a script to do it for you.  Such a script might look something like this:

function CTTMove-CSTrustedApplicationServer
{
param(
[Parameter(Mandatory = $true, HelpMessage="The current pool FQDN")]
[ValidatePattern("^(.+)$")]
$currentPool=(Get-CsService -Registrar)[0].PoolFqdn,
[Parameter(Mandatory = $true, HelpMessage="The new pool FQDN")]
[ValidatePattern("^(.+)$")]
$newPool=(Get-CsService -Registrar)[0].PoolFqdn,
[Parameter(Mandatory = $true, HelpMessage="The application server FQDN")]
[ValidatePattern("^(.+)$")]
$appServerFQDN=$null,
[Parameter(HelpMessage="Set this to true if moving a 2010 pool-2013 can't auto delete")]
[bool]$isLegacy=$False
)

#get the currently provisioned stuff for the apisLegacyp server
$site=Get-CSSite
$pool=Get-CsTrustedApplicationPool |where{$_.PoolFqdn -eq $appServerFQDN}
$cpus=Get-CsTrustedApplicationComputer |where{$_.Pool -eq $appServerFQDN}
$apps=foreach($a in $pool.Applications) {Get-CsTrustedApplication | where {$_.ApplicationID -eq $a}}
$eps=foreach($a in $pool.Applications){ Get-CsTrustedApplicationEndpoint |where {$_.OwnerUrn -eq $a} }

#remove the application server
if($isLegacy -eq $false)
{
    Remove-CsTrustedApplicationPool $appServerFQDN -Force
    Enable-CsTopology
}
else
{
    Write-Host "Please remove the pool from from the lync 2013 topology builder and publish the topology before proceeding" 
    Read-Host "Hit enter to continue:"
}

#re-add the pool

if($cpus.Count -eq 1)
{
    New-CsTrustedApplicationPool -Identity $pool.PoolFqdn -Registrar $newPool -Site $site.SiteId -RequiresReplication $pool.RequiresReplication -Force
}
else 
{ 
    New-CsTrustedApplicationPool -Identity $pool.PoolFqdn -Registrar $newPool -Site $site.SiteId -RequiresReplication $pool.RequiresReplication -ComputerFqdn $cpus[0].Fqdn -Force
    for($i = 1;$i -le $cups.Count;$i++)
    {
        New-CsTrustedApplicationComputer -Pool $pool.PoolFqdn -Identity $cups[$i].Fqdn
    }
}
foreach($a in $apps) {New-CsTrustedApplication -ApplicationId $a.ApplicationId -TrustedApplicationPoolFqdn $appServerFQDN -Port $a.Port}
foreach($e in $eps) {New-CsTrustedApplicationEndpoint -SipAddress $e.SipAddress -DisplayName $e.DisplayName -LineURI $e.LineUri -TrustedApplicationPoolFqdn $appServerFQDN -ApplicationId $e.OwnerUrn}
Enable-CsTopology
}

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

This script grabs the information about the application pool, computers, applications, and endpoints, and recreates them all using the new registrar.  This assumes that you want to target all applications on a particular server to a new registrar, which will likely be the case if you’re in the process of decommissioning Lync 2010.  Of course, this can’t be completely straightforward…  If you try to run the script as-is, you’ll probably get an error like this:

image

Which is saying that you can’t delete a legacy pool from the 2013 tools.  The problem is, you also can’t delete it from the 2010 powershell.  You can, however, delete it from the 2013 topology builder, but if you do this you lose the provisioning information that this script tries to hard to save.  What you need to do is run the script with –isLegacy $true.  This will gather all the info, pause the script, and then tell you to delete the existing pool.  When it pauses, open the topology builder, locate your pool, delete it, and then publish.  Then, let the script continue and everything should get recreated.  I tried having the script detect this case, but that big red failure of Remove-CSTrustedApplicationPool didn’t actually throw an exception, so I wasn’t able to catch it.  Feel free to modify and improve on this script if you’d like-I’m a .net developer, not a powershell ninja, and this is actually the first reusable script I’ve come up with.  Although, seeing how useful it can be, it probably won’t be the last. 

So, to summarize, UCMA 3.0 applications appear to “just work” against Lync 2013 as promised, which is great to see, and other than the upgrade path being a little more cumbersome than it needs to be, things will continue to work as they have in the past.  Has anyone out there found something about a UCMA 3 app that won’t work with Lync 2013?  If so, shoot me an email or leave a comment-I haven’t seen anything myself, but I’d love to know if there’s something else to watch out for. 

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

One Response to UCMA 3.0 applications and Lync 2013 RTM

  1. Pingback: Tools, runtimes, and versions-what works, and what doesn’t | Chris Bardon

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s