Migration and Coexistence of UCMA Applications
This section discusses the steps needed to enable coexistence of Microsoft Unified Communications Managed API (UCMA) 2.0 and Microsoft Unified Communications Managed API (UCMA) 3.0 applications in an environment with Microsoft Office Communications Server 2007, Microsoft Office Communications Server 2007 R2, or Microsoft Lync Server 2010 pools. It is expected that users homed on these different Communications Server/Lync Server 2010 pools will be able to communicate with these applications. This topic also discusses the steps needed to migrate and upgrade a UCMA 2.0 application to a UCMA 3.0 application.
Before going further in the section, read Activation, Provisioning, and Deployment Changes in UCMA 3.0 Core, which should be considered a prerequisite to the material in this section. It is strongly recommended that you read the following topics in the Microsoft Lync Server 2010 Migration Guide: Migration from Communications Server 2007 R2 to Lync Server 2010; Migration from Communications Server 2007 to Lync Server 2010.
An external UCMA trusted application is an application developed by a third party, that is granted trusted status to run against Communications Server/Lync Server 2010 and that runs on its own pool of computers. In this topic, the phrase UCMA 2.0 application should be interpreted to mean an external UCMA 2.0 trusted application. In the same way, a UCMA 3.0 application should be interpreted to mean an external UCMA 3.0 trusted application. An application pool is the group of computers on which these external trusted applications run.
Coexistence and Migration Scenarios
The following table lists a number of different scenarios involving applications created using the three released versions of UCMA running against three Communications Server/Lync Server 2010 releases. The table indicates the level of support for each scenario. Before attempting any of these scenarios, check with your ISV to see which ones are certified for your application.
For more detailed descriptions and illustrations of scenarios 1 through 5, see UCMA 2.0 Core Application Coexistence, Migration, and Deployment.
Scenario |
Description |
|---|---|
Scenario 1: Coexistence of a UCMA 2.0 application with users homed on different Communications Server/ Lync Server 2010 versions A UCMA 2.0 application connects to Office Communications Server 2007 R2, but there are users who are homed on either Lync Server 2010 or Office Communications Server 2007 whom you want to be able to communicate with this application. |
Supported. |
Scenario 2: Upgrading a UCMA 2.0 application to a UCMA 3.0 application You expect to reuse the contact object configurations from the UCMA 2.0 application. Starting Point: scenario 1 After the UCMA 2.0 application is running successfully in a mixed Office Communications Server 2007 R2-Lync Server 2010 topology in coexistence mode, consider upgrading the UCMA 2.0 application to the UCMA 3.0 version of the application. .gif "Note") Note
This scenario should be attempted only if the contact objects for all of the applications in the UCMA 2.0 pool are pointed to by the Lync Server 2010 Registrar pool.
|
Supported and strongly recommended as an upgrade path. |
Scenario 3: In-place migration of a UCMA 2.0 application to allow for decommissioning of an Office Communications Server 2007 R2 pool Starting point: scenario 1 After the UCMA 2.0 application is running successfully in a mixed Office Communications Server 2007 R2-Lync Server 2010 topology in the coexistence mode, consider performing in-place migration of the UCMA 2.0 application. This entails pointing the application and application contact objects to a Lync Server 2010 Registrar pool. The application bits and the application pool are not changed at all. This step is needed before fully decommissioning an Office Communications Server 2007 R2 pool. |
Supported but not recommended, due to complexities involved in adding new contact objects. |
Scenario 4: Direct deployment of an UCMA 2.0 application against pure Lync Server 2010 You need to connect an existing UCMA 2.0 application to Lync Server 2010 in a pure Lync Server 2010 topology without making changes in provisioning and activation logic for Communications Server-specific settings. This happens when the UCMA 2.0 application provided to you by an ISV was originally designed to work against Office Communications Server 2007 R2 but you have a pure Lync Server 2010 greenfield deployment. |
Supported but not recommended, due to complexities involved in deploying the application and adding new contact objects. |
Scenario 5: Upgrading a UCMA 2.0 application to a UCMA 3.0 application after in-place migration or direct deployment of a UCMA 2.0 application Starting points: scenarios 3 or 4 After the UCMA 2.0 application is running successfully against Lync Server 2010 after in-place migration or direct deployment of a UCMA 2.0 application, consider upgrading the UCMA 2.0 application to the UCMA 3.0 version of the application. You expect to reuse the contact object configurations from the UCMA 2.0 application. |
Supported but not recommended, due to complexities involved in scenarios 3 and 4, as well as during upgrade. |
Scenario 6a: Coexistence of a Microsoft Unified Communications Managed API (UCMA) 3.0 application in an Office Communications Server 2007 R2-Lync Server 2010 topology A UCMA 3.0 application connects to Lync Server 2010 but there are users on Office Communications Server 2007 R2 whom you want to be able to communicate with this application. |
Supported. |
Scenario 6b: Coexistence of a UCMA 3.0 application in an Office Communications Server 2007-Lync Server 2010 topology A UCMA 3.0 application connects to Lync Server 2010 but there are users on Office Communications Server 2007 whom you want to be able to communicate with this application. |
Supported. |
Scenario 7: Direct deployment of a UCMA 3.0 application against pure Office Communications Server 2007 R2 A UCMA 3.0 application is intended to deploy against an Office Communications Server 2007 R2 pool. |
Limited support, for UserEndpoint instances using IM and Presence. |
Scenario 8: Coexistence and migration of a Unified Communications Managed API V1.0 application. A Unified Communications Managed API V1.0-based application is intended to work in a coexistence environment, specifically a mixed Office Communications Server 2007–Lync Server 2010 environment or a mixed Office Communications Server 2007 R2–Lync Server 2010 environment. |
Direct coexistence and migration of Unified Communications Managed API V1.0 applications is not supported. Customers with Unified Communications Managed API V1.0 applications must obtain and deploy new versions of their applications from their ISVs, and must compile them using UCMA 2.0 or UCMA 3.0. |
Constraints Associated with the Preceding Scenarios
UCMA 2.0 Windows Management Instrumentation (WMI) activation tools, such as the ApplicationProvisioner.exe sample that was shipped with Office Communications Server 2007 R2, and new Windows PowerShell tools cannot coexist on the same computer.
Important
The source code for ApplicationProvision.exe must be modified before it is used. For more information, see Modifying ApplicationProvisioner.exe Sample Code.
WMI tools, such as the ApplicationProvisioner.exe sample, and new PowerShell tools depend on separate versions of OCSCore.msi. WMI tools use the Office Communications Server 2007 R2 version of OCSCore.msi, while PowerShell tools use the Lync Server 2010 version of OCSCore.msi. The two versions are incompatible and cannot coexist side-by-side. If you need to run both a WMI-based activation tool and PowerShell, the PowerShell Remoting feature might be helpful. For information on how to manage Communications Server components using remote PowerShell, see Quick Start: Managing Microsoft Lync Server 2010 Using Remote PowerShell.
The Lync Server 2010 trusted-application PowerShell cmdlets do not work with UCMA 2.0 deployments.
In order to learn more about when to use WMI versus PowerShell, see the relevant topic in Migration and Coexistence Details.
There is no support for a coexistence topology in which Office Communications Server 2007, Office Communications Server 2007 R2, and Lync Server 2010 are all present together.
The only supported coexistence topologies are the following:
A mixed Office Communications Server 2007–Lync Server 2010 topology.
A mixed Office Communications Server 2007 R2–Lync Server 2010 topology.
If a contact object or user is not homed on a Lync Server 2010 Registrar, UCMA 3.0 APIs are not supported.
There is one exception to this rule: UCMA 3.0 is supported for IM and Presence for Office Communications Server 2007 R2 users. Contact-object-based UCMA 3.0 applications are not supported against Office Communications Server 2007 R2.
UCMA 2.0 and UCMA 3.0 applications cannot be run on the same computer.
There is no workaround available. If a computer is part of a UCMA 2.0 application pool, it cannot also be part of a UCMA 3.0 application pool. A computer in a Lync Server 2010 topology can only be a part of a unique pool. By design, a UCMA 3.0 application cannot be deployed in a UCMA 2.0 application pool.
In a Lync Server 2010 topology, two external trusted application pools can point to the same Lync Server 2010 Registrar pool, but they cannot home the same application or multiple applications with the same ApplicationId.
As an example, suppose you have an application deployed on application pool A, which depends on a Lync Server 2010 Registrar pool R1. You cannot deploy a new version of the same application to pool B, if that pool depends on the same registrar (R1). This is because only one application pool with a particular application deployed on it can depend on a given registrar pool. To work around this problem, disassociate pool A from registrar R1 by running the following PowerShell cmdlet: Set-CsTrustedApplicationPool A –Registrar $null. After running this cmdlet, set up the new application on application pool B.