Moving to Office Communications Server 2007 R2 -Part 2

In the second part of his article on Moving to Office Communications Server 2007 R2, Desmond looks 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.

In a nutshell, you will need to set up R2 server roles alongside the RTM counterparts to provide equivalent functionality. This is because not all RTM and R2 server roles can interoperate with one another directly without first sorting out certain changes which are vital for smooth operations. Therefore, the different RTM server roles should remain in operations until UC-enabled users are fully migrated and homed on new R2 server pools. Only then should you considering bringing in R2 specific server roles such as Group Chat and Outside Voice Control after the complete RTM infrastructure has been migrated to R2. In part 2 of this article (see Part 1), I shall take you through some of the highlights of how to implement an Enterprise consolidated topology from the inside-out in a side-by-side migration from OCS (Office Communications Server) 2007 RTM.

Back- to Front- End

Before you start, check that you always login with an account that has membership in the Domain Admins, RTCUniversalServerAdmins as well as local Administrators group. You will find that not all but some of the steps in the R2 setup will fail if this condition is not fulfilled. With the named SQL database instance on the Back-End database ready, you can go ahead to run the Create Enterprise Pool task. This step should be carried out right on the back-end database server running x64 editions of SQL Server. For those of you who are still using the 32-bit version or SQL Server 2005 SP2 (in particular) as the Back-End database, you will have to install the SQL Server client tools on the new Front-End server before proceeding further. The database itself will be created for you when the R2 Enterprise pool is created.

A number of shared folders must already be prepared ahead of time – preferably on a dedicated file server – to support client and device updates as well as data files for meeting presentations, Address Book Service (ABS), etc. You may find that deploying them directly on a Front-End server may just work for you in your environment.  Following that, you install the first R2 Front-End server to the pool and activate it. For administrators that are responsible for both the RTM and R2 infrastructure, it would be a good idea to use the same RTC* accounts in Active Directory. I suggest that you let the R2 setup program to create these service accounts (if they do not already exist) so that the correct group membership and security settings can be applied. These service accounts do not have their “Password does not expire” option enabled by default. You can prevent a number of seemingly unexplained incidents that potentially arise after R2 is in production for a period of time by simply changing this initial setting (verify that this is in accordance with your corporate security policy though).

Subsequently, you assign the digital certificate that you prepared earlier to the Enterprise Edition server. Although the Web Components Server resides on the same physical machine as the Front-End server in a consolidated topology, you must make use of the Internet Information Services (IIS) Web Server Certificate Wizard to separately assign the certificate to it. If the design calls for the same FQDN to be deployed for the Enterprise Pool and Web Components, it is a simple matter of selecting the same certificate in the drop down box. This is possible by virtue of the saved certificate in the local computer certificate store.

Once you verified that AD has replicated changes in the domain, ascertain that Windows Firewall is already running before attempting to execute the Start Services Wizard. The big advantage of this is that R2 setup will automatically configure all the necessary exception rules in the firewall for you. In case Windows firewall is turned off or your organization has deployed other host-based firewall solutions as a standard, it will be necessary for you to make the adjustments manually. To identify the ports to open in the firewall, search through the installation log files for the string “firewall exceptions”.

Communications Web Access

The optional CWA server role provides UC-enabled users the capability to utilize almost the entire feature set of the matching version of Front-End home server from a supported web browser (Internet Explorer, Mozilla Firefox, Apple Safari, etc.). There is no requirement to have a prior installation of the full MOC client application on the machine or device. One usage scenario that is gaining popularity is to initiate an IM session on your Apple iPhone 3Gs by simply using the in-built browser itself.

You must setup a new R2 CWA for users homed on R2 Front-End servers and retain the RTM version of CWA server as long as users remain on the older version. In order to maintain a consistent experience for all users, you can keep the current CWA URL by modifying the existing DNS record to point to the R2 CWA machine. The latter will then automatically redirect users to the corresponding version of CWA base on their actual home server. Similarly, you will find that you do not need to re-publish the URL in Active Directory as the dialin and join web pages for users to schedule and join conferences will remain unchanged i.e. and The downside to this is that a user homed on RTM Front-End server will be prompted to sign in again.

You can use Table 1 as a guide to configure the appropriate internal DNS records to support such a scenario. Here, the CWA URL is identified as served by a server located behind the corporate firewall. This maps to a web site or more commonly a CWA virtual server on IIS. The CNAME records download and as are essential to support the desktop sharing feature introduced in R2.

Table 1: Sample DNS records (CWA URL)


Dns record type


