Lync Server Topologies - on Sites Pools and Services
Today we will finally start delving into the topology document - well sort of. In the previous two days I covered the Content Management Server and how documents are defined. I also mentioned that the topology document itself is stored in the Content Management Store. Today I will cover what exactly a topology is.
In the most basic sense, the topology lists all of the machines in a deployment and which parts of the Lync Server deployment are installed on them. It does this in a hierarchical manner. A topology is divided into one or more sites. Each site contains one or more pools. Each pool contains one or more machines, and on each pool zero or more services may run. In this blog, I will define what all of these mean.
Say you have a global deployment. Your company has offices in North Carolina, Latvia, and Tajikistan (bonus points for those who can figure out why I chose those three places :)) Clearly you will want to set some rules about network traffic and will want to minimize the communications that occur between these locations. Therefore, you will create three sites. A Lync Server site usually corresponds to a geographic region - though you can create multiple sites in the same geographic area if you wish. In truth, a site is a collection of pools.
Each site has a siteId and a site name. Sites can only be created using the Topology Builder. It is not possible to create a site using Powershell. When asked for the name in the Topology Builder, this is the site name. The Topology Builder then assigns a number - typically starting at one - to the site and that is its siteId. In most situations you will not need to know the siteId and can always reference the site using the name, but unfortunately there are still a handful of situations where the siteId is required.
To retrieve all sites in the topology, run Get-CsSite in Powershell. To retrieve a specific site, run Get-CsSite and pass in either the siteId or the site name. The following is a sample of the results returned from Get-CsSite.
Identity : Site:Redmond1
SiteId : co1
Services : {CentralManagement:pool0.vdomain.com, CentralManagementDatabase:client.vdomain.com, ConferencingServe
r:pool0.vdomain.com, UserServer:pool0.vdomain.com...}
Pools : {dc.vdomain.com, pool0.vdomain.com, client.vdomain.com, accessproxy.vdomain.com...}
FederationRoute : EdgeServer:accessproxy.vdomain.com
Description :
DisplayName : Redmond1
SiteType : CentralSite
ParentSite :
The identity will always be the site name (here DisplayName) prefixed with Site:. Whenever you specify a site in Powershell, in most cases you do not need to prefix a site with Site:. The one exception is when scoping a Central Management Server document, in which case this is actually the scope. As you can see the services and pools in the site are also enumerated here.
There are two types of sites in the topology.
Central Sites - These are the standard type of site and are used for most purposes.
Remote Sites - These are used for branch offices. A remote site must have a parent central site.
Each site is made up of one or more pools. Lync Server 2010 pools are very similar logically to Office Communications Server 2007 pools. In fact, for most purposes you can consider them to be the same thing. A Lync Server pool is really a collection of machines. All machines in the pool run the exact same services and one machine in a pool of many can go down without detrimenting the pool.
A pool is defined by a full qualified domain name. To retrieve all pools in a deployment, run Get-CsPool. To retrieve information about a specific pool, run Get-CsPool {fqdn}. The following is an example of the information provided for a pool.
Identity : pool0.vdomain.com
Services : {CentralManagement:pool0.vdomain.com, ConferencingServer:pool0.vdomain.com, UserServer:pool0.vdomain.com,
egistrar:pool0.vdomain.com...}
Computers : {server.vdomain.com}
Fqdn : pool0.vdomain.com
Site : Site:Redmond1
Finally, each pool runs one or more services. Over time, I will detail what exactly these services are, but a number of them are obvious from the context. Similar to sites, services have two primary different methods of identification.
Within the vast majority of the product, services are defined by the service role (type) followed by a colon, followed by the Fqdn of the pool. This is the format displayed above. When specifying services throughout the product, this is the format you should use. In some situations where the role name can be determined from the context, the role name is not required and just the Fqdn may be provided.
The Central Management Server, however, does not use this syntax when tracking services. Instead it uses the following format.
{siteId}-{role}-{instance}
SiteId - This is the SiteId as returned from Get-CsSite and is not the name. The topology builder automatically assigns an incrementing number as the siteId.
Role - In some cases, this is the same role name used in the serviceId mentioned above. However, in some cases the role name differs. For instance the Central Management Server uses the role name of ApplicationDatabase, while the serviceId uses ApplicationStore. Incidentally, when specifying a role name in Powershell one can use either name.
Instance - A number that makes the service unique in the topology. Typically this number starts at one and increments with each service of the given role.
There are almost no cases where you'll need to know or care about a CMS serviceId, but if you are curious you can see the CMS serviceId by running Get-CsService. Get-CsService enumerates all services, or you can pass in the serviceId of the one you are interested in. Incidentally, throughout Powershell wherever a serviceId is required, a CMS serviceId may also be used. Note that unlike Get-CsSite and Get-CsPool, Get-CsService may return one of serveral different objects. Depending on the role name of the service, different properties are exposed.