SQL Server Magazine

Unified communications (UC) is yet another in an endless parade of technology buzzwords that you know must be important, since it’s popping up on technology sites all over the Web, but you’re not quite sure what it means-or how it will affect your IT job duties. If you’re confused about UC, you’re not alone: Microsoft, Cisco Systems, IBM, and other key players have their own definitions for UC, and those definitions sometimes differ considerably. As you might expect, Microsoft’s definition of UC encompasses several of its own products-in particular Exchange Server 2007 and Microsoft Office Communications Server (OCS) 2007. To help you make sense of Microsoft’s UC strategy, we’ll look at some key aspects of that strategy, including various UC scenarios and the products that Microsoft envisions for them, as well as UC deployment decisions you’ll need to make in the future.

UM and UC
First, let’s talk about the difference between unified messaging (UM) and UC. The former generally refers to the ability to store and process voice and fax messages in the same containers, using the same clients, as regular email. Microsoft calls the voicemail and fax functionality in Exchange 2007 “UM,” and Cisco and Adomo (two competitors in the market for Exchange-based voicemail systems) use the same term for their products. Other PBX vendors, including Nortel Networks, have long offered UM solutions specific to their PBX systems. The difference is that the current generation of UM products are IP centric instead of being tied to specific PBX models.

UC, on the other hand, is a much broader term whose definition depends on the vendor you ask. Microsoft defines UC as a way to let people communicate by uniting desktop telephones, Time-Division Multiplexing (TDM) and IP PBX systems, the Internet, voicemail, and faxes using a broad variety of clients and services. Perhaps more important, Microsoft places great emphasis on the fact that OCS-Microsoft’s IM, voice, conferencing, and presence server and, with Exchange 2007, the cornerstone of its UC offerings-offers “software- powered VoIP.” So, rather than trying to convince companies to dump their existing PBX systems and deploy OCS, Microsoft’s angle is to point out that OCS adds advanced VoIP functionality to computers, so that you can complement (and, of course, selectively replace) your existing telephony capabilities. As a bonus, the upgrade costs for deploying future versions of OCS could well be lower than the costs of replacing or upgrading a PBX, especially if the PBX in question is an existing TDM system.

UC Components
In its UC vision, Microsoft positions Exchange as the UM component, handling voicemail, fax, and telephone access to messaging. OCS is the component that offers IM, conferencing, presence, and voice services. Microsoft is aiming OCS 2007 and Exchange 2007 at these primary scenarios:
• deploying Exchange 2007 for UM: In this scenario, OCS needn’t be deployed, although Microsoft pitches OCS presence and IM as a natural complement to Exchange.
• providing Web conferencing: In this scenario, Microsoft positions OCS as a drop-in replacement for hosted conferencing services, such as Microsoft Office Live Meeting or Cisco’s WebEx-which, by the way, just happens to also deliver presence and IM. Microsoft previously tried its hand at conferencing with the Exchange 2000 Server Conferencing Server product, which never caught on in the marketplace.
• using OCS to provide voice and conferencing alongside existing PBX systems: In this scenario, users in an organization can use Microsoft Office Communicator 2007 (Microsoft’s UC client) as an OCS client while still using their ordinary desktop phones.
• using OCS to provide voice services instead of a traditional PBX: In this scenario, some users in an organization move to using IP telephones and Communicator as replacements for their existing desk phones. There are several specialized PBX features (such as analog fax and those huge multi-button phone consoles often seen at reception desks) that OCS doesn’t handle, so in this scenario there may still be PBX-based devices.

In all these scenarios, Microsoft’s strategy is to point out the tangible business value that can come from enhancing communication within an organization. Each scenario offers its own advantages from this viewpoint. All the scenarios benefit from the fact that OCS and Exchange rely on Active Directory (AD) for authentication and authorization, so there’s a single unified directory for finding contacts, making appointments, and so on. Additionally, integration of Exchange, OCS, and other products (as I’ll discuss shortly) form a key part of Microsoft’s UC strategy moving forward. Because you can deploy OCS and Exchange independently of one another, one key aspect of Microsoft’s strategy to move customers along into UC is to get people who are now using one of these products to try the other.

