VMware and SfB/Lync

In attempting to answer some customer questions, I ran across this document from VMware.  Interesting reading, don’t know why I have never seen it before, but maybe the rock I live under blocked the transmission…
https://blogs.vmware.com/apps/2015/01/virtualizing-microsoft-lync-server-lets-clear-confusion.html
YMMV

SfB Conferencing Fails

Disclaimer:  While I found the failures, I did not initially get the fix.  When I saw the fix, I then remembered what I had forgotten.  Dang do I hate it when that happens.

The Scenario

My current project is to replace a seriously ill Lync 2010 deployment with SfB.  As part of Phase 3 of this project, we will be doing full EV and HA/DR.  All in all, an interesting project.
We had the SfB pool installed, and finally we got all the bits and pieces of the network, firewalls, and load balancers done the way we wanted them to be done (with the attendent convincing of network and security teams that we really did need things to be the way we wanted)(and that the errors we were seeing in the various layers where mis-configs on the network, firewall, and HLB layers) so we could move forward with doing the basic client tests.  And from there, move to the more complex testing.  Alas, this did not go so well.  And finding the fix proved to be a bit trying.

The Error

When a user moved to the new SfB pool, no conferencing worked.  This means that 1:1 worked OK, but moving to three or more users in conference bombed immediately.  Some careful testing revealed an “error 500 source 329” which I have seen before, but associated with voice calls.  MVP Greig Sheridan has a nice error message blog.

Oddly, the SfB user could create a meeting – joining which failed miserably for users on both sides of the environment.  Moving the user back to 2010 resulted in the meeting working. 

The Culprit

Because the customer did not want the 2010 environment to be fixed, we did not go past validating topology before we started SfB installs.  What we found was that the customer had never cleaned up the conference directories.  And what appears to be true for the 2010-2013 migrations apparently still holds true for 2010-SfB migrations.  To whit: having an orphaned conference directory screws up 2013 (and SfB) but not 2010.  You can read the baseline stuff here and here.  While these two references don’t exactly match what we were seeing, they were close enough to get the stupid out of my system and allow me to move forward.

The Fix

In my case, I removed the orphaned conference directory with a remove-csconferencedirectory –force command, which I sort of thought might fix things.  But I also had to run (on each SfB front end pool server)

• enable-cscomputer
• bootstrapper
• rebooted the entire mess.

Retesting was flawless.
YMMV