Configuring Multiple Lync 2013 Standard Edition Front Ends With a Single Database Instance for Monitoring

Intro and Scenario

A few days ago I was talking with a friend of mine that was working on a scenario similar to that described here Why I added a Lync Director Pool (also if I don’t like it).

His company was deploying two Lync 2013 Front Ends (Standard Edition) paired on the same site. A question I was quite surprised was: how do I centralize data from monitoring, rather than spreading them across multiple instances (and thus, creating additional complexity in the reporting) ?

The intuitive answer that I came up with was to use the same SQL instance for both Front Ends.

The previous answer was also supported by a TechNet article: Defining Your Organizations’s Requirements for Monitoring

Citing the interesting part:

How many backend monitoring databases do you need? A single monitoring database can support tens of thousands of users (for Microsoft Lync Server 2010, it was estimated that a collocated database for both monitoring and archiving could support 240,000 users). In addition, a single monitoring database can be used by multiple Front End pools; if you have three Front End pools in your organization then you could associate all three of those pools with the same backend store.

This simply means that, for many organizations, database capacity will not be the deciding factor when determining the number of backend monitoring databases that will be required. Instead, a more important consideration could be network speed. Suppose you have three Front End pools, but one of those pools is located across a slow network connection. In that case, you might want to use two monitoring databases: one database to service the two pools with the good network connection, and a separate database to service the pool with the slower network connection.

Testing it in a Lab

I have replicated the scenario in a lab, with no issue.The test environment is the one you can see in the following image

I have defined a named instance in SQL server.

Then I have used on both Front Ends to the same SQL instance for monitoring

Topology Builder presented no error. Adding monitoring to my Front Ends required a reboot. After that, I had no problem with Lync monitoring and the related reporting.

Was it Enough for me ?

Of course not. I proceeded to open a case with Microsoft, to confirm that the solution was supported. The response was positive.

The sr. support engineer who managed the solution was extremely professional. I cannot quote him for privacy reasons, but I have expressed my satisfaction.

So all’s well ?

As I am writing the solution has been successfully applied in a real-world scenario. I have also to admit that the existing documentation may be a bit confusing. Discussing the problem with Johan Veldhuis @jveldh , he talked to me about a TechNet post Components and Topologies for Monitoring that seemed to point in the opposite direction as indicated.

However, at this point I would say that the closed case may be considered as the final answer.