OCS Roles Primer, Part 1

One of the first things I really struggled with when ramping up on Microsoft Office Communications Server 2007 was understanding roles, their responsibilities, and how roles overlap.  What roles do I need?  How many of them do I need?  Can an edge role be installed on a mediation server?  What’s more, Microsoft tosses out diagrams like the following with very little explanation:

The information that is available out there about OCS server roles is scattered across many different documents, Web sites, and blog posts.  Hopefully, this post will distill information on the roles available in OCS, their coexistence constraints and hardware/software requirements.  That said, let’s get a little bit of vocabulary out of the way first.

  • Office Communications Server: A Microsoft product designed to facilitate communications both inside and outside the office.
  • Presence: A metric that takes into account both your availability (available, idle, away) and your willingness (available, busy, on a call) to communicate.
  • Endpoint: Any device (SIP phone) or software package that registers itself with Office Communications Server as belonging to a user, meaning that the user can be contacted through the device or software package.
  • Enterprise Voice: Probably the most noteworthy addition to the product since 2005; allows calls to enter and exit Office Communications Server.  This means that from any endpoint, users can make or receive calls to traditional phone numbers.
  • Public Switched Telephone Network (PSTN): The traditional telephone network that delivers telephone service over dedicated copper cables.

 

Pool Server Roles

In enterprise-class deployments, multiple servers are typically assigned the traditional front-end server roles.  Although this is sometimes referred to as a cluster, the term that has been assigned in this case is “pool”.  As an aside, I would recommend that any business who is seriously considering OCS for Enterprise Voice use an enterprise-class deployment even if scalability is not a concern.  Resiliency is also something you gain when you deploy multiple servers playing the same role.

Front-End Servers

The front-end server handles a lot of the plumbing for OCS.  It authenticates users against Active Directory, routes invitations to appropriate endpoints, and generally coordinates all other features of OCS.  It is important to note that once a front-end server has assisted in routing the invitation to appropriate endpoints, it gracefully steps back and allows the endpoints to communicate directly.  This means that a front-end server will not be overwhelmed by handling thousands of simultaneous video chats.  It merely directs the invitations and coordinates the set-up of communications, then allows the endpoints to communicate however they may choose.  (The exception to this rule is instant messaging sessions, which always travel through the front-end server for archiving purposes.)  It is also important to note that a front-end server may handle merely these responsibilities or more if the deployment team decides to consolidate multiple roles onto the front-end server.

Specifically, the front-end server:

  • Authenticates users against Active Directory
  • Aggregates and disseminates presence, contact, and other similar information
  • Routes invitations to appropriate endpoints (or gateways) and cancels other invitations once an endpoint has accepted
  • Tracks status of sessions (even though the session communicates from endpoint to endpoint) and delivers status update messages like typing, ringing, accepted, etc.

Requirements:

  • Dual processor, dual core 2.6GHz+ processor
  • 2 x 18GB HDD
  • 2GB RAM
  • Gigabit NIC
  • Windows Server 2003 SP1+*

Directors

Directors have two primary responsibilities: user authentication and direction.  User authentication comes in especially handy when dealing with remote users.  Because remote users cannot be redirected to their home server/pool, the director role proxies their connection through to the correct server/pool.  However, user authentication by a director is also important when an enterprise hosts multiple standard servers or enterprise pools.  Users are “homed” to a server/pool, meaning that that server/pool is the one that stores the users account information.  A director will get the user to the right pool on the first try rather than repeatedly polling every server/pool to see if the user’s account is stored there.  In summary, directors are always recommended when you have remote users and/or multiple standard servers or enterprise pools.

Conferencing Servers

Conferencing servers, in contrast to front-end servers, are designed to maintain a central hub for communications when more than two parties are involved.  This minimizes bandwidth requirements for the conference by maintaining one open channel per endpoint.  Conferencing servers also register and update “focus” on front-end servers.  “Focus” means security and state management for conferences.  Conferencing servers come in two major flavors: A/V conferencing servers, which facilitate audio and/or video conferences, and Web conferencing servers, which facilitate Live Meeting 2007 conferences.

The IM conferencing server:

  • Controls focus for three or more IM participants
  • Focus includes:
    • Participant list tracking
    • Leader determination
    • Security and management controls
  • Is installed by default on all front-end servers and cannot be installed separately

The A/V conferencing server:

  • Enables three or more parties to have audio and/or video chats (two parties use a point-to-point connection)
  • Reduces bandwidth requirements by mixing audio from other participants into one channel instead of n channels

The Web conferencing server:

  • Allows application and file sharing
  • May leverage an A/V conferencing server to distribute audio/video in a Live Meeting

The Telephony conferencing server:

  • Provides functionality for exposing an audio conference to the PSTN
  • Allows the organizer to
    • Mute everyone except the presenter
    • Mute themselves
    • Remove parties
  • Is installed by default on all front-end servers and cannot be installed separately

Requirements**:

  • Dual processor, dual core 3.0GHz+ processor
  • 2 x 18GB HDD
  • 4GB+ RAM
  • Gigabit NIC
  • Windows Server 2003 SP1+*

Archiving and CDR Server

The archiving and CDR server is designed to provide a first-shot at archiving instant messaging sessions and call detail records for compliance purposes.  Although this is Microsoft’s stated intent for the role, it’s hard for a layman to imagine how an out-of-the-box solution could really meet the compliance needs of any reasonable organization.  I have not been able to locate any customizable fields, which means that we have a great track record of who called whom at what time, but that’s pretty much it.

Requirements:

  • Dual processor, dual core 2.6GHz+ processor
  • 2 x 18GB HDD
  • 4GB+ (16GB+ if archiving is enabled) RAM
  • Gigabit NIC
  • Windows Server 2003 SP1+*

* I was not able get the OCS primary installer to run successfully on Windows Server 2008 RTM.  It may be that the individual installers would run successfully, but I have not confirmed this.  The only role I have successfully installed on Windows Server 2008 is Speech Server 2007.

** The work of mixing audio channels is intense; A/V conferencing servers will benefit from more robust hardware.

2 Responses to “OCS Roles Primer, Part 1”

  1. OCS Roles Primer, Part 2 « IT’s Dilemma Says:

    [...] OCS Roles Primer, Part 1 « Queues are for the Brits, Part 2 [...]


Leave a Reply