Moving to Office Communications Server 2007 R2

Office Communications Server 2007 R2 has some exciting new features, which make its deployment well worth considering. Desmond focuses on using the side-by-side method to migrate existing OCS RTM servers and clients over to R2, which you can likewise adopt to create an entirely new R2 installation.


Like many organizations, you may already be operating a Unified Communications infrastructure based on Live Communications Server 2005 SP1 or Office Communications Server 2007.  OCS 2007 R2 edition has come with some major improvements and exciting new productivity features that compel companies to look into deploying this new version to stay one step ahead. Whether you are beginning with bare soil or have an existing OCS setup, this article lays out the key considerations to help you move as early and as effortlessly as possible to the world of Unified Communications with OCS 2007 R2.

Migration Strategies

Those of you who are starting out from scratch may like to read my last article to kick start your OCS deployment with R2. Although it is written from a virtualization perspective, the principles and instructions in that last article apply equally to a production environment. Nevertheless, look out for pointers in this article to help ease your implementation woes and challenges. At the time I write this, running OCS in a virtualized environment in production is not supported regardless of the underlying virtualization platform i.e. Microsoft Hyper-V, VMware Esx Server or the recently announced vSphere.

Update (13 May 2009): Microsoft has released a blog post on Office Communications Server 2007 R2 Virtualization. You can read and find out more about this topic here.

If you already have a production setup based on either Live Communications Server 2005 SP1 (LCS) or OCS 2007 RTM (some refer it to R1), resist the urge to simply pop in the R2 DVD to run setup. There are significant architectural changes in the product with updated AD environment and back-end database requirements. They must be fulfilled for a successful rollout whether building the environment brand new or migrating to R2 in phases with coexistence of previously supported versions. Because there is no direct upgrade path to R2  from OCS 2003, Office Communications Server 2003 users will have to migrate to at least LCS 2005 SP1 first.

You can take one of two alternative migration strategies on the road towards implementing R2; these are ‘uninstall/reinstall’ and ‘side-by-side’.

To keep operations going with minimum disruptions and inconvenience to end-users, the side-by-side migration is typically the preferred approach. This is at the expense of having to invest in new hardware for the R2 infrastructure with varying degrees of complexity to maintain proper coexistence. In addition, new names for the servers, pools and IP addresses have to be assigned. Since OCS 2007 R2 at its core is exclusively 64-bit, it can only run on x64 versions of Windows Server 2003 SP2 or higher and Windows Server 2008.
The uninstall/reinstall method allows you to preserve system settings and repurpose compatible hardware wherever possible. However, you will have to be prepared for longer periods of downtime to deal with major tasks such as backup/restore of existing user, configuration data and server rebuilds.

To help you quickly get up to speed with migrating the core infrastructure to R2, I have attempted to distill the mass of information down to what I believe are the most important and essential steps. This can be taken as a guide to migrate using the uninstall/reinstall or side-by-side methods. The latter is the focus of this article where migration starts from the internal network before moving out to the perimeter network. This is commonly known as an “inside-out” migration strategy. During the migration process, the R2 deployment operates independently yet can communicate with existing LCS or OCS RTM deployments in the same AD framework.

Pre-Migration Tasks

Quick side-by-side Migration Checklist

  1. Raise Active Directory domain and forest functional level
  2. Move default location of OCS global settings
  3. Apply hotfixes to OCS RTM server roles and clients (co-existence)
  4. Prepare back-end database server and x64 server for R2 installation
  5. Run preparation steps for AD Schema, forest and domain
  6. Prepare DNS records and digital server certificates
  7. Deploy R2 server roles and services and install R2 administrative tools
  8. Move users to home on R2 Front End servers
  9. Inside-out migration for remaining internal server roles out to DMZ
  10. Standardize and rollout R2 client applications and supporting components
  11. Decommission OCS RTM servers

The very first step is to raise both the domain and forest functional level to at least the Windows Server 2003 mode required by R2 to function (see TechNet Library here). To do this, login to an active domain controller holding the Schema Master role with an appropriate administrative account in Active Directory.

