Cloud

Lync Control Panel Fails When Moving Legacy Users

I am working with a customer to migrate their OCS 2007 R2 environment to Lync 2010. Initially, a single Lync Enterprise Front-End server was installed and placed behind a hardware load balancer. As there was only a single front-end server configured at the time, the internal and external web services URLs matched the Lync pool FQDN (lyncpool.domain.com). With the single front-end behind the HLB, everything worked great and we were able to successfully move legacy users with the Lync Control Panel and the Lync Management Shell.

Figure 1 – Hardware Load Balanced Front-End

A week later, we introduced a second Lync Enterprise Front-End server and decided to use DNS Load Balancing for the SIP and media traffic. As a best practice, we continued to use the hardware load balancer for the Lync HTTP/HTTPS web traffic. To accommodate the web traffic change, we updated the internal and external URLs in the Lync Topology builder to lyncweb01.domain.com.

Figure 2 – DNS Load Balancing with HLB Web Services

Microsoft - The Essential Guide to Microsoft Teams End-User Engagement
The Essential Guide to Microsoft Teams End-User Engagement

We take you through 10 best practices, considerations, and suggestions that can enrich your Microsoft Teams deployment and ensure both end-user adoption and engagement.

Get the Guide

Once the topology change was published, we launched the Lync Control Panel to continue migrating legacy OCS 2007 R2 users. All of a sudden, we received the error Move-CsLegacyUser: verify that WMI Provider is installed by running OCSWMIBC.msi. For details, see the inner exception. At this point, I started to scratch my head. OCSWMIBC was installed and obviously had worked before since the topologies were merged and legacy users had been successfully migrated before. Even stranger, we were still able to move legacy users with the Lync Management Shell.

After a bit a digging, the issue seemed to be related to DCOM traffic and the hardware load balancer. I came across the Lync Server 2010 (RTM) Release Notes and Doug Deitterick’s Blog which outlined potential workarounds for this issue. Both articles state that the error was specifically Unable to connect to some of the servers in pool “<pool name>” due to a Distributed Component Object Model (DCOM) error. This was not the case for us though. Again, we were receiving the following failure in the Lync Control Panel:

Even though the errors weren’t exactly the same, we decided to try modifying the BackConnectionHostNames under the Local Security Authority. After reading the workaround, we noticed a few differences:

  1. The Lync Front-End servers already had the BackConnectionHostNames string in the registry (HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaMSV1_0).
  2. The BackConnectionHostNames values were different on each front-end server (see the figure below)

Figure 3 – Original BackConnectionHostNames Settings

Seeing as we already had the VIP for Lync Web services on one of the Lync Front-Ends and the Lync Control Panel wasn’t working, we decided to clean things up a bit. Instead of adding the VIP address on the second Lync Front-End, we simply removed all the entries and added the Lync web services FQDN (lyncweb01.domain.com).

Figure 4 – Corrected BackConnectionHostNames Settings

Once the settings were applied, we restarted each front-end and everything started working again!

About the Author

Skype for Business Team Lead & Senior Solution Architect at Perficient | Microsoft Certified Master: Lync Server | Focused on deploying Microsoft UC solutions

More from this Author

Thoughts on “Lync Control Panel Fails When Moving Legacy Users”

  1. I think this was my issue. I did not “hack” around the registry to fix this. 🙂 I substituted the FQDN for the control panel with the IP address of one of the FE servers, bypassing the HLB, to access the control panel. So I am going to do this for legacy moves. This post pointed me in the right direction though. Hope this helps someone.

  2. Keenan Crockett

    Thanks for the feedback Jason. Glad you’re able to continue with your migrations 🙂

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe to the Weekly Blog Digest:

Sign Up