Host (A)

IP address of RTM CWA

Host (A)

IP address of R2CWA

Canonical name (CNAME)

CWA URL, modify to reference from

Canonical name (CNAME)


Canonical name (CNAME)


To improve the availability and capacity of CWA servers, you can deploy dedicated hardware load balancers (HLB) that are not shared with other R2 or RTM server roles, such as the Front-End Pool or Director arrays. In this case, you should edit the CNAME record for the CWA URL to resolve to the physical IP address of the load balancer.

One important fact to know is that it is no longer possible to add RTM version of the CWA server role once you get pass the R2 Active Directory preparation steps. To manage and administer the R2 release of CWA, you must also install the Communicator Web Access snap-in (x64-only) separately after satisfying the requirements as discussed here. As a security best practice, you should create two virtual servers, one on each host computer, to segregate external and internal users from one another. Further, consider deploying a reverse proxy server in the perimeter network (DMZ) to publish the CWA virtual server that is designated to handle traffic from external users.

A commonly asked question concerns the collocation of the CWA with other R2 server roles on the same box. This is not an officially supported scenario (see Supported Server Role Collocation). Should you somehow decide to go ahead and setup CWA on the Front-End server for instance, you will have to explicitly resolve the conflict of both the CWA and Web Access Services that arise from using the same default TCP port 443.

The Director and Edge

The Director shields the CWA server and Front-End server pool from incoming traffic with another layer of security. This particular server role does not home any users and functions as a next-hop server. Internal users hitting the Director will be redirected to the respective home pool whereas traffic will be proxied for remote users coming through the Edge server. In an environment with more than one pool in production, deploying the Director will spare you from having to configure one of the pools to perform the proxy task and the risk of performance degradation (see Deploy a Director on how to do this). Existing RTM Director and Edge server roles can communicate with R2 server pools and clients. However, R2 editions of the Director and Edge server roles do not work with the RTM server pools. As a result, upgrade of these two server roles at the same time to support both RTM and R2 server pools may be essential early in your project plan to ease transition for users already homed on R2 servers.

You should be aware of restrictions such as public IM and federation for side-by-side configurations in the same organization and SIP domain. Remote users with MOC R2 clients will not be able to communicate until the R2 versions of the Director and Edge server roles are operational. This is another good reason to hold back deployment of MOC R2 for users that need to consume any R2 services outside the corporate firewall in the absence of a VPN.

With or without hardware load balancer, RTM and R2 server roles cannot co-exist in the same Front-End Pool, CWA server pools, an Edge array or Director array. However, the same HLB can front RTM and R2 Enterprise Pools at the same time. As with the R2 Front-End configuration, the Access Edge, Web Conferencing Edge and Audio/Video Edge services now reside on the same physical machine in a consolidated Edge topology. In any case, only the Access Edge server role at the data center is active and responsible for SIP signaling traffic for the entire organization. This is regardless of how many branch office Edge servers you may have out there. On top of the classic DNS and certificate dependencies, I also want to draw your attention to how DNAT and SNAT could affect your firewall deployments (destination and source network address translation). See Planning for External User Access for more information on this topic.

Monitoring and Compliance

Because the Quality of Experience (QoE) Monitoring Server is deprecated in R2, this particular server role should not be removed from the environment if you need to continue collecting Call Detail Record (CDR) metrics from users that are still homed on RTM server pools. Tracking CDR collects statistical usage data without saving details of the actual conversation itself.

Note that in R2, both the QoE data collection and CDR services now reside on the new Monitoring Server role. Previously, the CDR service is an integral part of the Archiving and CDR Server (RTM). For legal and compliance requirements, your organization may be obliged to log the contents of every communication taking place in the network. As all Instant Messaging conversations must traverse through the users’ home servers, you can enforce this transparently at the Archiving Server level. If you intend to start data capture from day one, you should already install, activate and configure the R2 Monitoring Server as well as R2 Archiving Server before you home any users on R2 Front-End pools.

You should double check that the pool is correctly associated with the deployed R2 Monitoring Server when you enable the CDR and QoE data collection option. Once again, you will have to maintain the existing Archiving and CDR Server (RTM) and build a different Archiving Server (R2) with its own SQL Server database (on the same or another dedicated machine) to facilitate logging conversations on the associated R2 Front-End pools. Additionally, you must manually install the Message Queuing (MSMQ) service on all R2 Front-End and Standard Edition servers, Monitoring Server and Archiving Server itself prior to deploying these 2 latter server roles. I propose that you consult the Archiving and Monitoring for Office Communications Server 2007 R2 for an overview of the archiving and monitoring architecture and lookout for the various agents and service components to make this work correctly.

