Over the last week or, so I’ve posted several articles on the Microsoft View of Unified Communications (UC), looking at

1. An introduction to UC (from a Microsoft view).
2. How UC can change the ways in which we work.
3. How the various Microsoft UC components work together.
4. Some of the things to know about Cisco’s UC solutions, QoS and codecs.

This final post in the series has been part-written for over a year now (ever since I got involved in a UC pilot project in 2007). Even though I was a Microsoft Certified Technical Specialist (MCTS) for Live Communications Server 2005 (the predecessor to Office Communications Server 2007) and have worked with Exchange Server since 1996, I haven’t carried out a real LCS deployment and unified messaging is a new feature in Exchange so the project involved a steep learning curve. This post summarises the points that I learned along the way (with more than a little help from colleagues) – not so much a product review as a collection of notes that I made that might be useful to others.

• DNS is critical to a successful UC deployment as OCS relies heavily on DNS for name resolution. Specifically, it uses SRV records to hold details of key servers within the organisation for automatic logon (_sipinternaltls for TCP connections over port 5061 to sip.domainname.tld). If users are having problems with OCS, start off by checking the DNS event logs.
• Other services that are required include Microsoft IIS and ASP.NET.
• Secure communications require a certificate service. For internal deployments, it might be possible to get away with a self-signed certificate (especially if group policy can be used to ensure that all the clients trust the entire certificate chain); however for external deployments it’s best to get a certificate from a known trusted source. Certificates from well-known and trusted organisations like Verisign are pretty sure to work whilst providers of free certificates may not be trusted (so offer little advantage over self-signed certificates); there is a middle ground though as low-cost certificates can be found which are trusted by default in many browsers. Subject alternative name (wildcard) certificates are also available (e.g. for *.domainname.tld).
• Like some other products (e.g. Exchange Server 2003), OCS uses a wizard-based approach to deployment, guiding an administrator through each of the stages depending upon the type of server that is being installed.
• If an organisation is nervous about making schema changes OCS may cause some issues as it requires a schema update (as does Exchange Server). This is often made out to be a bigger problem than it really is.
• OCS does require the domain in which it is to be installed to be running at Windows Server 2003 functional level.
• Location profiles can be used to normalise numbers into the correct format.
• Web conferencing (e.g. for Live Meeting) is enabled in the OCS global properties.
• OCS contacts are stored in Active Directory in a container called RTC Special Accounts (visible with advanced features enabled).
• During our deployment, we used method 2 in Microsoft knowledge base article 951644 to get around Outlook integration errors because our OCS signon address did not match the e-mail addresses use in Outlook. The Office Communicator team has published some good advice for troubleshooting Outlook integration and address book errors.

OCS is only one of Microsoft’s unified communications technologies and another key element is the new unified messaging (UM) role in Exchange Server 2007. Note the distinction between unified communications (bringing together multiple forms of communication along with presence awareness) and unified messaging (one inbox for all message types – e-mail, fax or voicemail – for a more detailed explanation, refer to part 1 in this series of posts).

In terms of deployment, Exchange UM is far less user-friendly than OCS and requires the use of Windows PowerShell/the Exchange Management Shell. Setting up Exchange UM to work with OCS involved:

• Creating a new dial plan (e.g. new-umdialplan -name dialplanname -uri
type "sipname" -voipsecurity "sipsecured" -numberofdigitsinextension 5).
• Specifying the UM server to be associated with a dial plan (e.g. set-umserver -id exchangeservername -dialplans dialplanname).
• Enabling mailbox access for users (e.g. enable-mailbox -identity 'msuc.co.uk/Users/username' -alias 'aliasname' -database 'exchangeservername\storagegroup\database').
• Enabling the user’s mailbox for UM (e.g. enable-ummailbox -id username -ummailboxpolicy "mailboxpolicy" -extensions voiceextensionnumber -sipresourceidentifier emailaddress -pin pin.
• Creating a UM-IP gateway with associated hunt group and set permissions (run .\exchucutil.ps1 from Exchange Server 2007 service pack 1).
• Creating a UM auto attendant (e.g. set-umipgateway -identity ocsserver -port 5061).
• Get details of the OCS pool (run .\get-ucpool.ps1 from Exchabge Server 2007 service pack 1).
• Running the Exchange UM integration utility (ocsumutil.exe /domain:dnsdomainname) to allow OCS calls to be routed to Exchange Server (for capture as voicemail).
• Configure SSL on the Exchange Server.

Of course, the beauty of PowerShell is that this may appear complicated but can be scripted for re-use.

All of the above is concerned with deploying OCS for instant messaging/presence and integrating it with Exchange for voicemail. It should be noted that OCS is not a PBX replacement (even though it will integrate with major manufacturer’s PBXs) and that for routing voice calls to/from OCS a mediation server is required. In the pilot, we used an Dialogic IP Media Gateway 1000 but this is very much an entry-level system and there are appliance servers (e.g. the Dialogic DMG4000) that combine the role of OCS mediation server with the IP media gateway functionality. The mediation server is fairly simple to deploy, with the only specialist requirements being the definition of the listening address and gateway, along with the details of the PSTN gateway (the IP-PBX or the media gateway).

Communicator Web Access (CWA) is a potentially useful feature within OCS – providing a OCS client access from within a web browser. The only gotcha that I came across during testing was the need to create a certificate (for activation) using a tool from the LCS 2005 resource kit (lcscertutil.exe) with the web server certificate template.

A couple of other server roles that are worth mentioning are update servers (for updating OCS software on unified communications devices such as IP phones deployed within the organisation) and archiving servers (for archiving conversation history for reasons of compliance). I didn’t set these up in my environment but they complete the picture in terms of OCS deployment.

Further information

• Microsoft OCS TechCenter.
• Planning for Unified Messaging (Microsoft Exchange Server TechCenter).