Migration and Coexistence Details

The sections in this topic provide detailed information about migrating applications from previous UCMA versions to current versions, in topologies that can consist of different Microsoft Communications Server/Lync Server 2010 versions.

When Should I Use WMI and When Should I Use PowerShell?

WMI tools such as ApplicationProvisioner.exe, a tool that shipped with the Microsoft Unified Communications Managed API (UCMA) 2.0 SDK, can be used to create trusted service entries and contact objects so that UCMA 2.0 applications continue to work even after an application is migrated. Before using ApplicationProvisioner.exe, you must modify the source code for this tool, and then rebuild it. For more information, see Modifying ApplicationProvisioner.exe Sample Code. In general, Microsoft Lync Server 2010 trusted application PowerShell cmdlets do not work with UCMA 2.0 deployments. The only exceptions are the following cmdlets.

• Get-Xxx cmdlets.

• The Set-CsTrustedApplicationPool cmdlet, which can be used to retarget the Registrar for an application.

• The Move-CsApplicationEndpoint cmdlet, which can be used to retarget the contact object to a new application pool or populate the missing attributes of a UCMA 2.0 application contact object, when the contact object must be routed through the Lync Server 2010 Registrar.

Migrating Trusted Service Entries Using Microsoft Lync Server 2010 Topology Builder or PowerShell Cmdlets

Using Topology Builder

1. Launch Microsoft Lync Server 2010, Topology Builder.

2. After the existing topology is loaded, under Action, choose Merge 2007 or 2007 R2 Topology. This launches a wizard.

3. Go through the wizard, keeping the default options. After the wizard has finished, check that it completed successfully. There should be no errors in the UI.

4. Select Publish Topology and complete the wizard, as in the previous step.

Using PowerShell

1. From the Start menu, in the Microsoft Lync Server 2010 program group, open Lync Server Management Shell.

2. Run the following PowerShell cmdlet. Merge-CsLegacyTopology -TopologyXmlFileName D:\output.xml

3. Run the following PowerShell cmdlet. Run Publish-CsTopology -FileName D:\output.xml

Verify That Trusted Service Entries Migrated Successfully

Using Microsoft Lync Server 2010 Topology Builder

1. Launch Topology Builder

2. Verify that a BackCompatSite node appears under the Lync Server 2010 node.

3. Under BackCompatSite, in the Trusted application servers node, you should see a pool entry for your application pool.

Using Microsoft Lync Server 2010 Control Panel

1. Launch Microsoft Lync Server 2010 Control Panel.

2. Click Topology.

3. Under the Trusted Application tab, verify that the UCMA 2.0 application has an entry with the correct pool and port numbers, as shown in the following illustration.

Using PowerShell Cmdlets

Although the New-CsTrustedApplicationXxx, Set-CsTrustedApplicationXxx, and Remove-CsTrustedApplicationXxx versions of the Lync Server 2010 cmdlets cannot be used to manage legacy application pools, the Get-CsTrustedApplicationXxx versions can be used to verify that the Pool, Service, Application, and ApplicationEndpoint entries have been created correctly. For more information about any of these cmdlets, run get-help <cmdlet>.

The following PowerShell cmdlet is an example. Get-CsTrustedApplicationPool –Identity TrustPool.contoso.com

In this example, the Identity parameter has been used to ensure that only one trusted application pool is retrieved, the pool whose FQDN is TrustPool.contoso.com. After running the cmdlet, you should verify the following settings in the returned value.

• Registrar—should still be the Office Communications Server 2007 R2 pool.

• Applications—should contain a list of all UCMA 2.0 applications running in the pool.

• SiteId—should be Site.BackCompatSite.

Associate the Existing Backward-compatible Legacy Pool with the Lync Server 2010 Registrar

You will need to run Set-CsTrustedApplicationPool with the needed values for your application pool and Lync Server 2010 registrar pool as follows: Set-CsTrustedApplicationPool –Identity TrustPool.contoso.com –Registrar CS14RegistrarPoolA.contoso.com

Get OCSCore.MSI from the Office Communications Server 2007 R2 Installer

The most important thing about this scenario is that the UCMA 2.0 application is expected to be installed in a pure Lync Server 2010 environment using Office Communications Server 2007 R2 WMI tools, which require the Office Communications Server 2007 R2 version of OCSCore. The application also needs OCSCore.msi at run time if it uses WMI-based auto-provisioning. The OCSCore Components runtime package can be downloaded from Office Communications Server 2007 R2, Core Components Runtime Package.

Install the UCMA 2.0 Application

Install the UCMA 2.0 application just as you would have installed it against Office Communications Server 2007 R2. This includes but is not limited to installing UCMARedist(Runtime), SpeechRedist, and OCSCore, creating trusted service entries, and optionally creating Active Directory contact objects. For more information, see Deploying a UCMA 2.0 Core Application.

Add AllowedDomains Using WBemTest

When a UCMA 2.0 application is deployed directly against Lync Server 2010, the SIP domains used in the Lync Server 2010 environment must be added to the Office Communications Server 2007 R2 SIP domain list before you run the Merge-CsLegacyTopology cmdlet. The application is being deployed as if it were being deployed against Office Communications Server 2007 R2, and then migrated to run against Lync Server 2010.

WBemTest can be used to add the SIP domains, as described in the following procedure.

To add AllowedDomains Using WBemTest

1. In a command prompt window, start WBemTest.exe by typing WBemTest, and pressing ENTER.

2. In the Windows Management Instrumentation Tester dialog box, click Connect.

3. In the Connect dialog box, click Connect.

4. In the Windows Management Instrumentation Tester dialog box, click Enum Classes.

5. In the Superclass Info dialog box, click OK.

6. In the Query Result dialog box, scroll down the listbox to MSFT_SIPDomainData(), and double-click this entry.

7. In the Object editor for MSFT_SIPDomainData dialog box, click Instances. This causes the Query Result dialog box to open, displaying the InstanceIDs for any instances of the MSFT_SIPDomainData WMI class. These entries are the AllowedDomain entries.

8. To add AllowedDomain entries, click Add.

9. In the Instance of MSFT_SIPDomainData dialog box, in the Properties listbox, double-click Address.

10. In the Property Editor dialog box, select the Not NULL radio button.

11. In the Value text input pane, type the name of the new allowed domain; for example, contoso.com.

12. Click Save Property.

13. In the Instance of MSFT_SIPDomainData dialog box, in the Properties listbox, double-click Authoritative. The Authoritative property should not be Null and should be set to False.

14. Click Save Property.

15. In the Instance of MSFT_SIPDomainData dialog box, in the Properties listbox, double-click Default Domain. The Default Domain property should not be Null and should be set to True.

16. Click Save Property.

17. In the Instance of MSFT_SIPDomainData dialog box, click Save Object.