The optional Monitoring Server Report Pack greatly simplifies generation of captured data and is highly recommended. To this end, you must install the SQL Server Reporting Services from the deployed version of SQL Server (2005 SP2 or 2008). For installations using SQL Server 2005 SP2, go ahead and apply both the KB942662 and KB940382 updates that are required for reporting to function correctly.

Enterprise Voice

The Quality of Experience Monitoring Server Administration Tool (RTM) does not have any built-in capability to associate a RTM Mediation server with a R2 Enterprise Pool. As such, you must take extra steps to realize this by applying KB956829 followed by the Microsoft provided script (Associate.vbs). The purpose is to enable QoE reports to be delivered to the R2 Monitoring Server that is bound to its R2 Standard or Enterprise Edition Pool in a coexistence environment. For this to work, UC-enabled users must be homed on the R2 Pool. Like the other RTM server roles, the QoE Monitoring Server can be decommissioned once you are completely migrated to the R2 counterparts.

For those of you who intend to integrate R2 with the Unified Messaging feature in Exchange Server 2007 SP1 or an existing PBX, you should closely follow the TechNet Library documentation entitled Deploying Enterprise Voice. The outlined steps apply equally regardless of whether you have a current RTM setup or not. Like the different R2 setup steps during installation, it is safe to re-run scripts and applications that you have executed previously e.g. from exchucutil.ps1, ExchUMutil.exe to OCSUMutil.exe. Obviously you should carefully review the installation logs for hints in resolving any warnings or errors that surface. Configuration information from location profiles, dial plans to Exchange AutoAttendant functionality should continue to work without modifications. Nevertheless, you will want to perform tasks such as defining a new Exchange UM IP Gateway object and point it to the new R2 Mediation Server to optimize traffic routing, for instance.


The principle behind a side-by-side migration is rather straightforward and can be tedious nonetheless. It mirrors that of a brand new R2 installation parallel to your production OCS 2007 RTM deployment. In this final installation of the article, you have learnt that to achieve this goal, you can essentially adopt the same set of official R2 deployment guidelines with a careful lookout for any gotchas.

In a typical inside-out migration, you start by deploying the Front-End Pool and gradually introduce additional internal R2 server roles from CWA, Monitoring, Archiving to Director that is appropriate to your organization. Along the way, you should validate and run functional tests to confirm that everything works as expected with the necessary adjustments. Until the supporting R2 Director and Edge server roles are in operations, UC-enabled users homed on R2 Front-End Pool will be blocked from access remotely.

As soon as the infrastructure has been fully migrated to R2, you should take the next step to move UC-enabled users to home on R2 server pools. To take immediate advantage of new R2 features, migration to the MOC R2 client is the next logical thing to do. Eventually, you can gradually decommission remaining RTM servers before planning on adding new R2 server roles to the equation. Taking your time to plan, test and execute the migration in manageable phases will go a long way to keep the project team and end users happy.

The Client Side Story


Besides Office Outlook 2007, you will find that the majority of users will primarily be using the MOC R2 and Office Live Meeting 2007 clients to conduct their day to day business from instant messaging, presence, peer-to-peer video and voice call to web conferencing. With additional R2 productivity features, the new Office Communications Server 2007 R2 Conferencing Attendant and Office Communicator 2007 R2 Group Chat clients should be listed in your deployment plans as well. For those of you on the RTM version of MOC, you can directly upgrade to the R2 equivalent without first uninstalling the former. It is important to understand that users using the R2 version of MOC can only be homed on an R2 Enterprise pool or Standard Edition server, although users running MOC RTM can also be hosted on the latter two. In other words, you can first move users running MOC RTM to home on R2 pools and defer upgrading to the MOC R2 client to a later date.

Taken together, all of the R2 client applications rely on different minimum versions of Windows service packs and supporting components to operate correctly. To take full advantage of the latest functionality, simplify rollout and on-going maintenance, I recommend that you consider standardizing at least on the following:

In contrast with the back-end R2 server roles, Windows client computers are not required to be 64-bit capable to run any of the R2 client applications. Although Windows 7 as well as Service Pack 2 for Windows Vista have recently been released (KB948465), IT shops may still need to devote sufficient time to test for compatibility with their line-of-business applications. Besides, Vista SP1 is a pre-requisite for SP2. Unless your Vista client desktops are already deployed with SP1, it makes sense to start off at this base level before pushing out SP2 within the next 24 months.