Lync Server 2010 has made some significant changes to
how the deployment is managed. Instead of individually installing and
configuring servers, the deployment is managed centrally through the
Topology Builder. This shift in management helps make administration
easier for organizations and limits the potential for mistakes.
In prior versions of the product, administrators had
to log on to each server in the topology and manually configure options
such as next hops, monitoring associations, and service ports. With Lync
Server 2010, the configuration is completed in advance and then
published to the Central Management Store (CMS).
When a server is deployed, it installs SQL Server
Express. A local copy of the CMS is then replicated to this SQL instance
so that the server can reference the entire topology. When the
administrator begins installation, the server reads the topology and
installs any roles within the topology that match the fully qualified
domain name of itself.
Note
The only configuration required to link or associate
servers with each other is performed automatically during the
installation process. This helps reduce the chance for incorrect
settings that cause unpredictable or problematic behavior for the
servers.
To review, the deployment model with Lync Server follows the following high-level steps:
1. | Administrator creates topology by defining all sites, servers, and gateways in the deployment.
|
2. | The topology is then published to the Central Management Store.
|
3. | A Lync server installs the SQL Express engine and creates a local replica of the CMS.
|
4. | The Lync server reads the local CMS replica and installs the roles matching its FQDN.
|
Central Management Store
The previous section referenced the Central
Management Store. To understand the responsibility of the CMS, it is
important to understand how prior versions of the product operated where
server and service configuration was stored within Active Directory.
Live Communications Server and Office Communications Server both stored
configuration information within the System partition of the forest root
domain. In many cases, this was acceptable, but it caused performance
problems in scenarios where a remote office had poor connectivity to a
domain controller in the forest root domain. This was because the System
container is not replicated to all domain controllers in the forest, so
servers could be required to leverage WAN links to read settings even
if a domain controller existed locally.
To mitigate these problems, Office Communications
Server 2007 R2 recommended migrating the settings to the Configuration
container instead, which is replicated to all domain controllers in the
forest. This solved the problem, but organizations had a confusing
manual migration path to move settings to the new container and often
skipped this step. Furthermore, organizations could not move the
settings after installing OCS 2007 R2, so they were stuck in this state
with performance problems.
With Lync Server 2010, the settings for the
deployment have moved from Active Directory to the CMS, which is just an
additional SQL database. The CMS must be populated before the first
pool is created and is done automatically if the first pool is a
Standard Edition server. The CMS can be stored on the same SQL server
and instance acting as a Back End server for a pool, and after
installation the CMS can be moved to another server at any time.
As indicated earlier, when a server is prepared for a
Lync Server installation, the first action it takes is to install a
local replica of the CMS. As changes occur in the CMS, these changes are
synchronized out to all members of the topology, which removes the need
for servers to maintain a constant connection to a centralized
configuration store. Servers synchronize the changes regularly and use
the information stored locally instead of contacting a central point for
settings, which improves performance and stability.
Topology Builder
New to Lync Server 2010 is the Topology Builder
application. The Topology Builder is a centralized configuration point
for adding servers to the deployment or changing configuration. All
naming, IP addressing, and association of servers are performed through
the Topology Builder so that administrators do not need to individually
configure servers. This helps reduce the number of errors made during configuration of pools with multiple members.
Each server site is defined within the Topology
Builder, and then each specific server role is defined and associated
with a site. When completed, administrators can publish the topology to
the CMS where it can be read by servers.
Tip
The Lync Server 2010 Planning Tool can export the
planning topology to an XML file, which can then be imported into the
Topology Builder. This enables an administrator to quickly plan, build,
and publish a configuration in a streamlined workflow. Figure 1 shows the layout of the Topology Builder.
Scopes
A new concept in Lync Server 2010 is the idea of
scopes, which help define the boundary of a policy. Scopes are applied
based on the topology built within the Topology Builder. The highest
level that exists is the Global level. Within the Global level are
sites, which represent physical locations where pools exist. Sites
typically are datacenters where the Front End pool servers reside. Each
site then contains the pools that make up the deployment. A site can
have one pool or multiple pools. This arrangement is depicted in Figure 2.
After the topology is defined, default policies for
many different aspects of Lync Server 2010 are created. For example,
global policies are created for Voice Policies, Conferencing Policies,
and External Access Policies.
Global policies apply to all sites, pools, and users
by default. Additional policies can be created at any of the other
scopes as well, giving flexibility on overriding the defaults. The
benefit of applying policies to a site or pool scope is that the
additional task of assigning a policy directly to the users is no longer
required. Instead, policies defined at a higher level are automatically
applied to all scopes below as long as the lower scope does not have a
policy already defined.
Administrators can still create new policies and
assign them directly to a user account to override any global or site
policies. This might be necessary to grant executives or VIP users a
higher level of access than the default for everyone else in the site.
Note
In terms of priority, the policy assigned closest to
the user account takes precedence. User policies override pool policies,
pool policies override site policies, and site policies override the
global policy. Policies automatically trickle down from the global level
unless a policy exists closer to the user.
