Microsoft Office Communicator Server 2007

Recently an odd thing happened on the way to The Forum.  We are still trying to figure out why these things happened however the upshot was that we lost connectivity to our OCS server.

The trouble with OCS is that it is one of those technologies which is quite involved yet once put in properly it also just works.  This has the double nightmare of when things go wrong they are normally something you have seen before but can't remember and also require you to relearn all that you forgot - remembering the best way of learning is making mistakes....so yes you do all the same mistakes again.

Well that's what happens if you don't write things down.  So I am.

First thing I did was reboot the box as to my knowledge nothing had changed. 

Can you see where this is going?

Red Herring:  Still no joy so I checked the services for OCS and they wouldn't start, the event log showed that our evaluation license for OCS Enterprise has expired.  Great.  So I checked Microsoft Licensing and found that there was no evaluation license for OCS Enterprise, strange.

We deploy our monthly patches using WSUS to install them and all that is required to make these patches live is a reboot....uh oh.

It turns out a Microsoft Patch (ms09-056) put our OCS servers into "expired evaluation mode" which was nice.  Then I found this article from Microsoft detailing the known error and how to fix it.

http://www.pro-exchange.be/blogs/ocs2007/archive/2009/10/24/update-on-patch-ms09-056-which-caused-ocs-to-revert-to-an-expired-eval-version.aspx

So this hadn't stopped our OCS from working just merely confused the issue with an hour of Googling.

I found all but one of the services now started up fine.  The service which clients connect to steadfastly refused to start.  This made me think that possibly the certificate was incorrect.

I found that the certificate was infact not installed at all on the server, however MTLS was configure to use a certificate.  I duly ran the certificate wizard from OCS (after finding that you can't generate the cert request and manually complete the request!)

Once the certificate was installed things began to look up and all services started, however I was still unable to get the MOC client to auto-config.  Now I know auto-config uses DNS and as we have two domains (in SIP terms), an internal namespace and a different email/SIP namespace we needed some jiggling around of DNS to allow things to work correctly.

For those on the search for these things, here is what you need, DNS wise if your internal AD domain is different from your email/SIP domain name (who's isn't?)

Internal AD Domain Name: internal.org
Email/SIP Domain Name : email.com
OCS Server Name : ocs-server.internal.org

I am assuming you already have a DNS zone for internally resolving your email./SIP domain name.  If not you need one.  Also assuming you are using (M)TLS if not then use _sipinternal not _sipinternaltls.

An SRV record called _sipinternaltls.email.com which resolves to sip.email.com (or anything to that mater but HAS to be in the SAME domain and sipinternaltls).  Configure this with the protocol of _tcp and port set to your port which defaults to 5061 for (M)TLS and 5060 otherwise.

A host record resolving sip.email.com to IP of ocs-server.internal.org

Test test and test again.  Using nslookup from a client machine enter:

>set type=srv
>_sipinternaltls._tcp.email.com

the output should be something like:

_sipinternaltls._tcp.email.com SRV service location:
priority          = 0
weight            = 0
port              = 5061
svr hostname      = sip.email.com
sip.email.com internet address = 192.168.0.1

Simple.

Now I've written this down, I'll never need it again.  Roll on Lync 2010.

Comments

Popular posts from this blog

PXE booting, MDT and 802.1x

Intune installation requires a wire...or does it?

Security Policy 1001