Saturday, May 16, 2009

Microsoft Unified Communications Reference Guide: Part 2 (IM)

This post will cover the basic requirements for Instant Messaging features and will outline all the components you will need to install/configure/support the environment.

To get started, lets build out a scenario first. A company has less than 5000 users who need Instant Messaging for both internal and external employees. Connectivity to federated users and Public IM is necessary. The company would like to report on both the usage of Instant Messaging but also be able to archive and extract historical conversations. High availability isn't a requirement today but may become important in the near future.

What infrastructure you need:
  • Office Communications Server 2007 R2 Enterprise Edition
  • Monitoring Server (collocated with OCS pool server)
  • Archiving Server (collocated wtih OCS pool server)
  • Edge Server
  • SQL Server database server (for OCS/CDR/Archive DB)
  • File Server or SAN (for shared file data)
  • Existing PKI infrastructure
  • Firewall with two DMZ networks ("OCS Internal" and "OCS External")
  • Split-horizon DNS infrastructure

For collocation information please see the following Microsoft article:

The above article suggests you can collocate all the above server roles with the exception of the Edge Server on the same system. It isn't typically recommended that the OCS Server and Archiving Server roles be collocated, however given today's powerful servers I'm more inclined to put it all together.

From a physical server perspective you need:

1 - Dual proc/quad core server with 8GB RAM for OCS/Monitoring/Archiving
1 - Single proc/quad core server with 4GB RAM for Edge (must have dual NIC's)
1 - Single proc/quad core server with 4GB RAM for SQL database (unless you have one already)

You will be building an Enterprise Edition environment which has a defined "pool" name. This name is used by clients when they connect and is important to determine before you begin installing.

My guidelines for creating a pool name are quite simple. I typically ask the customer what their SMTP domain is. Let's say it's "". I then ask what their NetBIOS domain name and domain fqdn are. The reason for this is that I need to determine if the domain fqdn is different from the SMTP domain (i.e. Domain fqdn=contoso.local, SMTP

When you create your Enterprise pool name, the setup application will attempt to suggest a pool name by combining your domain fqdn with the name you've given the pool. I always override this because a pool name of "pool01.contoso.local" is of no use to us if we attempt to create SIP URI's with a "" suffix. There is a GPO you can set whereby the OCS client application won't deny a logon if the SIP URI suffix is different from the pool fqdn. This is very important as you can't change it easily once you've created the pool name.

DNS Requirements:

1 Internal A record for the pool name = pointing to the IP of the Enterprise Edition server.

1 Internal SRV record pointing to the pool name (i.e. Set the port to 5061, the priority and weight as default.

1 External SRV record pointing to Set the port to 443, the priority and weight as default.

1 External A record for the Edge server's Access Edge role = which should point to the public IP for this service.

Certificate Requirements:

1 Internal PKI certificate with a subject name of and a subject alternative name of server01.contoso.local, and

1 External public CA certificate with a subject name of

IP Address Requirements:

1 IP for the pool server
1 IP for the database server
2 IP's for the Edge Server (1 internal/1 external)

NOTE: If you're NAT'ing the external IP for the Edge server then you should have a public IP as well as a private IP.

File Share requirements:

Meeting Content Share: file://server/meeting_content
Meeting Metadata Share: file://server/meeting_metadata
Application Data Share: file://server/app_data
Client Update Share: file://server/client_update
Address Book Share: file://server/abs_store

Service Accounts:

RTCEdgeUser (often times a local user if no perimeter domain exists)

Database Requirements:

RTC (persistent user data/contacts/allow & block lists/etc)
RTCConfig (global/pool/computer-level settings)
RTCDyn (transient user data)
LCSLog (used by Archiving Server for IM data)
RTCCDR (used by Monitoring Server's call detail recording and IM stats)
QOEMetrics (used by Monitoring Server's quality of experience data)

Firewall requirements:

Permit 443/TCP from any to Public IP of Edge Server
Permit 5061/TCP from any to Public IP of Edge Server
Permit 5061/TCP from Internal IP of Edge Server to IP of the pool server
Permit 5061/TCP from pool server IP to Internal IP of Edge Server

Now that we have most of the base requirements for the infrastructure, let's talk about the Edge servers. When I first began installing an Edge server I was perplexed at the idea of an "internal" vs. "external" interface and how these would sit on two different networks. After reading some of the OCS documentation I found that you can actually set the Edge server up in three different configurations.

First, the Edge servers can be set up so the external and internal network interfaces are on completely separate networks from the "internet" network and the "lan" network. This means your external interface is on a DMZ network protected by a firewall and using NAT (or not). This also means your internal interface is on a DMZ network protected by the same (or another) firewall.

Q: So how can you have two network interfaces each on separate networks with two default gateways?
A: Well you can do this but I wouldn't advise it. If connectivity is lost for a certain duration, you may have all traffic routed through the wrong NIC. This is due to a feature called "dead gateway detection" and is enabled by default. Read this link for more: My suggestion would be to set your default gateway on your external interface and add a static route for any internal networks you need to get to (i.e. pool server, etc.).

Second, you can have both "internal" and "external" physical interfaces on the same network segment. Again, the external interface will hold the default gateway and a static route is required for all traffic destined for the LAN (i.e. your pool server(s)).

Third, you can get away with a single NIC but this isn't supported by Microsoft.

Another interesting case I run into with each project is an over zealous IT administrator wanting to team every NIC he can find. I really don't get this as I've only seen one network card ever fail in my 15 years of working in IT. Often times the network throughout isn't redundant and the team of NIC's are not connected to different switches, etc. etc.

Q: So what about NIC teaming in general for OCS?
A: Well I've had a few Microsoft support cases with Jithendranath Reddy and he is a smart guy! Check this post of people "having no issues" with NIC teaming: My response is much the same. Leave it out....don't confuse the design by adding this complexity as it will almost always cause more work than it is worth!

Well this is enough for now. Keep checking back for updates to this post for the latest information.



No comments:

Post a Comment