This task should be performed at the earliest possible moment so that the changes have sufficient time to propagate to all domain controllers throughout the AD forest. The domain controllers themselves can be running Windows Server 2003 SP1 or higher and Windows Server 2008 (Standard or higher editions) with a minimum of one Global Catalog server available. The processor architecture does not matter and can either be x86 or x64.

By default, both LCS and the RTM versions of OCS store the global settings in the root domain’s System Container within AD. LCS/OCS servers must be able to access these settings anywhere in the forest. In an environment already installed with LCS 2005 SP1 or OCS 2007 RTM, the ability to change the location for storing the global settings in the System Container to the Configuration Partition or vice versa is disabled (see Figure 1).


Figure 1

You can download the Microsoft Office Communications Server 2007 Global Settings Migration Tool and follow the instructions in the TechNet library to relocate the OCS global settings. You must use the OCS RTM tools to move the global settings before launching the step to prepare the AD schema. Ascertain that you first stop all LCS and OCS services ahead of time and re-start them after the move. Otherwise, you will not be able to make this change once the schema has been upgraded to R2. The OCS global settings themselves are actually created during the Forest Prep step.  Like raising an AD domain or forest functional level, this operation is a one-way street. Presently, no official tools are known to exist that can move this back or to enable relocation of the global settings after a R2 schema extension is complete. A clean installation of R2 will by default store its global settings in the Configuration Partition.

Why should I care if I have only a single domain, single forest AD structure? Basically, a number of AD sites are usually created to optimize network traffic in a decentralized AD topology involving multi-site deployments. If sub-domains are present or added at a later stage, OCS servers and UC-enabled users deployed in the child domains will continue to reach out to a domain controller and Global Catalog server in the root domain to retrieve data for the global settings. Failure to move the OCS global settings could cause long startup times for the core OCS services, synchronization and update errors, long replication delays, inter-domain instant messaging/presence issues or user login problems. This becomes even more critical if you are considering deploying Enterprise Voice (VoIP) for mobile users across disparate geographical locations with anywhere access via Microsoft Office Communicator client (MOC) or a supported browser in R2.

You therefore have to move the OCS global settings to the Configuration Partition from the pre-R2 default location. Also known as a Naming Context (NC), this is one of 3 stores in AD – Schema, Configuration and Domain (or System Container in OCS speak) – where only the first 2 NCs are replicated to every domain controller in the forest. In so doing, the global settings can be directly accessible on local DCs and GCs in the respective domains; all without the need to traverse over slow, costly and often unreliable WAN links. You can access the various global settings by navigating to the Forest – <FQDN> node / Properties then click on the Global Properties, Voice Properties or Conferencing Attendant Properties menu options using the R2 administrative snap-in.

Infrastructure Readiness

To ensure that R2 servers can operate problem free in an existing OCS RTM environment, you should download and apply the list of updates on the RTM server roles (Table 1). Check that you have updated documentation of your current environment (including user account inventory) and make a full system backup before you go ahead with any changes. Since it usually takes an organization much more time to test and deliver patches to its fleet of Windows client machines, I suggest that you also prepare the user base running the MOC client well ahead of the first batch of R2 users going live. Until all clients are migrated and homed on R2 server pools, different MOC versions will negotiate and continue to communicate using the most common feature sets available to them. Eventually, you should develop a plan to rollout the MOC R2 client to all your users after the entire end-to-end infrastructure has been upgraded to the R2 equivalents.

Table 1: OCS and MOC RTM Updates


All OCS Server Editions & roles

Mediation Server role

MOC 2007


KB956389 (Nov 2008)



Supersedes KB952783 (Aug 2008). Fixes issues described in KB958560 (Nov 2008) and KB958561 (Nov 2008)

KB956831 (Nov 2008)



Supersedes KB946763 (Jan 2008). Fixes issues described in KB957489 (Oct 2008), KB957595 (Oct 2008) and KB957648 (Oct 2008).

KB956829 (Oct 2008)




Supersedes KB952780 (Aug 2008). Fixes issues described in KB957490 (Oct 2008) and KB957648 (Oct 2008)

KB961552 (Mar 2009)



Supersedes KB957465 (Dec 2008) with fixes for a number of issues.

