More about manageability changes in Lync Server 2010

In yesterday's post, I glossed over the small fact that pretty much every single line of manageability code has been rewritten in Lync Server 2010.  In today's post, I thought it would be a good idea to explain this further.

Almost every single line of manageability code was rewritten in Lync Server 2010.

There.  I am sure that sheds a lot of light on the fact.  So, you may be wondering, why exactly did we do this?

As I mentioned yesterday, deployment was a major concern for this release.  As more and more server roles were added, it became increasingly complex to setup an Office Communications Server deployment.  In addition, new versions of Live Communications Server and Office Communications Server required changes to the Active Directory schema.  For may companies, changing the schema is no minor task and I remember personally having discussions with a number of customers when we launched Office Communications Server 2007 who were very dismayed about doing this.

However, it is difficult to not change the AD schema with each release when a large portion of our settings were in Active Directory.  Settings in general were a very complicated area in OCS.  Some settings were stored in AD, others in a Sql backend database, and some on the local machine.  All settings were accessible from WMI but querying the setting required that you know where it is being stored.  For instance, if you wanted to query data stored in the Sql backend database, you needed to specify the database in the query.

Therefore, the solution to the Active Directory schema issue was to move the majority of our settings out of AD.  I say the "majority" because there still are some things that we have to keep in Active Directory - notably information about endpoints and users - but the vast majority of settings were removed.  Where did they go?  Well, that is where the Central Management Server comes into play.

In Lync Server 2010, this information is all stored in Xml documents.  With the exception of the topology, we do not provide access to the Xml documents directly, but that is how they are stored.  Each of these Xml documents is stored in a database - called the Central Management Database.  As explained yesterday, the job of the Central Management Server is to coordinate replication of these documents to replica databases running on each machine in the topology as well as providing access to the master copy.

Each document has three things that make it unique.

A schema - This is an Xsd schema that explains exactly how the document must be formatted.  Each schema corresponds to a grouping of settings.  For instance, the topology document is described in a single schema.  Health monitoring and dial in conference settings are other examples of documents with their own schemas.

A scope - For each schema, multiple copies of the document may exist.  The scope describes which category of thing this copy belongs to.  There are four possible scopes.

• Global - This document applies everywhere.
• Site - This document applies to a specific site (I'll explain what sites are in a later blog)
• Service - This document applies to a specific service (I'll explain these too in a later blog)
• Tag - This document uses an arbitrary string to specify its uniqueness.  Typically the string is not truly arbitrary but has different meanings depending on the document.

An anchor - The anchor is a text string that accompanies the scope.  For the global scope, no anchor exists.  For the site and service scopes it is the unique identifier for the site and service respectively.  For the tag scope it is the arbitrary string.

You will see the scope and service attributes later on when we start discussing Powershell in a future blog.  Each schema limits which scopes apply to it and for most documents, not all scopes apply.

In addition, we have three types of schema documents.  The main differences between these types is how they are exposed to the administrator.

Deployment schemas - These schemas describe how the deployment is configured.  The topology schema is the most important example.  Many of these schemas are not directly exposed to the administrator, with the exception of the topology.  Most of these schemas only support the global scope.

Policy schemas - These contain information about what particular users can and cannot do or contain conferencing, presence, etc. settings per user or a group of users.  Typically a policy document is created and then assigned to one or more users.  I will have more about this in a future blog.  These schemas use the tag scope.

Settings schemas - These schemas contain configuration information pertaining to specific roles within the deployment.  Many of these schemas can be scoped to an individual site or service.

As you can probably see, this required a huge change to our infrastructure.  With the removal of the WMI classes in Lync Server 2010, we had to change all of the code in the product that relied on WMI.  In addition, huge pieces of our manageability infrastructure depended on both WMI and Activate Directory.  The following just gives an idea.

In Office Communications Server 2007, we had a mainly unmanaged executable called LcsCmd.exe that allowed administrators to prepare servers, domains, and forests.  This was a huge executable that was the core of the deployment process.  This entire executable was removed and replaced with managed code that communicates with the Central Management Server and in some cases Active Directory. 

The MMC in Office Communications Server 2007 was completely discarded and rewritten as a web administration tool.

The new method for administrators to manage Lync Server 2010 is Powershell.  Office Communications Server 2007 did not support Powershell and this area is completely new.  With the exception of most topology changes, all administrative capabilities of Lync Server 2010 are available through Powershell.

One rather humorous bit of information that you will not likely find in the documentation is the internal name for the Central Management Server.  The name given to this functionality was "Squid".  It received this name because it had the reputation of a monster that gets its tentacles into everything.  Every area of the product was affected by it in one way or another.  However when it came time to release the product, our marketing team figured that "Central Management Server" was a better name.

So now that you have a better idea what changed and why we did it, in my next blog I will begin to discuss the topology.