Rick Varvel

OCPE Device (Tanjay) Upgrade Guide

This document provides best practices for upgrading an OCPE device (Tanjay) from build 199 to 522 and then to 6907 using just the Office Communications Server 2007 R2 (OCS 2007 R2) Device Update service.

For those familiar with the process, there is a high level walkthrough in the “OCPE Device Upgrade Steps (Summary Version)” section; otherwise the detailed process begins with the Step 1 in the “OCPE Device Upgrade Steps (Detailed Version)” section.

Also included:

• Background information on how the different Tanjay firmware builds behave during the sign in and download process to assist with troubleshooting
• Environmental dependency settings for DHCP, NTP, certificates, and DNS
• Pool configuration changes required to successfully sign in and upgrade a Tanjay
• Syntax examples and a sample scenario to simplify the deployment process
• A sample NetMon trace file highlighting a successful sign in and upgrade
• Log file locations and URLs used in troubleshooting common issues
• An Appendix with step by step instructions for many common tasks

 

OCS 2007 R1/R2 Remote Access Configuration Guide

Configuring port, certificate and DNS values for an OCS 2007 R1 / R2 Edge server topology can be confusing, especially when multiple Edge servers are involved. This OCS 2007 R1/R2 Remote Access Configuration Guide was created to simplify the process:

http://cid-b6d0e1f9969eb052.skydrive.live.com/browse.aspx/.Public/OCS2007R2EdgeConfigGuide

Office Communications Server (OCS) 2007 R2 provides instant messaging (IM), presence, conferencing—and if PSTN integration is configured—voice capability for employees within your organization. To allow remote access to these features it’s necessary to install and configure one or more Edge servers.

Currently there are 2 versions of OCS deployed in production environments; the original version which is referred to in this document as OCS 2007 “R1” and the most recent version called OCS 2007 “R2”.

Between the 2 releases there are four primary Edge topologies and this document covers all of them, starting with the simplest and moving to the most complex. The focus will be on the current R2 version of OCS 2007 but configuration and operational differences between versions will be clearly defined when necessary.

The Configuration Guide is split into 3 sections:

1. Overview – OCS remote access best practices
2. Scenarios – detailed certificate / port / DNS values for each topology
3. Step by Step – detailed instructions for configuring Edge / Reverse Proxy servers

Recommended Usage:

Step 1 - Review the information in the Overview section and determine which remote access scenario matches your business requirements

Step 2 - Review the 10 to 15 pages associated with the specific scenario you want to deploy

Step 3 - Search each of the tables related to the chosen scenario replacing existing server FQDNs / IP Addresses with your production values

Step 4 - Print out the results and use it as a reference for ordering certificates, opening firewall ports and creating DNS A / SRV records

Step 5 - Optionally, use the Step by Step instructions to configure OCS for remote access if necessary

The best practice and related configuration information provided in the various sections is based on over 50 production remote access deployments but please keep in mind they are recommendations only. It is possible to configure OCS remote access many different ways but this document focuses on the approach proven to produce consistent results with a minimum of errors.

For reference, here is a summary of the content:

SECTION 1 – Remote Access Overview

·         Introduction

·         Edge Topology Options

·         Remote Access Best Practices

·         Certificate Recommendations

·         DNS Recommendations

SECTION 2 – Deployment Scenarios

·         Deployment Model (Scenario Based)

·         Scenario 1 – Single Consolidated Edge (R2)  

·         Scenario 2 – Scaled Consolidated Edge (R2)

·         Scenario 3 – Single Site Edge (R1)

·         Scenario 4 – Scaled Single Site Edge (R1)

SECTION 3 – Step by Step Instructions

·         Step by Step – Edge

·         Step by Step – Next Hop Pool

·         Step by Step – ISA

·         Appendix A: Common Configuration Issues

For assistance with OCS 2007 remote access design refer to one of these links:

For R2 Edge:

http://technet.microsoft.com/en-us/library/dd425196(office.13).aspx

For R1 Edge:

http://www.microsoft.com/downloads/details.aspx?FamilyId=ED45B74E-00C4-40D2-ABEE-216CE50F5AD2&displaylang=en

