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).
The Director role is used to route traffic to the proper OCS pool (OCS servers), as well as act as a middleman between the Access Proxy role and the front-end OCS servers. A compromised Access Proxy role can't bring down AD or the OCS front-end servers, because the Director role would take the brunt of any Denial of Service (DoS) attack. Installing the Director role is simple.
OCS 2007 also includes four new roles. These roles are telephony enablement (Mediation Server), on-premise conferencing (Microsoft Office Live Meeting), compliance (Archiving Server), and remote telephony (Edge Server).
Telephony configuration. Telephony is particularly interesting to me because of what my company does, so I've spent quite a bit of time working with OCS's telephony features. Installing and configuring OCS's Mediation Server role is far simpler than installing some of the more traditional (if we can use that word yet) VoIP vendor solutions. Because AD already contains much of the necessary user information, the only areas you need to focus on are call routing and rules. Setting rules can be a bit confusing if you don't have any experience writing regular expressions. Figure 1 shows an example. The Help files are almost nonexistent in OCS Beta 3. However, searching the Web can be useful.
After you've written your rules (and configured your SIP gateway), you can begin testing the OCS softphone (which is the MOC 2007 application) connectivity to the outside world. In my lab, I used an AudioCodes MP-114 device (with a plain old telephone), as well as an SIP trunk to my Cisco CallManager 5 server. If you don't have access to such equipment, you can use MOC, which also functions as a softphone, to make MOC-to-MOC calls as if they were telephony calls. This process effectively eliminates the need for a traditional handset in order to place a phone call. Microsoft recently announced that their handset line is in full production via several manufacturing partners (http://www.microsoft.com/presspass/press/2007/may07/05-13newgenwork phonespr.mspx), which will present some interesting solutions as well.
Something that I found perplexing, at least in the beta version of OCS, is that only one PSTN gateway is allowed per Mediation Server role. Depending on the size of the environment, it's not unreasonable to assume that a company might have one gateway supporting its T1 links and another gateway supporting PSTN, or possibly a split load for redundancy. We can only hope that this deficiency is addressed before release.
On a similar note, although OCS's Exchange 2007 UM tie-in appears to be pretty tight, some of the steps for integrating the two aren't as seamless as you'd expect. For instance, you must run several command-line scripts, as well as stop and start several services, for OCS and Exchange 2007 UM to communicate and interoperate.
Conferencing. For many years now, Microsoft has offered hosted Live Meeting services via the Web. With the introduction of OCS 2007, Microsoft brings that same functionality on-premise. OCS 2007 lets you provide ad-hoc escalation of conferences (e.g., via IM) for internal and federated contacts, as well as scheduled Live Meeting conferences for "trusted" and anonymous contacts. Thus, many of the meeting events that you previously outsourced to Microsoft or other companies (e.g., WebEx) can now be maintained inside your network. In addition, an Outlook plugin lets you use Outlook's familiar scheduling interface to set up conferences.
The Live Meeting role's configuration is straightforward and mostly focused on meeting policies—particularly who is allowed to participate. The Live Meeting user plug-ins are hands-off, requiring only the basic user information (sign-in name, service URL, and credentials), as well as a complete restart of Outlook. OCS 2007's on-premise conferencing services will be a cost-effective, user-friendly solution for companies. Oddly enough, OCS 2007 is becoming available at the same time that Cisco is moving in the other direction— from on-premise (Cisco MeetingPlace) to offpremise (with the acquisition of WebEx). Only time will tell which method end users prefer, or whether both methods will simply coexist.
Compliance. One of the major reasons for implementing an in-house presence solution is to keep confidential company information off the public wire. However, because you can configure OCS for federation and public IM connectivity, this information can be leaked. Although actually preventing users from revealing this type of information is difficult, you can easily record and audit communications that initiated from OCS.
One of the downsides of archiving for many companies is that to implement archiving, you typically need another server, as well as another instance of Microsoft SQL Server. However, installing the archiving service is a straightforward process. The last step in configuration is simply associating the Archiving Server role with a front-end server. Again, stopping and restarting OCS services on the front-end servers is a bit disruptive but is necessary to properly configure the archiving server.
Viewing archived OCS data is no easy feat for a SQL Server novice. The only way I could find to view an archived conversation was through SQL Server Management Studio (SSMS)—and only then because of some documentation that Microsoft provided to me.
A new OCS feature, Call Detail Record (CDR), includes some slick trending and
analysis reports that take advantage of Excel 2007's new conditional formatting
feature. CDR isn't new to telephony—this feature is crucial to a telephony
system's reliability and functionality. In addition to standard CDR information
(e.g., missed calls, call duration), OCS's CDR reports provide several key pieces
of information, including tracking of:
• application sharing sessions
• A/V sessions
• file transfer sessions
• length of IM sessions
• number of IM sessions
• number of IM messages
• number of IM users
• remote access sessions
Remote telephony. In LCS 2005, if you want to work remotely and use A/V, data sharing, or remote access, you must first connect through your VPN. This requirement is necessary because these features are intended to be point-to-point, and they can't be proxied via the LCS 2005 Access Proxy. Because public IM services already provided these functions, improving upon this area was important when Microsoft replaced LCS 2005 with OCS 2007. However, you still need yet another edge server. Whether the Edge Server role can (or will) coexist with LCS 2005's Access Proxy server role is yet to be determined—but it must if you want to provide Live Meeting, A/V, or telephony support for remote users.
If connectivity "at the edge" works as intended, the Edge Server role will be a major victory for Microsoft. One area that will become clear over time is how the quality of a call that's routed through the Internet via the edge server is affected, especially when multiple users are hitting the gateway at once. According to Microsoft, a high-quality two-way (dual stream) call requires approximately 80Kbps of bandwidth. Multiply that by 20 simultaneous calls, and you could have some congestion on your Internet pipe.
A Force to Be Reckoned With
When Microsoft releases it, OCS 2007 will be a force to be reckoned with. The
previous LCS presence capabilities have been greatly improved, and the voice
capabilities have a lot of promise. Although certain features still need improvement
from the beta version (mainly related to administration and scalability), OCS
2007's one-stop-shopping approach to presence, collaboration, voice, video,
and conferencing will make the product more of a "need" than a "want." With
OCS 2007, Microsoft deftly reigns in the current silos of communication, putting
the rest of the UC world on notice.
| Summary |