4. Planning for Management
Lync Server 2010 follows the currently popular model of role based
access control (RBAC). The concept is that one defines a role,
typically based around common tasks, and then delegates the capability
to perform these tasks to the role group. Existing security groups or
individuals are then populated into that role group to grant them the
necessary rights to perform the tasks.
Lync Server 2010 predefines nine RBAC groups that cover most of the
commonly delegated tasks within Lync Server 2010. These groups and
their allowed tasks are as follows:
• CsAdministrator—This
group can perform all administrative tasks and modify all settings
within Lync Server 2010. This includes creating and assigning roles,
and modification or creation of new sites, pools, and services.
• CsUserAdministrator—This
group can enable or disable users for Lync Server 2010. They can also
move users and assign existing policies to users. They can neither
create new policies nor modify existing policies.
• CsVoiceAdministrator—This
group can manage, monitor, and troubleshoot servers and services. They
can prevent new connections to servers, apply software updates, as well
as start and stop services. They cannot, however, make changes that
affect global configuration.
• CsViewOnlyAdministrator—This group can view the deployment, including server and user information, in order to monitor deployment health.
• CsHelpDesk—This
group can view the deployment, including user’s properties and
policies. They can also run specific troubleshooting tasks. They can
neither change user properties or policies nor server configuration or
services.
• CsArchivingAdministrator—This group can modify archiving configuration and policies.
• CsResponseGroupAdministrator—This group can manage the configuration of the Response Group application within a site.
• CsLocationAdministrator—This
group offers the lowest level of rights for Enhanced 911 (E911)
management. This includes creating E911 locations and network
identifiers and network identifiers and enables associating these with
each other. This role is assigned with a global scope as opposed to a
site-specific scope.
To comply with RBAC best practices, do not
assign users to roles with global scopes if they are supposed to
administer only a limited set of servers or users. This means creating
additional role-based groups with similar rights to previous groups,
but applied to a more limited scope because all default role groups in
Lync Server 2010 have a global scope. That is to say, the rights apply
to all users and to servers in all sites.
These scoped role groups can be created through the PowerShell
commandlets provided with Lync Server 2010 by using an existing global
group as a template and by assigning the rights to a precreated group
in Active Directory. For example:
New-CsAdminRole –Identity "Site01 Server Administrators" –Template
CsServerAdministrator –ConfigScopes "site:Site01"
This commandlet gives the Site01 Server Administrators group the
same rights as the predefined CsServerAdministrator role, but rather
than giving the rights globally, the rights apply only to servers in
Site01.
A similar process can be used to create a role that is scoped based on users rather than on sites:
New-CsAdminRole –Identity "Finance Users Administrators" –Template
CsUserAdministrator –UserScopes "OU:OU=Finance, OU=Corporate Users,
DC=CompanyABC, DC=com"
This grants a group called Finance Users Administrators rights
similar to the predefined CsUserAdministrator group but rather than
getting the rights across all user objects, they will be limited to
user objects in the Finance OU as defined in the commandlet.
After the necessary role groups have been defined, simply add users
or other groups to the role groups through Active Directory Users and
Computers.
Note
When users are placed into either a new
security group or into a role group, they need to log out and then log
on for the Kerberos ticket to be updated with the new group membership.
Without this process, they will not be able to use the new rights that
they are granted.
For users who are given any level of administrative rights within
Lync Server 2010, carefully consider which tasks they need to perform
and then assign them to the roles with the least privilege and scope
necessary to perform the tasks.
5. Documenting the Plan
After all the various requirements have been determined and the
options thought out and decided on, put these decisions and
requirements into a design document. The complexity of the project
affects the size of the document and the effort required to create it.
The intention is that this design document summarizes the goals and
objectives that were gathered in the initial discovery phase and
describes how the project’s result will meet them. It should represent
a detailed picture of the end state when the new technologies and
clients are implemented. The amount of detail can vary, but it should
include key design decisions made in the discovery process and
collaboration sessions.
The following is a sample table of contents and brief description of the design document:
• Executive Summary—Provides a brief discussion of the scope of the Lync Server 2010 implementation (the pieces of the puzzle).
• Goals and Objectives—Includes
the 50,000-foot view business objectives, down to the 1,000-foot view
staff level tasks that will be met by the project.
• Background—Provides
a high-level summary of the current state of the network, focusing on
problem areas, as clarified in the discovery process, as well as
summary decisions made in the collaboration sessions.
• Approach—Outlines
the high-level phases and tasks required to implement the solution (the
details of each task are determined in the migration document).
• End State—Defines
the details of the new technology configurations. For example, this
section describes the number, placement, and functions of Lync Server
2010.
• Budget Estimate—Provides
an estimate of basic costs involved in the project. Whereas a detailed
cost estimate requires the creation of the migration document,
experienced estimators can provide order of magnitude numbers at this
point. Also, it should be clear what software and hardware are needed,
so budgetary numbers can be provided.
When developing the document further, one will want to add
additional detail in various sections to lay out the costs and benefits
as well as providing a long-term vision to the project. Consider
including these details in the various sections of the document:
• Executive Summary—The
executive summary should set the stage and prepare the audience for
what the document will contain, and it should be concise. It should
outline, at the highest level, what the scope of the work is. Ideally,
the executive summary also positions the document in the
decision-making process and clarifies that approvals of the design are
required to move forward.
• Goals and Objectives—The
goals and objectives section should cover the high-level goals of the
project and include the pertinent departmental goals. It’s easy to go
too far in the goals and objectives sections and get down to the
1,000-foot view level, but this can end up becoming confusing, so this
information might be better to record in the migration document and the
detailed project plan for the project.
• Background—The
background section should summarize the results of the discovery
process and the collaboration sessions, and can list specific design
decisions that were made during the collaboration sessions.
Additionally, decisions made about what technologies or features not to
include can be summarized here. This information should stay at a
relatively high level as well, and more details can be provided in the
end state section of the design document. This information is useful as
a reference later in the project when the infamous question “Who made
that decision?” comes up.
• Approach—The
approach section should document the implementation strategy agreed
upon to this point, and should also serve to record decisions made in
the discovery and design process about the timeline (end to end and for
each phase) and the team members participating in the different phases.
This section should avoid going into too much detail because in many
cases the end design might not yet be approved and might change after
review. Also, the migration document should provide the details of the
process that will be followed.
• End State—In the end
state section, the specifics of the Lync Server 2010 implementation
should be spelled out in detail and the high-level decisions that were
summarized in the background section should be fleshed out.
Essentially, the software to be installed on each server and the roles
that will be installed on each server are spelled out here, along with
the future roles of existing legacy servers. Information on the clients
that will be supported, policies that will be enforced, and so on
should be in this section. Diagrams and tables can help explain the new
concepts and show what the solution will look like, where the key
systems will be located, and how the overall topology of the
implementation will look. Often, besides a standard physical diagram of
what goes where, a logical diagram illustrating how devices communicate
is needed.
• Budget Estimate—The
budget section is not exact but should provide order of magnitude
prices for the different phases of the project. If an outside
consulting firm is assisting with this document, it can draw from
experience with similar projects of like-sized companies. Because no
two projects are ever the same, there needs to be some flexibility in
these estimates. Typically, ranges for each phase should be provided.
The goal is for the audience of the document to understand what the
project will cost and what they are getting for that money. This is
also a great place to point out anticipated returns on investment (ROI)
because these often act as the primary justification for a Lync Server
2010 implementation.