Thanks.

Configuring R2 A/V Edge Service for NAT

OCS 2007 R2 introduced support for configuring a firewall to perform Network Address Translation (NAT) for the A/V Edge external interface. This option is available only with the Single Consolidated Topology as shown in figure 1.0.

When configuring the A/V Edge for NAT it’s possible that remote users (both employees and federated) will be able to establish IM connectivity and view presence data but not escalate the conversation to an audio session. The call will typically appear to connect but then drop within about 5 seconds with the error message: “The call was disconnected because you stopped receiving audio from firstName lastName. Please try the call again.”

Figure 1.0 – Typical AV Edge Configured for NAT

Cause:

The error only occurs when remote users are trying to establish a MOC to MOC audio conference with an internal user (with 2 remote MOC clients, the audio stream is point to point between them via the Internet).

The error is caused by a change in R2 A/V Edge service behavior. When the “External IP address is translated by NAT” checkbox is checked, it signals the A/V Edge service to provide the Pool front end server with the IP address associated with A/V Edge’s external FQDN. That IP address is then returned to the remote client via in-band provisioning and if it happens to be the NAT’d IP address of the A/V Edge service instead of the Public IP address, the remote MOC client will not be able to connect.

Detection:

A Snooper trace of the Communicator-uccapi-0.uccapilog will look something like this:

Figure 1.1 – Snooper trace showing sample A/V Conference Initiation

 

Trace of Failed Connection:

200OK from Address Exchange (16:18:07.558) – a=candidate: list indicates which IP Addresses are available to the remote endpoint. Note that all candidates are non-routable in this trace.

200OK from Candidate Promotion (16:18:13.246) – a=candidate: list indicates which IP Addresses the remote endpoint will attempt to connect to. The remote endpoint will fail when trying to connect to 10.45.16.5

For comparison, the trace from a successful connection below shows that the remote endpoint will attempt to connect to a publicly routable IP address (which will NAT to the A/V Edge service’s private IP address) and the audio conferencing session will be established.

Trace of Successful Connection:

200OK from Address Exchange (16:18:07.558) – a=candidate: list indicates which IP Addresses are available to the remote endpoint. Note that 4 of the candidates are publicly addressable in this trace.

200OK from Candidate Promotion (16:18:13.246) – a=candidate: list indicates which IP Addresses the remote endpoint will attempt to connect to. The remote endpoint will succeed when trying to connect to 63.123.155.5

Prevention:

To avoid this issue perform the following 4 steps as part of the A/V Edge service configuration. And keep in mind they are unique to the single consolidated Edge topology.

Step 1 –  Configure the firewall to perform DNAT inbound and SNAT outbound for the A/V Edge external interface

In any location with multiple Edge Servers deployed behind a load balancer, the external firewall cannot function as a network address translation (NAT) device. However, in a site with only a single Edge Server deployed, the external firewall can be configured as a NAT.

If you do so, configure the NAT as a destination network address translation (DNAT) for inbound traffic—in other words, configure any firewall filter used for traffic from the Internet to the Edge Server with DNAT, and configure any firewall filter for traffic going from the Edge Server to the Internet (outbound traffic) as a source network address translation (SNAT). The A/V Edge server external interface will have a private IP address, as shown in Figure 1.2.

Figure 1.2 Sample AV Edge configuration for NAT

   

 

Step 2 –  Configure the Edge server to resolve the FQDN associated with public A/V Edge service to the public IP Address, not the NAT’d IP address. Using Figure 1.0 for reference; assume your A/V Edge service has a public IP address of 63.123.155.5 and a NAT’d IP address of 10.45.16.5; if you run CMD.exe from the Edge server and type ping av.contoso.com it must return 63.123.155.5

Step 3 –  Configure the A/V Edge service to support NAT by checking the “External IP address is translated by NAT” checkbox

Step 4 –  Restart the Edge server (or at least the A/V Edge service) to force the changes to take effect

Remember, if the A/V Edge external interface is not publicly addressable, federated A/V conferencing with OCS 2007 R1 clients is not an option.