If you haven't yet heard about Microsoft's Unified Communications (UC) strategy,
chances are good that you'll be hearing about it ad nauseam over the
next 6 to 12 months. Steve Ballmer and his crew have made it very clear that
they're ready to take the world of convergence head-on. With apologies to Microsoft
Speech Server, Exchange Server 2007 Unified Messaging (UM)—released late
last year—was Microsoft's first real attempt to enter the IP telephony
market. Exchange UM provides the ability to integrate voicemail, fax, and of
course email into a single mailbox solution. However, Exchange UM still relies
on third-party telephony systems, whether legacy PBX or IP-PBX solutions.
At the same time, the concept of "presence" is causing
quite a stir. Companies such as Microsoft, Cisco, and IBM
are all battling for the rights to own and control the presence engine. What is presence? It's the ability to locate and
identify a person (or group of people) and communicate
with them, regardless of the means of communication (e.g.,
PC, desk phone, cell phone, IM). Microsoft's first attempt at
presence was Microsoft Office Live Communications Server
2005 (LCS 2005). (Exchange 2000 Server IM and LCS 2003
predate LCS 2005 but were crude at best.) However, LCS
wasn't an ideal solution.
With the introduction of Microsoft Office Communications Server (OCS) 2007, Microsoft merges call control (the
ability to route and place a telephone call) and presence
technologies together into a single offering. OCS 2007 Beta
3 was released in March 2007. Since the product's release,
Microsoft has been very proactive in distributing the various deployment and administration guides, as well as providing hands-on training for many of their key partners.
Although I've been through Microsoft's official "Ignite" program for partners,
I wanted to step outside the Microsoft sandbox and install OCS Beta 3 from scratch
in my environment. To test the product's functionality, I needed several puzzle
pieces: Active Directory (AD), Exchange 2007, a member server for OCS, and a
Session Initiation Protocol–Public Switched Telephone Network (SIP-PSTN)
gateway. I used an inexpensive, yet very configurable, gateway device from AudioCodes—the
MP-114 (http://www.audiocodes.com/content.aspx?voip=2823).
Installation
Because AD will contain all of the SIP user information and settings, you need
to extend the schema to accommodate these additional attributes. The schema
extension itself is fairly straightforward, with the same administrative requirements
as Exchange, LCS, and Microsoft Systems Management Server (SMS).
Likewise, OCS setup must be run at
both the forest level and domain level to
prep AD. Microsoft has made this portion
of the setup process almost foolproof by
reducing the number of use-interactive
steps required, as well as preventing you
from being able to initiate a step without
finishing the earlier steps.
If you're familiar with LCS installation,
you'll be happy to know that Microsoft has
simplified the process of installing certificates as well. However, a glitch I stumbled
upon is that if your forest and domain functional levels aren't set for Windows Server
2003, the certificate requests will fail with
very little explanation.
One of the handiest installation features is the verification process, which
lets you verify not only server configuration but also connectivity. I discuss
installation of the other server roles later in the article.
Configuration
For anyone familiar with AD, enabling and configuring OCS users is easy. You
can enable users in bulk or on a user-by-user basis. The minimum setting that
must be completed is the SIP address assignment (commonly, the user's email
address). However, additional settings can be configured, including federation
(presence connectivity with other LCS/OCSenabled companies), public IM connectivity
(Yahoo!, MSN, AOL), and remote user access (the ability to connect to OCS from
outside the firewall).
One of OCS's new features is Enhanced Presence, which you can also configure
on a per-user basis. Enhanced Presence lets you place users into various Presence
Access Levels (Block, Public, Workplace, Team Members, and Personal). Each level,
from left to right, allows more presence data to be presented to contacts. For
example, contacts who are in the Public level can see only Presence State (e.g.,
Online, Busy), Display Name, E-mail Address, Title, and Company. At the other
end of the spectrum, Personal contacts can essentially see all user data stored
in AD for a particular user (e.g., Work Phone, Home Phone). A caveat with Enhanced
Presence is that if you enable it, users must use Microsoft Office Communicator
(MOC) 2007. Older versions (e.g., Windows Live Messenger, MOC 2005) won't be
able to connect.
With relation to OCS itself, most of the configuration is already complete
in this scenario. The only piece that still needs configuration is DNS. OCS,
like LCS, requires the creation of specific SRV records in order for automatic
server detection to function. Within DNS, you must create an "Other New Record,"
setting the Service type to _sipinternaltls, protocol to _tcp, and port number
to 5061 (which represents Transport Layer Security—TLS—encrypted
SIP traffic). After configuration, users won't need to enter a specific OCS
server IP address or Fully Qualified Domain Name (FQDN) address into the MOC
client. This is especially important for users who work both onsite and remotely,
because the two IP addresses will almost certainly vary.
Additional Roles
Microsoft seems to be moving toward a distributed solution model in which a
single product needs to be installed on separate physical servers. Such is the
case in Exchange 2007, Microsoft System Center Operations Manager 2007, and
now OCS 2007. What this requirement actually means depends on the size of your
implementation. Roles can be consolidated onto one piece of hardware, but for
larger organizations that will be taxing the resources on an OCS server, additional
physical hardware is needed. The two roles that carry over from LCS 2005 are
Access Proxy and Director.
The Access Proxy role lets you enable remote connectivity, federation, and
public IM connectivity. Although this role is fairly straightforward, additional
network planning is necessary because it resides in a demilitarized zone (DMZ).
Prev. page
[1]
2
3
next page 
