As I was building my Lync 2010 lab today, I came across an interesting problem. I am calling it interesting because I had already installed two front-end servers which were going to be in an enterprise pool. Now was the time to install SE in simulated multi-site environment.

As I started the install and started step 1 – “Install Local Configuration Store”, I clicked “next” to retrieve topology from CMS as the SE was on a routed subnet that was able to connect to FEs in different AD Site. The error I received (see figure below), instead of expected next page, “Automatic collection of configuration data failed” was least expected. Least expected because I had already built two FEs so common cause of this error, not properly publishing the topology or corrupt store, was out of question. What else could I have missed that is causing this weirdness?

The only other configuration I can think of was firewall. I remembered that I had followed the SQL server documentation and instead of allowing SQL server executable through windows firewall, I had run:

netsh advfirewall firewall add rule name = SQLPort dir = in protocol = tcp action = allow localport = 1433 remoteip = localsubnet profile = DOMAIN

As you may have guessed already, my problem was caused by my own doing. I had SQL port rule configured, however, limited to local subnet! As you can imagine, this is exactly why I was able to build my FEs in the site where SQL server was, trying to build SE in different subnet (regardless of AD site) was hitting a wall, and not a proverbial one! J

As soon as I lifted the subnet restriction and allowed any IP address (see figure above) in configuration of Windows firewall on SQL server, SE install moved on to actually installing local configuration store as it was supposed to. Lesson learned. Albeit at an expense of few hours. Well, I’ll make it a late movie night. J