KB953582 (Oct 2008)




Fixes registry extensions permission errors with program installation in Vista and Windows Server 2008. Must apply before installing the R2 administrative tools.

KB953990 (Jan 2009)




Applies to machines with .NET Framework 2.0 SP1 on Windows (x86 and x64).

In the event that you are installing an R2 Enterprise pool, a dedicated Windows server (or active/passive cluster) running Microsoft SQL Server 2005 SP2 or SQL Server 2008 must already be setup and configured on another physical server. Both the operating system and database application can either be 32- or 64- bit editions. A new database instance will be automatically created when you install the R2 Enterprise pool. The reason behind this is due to the back-end database schema change in R2.

This same box can host multiple SQL databases and instances supporting the unique needs of the Enterprise pool, Archiving or Monitoring Server R2 server roles. Nonetheless, it is not a recommended practice to collocate the pool’s back-end database and archiving database for performance reasons. Note also that collocating any R2 server roles on the same back-end SQL Server remains unsupported. For R2 Standard Edition setup, the SQL Server 2005 Express Edition SP2 database is automatically created on the local machine to store user and configuration data as part of the setup process.

Let the Show Begin

With the pre-migration tasks out of the way and the back-end infrastructure in place, you are almost ready to run the R2 setup executable. As stated before, you need to provision a machine with a supported x64 edition of Windows and join it to the domain so as to conduct a fresh R2 install.

Now if you are targeting an AD environment with domain controllers that run only x86 editions of Windows, you can still execute Step 1 to 7 under “Prepare Active Directory” on the main R2 setup screen from a member server with good IP connectivity to the Schema Master. Clearly, the member server must be operating on an x64 edition of Windows as the R2 installation Wizard relies on the 64-bit version of setupEE.exe or setupSE.exe. If not, you will have to explicitly extract and deploy the 32-bit version of LCSCmd.exe from the DVD media to prepare AD.

To avoid the hassle of switching between consoles, I recommend that you execute all setup steps for R2, including those for preparing AD, on a remote Windows Server 2008 server that will eventually be installed with one of the R2 server roles. This must be the full graphical version of Windows Server 2008 (not Server Core). The optional Remote Server Administration Tool (RSAT) feature is needed to accomplish this on Windows Server 2008. For AD environments with multiple domains, you must execute the Domain Prep step for each domain where R2 servers will be deployed. Even if the latter is not planned for a particular domain, this procedure must still be done if you intend to UC-enable any user account in that domain. This step to prepare an AD domain mirrors the requirements of Exchange Server 2007. Again, set aside adequate time to allow AD replication to run its course in the forest.

As soon as AD preparation steps for the schema, forest and domain are completed, you can commence with the actual deployment of an R2 Standard or Enterprise Edition server pool. Mixing RTM and R2 servers in the same pool is not supported; consequently you can rule out the rolling upgrade option where servers are upgraded one by one in the pool. After all, an in-place upgrade is not possible between disparate processor architectures i.e. OCS RTM x86 to R2 x64.

Even though the Enterprise expanded topology continues to be supported, Microsoft recommends targeting new R2 Front End server pools as well as Edge Server roles and services to be based on the consolidated topology. Such configurations simplify deployment and reduce operational overhead since all server roles are collocated on a single machine. More computers with analogous, collocated server roles can be added to the hardware load-balanced pool to scale out and scale up the infrastructure afterwards, thereby improving overall system availability.

Application Server

The new Application Server is an integrated component of an R2 front-end server comprising of the Conferencing Attendant, Conferencing Announcement Service, Response Group Service and Outside Voice Control. Each of these UC applications can be activated individually. The Application Server component always runs as a separate process within the front-end server and cannot be segregated for deployment on another machine in the pool.

Other than making sure that the prerequisites for hard- and soft- ware are met, you should be ready to call up the passwords for the RTCService and RTCComponent service accounts that were created from the previous OCS installation when prompted during setup. For R2 Standard Edition or Enterprise consolidated topology setup on Windows Server 2008 to succeed, you need to separately install the Web Server (IIS) server role then select the IIS 6 Management Compatibility and security role services (Figure 2).


Figure 2

