Thursday, May 28, 2009

Auto client update in OCS 2007 R2

I have to give Aaron Tiensivu credit for this entry today. The ability for the OCS server to deliver a new version of the MOC client is an interesting method for keeping your client machines up to date however it does have its own drawbacks as well.

Aaron's blog explains how to set this up and I have included my concise steps below as well:

  • Download your Communicator patch file (.msp)
  • Log into your OCS server, run the admin tool and right click your server (for standard edition) or your pool name (for enterprise edition) and choose Filtering Tools then Client Version Filter.
  • Click the Add button
  • Set the User Agent Header to OC
  • Populate the version numbers to coincide with the version you want to update. For example, if you have clients at 6907.0 and you want to patch them to 6907.9 then type in the values as per the image below:

  • Set the remaining options as shown above. One difference here is that I like to set the folder name to be equal to the patch I'm upgrading to (i.e. 6907.9).
  • Next, if you're running Standard Edition, create the folder structure show in the image above exactly. For example, on Standard Edition use: C:\Program Files\Microsoft Office Communications Server 2007 R2\Web Components\AutoUpdate\Files\6907.9\x32\fre\1033.
  • If you're running Enterprise Edition use your shared file location you specified for your Client Update share: \\servername\client_update\Files\6907.9\x32\fre\1033.
  • Now that you have the file structure in place, copy your msp file to the 1033 folder.
  • Your clients should now update properly. You can right-click on the Communicator icon in the system tray and choose Configuration Information to view the update status.

So here is what I don't like about this process....

1. The user needs to have the right to install software. This update process is not much good to organizations with typical security measures in place.

2. These patches should be managed through the companies patch management strategy. Microsoft now offers patches to the MOC client through Windows Update so my suggestion would be to leverage that method instead.

Oh, and by the sure to install the latest May update (6907.22) because previous versions apparently have a bug which prevent them from contacting the update server process.

Thursday, May 21, 2009

Rock solid Tanjay update!

I've found a fool proof way to update the Tanjay phones with or without signing in.

If you want to update an R1 phone without signing into it:

Add a DNS A record called "" where "" is the fqdn of your pool name. Point the A record at your Enterprise pool server or Standard edition server. Also add a static WINS entry called "ucupdates" and key in the same IP you did for the DNS record.

If you want to update an R2 phone:

Add a DNS A record called "" where "" is the fqdn of your pool name. Point the A record at your Enterprise pool server or Standard edition server. Also add a static WINS entry called "ucupdates-r2" and key in the same IP you did for the DNS record.



Wednesday, May 20, 2009

New layout!

I was getting tired of trying to decipher which text was bold and found the old layout to be too 'skinny' :)

Tuesday, May 19, 2009

Install pre-requisites for OCS - the easy way

Thanks to Tom Pacyk in Portland for this tip...

One of the more annoying installation pains we often feel when we install OCS 2007 R2 on Windows 2008 Server is the multitude of requirements which need to be met. Even when you think you've installed them all (IIS in particular), you inevitably find out there are more and more to install.

Tom's information here: shows you how easy the installation can be when you leverage an XML file for installing pre-requisites.

Thanks Tom!



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.



Microsoft Unified Communications Reference Guide: Part 1 (Architecture)


This part will cover the overall architecture of Microsoft's Unified Communications platform.

One of the reasons I appreciate working with this platform is the truely unified nature of the application stack. We're dealing with two server products (for the most part) when it comes to Microsoft UC; Office Communications Server 2007 R2 and Exchange Server 2007.

Office Communications Server 2007 R2 is available in two versions; Standard and Enterprise. The same goes for Exchange Server. So the first question is:

Q: What is the difference between Standard and Enterprise for OCS and Exchange?
A: It has to do mostly with your requirement for High Availability. Do you need HA? If so, then use Enterprise for both platforms.

The Standard Edition of both OCS and Exchange do not support high availability at all. In fact with OCS you don't get the choice of where to install the database and shared components; it will install SQL Express locally.

It should be worth mentioning that the server edition software is independent of the client licensing platform. For example, you can have an Enterprise OCS and Exchange CAL for your users who connect to a Standard Edition OCS/Exchange environment (and vice versa).

Q: What is the difference between the Standard OCS CAL and Enterprise?
A: The Microsoft web site has a great page which talks about this.

Q: What is the difference between the Standard Exchange CAL and Enterprise?
A: Again the Microsoft web site explains this well.

When you license both Exchange and OCS with 'all the trimmings' you get the following high-level features:

OCS Features
  • Presence/Instant Messaging
  • Web Conferencing (Live Meeting)
  • PC to PC and voice/video
  • IP Telephony (VoIP)
  • Audio dial-in conferencing
  • Group chat

Exchange UM features

  • Unified Messaging
  • Outlook Voice Access
  • Auto Attendant

As a best practice I like to design OCS solutions so they include some additional Microsoft UC platforms such as:

  • Microsoft OCS Monitoring Server (for QoE/CDR)
  • Microsoft OCS Archiving Server (for IM logging)
  • Microsoft OCS Edge Server (for remote IM/Voice/Video/Federation/etc)
  • Microsoft OCS Mediation Server (for VoIP/PSTN features)
  • Microsoft OCS Communicator Web Access (for dial-in conferencing and web-based IM)

