by Problem
Recently I was working on a Lync 2013 deployment, where trusted application servers (used for Remote Call Control with an NEC PBX) needed to be moved from 2010 to 2013. This work was carried out by an external contractor, who removed the trusted application servers from the Lync Topology, published, and then re-added them to the 2013 pool. I can’t be sure exactly what steps were followed, however shortly after it was discovered that all Lync Front End services across all Front End servers would not start:
Trying to manually start the services would result in the following error:
Checking the Event logs, I could see the following errors:
Again, I’m not sure how this occurred, but it would seem that CMS lost IP address configuration for the Front End servers.
Resolution
To fix the issue, I manually added the Front End server IP addresses to Topology Builder. To do this:
- Open Topology Builder,
- Right click on each Front End server in your pool, and select Edit Properties…
- Instead of using all configured IP Addresses, manually add the server’s IP address
- Publish the topology
Once replicated, I could once again start Lync Front End services.
Happy Lyn… Skyping!
Damien Margaritis
dmunified 
I am not really convinced that there are no negative consequences of the activity you performed.
Immediately came to my mind this issue:
webservice related issue of the PIN authentication that goes dead if the IIS does not listen on all available IPs.
http://uclobby.com/2014/01/20/no-available-servers-to-connect-to-when-trying-to-view-user-pin-status/
Hi Soder,
I can confirm that making this change does not affect the ability to check a user’s PIN status. No negative consequences have been reported (pool of 8000+ users).
Well, if it works in your system, great. However I have seen such cases in the past (personally I have seen, not just simply heard from somebody), where a change seemed not to cause any regression, but after a couple of months some convoluted use-case surfaced sneaky ugly issues, that could be traced back to that particular change several months before. So I am by default very skeptic regarding any such change similar to what you described in this post, and the easy detectability of any regression it may cause. Lync is an ugly over-complicated beast.
Oh come now, it’s not that ugly 🙂
I blame RCC, Now you just need to convince the client to move to Skype4B and use Call Via Work instead.
Sure it uses twice the call legs.. but hey, RCC is dead!