On top of that, you should arrange for the required number of digital server certificates configured with the correct Fully Qualified Domain Name (FQDN) of the distinct R2 server roles. You will need this at the “Configure Certificate” setup step. An OCS infrastructure relies heavily on digital certificates to enforce server and client authentication as well as securing all communications channels with encryption (signaling and media).

Nowadays, you can procure what is known as “Unified Communications (UC) Certificates” from public root Certificate Authorities (CA) such as Entrust. This type of certificate is designed to be compatible with Exchange Server 2007 and OCS 2007. It supports multiple, unique domains and hostnames that are inherently more secure than wildcard certificates (the latter is not supported in any OCS versions). Also, added support for X.509v3 Subject Alternative Name (SAN) extensions makes deploying the same SSL certificate for multiple virtual hosts, applications or different SIP domains on the same physical box possible. It is worthwhile to note that certain R2 server roles require SAN certificate to be deployed. To make certificate management easier and further contain cost, consider setting up an internal Windows Server 2008 Enterprise root and sub-ordinate CAs integrated with AD and turn on the automatic web-enrollment feature. For external, public facing R2 server roles, you should continue to procure and deploy certificates from trusted public root CAs to avoid unnecessary errors from unknown or unrecognized certificates that are generated from private, internal CAs.

You should be able to execute the remaining setup steps to arrive at a functional side-by-side R2 environment comparable to an entirely new installation. I recommend that you run the R2 validation tests at the end and verify the core functionality with a small test bed of RTM and R2 users. Once you feel comfortable and confident enough, you can plan for the definite move of production users over to the new home pool.


Unlike their predecessors, you need to manually install the updated set of R2 administrative tools using the Office Communications Server 2007 R2 Deployment Wizard. They essentially come in 4 different flavors – a new Office Communications Server 2007 R2 Administrative snap-in, management components for Active Directory Users and Computers (dsa.msc), a snap-in extension for the Computer Management console plus the LCSCmd.exe command-line tool. Furthermore, other standalone administrative tools must be installed to administer new R2 applications such as the Group Chat Administration Tool and Response Group Service.

While R2 is available in a 64-bit edition only, the OCS 2007 R2 Administrative Tools are shipped in both x86 and x64 versions. Supported platforms include Windows Server 2003 SP2, Windows Server 2008 (x86, x64) and Vista Business or Enterprise with SP1 (x86, x64). Beware of  the fact that you need to apply the relevant patches for the latter 2 platforms beforehand.

Installation of the R2 and OCS RTM administrative tools on the same box is not supported by Microsoft. Moreover, they can only be used to manage user settings on the respective OCS server versions, are not upward or backward compatible and cannot be mixed i.e. R2 administrative tools for R2 server pools only. An exception to this rule is the use of the Move User Wizard in the R2 or ADUC snap-in to transfer UC-enabled users homed on an OCS RTM server to a new R2 server pool. In fact, this is the easiest and recommended method to migrate a single user or in bulk over to the R2 platform through a graphical interface. Obviously, you can automate this with VBScript, PowerShell or your favorite scripting language.


You have learnt that there are two migration strategies you can consider in deploying OCS 2007 R2 in your organization. In this article, I focused on using the side-by-side methodology to migrate existing OCS RTM servers and clients over to R2. This approach can similarly be adopted for an entirely new R2 installation since it operates independently from existing OCS RTM or LCS 2005 SP1 in the environment.

After raising the Active Directory domain and forest functional levels to the required mode and laying the groundwork by relocating the OCS global settings, you apply the appropriate hotfixes to ensure peaceful co-existence of OCS RTM and R2. Once the relevant digital server certificates are prepared, we launched into the actual R2 setup process to deploy server roles and services. A successful deployment enables users to be moved to an R2 home server and migration to continue in phases with the remaining internal servers roles. I have also showed you that it is necessary to manually install the new and updated R2 administrative tools while keeping the previous versions to administer pre-R2 user settings.

In part 2 of this article, I shall look into recommendations to standardize the client desktop to support the different R2 applications, other infrastructure concerns and migration of the remaining internal server roles before moving out to the Edge servers in the screened network.