Running UCMA 2.0 applications on Lync Server 2010
While the most ideal scenario is to only run UCMA 3.0 applications with Lync Server 2010, for many of you this is simply not possible. You may own an application that was written for UCMA 2.0 and you want to upgrade to Lync Server 2010, but the application has not yet been updated to UCMA 3.0. Likewise, you may want to continue running your UCMA 2.0 application on an Office Communications Server 2007 R2 front end but still want it to be accessible by users homed on a Lync Server 2010 front end.
These scenarios are all possible, but unfortunately the steps to configure them are rather confusing. In some respects, this is one area where you really need to follow the directions to the exact letter. Several steps may look rather peculiar but unfortunately must be run exactly as specified.
A note about the UCMA 3.0 runtime
Unfortunately, UCMA 3.0 and UCMA 2.0 cannot be setup on the same machine. This is a limitation caused by their dependencies and therefore when you plan a topology that contains both UCMA 2.0 and UCMA 3.0 applications, you must take this into account. If you have applications of both types, they must exist on separate machines.
UCMA 2.0 on OCS 2007 coexisting with Lync Server 2010
This is the most common scenario, and from here I will cover the typical lifetime of such an application. I will cover directly installing a UCMA 2.0 application on Lync Server 2010 at the end of this blog.
In this scenario, you have at least two pools. One pool has Lync Server 2010 and the other pool has OCS 2007 R2. If your application is not already installed on the OCS 2007 R2 pool, you can do so by running the ApplicationProvisioner tool that is used with OCS 2007 R2 or making the WMI changes yourself. This is the same setup procedure for any OCS 2007 R2 application. After you do this, there is one more step to take to enable it to coexist with Lync Server 2010.
You will need to run the Merge-CsLegacyTopology cmdlet. To use it, run the following
Merge-CsLegacyTopology -TopologyXmlFileName newtopology.xml
Publish-CsTopology -FileName newtopology.xml
Enable-CsTopology
Merge-CsLegacyTopology reads information from WMI and the current Central Management Server topology and creates new entries for the OCS 2007 R2 servers not already in the topology. You then must publish this new topology document for the changes to take effect. The UCMA 2.0 application residing on the OCS 2007 R2 server will now interoperate with Lync Server 2010.
Migrating a UCMA 2.0 application running on OCS 2007 R2 to Lync Server 2010
So your application is happily coexisting now, when your boss informs you that you should retire the OCS 2007 R2 pool and only use Lync Server 2010. This means you will now need to migrate your application to Lync Server 2010. What is the best (only) way to do this?
When you ran Merge-CsLegacyTopology, it created a new trusted application pool for your application's server. This pool is similar to a Lync Server 2010 pool but has a lower version number. However, what really determines what version your application is running under is the version of the registrar that the trusted application pool depends on. Therefore, the first part of migration will be changing the registrar from the OCS 2007 R2 registrar to a Lync Server 2010 registrar.
To view the current registrar, run Get-CsTrustedApplicationPool {pool fqdn}. You will see the Registrar dependency listed.
On your system, though, the version will be set to 4 instead of 5. OCS 2007 R2 = Version 4, while Lync Server 2010 = Version 5. To see the registrar, run Get-CsService {registrar identity}. Alternatively you can use
$myserver = Get-CsTrustedApplicationPool {fqdn}
Get-CsService -Identity $myserver.Registrar
Of course, your registrar will show a version of 4. You can view the available registrars using Get-CsService -Registrar. Once you have selected the registrar, you will need to run the following to change the registrar of the OCS 2007 R2 trusted application pool to a Lync Server 2010 registrar.
Set-CsTrustedApplicationPool {fqdn} -Registrar {identity of Lync Server 2010 registrar}
The interesting thing is normally Set-CsTrustedApplicationPool does not allow you to make any changes to an OCS 2007 R2 pool. To make changes to an OCS 2007 R2 pool, you must make the appropriate changes in WMI and then rerun Merge-CsLegacyTopology as shown above. However, this is the one exception to the rule and Lync Server will allow you to use this cmdlet for an OCS 2007 R2 pool if the only thing being changes is the registrar and the registrar is a Lync Server 2010 registrar. Note that this is a one way operation! It is not possible to change the registrar back to an OCS 2007 R2 registrar.
Once this step is complete, you are still not finished. You will need to change all contact objects so they work in Lync Server 2010. To do this, you will need to migrate them. The syntax for doing this is.
Move-CsApplicationEndpoint {endpoint identity} -TargetApplicationPool {pool fqdn} -Force
Yes, you need to move each endpoint to the pool where it is already homed. In addition, the Force flag is extremely important. Without it the move will not work and you will notice a DCOM error. Once you have 'moved' all of your contacts, your application is now running on Lync Server 2010 and you can safely retire the OCS 2007 R2 pool.
Also note that whenever you create a new contact, you will again need to 'move' it using this cmdlet.
Migrating to a UCMA 3.0 application on Lync Server 2010
Your application is happily chugging away on Lync Server when a few months later your boss comes in and mentions that a UCMA 3.0 version of your application has now been released! You now need to configurate the UCMA 3.0 application on Lync Server while making sure all contacts are preserved. Provisioning the UCMA 3.0 application on Lync Server is the easy part and I will leave that to the product documentation. Where things get tricky is the fact that only one application with the same applicationId can depend on a given registrar at one time.
What you will therefore have to do is set the legacy application's registrar to null first, then configure your UCMA 3.0 application on Lync Server. This means that a service outage in this scenario is unavoidable. To set the registrar to null, simply run.
Set-CsTrustedApplicationPool {pool fqdn} -Registrar $null
Once your UCMA 3.0 application is configured and the pool depends on the same registrar, you will need to run the following to again 'move' your contacts.
Move-CsApplicationEndpoint {identity] -TargetApplicationPool {fqdn} -Force
Again, the pool is the fully qualified domain name of the trusted application pool where the contacts reside. Again this is the exact same pool where they already reside and again the force flag is required.
Luckily, from here the ApplicationProvisioner tool or WMI changes are no longer required. You can now use New-CsTrustedApplicationEndpoint to create new endpoints for your application as it uses UCMA 3.0.
Installing a UCMA 2.0 application on Lync Server 2010
Now that we have gone through the above steps, you may be able to guess how one installs a UCMA 2.0 application on Lync Server. To do this, you need to first use the OCS 2007 R2 ApplicationProvisioner tool or WMI to provision your application exactly as you did in OCS 2007 R2. For the registrar though, you will use the Lync Server 2010 registrar.
The next step is to run Merge-CsTopology
Merge-CsLegacyTopology -TopologyXmlFileName newtopology.xml
Publish-CsTopology -FileName newtopology.xml
Enable-CsTopology
This will create the OCS 2007 R2 version of the pool in your Lync Server topology. Even though you do not have an OCS 2007 R2 front end, as far as Lync Server is concerned this is still an OCS 2007 R2 pool.
Finally, you will need to 'move' your contacts.
Move-CsApplicationEndpoint {identity] -TargetApplicationPool {fqdn} -Force
In order to create new contacts for your application, you will need to continue using the ApplicationProvisioner tool and then run Move-CsApplicationEndpoint with the above parameters. You will not be able to use the *-TrustedApplicationEndpoint cmdlets because they will only work with UCMA 3.0 applications running on Lync Server.