Q: When do you need a Monitoring Server?
A: I like to include the Monitoring Server role in just about every implementation for two reasons. First, the Quality of Experience technology is key to understanding the Mean Opinion Score (MOS) of your voice conversations. The MOS score is given to a voice call and is a simulated subjective analysis of voice quality on a per call basis. The QoE data is invaluable when troubleshooting voice quality issues and has improved significantly from the R1 release. Second, the CDR data rolled up into the SQL reports contains excellent information when it comes to determining how many IM conversations, PC to PC calls, or conferences were conducted in a certain time frame. You can use this data to gauge relative interest in the technology or for capacity planning.

Q: When do you need an Archiving Server?
A: If you have a requirement to log Instant Message conversations.

Q: When do you need an Edge Server?
A: If you have a requirement to communicate with other companies running OCS (Federation), you want to enable users to have public IM capability (Yahoo!/AOL/MSN), or you simply want to enable remote access (anonymous or authenticated). One of the primary reasons for an Edge Server is to permit people to join your hosted Live Meeting sessions.

Q: When do you need a Mediation Server?
A: If you wish to enable Voice over IP and use OCS to place phone calls. The Mediation server performs a few tasks. First, it does basic protocol conversion from Microsoft's "RTAudio" codec to a more industry standard "G7.11" codec. Second, it performs encryption or decryption on voice traffic. Many vendors today offer this server in an appliance configuration where the Mediation Server is combined with a voice gateway; this is often called a "Hybrid Gateway". One vendor called "NET" has a gateway called the VX1200 which can perform both tasks without the need for a Windows operating system. The conversion is performed "on chip" and the integration with AD means you can implement OCS voice with one less server! Last, the Mediation Server performs inbound number normalization for PSTN calls (more on this later).

Q: When do I need a CWA Server?
A: If you want to provide dial-in audio conferencing or web-based IM.

That pretty much covers the high level components for now.



Microsoft Unified Communications Reference Guide: Part 0


I'm creating this guide since my colleagues and I often ask the same questions over and over again when implementing Microsoft UC solutions such as:

What databases are used by OCS and how big are they?
What type of certificate do you need for Unified Messaging and what subject name/subject alternative names should it have?

This guide will cover all aspects of implementing both Microsoft Office Communications Server 2007 R2 and Microsoft Exchange Server 2007 with Unified Messaging.

One of the most interesting topics of late is the need for E.164 formatted phone numbers. This means more than simply having a "+" sign in front of the digits. The use of this format, or more interestingly the use of a plus sign, has been debated by many in the industry along with Microsoft's internal product group. This guide will cover my theory behind using E.164 numbers, DID's and non-DID's.

Please feel free to email me or post your questions/comments/etc.



Sunday, May 10, 2009

To "9" or not to "9", that is the question

I know, terrible title....

Anyway I have a quick post today about normalizing numbers with a "9" prefix (or without) using one line rather than two rules. This tip comes from Mike Stacy.

....edited on May 28, 2009....

I've come across a nasty case where the MOC client normalizes the number but just doesn't want to dial it. I originally posted the fact that you could use a "?" following a number such as "9" so the input of that value is optional. As it turns out, this isn't the case.

The following format does work:


This will normalize the following numbers:


...all into the following:


No need to create two rules to handle the 9, 1 or nothing in front of your numerical value.


Friday, May 8, 2009

ZANTAZ (EASOWA) ISAPI Filter causes a 2007 CAS to fail with "Object Expected"

Again, another odd issue I've come across this week....

While installing an Exchange 2007 CAS server at a client site (getting ready for a 2003 to 2007 migration) we encountered a case where Outlook Web Access produced the following error:

"Object Expected"

A refresh of the page resulted in a white page with no formatting and some odd looking buttons. Exchange 2007 CAS server is supposed to proxy the client requests to either a 2003 or 2007 mailbox depending on where it "lives". During the implementation of of the CAS server we tested moving a user's mailbox to a 2007 server and logged onto the CAS just issues. It was when we attempted to authenticate a user who had a 2003 mailbox where things went sideways.

We tested navigating to the 2003 front-end server and directly at the 2003 mailbox cluster with no issues. I noticed a plug-in was installed when I visited the OWA site which lead me to ponder the possibility of it interfering with the proxy request. A call to Microsoft support confirmed this.

The 2003 mailbox server had an ISAPI filter on the IIS web site used for OWA. The plug-in is called "EASOWA" and is used by the ZANTAZ software (for email archive). We removed the ISAPI filter and it worked immediately.

Since the migration will be short, there will be no workaround for the issue and an EASOWA plug-in for 2007 is being tested as I write this.

Troubleshooting this issue was particularly difficult in that a direct connection to the 2003 FE or MB server worked fine. The 2007 CAS server also worked fine when connecting to the 2007 MB server. It was the process of proxying the link where things broke down. I was convinced it was the 2007 CAS server at the time but obviously I was wrong. Hmmm....that's twice now.



Exchange Update Rollup 7 blows up EWS/UM/AD

Well I spent a few hours with Microsoft support today throubleshooting an issue with Exchange Web Services, Unified Messaging, and Autodiscover. It appears that the web.config file contains a variable called %ExchangeInstallDir% which is invalid. The web application can't interpret what this variable is because it isn't set on the OS anywhere.

The issue is visiable in two ways:

1. Try to navigate to https://serverfqdn/ews/exchange.asmx (it will fail)
2. Try to run the "Test-OutlookWebServices -Identity fl" and it will show you all kinds of errors.

The fix was to open the web.config files at:

C:\Program Files\Microsoft\Exchange Server\ClientAccess\exchweb\ews
C:\Program Files\Microsoft\Exchange Server\UnifiedMessaging\WebService

...and replace the %ExchangeInstallDir% with C:\Program Files\Microsoft\Exchange Server\

Restart IIS using "IISRESET" and you should be okay.