Lync Topologies - an introduction
With the release of the Lync Server 2010 RC yesterday, I am finally free to begin discussing all sorts of things in my head. Today I will discuss one of the most crucial parts of Lync Server 2010 - the topology. There is a huge amount of information here and this will certainly take a number of posts to fully cover. If you're one of those people who enjoy learning all sorts of intricate details that serve no practical purpose other than the fulfill your curiosity, this series of posts will be for you!
Any administrator who needs to deploy Lync Server 2010 will need to understand the basic parts of a topology. However, the overwhelming majority of administrators will not need to understand it in depth. The recommended way to create a topology is through the Topology Builder tool. This tool allows one to specify the servers that make up your topology in a nice GUI fashion and provides helpful information if something is incorrect. It is the way that anyone should create a topology and is the supported way.
However, you know you're curious what the Topology Builder does under the hood, aren't you? What is this Xml document that it creates? What are sites, roles, services, etc? In this series I will cover both the basics - what each server role does - as well as more advanced topics such as what that Xml really means. Before I start doing this, I should probably point out one small detail.
Do not edit your topology by hand!
Yes, I will explain to you in future posts what each node in the topology Xml means, but you should still never edit this file by hand. It is possible to do this and there are a few very unique and rare situations where you may have to do this, but only do this if Microsoft product support specifically tells you to do so - and then only in the way they recommend. It is very easy to cause large portions of your deployment to fail by incorrectly editing this file. It is also extremely easy to do this. Because large portions of our product where developed before the Topology Builder existed, we do have test infrastructure consisting of hand edited topologies and a number of us here have spent a great deal of time debugging issues that arose from incorrect topologies. This is the reason we created the Topology Builder - as it will not let you do this!
So what is a topology?
In Office Communications Server 2007, setting up a deployment could prove tricky. Designing the deployment took careful preparation and each machine then needed to be setup and configured. The administrator would have to go to each machine and physically install specific pieces, then change settings to make everything work. This was a real pain, and we realized that.
Ease of deployment was one of the highest priority pieces for Lync Server 2010 and resulted to dramatic changes in our product infrastructure. The entire administration feature was completely rewritten for Lync Server 2010 due to these changes. The key behind this is a critical piece called the Central Management Server. The Central Management Server does a lot of things that I will get to explaining one day or another, but the most important thing it does is store a list of all the servers involved in the deployment and what each of them does.
The Central Management Server depends on a Central Management Store. When you hear the word "Store" you should really think database. In this case it is a Sql back end that stores all of this information. On each machine involved in the deployment, a Replica runs. This replica contains all of the information in the database. One of the primary jobs of the Central Management Server is to ensure all replicas receive the latest updates to the Central Management Store. The replica typically uses a Sql Express database to store this information. The Central Management Store is the master database for the deployment. It is the only database with write access and all replicas are read only.
The Central Management Server also handles all settings for the deployment. It stores these settings in Xml documents. For each Xml document, there exists a schema that explains exactly what data is allowed in the document. One of these documents is called the "topology". The topology contains the list of all of the servers involved in the deployment and what each one of them does. Every server that is involved in the deployment is listed here - even servers that are not specifically Lync Server components but which only have a trust relationship with Lync Server components.
Over the next several posts, I will begin to explain the topology document in much more detail.