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
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.
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:
- The Lync Front-End servers already had the BackConnectionHostNames string in the registry (HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaMSV1_0).
- 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!