Deploying Exchange Server 2007 and Office Communications Server 2007 R2 (Part 1)

If you would like to read the other parts in this article series please go to:


There are a lot of questions out there about Exchange Server 2007 and OCS 2007 R2 deployment, in this article series we are going to go over the entire process in order to help you set up both products and make sure that our clients are configured properly. As you may know, Exchange Server 2007 and OCS 2007 R2 use the concept of roles and each product has several roles to deploy, which in turn increases the complexities for the IT administrator. Based on roles, we can start adding complexity and functionalities to the Exchange Server and OCS, such as: archiving, federation with public IM providers (MSN, AOL and Yahoo), add severs in a DMZ to provide external access (OCS) and hygiene for the incoming mail traffic (Exchange).

As you can see, there are plenty of options for using both products, the idea of this article series is to provide some guidance on how to deploy and integrate both products. You may want to use this article series to help you out during your POC (Proof of Concept) or before you start building your environment. At the end of the series, you will be able to visualize the basic steps in order to build your UC (Unified Communications) environment and as a result, your end-users will be way more collaborative through OCS Communicator, Live Meeting and Outlook.


We are going to create an environment from scratch in this article series, and we are going to use the scenario shown in the Figure 01. Our Active Directory domain/forest will be called apatricio.local and the public name will be, the public name will be used to associate the e-mail address of all users of our company and also the OCS logon name.

Figure 01

In the table below we can see more details about the environment. As you may have noticed, we are using two Domain Controllers and they are also part of the Global Catalog. Exchange Server and OCS 2007 R2 rely entirely on Active Directory and a single Domain Controller will be the single point of failure in our environment. It is for this reason that I always recommend to use a minimum of 2 (two) domain controllers. Also, Domain Controllers should not be shared with OCS or Exchange Server servers.

Server Name

IP Address



Domain Controller and Global Catalog


Domain Controller and Global Catalog and Certification Authority


Exchange Server 2007 SP1


Office Communications Server 2007 R2

We also know that Exchange Server and OCS may be a critical system and they may require fault tolerance, high availability and disaster recovery solutions. We are going to go over some of these options during the course of this article series. We are going to start simply with a single server for each product and afterwards I am going to demonstrate how we can improve fault tolerance, high availability and disaster recovery solutions to both products.

Before going any further in the technical portion of the deployment, let us take a step back and analyze the current roles of each product and the minimum roles required in our deployment.

Exchange Server roles

Exchange Server 2007 has been out there for a while now and its successor Exchange Server 2010 will use the same architecture (there are some changes but the number of roles have not changed), the role architecture of Exchange Server can be seen in the Figure 02.

Figure 02: Exchange Server 2007 High-level architecture (Courtesy of Microsoft)

Based on the figure above, we can get an idea about the roles and where they are located in a network. Topics for each role with key features and their use are as follows:

  • Client Access Server:
    Role responsible for all non-MAPI communication between clients and Exchange Server (OWA, Outlook Anywhere, POP3 and IMAP4). In Exchange Server 2010 it will include MAPI as well.
  • Edge Transport Server:
    Role responsible to clean up all incoming mail traffic using built-in anti-spam agents. Edge Server cannot share hardware with any of the other roles and it should be placed in a DMZ.
  • Hub Transport Server:
    Role responsible to route messages within the organization. It can also be configured to receive external e-mail.
  • Mailbox Server:
    Is the repository of all data (messages, voice mail, appointments, contacts and etc.). This role is able to host mailbox and public folders. It is the only role that can use cluster to provide high availability and automatic failover, in Exchange Server 2007 it comes in two flavors (SCR and CCR).
  • Unified Messaging:
    UM role can connect Exchange Server with the PBX systems. This role is able to receive faxes, OVA (Outlook Voice Access), Auto Attendant and Voice Mail systems for an Exchange server organization. UM role also integrates with OCS and allows the Communicator clients to retrieve Voice Mail and OVA features.

Okay, we have 5 (five) roles that can be distributed among different servers but we have just one box in our initial deployment we need to use the minimum required, which is 3 (three) roles: Hub Transport, Mailbox Server and Client Access Server. In order to have an Exchange Server 2007 organization we need at least one of these roles, they can be either in different servers or combined in a single box.

Office Communication Server 2007 roles…

Office Communications Server is also based on roles. In the OCS world, we have more roles available than Exchange, both products together in a large scenario may contain more than 10 roles easily and I am not even talking about high availability at this point.

In Figure 03, we can see a full deployment of OCS 2007 R2 using Load Balancing and all roles. We are going to see in the following articles how we can plan our solution. Do not be scared about the number of roles, most importantly at this point is to understand the architecture of both products and a good lab (this article series will help you on that one too!!) and start simply with a single role and begin adding more roles based on your company’s requirement.

Figure 03: OCS 2007 R2 Consolidated Topology (Courtesy of Microsoft)

Based on the topology above, we could see the OCS roles in consideration of the “bigger picture”. Here is a brief description of each role:

  • Front-End Server
    This is the first role that should be installed on your environment; using a Front-End Server your users will be able to be more collaborative using IM (Instant Messaging), Web Conferencing (Live Meeting), Application Sharing, Audio/Video conferencing and so on.
  • Edge Server
    This role works for external users that want to use OCS outside of the internal network and also to federate service with other public networks such as MSN, AOL and Yahoo.
  • Director role
    If you remember Front-End and Backend topology on Exchange Server 2003, then this analogy will work for you: The director acts as a Front-End Server on that scenario. Basically, this role does not host any user and it should be used by Edge Server to communicate with the internal servers, then it will route sessions to the proper internal servers or balance the requests among the pool (Enterprise version).
  • Monitoring (CDR & QoE)
    This role gathers two types of data: Call Details Record(CDR) and Quality of Experience (QoE). CDR captures usage of IM, file transfers, meetings, AV conferencing and so forth; on the other hand QoE captures data from VoIP and video calls such as: quality of the call, participants, IP addresses, device names and etc.
  • Archiving Server
    Archive IM conversation for regulatory purposes. The archive can be done at user or pool level.
  • Group Chat Server
    That is a new role that came with OCS 2007 R2 and allows the creation of persistent groups where members of the group can use online chat rooms and also the content can be persistent which is great for dispersed groups in a global company.
  • Mediation Server
    This role is located between the UC Infrastructure and another gateway that can be a Media Gateway or a PBX. This role will do all signaling and media between those two environments.


  • Communicator Web Access (CWA)
    A Communicator web client where non-Microsoft clients are able to join OCS and collaborate with another contacts using a web browser.


In this first article we saw an overview of the Exchange Server and OCS 2007 R2 roles. We also took a look at the lab that is going to be used during this article series. Keep in mind that the objective of this series is to provide help in order to create a UC environment from scratch. In the next article we are going to go over the process of building a basic network infrastructure to support Exchange Server 2007 and OCS 2007 R2.


If you would like to read the other parts in this article series please go to:


About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top