Multiple Clients = More Ways to Do UC
In the old days of email, you had email clients that did nothing but email. Separate applications handled calendaring. Gradually those technologies converged into single applications, and over time, other communications and data types (such as RSS feeds and public folders) have been added to email clients. UC represents a new wave of services that don’t fit comfortably into the mold of email clients like Microsoft Office Outlook and Lotus Notes; UC services are real time, and they offer communication types that might not directly match the existing paradigms of how we work with email clients.

That’s an opportunity rather than a problem: Microsoft is delivering several new clients that provide UC voice and conferencing functionality on desktop, laptop, mobile, and browser-based clients. Communicator 2007 is the premium client for conferencing and voice on Windows Vista/XP/2000 systems; Microsoft Office Communicator Web Access provides IM and presence capability on a variety of Web browsers (including, surprisingly, Safari on Mac OS X and Firefox on Windows and Mac OS X); and Microsoft Office Communicator Mobile provides similar functionality on Windows Mobile devices running Windows Mobile 5.0 or Windows Mobile 6.

On top of the software-based clients, OCS 2007 supports a number of “hard phones”: devices that look like phones (or parts of phones) but use Communicator 2007 or OCS 2007 for voice transport. For example, the “Catalina” class of devices is a USB handset that you pick up and use like a regular phone, but instead of a keypad you use Communicator to locate people and place calls to them. (You can find more information about Polycom’s Catalina- class devices at www.polycom.com/usa/en/support/voice/cx/communicator_cx200.html.) Because OCS has a flexible call-routing engine, OCS users can freely place calls to PBX extensions or to outside users who aren’t using OCS. A typical use case might be for me to use Communicator on a laptop to place a call to an internal user at my company, then use Communicator to conference in a third party on a cell or desk phone. I could probably do these things with other tools, but if you’ve ever tried to look up a number while in a phone call on your cell, then conference that person in, you’ll quickly see that the Communicator experience is worlds better than the button-mashing process required on most PBX phones. Of course, this improvement comes at a cost of additional deployment and implementation details.

The only problem with this approach is that the provisioning process for these new clients is still a big question mark. For example, Microsoft to date hasn’t released any information on best practices for deploying IP phones designed for Communicator. This isn’t surprising, given that the phones won’t start shipping in quantity until late 2007 from Polycom and LG-Nortel, but most organizations want to see detailed deployment information before they make any deployment commitments.

OCS and Exchange Integration
Microsoft has historically made a big deal out of the fact that its products integrate well together. Sometimes this is just marketing noise, but sometimes that integration really does make a big difference in how solutions can be designed and deployed. The integration between OCS and other products in Microsoft’s collaboration and communication lineup is a good example. You can deploy Exchange 2007 or OCS 2007 by itself, but in concert the products provide some extra capabilities:

• Exchange can send missed-call and voicemail notifications for calls originated by OCS, so that no matter where a call originates or terminates-OCS or PBX-you get consistent notification.
• Exchange can send a message-waiting indication for OCS clients, so that you get visual notification of available voicemail messages. This is a neat feature that typically requires third-party products.
• OCS automatically uses the out-of-office (OOF) message text you set in Exchange, so that you can set your OOF text once and have it reflected in both email and voice/ IM/presence.
• As soon as you install OCS, Windows Share- Point Services team sites and document libraries can display presence information about users in a library, and you can take actions (such as placing phone calls and initiating IM or conference sessions) directly from within SharePoint sessions.
• Microsoft Office Outlook 2007 and 2003 display presence information for contacts in your organization’s AD, as well as for selected external users, and you can make calls using OCS for any contact that has a phone number defined.

There are lots of other integration touch points: Microsoft has clearly learned from its previous efforts to integrate Exchange Server 2003 and Microsoft Office Live Communications Server 2005. Microsoft’s strategy in this area is to make UC capabilities broadly available through Microsoft’s client and desktop products, and to take full advantage of individual server products while doing so. From a deployment standpoint, you should bear in mind that it’s simpler to deploy Exchange 2007 first, then add OCS, rather than the other way around, because of the requirement to match UM dial plans and OCS location profiles. It’s possible to perform the schema updates required for OCS without installing the product; if you think you’ll eventually want to install OCS, you should consolidate the schema updates so that you only have one update and replication cycle.

Continued on Page 2

   Prev. page   [1] 2     next page