Microsoft Unified Communications - Network Considerations for Microsoft ODS Deployments Whitepaper

© Copyright 2009. Yankee Group Research, Inc. All rights reserved.

Network Considerations for Microsoft OCS Deployments

by Phil Hochmuth and Zeus Kerravala | November 2009

This custom publication has been sponsored by Microsoft.

Enterprises that are adopting unified communications (UC) platforms such as Microsoft Office Communication Server (OCS) must carefully

consider and plan how UC will affect their LAN and WAN infrastructures, as well as how their networks may either hinder or improve the

performance of a UC solution. Everything from bandwidth considerations, to firewall topology, to end-user habits and experiences must be

taken into consideration. If done correctly, enterprises can realize great productivity gains with new levels of collaboration, both internally and

with external parties. Reduction of WAN and LAN infrastructure, built to maximum capacity in support of past IP telephony or voice/data

convergence efforts, can also reduce costs and lessen management complexity in the long run.

This report examines four case studies of enterprises that have deployed Microsoft OCS Enterprise Voice and evaluates the cost-saving

opportunities, best practices and challenges around each organization’s deployment.

Executive Summary

Table of Contents

UC as a Strategic Collaboration/Communications Platform vs. PBX Replacement I. 2

Case Studies of OCS Deployments II. 2

OCS and Your Network: Recommendations and Best Practices III. 8

OCS Costs and Benefits: A Breakdown of Potential Savings 1IV. 1

Conclusions 1V. 2

OCS Enterprise Voice Deployment FAQs 1VI. 3

© Copyright 2009. Yankee Group Research, Inc. All rights reserved.2


UC as a Strategic Collaboration/I. Communications Platform vs. PBX Replacement

The adoption of enterprise IP telephony systems throughout

the 2000s led to wide-scale replacement of PBX systems with IP

PBXs and phones. During this transition, enterprise architectures

were modified to basically re-create circuit-switched TDM voice

infrastructures on top of IP networks. Enterprises saw cost

savings from IP/TDM network convergence and management

consolidation in return for large and often costly upgrades in LAN

and WAN infrastructure to support vendor requirements such

as QoS and traffic segmentation. Traditional IP telephony systems

do not provide deep integration of telephony with desktop and

line-of-business applications, do not incorporate the concepts of

identity and presence, and may have challenges providing a quality

experience on networks where the enterprise does not have end-

to-end control (i.e., the Internet). This latter limitation is becoming

increasingly important as enterprise workforces become more

dispersed and mobile.

Microsoft has taken a different approach, providing IP telephony

functionality as part of an integrated communications software

suite based on the concepts of identity and presence. Over the

past decade, the company has built upon its investments, from the

earlier days of Computer/Telephony Integration (CTI) to H.323

NetMeeting conferencing, messaging and video, and culminating in

its current OCS platform.

Microsoft OCS is a UC platform based on Microsoft Windows

server technology that incorporates enterprise telephony and

messaging along with presence management. The client technology

consists of Microsoft Office Communicator (for IM, voice, video and

presence) running on both PCs and dedicated telephony endpoints

from third-party partners. OCS uses a back-end server technology

based on industry standards, such as the Session Initiation Protocol

(SIP), as well as advanced media capabilities on endpoints using both

standard codecs and a codec developed and licensed by Microsoft.

This Yankee Group report examines the experiences of four

large organizations that have deployed Microsoft OCS, taking into

account their drivers for adopting the technology, their approach to

the deployment, and how they overcame obstacles and issues along

the way—particularly from a network-centric and voice-quality

troubleshooting point of view. The common thread—and the most

important trend—among these examples is that these enterprises

are deploying UC and OCS as more of an application, independent

of the network layer, as opposed to a service tied intrinsically to a

Layer 2/3 infrastructure or to proprietary, purpose-built endpoints.

The second half of this report breaks down best practices in

network-related aspects of OCS deployments, based on lessons

learned from the enterprises profiled in the case studies. At the

end, a TCO guide and FAQ section serve as handy references to

help enterprises and partners know what to expect when rolling

out this technology.

Case Studies of OCS DeploymentsII.

Many enterprise UC platforms begin as pure IP telephony solutions,

with features such as unified messaging (voice/e-mail), presence

and IM/chat added incrementally though the lifecycles of various

products. Microsoft OCS differs from other solutions in that it

had no previous IP telephony platform as its base. Components

of the OCS architecture came out of its predecessor, Live

Communications Server (LCS), a solution designed to deliver

all channels of UC in a single integrated package. Each UC tool

included was considered an equally important piece to the entire

solution, rather than just a feature added over time. While OCS

was initially criticized as lacking enterprise-grade telephony features

and resilience, the 2007 R2 release of the product introduced these

capabilities and positioned OCS as an option to replace incumbent

IP telephony solutions within an enterprise.

The following four case studies chronicle how companies across

various industries are deploying, or plan to deploy, OCS 2007 R2. In

each deployment example, the respective companies implemented

OCS alongside some existing traditional IP telephony deployment.

The case studies build toward a “net” conclusion, with regard to

best network architecture practices for deploying OCS Enterprise

Voice as identified by the deploying company.

Case Study 1: Manufacturing Company

A global manufacturing company with plans to deploy Microsoft OCS

2007 to tens of thousands of employees across the U.S. and worldwide

is currently in the early phases of its rollout. The firm has plants and

offices primarily in North America, but it also has a worldwide reach. It

connects most sites with an MPLS WAN backbone.

3© Copyright 2009. Yankee Group Research, Inc. All rights reserved.

November 2009

Business Driver Behind OCS

The manufacturer was one of the first large adopters of IP

telephony technology at the beginning of the decade, when it made

a mass transition from TDM telephony to Cisco’s then-branded

AVVID IP telephony architecture and later to Cisco CallManager

and Cisco Unified Communications Manager. It was ahead of the

curve with IP telephony in the early 2000s, and the company is

continuing this trend with UC as it enters the next decade.

Unlike the IP telephony migration, the switch to OCS is focused

on improving business processes, as opposed to just moving voice

traffic from one medium (TDM) to another (IP) or one vendor

(Cisco) to another (Microsoft). The manufacturer wants to bring

multiple communications channels under one common interface at

the endpoint (whether mobile or desk-bound) along with a single

back-end server and management infrastructure. The firm also

wants to put underutilized desktop processing resources toward

telephony, with the goal of reducing the company’s total telephony

endpoint/dial-tone footprint. For every employee, the company

currently supports approximately 2.5 “PSTN units” (i.e., desktop

phones, soft phones with assigned numbers, etc., that can reach the

PSTN). This was the result of years of slow migration from TDM

to IP telephony, which ultimately left the company with a complex

mixed environment that led to a sprawling, overprovisioned voice

environment. By consolidating telephony endpoints with OCS,

where voice services are tied to end-user identity and endpoint

PCs, the manufacturer plans to drive that number back down to one

PSTN unit per employee, with a correlated benefit on costs.

Methodology for Rollout

The manufacturing company’s OCS deployment is extensive,

although not complete. Each user in the 100,000-employee

company has Office Communicator on his or her desktop and

connects to a centralized OCS infrastructure for IM and presence.

About 300 employees have been using OCS Enterprise Voice for

about a year, and the company’s goal is to expand to 2,000 end-

users by the end of 2009. By the end of 2010, it expects to be at

12,000. The long-run goal is for the ratio of OCS users to Cisco IP

phone desktop users to be close to 50-50.

The company currently supports its companywide deployment

of OCS for IM, presence and conferencing in its three main data

centers, and it is in the process of adding voice services to these

data centers. OCS servers are in the same locations as its Exchange

infrastructure, which is centralized in two data centers; this is

different from its current Cisco CallManager infrastructure, which

requires dozens of server clusters in locations worldwide in order

to support the total end-user population.

The manufacturer’s OCS Enterprise Voice deployment is

fully interoperable with its pre-existing Cisco CallManager

infrastructure. Currently, Cisco ISR routers are used to connect

all OCS calls to the PSTN via a SIP trunk feature. No upgrade was

required on the Cisco side to support this because the SIP trunking

capabilities are based on a Session Border Controller (SBC) feature

native in the Cisco IOS routing software the company uses. The

interoperability is transparent to users because the dial plans did

not have to be changed.

Issues Experienced and the Approach to Solve Them

Overall, the manufacturing company has experienced no major

network-configuration issues that have affected the performance

or quality of OCS. The company attributes this both to the robust

network infrastructure and the independent underlying nature of

OCS itself, which largely operates independent of its underlying

transport technology and does not rely on network-based controls,

such as RSVP or network segmentation, to ensure quality.

What Worked Well

Because of the manufacturer’s existing Cisco deployment (which

it will retain for the next several years), it already has an extensive

QoS and VLAN structure for segmenting voice traffic and providing

priority queuing and express forwarding on its Cisco LAN and

WAN infrastructures. This will remain because the firm is working

to map its current QoS architecture to the OCS voice traffic.



“In my opinion, if [you] already have [QoS] installed,” says the

manufacturing company’s lead architect for enterprise voice and

UC, “you should be making OCS fit into your QoS architecture.”

To achieve this, the company is mapping the DiffServ priority tags

assigned to OCS voice traffic and mapping this traffic to existing

VLAN and QoS architectures—a relatively simple configuration

exercise. This strategy is the result of two factors: The

manufacturing company still has a very large deployment of Cisco IP

telephony, which requires separate VLANs and express forwarding

settings for LAN-based IP telephony; and VLAN separation and

QoS still offer troubleshooting and delivery guarantees over LAN

links that the company does not want to leave up to chance upon

the first rollout of OCS.

With more employees using PCs and mobile devices as primary

voice interfaces, the number of desktop phones will shrink over

time; as a result, the manufacturing firm will also be able to begin

gradual reduction of Power over Ethernet (PoE) switch ports

deployed in wiring closets throughout its enterprise. Currently,

every Cisco IP telephone connects to a PoE switch port, which

provides both power and network connectivity. Since PoE adds an

approximate 20-30 percent premium to the cost of a switch port,

reducing the need for PoE to desktops could save the company

millions in infrastructure costs in the long run.

“Net” Conclusions

Enterprises will want to leverage their already deployed extensive

IP telephony infrastructures. The QoS and native SIP functionality

within the OCS server stack was a key component to this

company’s migration strategy; the company was able to integrate

OCS users with its incumbent Cisco infrastructure without altering

dial plans or introducing other changes that would make the OCS

environment seem bolted on. This also allowed the manufacturer to

use its existing Cisco SIP-trunking gateway infrastructure instead of

purchasing new equipment.

Case Study 2: Europe-Based Consulting Firm

One Europe-based consulting firm is among the most aggressive

deployers of OCS Enterprise Voice of the four companies profiled.

With more than 6,500 employees across 20 offices, the firm is using

OCS to centralize disparate islands of telephony across its locations

and to provide advanced collaboration features to its employees and

partners via OCS federation.


For years, the consulting firm has envisioned a unified platform for all

channels of enterprise communications, from telephony, conferencing

and real-time chat to voice and e-mail. The company says it bought

into early iterations of IP telephony with an eye toward this ultimate

goal, but the reality of solutions offered over the last five to seven

years was that they were basic PBX replacements that transported

voice using IP networks instead of circuit-switched TDM networks.

In the interim between IP telephony and true UC, the consulting firm

had to fill in gaps, such as multimedia Web conferencing and instant

messaging, with outside services and tools, such as conference hosting

providers or consumer-based IM solutions pushed mainly by the

company’s own employees.


The consulting firm is on a rapid pace to roll out OCS throughout

its organization and plans to completely transition from its legacy

Nortel PBX platforms to Microsoft OCS Enterprise Voice by

the end of the year. Of the 6,500 employees in the organization,

approximately one third now use OCS for all communications. The

consulting firm’s CIO estimates that it will have all of its end-users

on OCS by the November/December 2009 time frame.

OCS Enterprise Voice still connects externally via Nortel PBXs,

which act as a gateway for OCS SIP traffic and the PSTN. The

firm plans to be off this hybrid architecture within the next three

to six months because it expects its regional telco to make pure

SIP-based trunking services available soon. The SIP trunking service

would tie the OCS Enterprise Voice infrastructure directly into the

carrier’s SIP-based VoIP network, eliminating the need for PSTN/

SIP gateways.

The firm is moving its 20 offices from Nortel telephony to full

Microsoft OCS support at a rate of one office about every two

weeks. Each office had its own IP PBX platform and connected to

the PSTN via a local trunk (although internal calls were routed

over the company’s WAN). As the offices move from Nortel

to Microsoft for voice, the main number and all internal direct

inward dialing (DID) numbers are rerouted through the company’s

headquarters, where its main data center for OCS is hosted. This

allows the firm to reduce receptionist staff at each of its offices and

reassign the workers to other support positions within the firm.


November 2009

The company is deploying Polycom USB-based handsets, which

connect to end-users’ laptops, to every desktop in the firm. The

Polycom phones are certified with Office Communicator clients

and OCS in general.


The consulting firm has experienced no real network-related issues

in its OCS deployment so far. Assigning dual 100 Mbps Ethernet

WAN pipes to each location gave the OCS deployment plenty of

bandwidth and low latency, which ensured quick call setups and

good voice quality.

One of the only issues end-users have complained about

during the rollout was the issue of resource contention on

desktop endpoints—particularly among users with older model

PC hardware and OSs. The firm’s CIO says that calls can be

interrupted when end-users copy large files to or from their PCs

over the network while having an OCS voice conversation. Even

though the firm will use USB-based handsets, which can boost

voice quality and offload voice processing from the PC to the

device’s digital signal processor (DSP), voice and data packets will

still contend for bandwidth at the endpoint level. The CIO says

the company plans to move to Windows 7-based workstations in

2010; this will entail upgrading processors and memory on many

older machines that were having the resource contention issue. He

anticipates the upgrade will improve performance for simultaneous

voice and data applications.

What Worked Well

Immediate results of the quick OCS rollout include a more

productive consultancy team, which is driving more customer

interactions—and more billable hours, according to the firm’s

CIO. Desktop sharing and click-to-dial integration for conferencing

and chat are used frequently by consultants giving presentations

to clients on-site. Instead of deferring to other colleagues for

questions beyond their own scope and making notes to follow up,

the consultants can now quickly conference their colleagues into

live presentations via the Office Communicator client. Presence

allows the consultants to see who is available, and connections

are made with a click of the mouse. “This capability lets us show

how we are different from an efficiency standpoint compared to

our competitors, which is crucial in this economic environment,”

says the firm’s CIO. The fact that the company was able to provide

all this without any complex or expensive network upgrades

is a testament to both the firm’s existing high-end network

infrastructure and the unobtrusiveness of the OCS platform.


While he realizes that not every enterprise can roll out a metro

Ethernet WAN to all of its sites, the consulting firm’s CIO says

that investing in a high-bandwidth network was one of the main

factors of success behind his firm’s OCS Enterprise Voice rollout.

A largely tech-savvy employee base and very large network pipes

allowed the firm to roll out OCS Enterprise Voice at a very rapid

clip—a pace the CIO says actually led to slow days in IT, given how

quickly he is able to turn over offices. “Sometimes we have [IT

staff] not doing anything for a few days at some offices, because the

change went so smoothly. It makes me think we should have been

more aggressive with our timetable.”

Case Study 3: Global Energy Company

The next enterprise operates in over 140 countries and currently

supports more than 15,000 users on Microsoft OCS Enterprise

Voice. The company also has an extensive TDM-based PBX system

from Nortel and other vendors, as well as IP telephony systems

from Nortel. The company is also upgrading its self-managed,

heterogeneous hub-and-spoke WAN architecture to a common

AT&T-hosted MPLS VPN network.


The energy company wanted to consolidate the management of its

voice infrastructure, which was spread across more than 270 PBXs

throughout the world. The company also sought a unified desktop

client experience for all communications channels—e-mail, voice

messaging, chat, telephony and video. The company is also keen

on extensive use of federation with OCS to allow for greater

connectivity with key external partners.




In initially deploying OCS 2007 over the WAN, the energy

company’s network team calculated the average number of users

and the average number of projected phone calls employees make

on a daily basis. It then calculated the bandwidth that would be

consumed on average per site. Based on that, the firm determined

the sites where it could enable Enterprise Voice and video services

in the short term, prior to network upgrade. The company also

factored in other bandwidth consumption and usage factors, such

as its global, centrally hosted deployment of SAP, which is accessed

by over 200 sites worldwide. During that phase, the company

hosted OCS 2007 from its data centers in Amsterdam, Houston

and Singapore to serve its worldwide client base.

No significant changes to the LAN were necessary to initially

accommodate OCS because the deployment was tailored to the

in-place network. Although sites have existing VLAN and QoS

architectures in switches to support Nortel-based IP telephony,

these will be abandoned when OCS becomes the predominant

voice application. On the WAN side, QoS will be used to prioritize

OCS voice traffic on the AT&T MPLS WAN.

Beyond this initial deployment, AT&T (acting as the energy

company’s outsourcer for network and telephony) is upgrading

the deployment from OCS 2007 to OCS 2007 R2 and rolling

out a global MPLS network to virtually every site. The goal is to

eventually enable OCS for Enterprise Voice and video at every site.

AT&T will deploy dual MPLS links to each site for link redundancy.

For smaller sites that do not warrant dual MPLS links, the company

will deploy local resiliency capabilities such as voice gateways,

which will allow the sites to make outbound PSTN calls in the

event of a primary MPLS link failure. Since AT&T will be managing

the OCS deployment on behalf of the company, the OCS server

infrastructure will be deployed at AT&T data centers in Europe, the

U.S. and Southeast Asia.


The IT architect at the energy company jokingly says the greatest

challenges are keeping up with end-user demands to deploy OCS

more widely to more sites and to enable new features such as

mobile device support.

As with the consulting firm, the only recurring issue the energy

company faces is with voice quality on older PC endpoints (i.e.,

Windows 2000 Professional, which is still widely used throughout

the organization). If employees use CPU-intensive applications on

these desktops or copy large files to or from their PCs while on an

audio conferencing call, this leads to interference in voice quality,

which can make calls sound choppy. Also similar to the consulting

firm, the energy company anticipates these issues will lessen as

it upgrades its end-users to Windows 7 in the near future. Also,

general user awareness about running multiple applications or

downloading/uploading large amounts of data will also increase as

the deployment matures.

What Worked Well

Overall, according to the energy company’s IT architect, voice

quality is an improvement over any previous IP telephony or

TDM voice solution due to the wideband (16 kHz) audio used

on peer-to-peer voice connections over the LAN. While some

initial users complained about voice quality at some sites where

underprovisioned WAN links were used, the advanced media

capabilities built into OCS endpoints have done well in adjusting for

resource contention on the WAN.


Upgrades to the WAN (to MPLS), as well as usage analysis and

right-sizing of branch office links, were among the most critical

aspects of the energy company’s project and have led to the success

of this rollout so far. At this point, process and implementation

timing challenges were the only drawbacks in the company’s rollout;

as for the technology, it has worked as advertised and has required

minimal network reconfiguration or workarounds. Looking back,

says the IT architect, the company probably would not have rolled

out its OCS deployment in parallel with moving to AT&T for hosting

and an MPLS network overhaul. Performing major simultaneous

changes to the network introduced complexity and delays that

could have been avoided had the project been taken on piecemeal.


November 2009

Case Study 4: European Telecommunications Company

A regional telecommunications company operating in Europe has

plans to deploy OCS Enterprise Voice across 120 office locations.

The company uses almost all Cisco IP telephony today, as well as

circuit-switched and packet-based telephony systems from Siemens,

Nortel and Alcatel in a few offices. Most non-Cisco sites have TDM-

based equipment.


The company wanted to leverage its ubiquitous Windows desktop

environment to include voice, messaging and presence applications

under one umbrella. What really pushed the idea of OCS as the

main voice platform was the 2008 acquisition of a smaller Web

conferencing service provider. The acquired company had used OCS

more aggressively, with a full deployment of OCS Enterprise Voice

to its 300 users. The company had started with Microsoft LCS and

stuck with the technology as it evolved into OCS. While it is not

yet deployed to all employees’ desktops, Office Communicator is

used by a majority of workers on their mobile devices, including

Windows Mobile and RIM BlackBerry.


The carrier’s own deployment of OCS IM and presence started in

late 2007 with 50 users and quickly expanded to 600 users by mid-

2008. It now has 17,000 employees accessing the system for IM and

presence. The carrier also uses federation with its partners via OCS.

Two redundant data centers host the OCS server infrastructure

inside the carrier. Multi-gigabit WAN connections link all three

of these data centers. External PSTN connections are all routed

through a Nortel Communication Server (CS) 2100—an IP PBX

still used to support a large portion of employees with Nortel IP

phones. The CS 2100 resides in one of the two data centers.

The carrier did little network engineering to augment the

performance of OCS voice. It relies on the OCS codecs and

endpoint software to provide voice quality, as opposed to

implementing separate VLANs or QoS prioritization on the WAN

or LAN. While the company did have a QoS/VLAN infrastructure

in place for its existing IP telephony deployment, OCS will not

be mapped to this scheme. This is because the company plans

to quickly move off its existing IP telephony platform to OCS

Enterprise Voice, unlike the manufacturing company profiled in Case

Study 1, which must support parallel Cisco/Microsoft OCS voice

infrastructures into the foreseeable future. (The manufacturing

company’s engineering team says the configuration effort will be

worth the benefit of being able to segment OCS traffic in VLANs or

apply Layer 2 QoS controls to the traffic.)


The major network reconfiguration the carrier faced was related to

its extensive internal network of Check Point firewalls—a complex

infrastructure with multiple zones and VPN segments. This had to

be re-engineered when OCS was deployed. Firewalls prevented

the any-to-any connection environment necessary for OCS, which

meant some employees could initiate chat or voice sessions, but

others could not call or message back due to zone restrictions. This

was alleviated by configuring the Check Point firewalls with rules

that permitted bi-directional signaling and codec traversal for OCS

traffic. Also, the Microsoft OCS Mediation Server—a critical piece

of infrastructure to the deployment—was hosted in a data center

that could not be accessed by all users. The Mediation Server was

moved to another data center that permitted wider access.

What Worked Well

The software stack and corrective codecs for voice allowed

the carrier to deploy OCS Enterprise Voice without any major

configuration changes to its LAN or WAN environments. The

customer decided that voice quality could be adequately assured

via endpoint software and close monitoring of voice streams via the

Quality of Experience (QoE) Monitoring Server—a platform for

ongoing voice traffic and call quality monitoring and reporting that is

part of the OCS Enterprise Voice suite. This allowed the company to

provision voice as just another application or feature of its merged

OCS infrastructure, rather than having to treat the voice rollout as a

separate, laborious process of network testing and fine-tuning.


Since bandwidth was not a great concern—considering that the

carrier could provide as much as it needed from its own network—

the carrier was able to rapidly migrate and build out its OCS

environment, moving relatively quickly from small OCS deployment

to integration with the larger organization, which had previously

used LCS. The end-user interface made migration simple from

an end-user-adoption standpoint: Workers just kept using Office

Communicator on endpoints.



OCS and Your Network: III. Recommendations and Best Practices

The previous case studies highlight the drivers behind each

company’s OCS deployment, the issues and challenges they

faced and examples of how network configurations and existing

environments can affect an OCS rollout. Next, we examine some

specific issues around network planning and deployment using

best practices drawn from the experiences of the four profiled

companies and the OCS user community at large.

Complete a Pre-Deployment Network Assessment

Each enterprise profiled assessed the capabilities of its network prior

to rolling out OCS Enterprise Voice. A critical first step in assessing

the network is to determine bandwidth availability and average

call usage per site. Provisioning voice and determining bandwidth

needs for a small-scale pilot deployment—perhaps to a group of

IT professionals testing the system, or to a select group of power

users—can be done by looking at call detail records from an existing

PBX or IP telephony system to gauge usage patterns. If an entire

branch office or department is being moved into production with

OCS, however, pre-determining how the network will handle this

new type of traffic and call volume on a more detailed level is critical.

In the case of the global energy company, call capacity and

bandwidth planning were part of the deployment process. The

energy company calculated the number of users at its various

remote sites and factored in the average monthly volume of calls

made from these locations. The company’s IT group also assessed

overall interest in video among the locations and factored this

into the estimates. The company then looked at the total available

bandwidth for each site to determine if it would be ready as-is for

an OCS Enterprise Voice deployment, or if more lines or larger

pipes needed to be provisioned.

Analyze Topology Schemes

Each enterprise interviewed for this report uses a centralized

deployment model for its OCS Enterprise Voice setup. This is one

of the main drivers for OCS in general—centralization of voice

call processing instead of dispersed islands of PBXs at remote

sites, or up to a dozen quasi-centralized IP PBXs, as in the case

of the manufacturing company with its multiple Cisco Unified

Communications Manager clusters.

Each user we spoke with used a centralized deployment model for

hosting OCS servers for the entire enterprise; in most cases, OCS

was deployed alongside the company’s existing Microsoft Exchange

messaging infrastructure. If enterprises had already deployed OCS for

presence, IM and conferencing, they deployed OCS Enterprise Voice

services within this infrastructure instead of deploying additional

servers in more locations in order to support enterprise telephony.

In the case of the manufacturing company, the firm is hosting OCS

from three data center sites in North America. This gives the

company localized geographical coverage for sites near each data

center and provides redundant OCS resources in case of a server

or site outage. This is the current approach used by all customers

interviewed in this paper: to have an entire off-line failover site

waiting to assume the burden of all voice traffic in the event of a

primary site failure. Although real-time failover features, where OCS

sessions would be seamlessly handed off from a failing site to a live

site, are not yet supported, the manufacturing company says it has

enough faith in Microsoft’s OCS road map to deploy only three sites

in anticipation of this feature in future revisions of the platform.

In addition to centralizing data center resources for enterprise

telephony, enterprises can use an OCS deployment as an

opportunity to right-size and optimize their WAN deployments

for branch offices. As was the case with the energy company and

European carrier, local gateways can still be used to provide backup

dial tone.

At the time of our interviews, the enterprises’ deployments of

OCS Edge Services were in various stages. The manufacturer

used Edge Services to federate its OCS resources with key

partners and customers; separate remote access or authentication

infrastructures were not needed in order to share presence,

conferencing and IM with outside partners.

Full Edge Services deployments are on the road map for each of

these companies. This will allow the organizations to further migrate

away from legacy IP telephony and remote access infrastructure,

such as IPSec VPN tunneling, to access OCS resources, which is a

method still widely used (e.g., the manufacturing company). Edge

Services will allow mobile and external users to access OCS without

VPN tunneling; also, internal users will be able to access external

OCS users directly from the OCS Edge Services infrastructure at

the network demarcation point.


November 2009

If You Have QoS, Use It

Each enterprise used QoS mechanisms, mainly DiffServ, to prioritize

voice media packets traversing WAN links. However, they used

little traffic shaping or prioritization on LAN connections for

Microsoft OCS Enterprise Voice. If practical to the customer,

Microsoft generally prescribes wiping VLAN segmenting and 802.1p

prioritization from a LAN architecture overall, with the idea that

right-sizing the network for bandwidth and latency has greater impact

on quality for less cost. Further, Microsoft’s RTAudio codecs and

features such as Forward Error Correction (FEC) can compensate

for less-than-optimal network conditions or constraints.

Of course, QoS and other flow management techniques can still

be considered. Enterprises can keep in place their predefined QoS

schemes from previously deployed IP telephony products, such as

Cisco Unified Communications Manager or Nortel Communications

Server 1000. This was the case with the global manufacturer, which

had a complete network-based QoS architecture already built on

both the LAN and WAN to segment and prioritize IP voice signaling

and payload traffic. The company plans to map OCS Enterprise

Voice traffic into the same 802.1p traffic prioritization and 802.1Q

VLAN tagging scheme it currently has.

In the case of the energy company, a QoS architecture is already

in place for the worldwide deployment of SAP, which the company

hosts from central data center locations in Europe, North America

and Asia. As it transitions these data centers to AT&T and moves

to the carrier’s global MPLS IP VPN, it will continue with its current

prioritization of SAP over the WAN (using DiffServ controls

mapped to MPLS switch labels) and will incorporate OCS voice

traffic into this scheme as well. The energy company considers SAP

and OCS to be the two highest-priority traffic types for operating

its business and will prioritize both flows over all others.

Become Familiar With Ongoing Management and Monitoring Tools

Another common denominator among the enterprises interviewed

is extensive use of the QoE server as the centerpiece of their

ongoing voice quality management and monitoring strategy. In past

IP telephony deployments, users typically had to rely on third-party

tools for supporting management and quality assurance of real-time

communications traffic on an enterprise network. These tools were

based in one of two camps: network-related products for measuring

packet loss and jitter of IP traffic streams, and voice quality analysis

tools (from vendors such as Qovai, NetQoS and Clarus Systems)

that delivered automatically generated mean opinion score (MOS)

analysis of voice call quality by sampling traffic streams.

The issue with such approaches was that they separated two

types of metrics: one on the performance of packet delivery of

an IP network; the other on the sound quality of packetized voice

delivered over an IP network. It was up to network engineers to put

these two areas of management together in order to troubleshoot

and fine-tune enterprise IP telephony deployments. The fact that

vendors of IP telephony gear did not supply such tools with their

systems also muddled the issue and forced end-users to do extra

work to find measurement and management tools that were

certified with their respective IP telephony platforms—or pay high-

priced, specialized consultants to do this.

Microsoft’s QoE server takes into account multiple factors that can

affect voice quality and system performance as perceived by end-users.

To start with, it goes beyond simple, passive network taps or probes;

the server has the ability to gather statistics on the overall quality of

an individual’s connection or group’s connections, taking into account

both the performance of voice traffic on the wire and the experience

of the end-user at the endpoint. Active monitoring, trend analysis and

end-user complaint mediation features are also included.

Some of these enterprises looking for a cross-platform view used

a secondary tool for the measurement and monitoring of voice

quality and overall network performance in conjunction with the

Microsoft QoE server. It’s no surprise that the carrier Yankee

Group interviewed, for whom running and optimizing networks is a

core business, is the biggest proponent of this approach.

The European regional carrier uses traffic measurement tools from

Ipanema Technologies to analyze multiple types of RTP traffic and a

variety of codecs traversing the carrier’s network. Along with this

method, the carrier uses Microsoft QoE server to specifically measure

OCS traffic as well. This combined approach gives the provider a large-

picture view of how OCS fits into the network as a whole, with the

QoE server used for OCS-specific management and monitoring.

Overall, use of a secondary tool is recommended for enterprises,

as opposed to solely relying on the QoE server for voice

troubleshooting and monitoring. Tools to consider are those

that can analyze OCS Enterprise Voice traffic; certified partners

providing such tools include NetQoS and Psytechnics. Such tools

can provide a good secondary analysis outside the QoE metrics

used by the Microsoft platform.



Consider Network Services Provisioning and Carrier-Provided SLAs

Many enterprises that are centralizing voice delivery for the first

time with OCS are also crafting service level agreements (SLAs)

with carriers around IP voice. In the case of the global energy

company, for example, this is the first time global voice delivery

could be included in an SLA with a carrier, since the company’s voice

infrastructure in the past was made up of over 270 PBXs connected

to the PSTN by various providers.

The energy company, which has run a centralized, global

deployment of SAP for several years, has had various SLAs with

its data carriers for delivering that traffic to branch offices. Now

that both voice and applications traffic will be delivered over a

single pipe (the AT&T MPLS network) and from a single source

(AT&T’s regional hosted data centers), the company is working

with the carrier to craft SLAs that will take into account whether

OCS voice traffic is delivered at a rate below the acceptable level

of the SLA. This is where the QoE server comes into play directly

as a potential revenue-saving opportunity. The QoE server can be

used to flag voice traffic that falls below a certain quality threshold

from both a network and endpoint perspective. The company is

working with AT&T to extract some of the network-related metrics

and parameters measured by the QoE server to use those as a

foundation for the SLAs.

Prepare Security Validation and Firewall Topology, Configuration Adjustments

Some enterprises faced security challenges related to firewall

topology and architecture during their OCS deployments. Firewalls

and IP telephony have a history of not playing well together. In early

VoIP deployments, network engineers had difficulty getting firewalls

and technology schemes such as network address translation

(NAT) to work well together. To this point, many enterprises have

avoided this issue by using VPN tunneling to connect VoIP clients

or resources on opposite sides of a firewall. The issue is also being

addressed by the development of standards that will allow for more

seamless inter-network VoIP connectivity; among these efforts is

the Interactive Connectivity Establishment (ICE) protocol, used in

OCS, for firewall and NAT traversal of SIP-based VoIP traffic.

Security and network considerations are not only focused on

enterprise boundaries, but on internal network segments as well.

As shown in the case of the regional European carrier, a firm that

operates an extensive internal firewall infrastructure can run into

trouble when deploying OCS if it does not account for how voice

traffic will traverse various security zones across an organization.

It is essential to place critical OCS infrastructure components on

segments of the network that are accessible to all employees.

In general, firewalls, traffic inspection gateways and other in-line or

out-of-band security appliances that will be traversed by OCS traffic

should only enforce policy at the routing layer. Firewalls should be

configured to recognize and allow pass-through of traffic across key

external and internal user ports, such as Ports 5061, 5062 and 443

for OCS Access and Audio/Video Edge Servers and Ports 443 and

8057 for Web Conferencing Edge Servers.

OCS’s end-to-end security model includes secure real-time

protocol (SRTP), which secures the audio stream of OCS Enterprise

Voice communications using a 128-bit AES encryption standard

to prevent against conversation interception or other tampering

with the RTP stream. Also, transport layer security (TLS) protocol

is used to secure SIP-based signaling, which prevents protocol-

based spoofing attacks at the signaling protocol layer. With these

safeguards in place at the OCS Enterprise VoIP application layer,

enterprises deploying OCS Enterprise Voice should adopt a more

open, any-to-any topology model for connectivity—at least in

terms of the pieces of their OCS infrastructures. Enterprises with

past experience in IP telephony and security best practices will also

have to rethink previous methods of cloistering segments of the

network exclusively for voice, or extensive use of access control

lists for blocking access to IP PBXs, or limiting what types of traffic

endpoints can receive and send.

Another general rule of thumb followed by all enterprises

interviewed for this report is the inclusion of their respective

security teams in the planning and testing of OCS infrastructure.

Federation and the prospect of opening up internal directories

to external partners was a serious undertaking from a security

standpoint in each case study. The enterprises all required sign-off

from their respective IT security teams to complete this, as well

as an audit of what types of communications and resource sharing

would be allowed among federated partners.


November 2009

OCS Costs and Benefits: A Breakdown IV. of Potential Savings

Enterprises are moving to Microsoft OCS Enterprise Voice to

improve end-user productivity, add powerful collaboration tools

such as video and presence, and make business-to-business

communications more open. This does not mean these enterprises

aren’t interested in finding ways to cut existing infrastructure costs

with OCS as well. This section analyzes some areas for cost savings,

based on some of the experiences of the four organizations profiled.

Network Right-Sizing

Organizations such as the global energy company are realizing

increased savings and management cost efficiencies by re-evaluating

the bandwidth requirements for all branch office voice connections

and redeploying WAN links accordingly. Previously, the energy

company managed a complex tangle of varying point-to-point

MPLS and VPN circuits across its multiple locations. Obviously

this infrastructure was deployed prior to the OCS rollout, so the

bandwidth provided did not take into account the actual calling

patterns and voice bandwidth utilization of these sites; as a result,

many sites were overprovisioned in terms of WAN bandwidth

requirements for voice, while links at other sites were unnecessarily

squeezed. Above most other cost-saving factors, the exercise of

evaluating how much network bandwidth will be required for OCS

Enterprise Voice and readjusting the infrastructure accordingly is

among the most powerful cost-saving aspects of an OCS rollout.

Back-End Equipment

Server consolidation and equipment reduction will be a very large

cost-reducing factor among many of the enterprises interviewed.

In the energy company’s case, it will decommission more than 200

PBXs and other IP telephony gear at its remote sites throughout the

duration of the rollout, as sites come online with OCS voice. Taking

into consideration the cost of ongoing maintenance, lease of some

equipment and other factors, this move will, over time, equate to a

savings in the tens of millions of dollars annually.

The consolidation of call control, as well as external telephony

connections, will also help reduce the number of PSTN gateway

interfaces the company currently uses. Prior to OCS, even Nortel-

based VoIP sites that included multiple offices connecting to an IP

PBX still required an external PSTN gateway link for outbound and

incoming calls. Putting the OCS servers into the AT&T data center,

where OCS can connect directly to AT&T’s SIP trunking service,

will also consolidate this entire infrastructure of hundreds of

gateways down to essentially three in AT&T’s data centers in Asia,

North America and Europe.

Endpoints

Another powerful cost-saving force in the realm of equipment

reduction is the use of PCs as IP telephony endpoints, which allows

for reduction of IP phones on desktops. This was cited as a driver

for the four organizations we talked to for this report. In the case of

the manufacturing company, the goal is to get the number of phones

per employee down from a range of about 2.5-to-1 to around 1-to-

1—that is, each employee’s desktop PC would become his or her

telephony endpoint as well. The manufacturing company estimated

that its total IP phone reduction could be in the tens of thousands

of handsets.

While most of the cost of the phones has already been depreciated,

the move to a phoneless desktop will save the manufacturing

company millions of dollars on desktop phone replacement costs

in the long run. Considering the list price of a new Cisco IP phone

starts at $250 for a basic-feature handset, the manufacturing

company would be saving as much as $10 million for an enterprise-

wide upgrade, which would include between 80,000 and 100,000

employees. There is also a potential for cost savings on the

network side, as fewer phones will require fewer PoE ports, which

could result in lower future LAN switch acquisition costs. Energy

consumption will also be reduced, since the company will no longer

be required to inject power as broadly over its structured cabling

plant. Additionally, the company would be able to provision remote

workers, teleworkers and even external contractors or partners

with OCS Enterprise Voice-based telephony without having to

deploy expensive VPN, remote access and hardware telephony

endpoints to these constituents.



Advanced Application Services

Conferencing is one of the most dominant cost-saving drivers

named by the enterprises as part of the OCS feature set. In the

case of the Europe-based consulting firm, the company’s 6,000

employees had frequently used external conferencing services

for both internal and external meetings. The use of various

conferencing provider services left employees working on platforms

with inconsistent interfaces, while requiring users to track call-in

numbers and manage various downloadable plug-ins to support an

array of meeting platforms shared with external partners and with

members of their own organization. In addition, employees were

being charged for these various services, which made funding and

accounting of costs difficult across the various business units using

the services.

Centralized conferencing covers all channels used by the company:

Web, voice and video with integrated chat and desktop sharing. The

central platform also provides a common interface familiarity across

the organization, as well as easier conferencing setup tools; any type

of conference can be easily initiated from a voice, chat, e-mail or

video communications session.

Also, federation allows the company to easily set up conferences—

including Web, video and voice—with other federated partners,

customers and external parties. This allows the company to

continue to keep its travel costs down while lowering its costs

further by using the internally hosted OCS platform instead of an

outside provider. Additionally, the wideband audio of the OCS

conferencing platform provides a superior quality to previous

solutions, making such meetings more resonant and productive.

Among enterprises in general, Web and video conferencing is also

seen as the greatest cost-saving component among all the areas of

UC. According to Yankee Group's Anywhere Enterprise: Large—

2009 Transforming Infrastructure and Transforming Applications

Survey, Wave 1-4, this is regarded as the No. 1 cost-reducing factor

of a UC deployment among enterprises that have deployed or are

considering UC.

ConclusionsV.

Each featured enterprise’s deployment of OCS Enterprise Voice

uses a different approach from past efforts around network voice/

data convergence or IP telephony. Users of the platform see OCS as

a strategic step forward and as a business-enabling communications

tool, as opposed to a tactical implementation of a technology to

save money or consolidate resources. The underlying theme among

all the enterprises is the decoupling of enterprise voice services

from the network infrastructure; the long-promised goal of “voice

as just another application” is starting to become realized in many of

these organizations. If done correctly, great organizational TCO and

end-user productivity gains are possible.

To that end, however, enterprises are still faced with getting

OCS Enterprise Voice to work on their networks. While

OCS Enterprise Voice offers many advanced features that can

compensate for network congestion and low bandwidth, such as

software and codecs that provide error correction and audio quality

improvement, careful consideration must still be given to how OCS

Enterprise Voice is deployed throughout an enterprise. Deployment

plans must still tackle several issues in order for implementation

to succeed, including network topology, integration with legacy

telephony systems, endpoint device scenarios and bandwidth

considerations—especially for branch and remote offices. Based on

the experiences of the OCS Enterprise Voice deployers detailed in

this report, the following conclusions can be drawn:

Network considerations should be included in a deployment plan

OCS Enterprise Voice introduces new bandwidth management,

voice quality assurance and other technologies that allow the

service to boldly go where enterprises have feared to send IP

telephony in the past—in particular, on high-latency and/or

bandwidth-constrained connections for remote or mobile users.

This capability opens up new possibilities in terms of use cases

and deployment scenarios, such as right-sizing WAN connections

and reducing VoIP-specific network constructs, such as VLAN/

QoS architectures and PoE switch infrastructures. Nevertheless,

simply throwing OCS Enterprise Voice onto an existing network

is not recommended unless bandwidth and latency are already

well provisioned in the network. Careful consideration must be

given to network topology (such as internal and external firewall

and security zone boundaries), deployment of services relative to

geographical location of remote users and branch offices, and where

QoS and traffic prioritization schemes might be applicable, such as

over low-bandwidth or long-distance WAN connections. The good

news is that the major Herculean tasks facing IP telephony projects

of the past—complete LAN/WAN redesigns and upgrades, or

introduction of new QoS protocol schemes such as RSVP—are no

longer part of the equation.


November 2009

Consolidation is key:• All of the enterprises interviewed for

this report used their OCS Enterprise Voice deployments as

an opportunity to consolidate voice communications into a

centralized service delivered from a small number of locations.

Distributed call control servers, gateways or other VoIP-enabling

CPE can be minimized, reducing equipment costs, management

complexity and overall TCO. To that end, those who have

deployed the technology should regard OCS Enterprise Voice

as a service similar to e-mail, corporate IM or other centralized

applications and services. Replicating this central infrastructure

over a small handful of data centers—anywhere from two to

four—is also the consensus approach taken by the enterprise

deployments highlighted in this report. By doing this, deployers

ensure that all OCS services will remain available in the event

of a network or data center failure. At the same time, they are

also anticipating future advancements that will allow for live-site

redirection and global live failover scenarios in future iterations

of OCS Enterprise Voice.

Measure, monitor, adjust, repeat:• Each enterprise in

this report found real value with the QoE server as a tool for

measuring all aspects of end-user voice quality experience—from

network performance in terms of packet delay, latency and

congestion, to perceived audio quality on endpoints. Unlike tools

used to measure performance and quality of IP telephony in pre-

deployment or ongoing integration scenarios, the QoE server is

designed to be an ongoing tool used frequently in tight conjunction

with OCS Enterprise Voice for maintenance and monitoring.

Enterprises going into an OCS deployment should regard this

platform as a future everyday OpenView- or Unicenter-like

systems management tool, not as a specialized piece of network

troubleshooting equipment brought out only during deployment

tests or to fix specific problems on the network.

Build upon existing engineering:• Like any major technology

displacement, the introduction of OCS Enterprise Voice will

require some parallel coexistence of previous enterprise voice

systems. At the very least, enterprises will initially have to

tie OCS Enterprise Voice servers to existing IP PBX or VoIP

gateway infrastructure in order to allow OCS clients to make

external calls over the PSTN. This is where the flexibility of OCS

can be used to adapt to existing polices without cumbersome

changes. Existing QoS schemes, set up for legacy IP telephony

systems, can remain in place to support workers as they

transition from old platforms to OCS Enterprise Voice. For

organizations looking at long-term mixed environments of IP

telephony and OCS Enterprise Voice, OCS traffic can be mapped

to existing traffic-shaping and network segmentation schemes

for VoIP, provided that such setups do not interfere with OCS

features and functions.

Endpoint endgame:• Enterprises should also consider

how—or if—they will transition employees who use IP

desktop handsets to PC-based Office Communicator clients

with headsets. Doing so can lead to a quick cost reduction and

simplification of network architecture: The former is achieved

by decommissioning expensive IP handsets on desks; the latter

is realized by decreasing the need for LAN switch-based PoE

to power phones at every desktop. Another consideration

is end-user acceptance. Workers used to lifting a receiver to

make a phone call may find the transition hard to make; options

to help with this include USB-attached handset devices that

are compatible with Office Communicator software. If some

employees are heavy mobile phone users, such workers could

be encouraged to use their mobile devices as primary voice

endpoints while at their desks or out of the office.

OCS Enterprise Voice Deployment FAQsVI.

The following is a list of common issues or concerns, presented in

question form, that the four case-study organizations faced around

their respective deployments of OCS Enterprise Voice, specifically

regarding network issues.



What common network-related trouble spots might I expect to see upon deployment?

Among the four enterprises examined in this paper, one major

network-related trouble spot highlighted was the deployment

of OCS Enterprise Voice across an infrastructure that is heavily

segmented via firewalls and other access control gateways. For

security and compliance purposes, many organizations use these

tactics to create secure zones for segmenting various departments,

or for keeping public and private LANs and extranet zones

segmented from each other. When deploying OCS Enterprise Voice,

however, enterprises must consider how OCS traffic will traverse

security zones. Also important to consider is the deployment

of OCS servers throughout the enterprise, taking into account

whether or not all users will be able to access the servers, given

their security zone. The “any-to-any” collaborative nature of OCS

can run into a brick (or fire) wall very quickly if these issues are not

worked out before wide-scale rollout.

How does OCS support QoS?

OCS supports the DiffServ model for QoS, and this is the

recommended approach if enterprises determine that a low-

bandwidth or a highly congested WAN connection used to provide

OCS Enterprise Voice services could be improved with traffic

engineering. In general, enterprises deploying OCS Enterprise Voice

view QoS as a best practice for WAN connections; on LAN links,

QoS is less critical. While some enterprises deployed previous 802.1p

packet prioritizing schemes on their LANs for legacy IP telephony

systems, generally, enterprises are finding that such controls are not

necessary for peer-to-peer LAN connections with OCS.

What are the available disaster recovery networking plans for OCS today, and what is on the road map?

Currently, OCS provides client redirection failover capabilities,

allowing clients to connect and re-register with secondary OCS

servers in the event that primary servers become unavailable due to

hardware, software or network failures. This type of failover does

not allow for seamless continuation of communications. Calls and

conferences with external parties are dropped in such a scenario.

However, the OCS road map includes capabilities that would allow

for seamless, live-call failover of voice traffic, as well as active/active

backup scenarios, where multiple instances of OCS Enterprise

Voice can serve various groups of end-users, with each set covering

for the other if one group of servers becomes unavailable. Most

enterprises deploying OCS Enterprise Voice today are building their

network and data centers toward this future model in anticipation

of the OCS road map.

What are the bandwidth requirements of OCS codecs?

A peer-to-peer enterprise OCS voice call, using the Wideband

RTAudio (16 kHz) codec, consumes 35 Kbps of bandwidth per

user. When video is added to an internal peer-to-peer call, another

260 Kbps of bandwidth is consumed. A server-hosted RTAudio

narrowband (8 kHz) connection, which connects end-users to the

PSTN, consumes 30 Kbps of bandwidth. For conferencing, OCS

uses the Polycom Siren protocol, which consumes 22 Kbps of

bandwidth per participant endpoint, and an additional 260 Kbps

of bandwidth when video is added. PSOM, the Web conferencing

and collaboration protocol used in OCS, consumes 10 Kbps.

For an example of a real-use scenario, putting together multiple

protocols, a remote conferencing session with video, conferencing

and collaboration would consume approximately 292 Kbps of

bandwidth. Here is an area where enterprises must take care in

capacity planning and bandwidth allocation for their deployments,

since sites that use older, lower bandwidth links, such as fractional

T-1 or ISDN, could become saturated quickly if multiple audio and

video conferencing features are spun up quickly.

How is the QoE Monitoring Server used in my network?

Microsoft’s QoE Monitoring Server is a centralized repository for

statistics about the performance of OCS voice and video traffic on

the network. OCS servers and endpoint clients generate data on

the performance of their call sessions, and this data is collected

by a centralized QoE Monitoring Server. The server takes into

account multiple factors that can affect voice quality and system

performance as perceived by end-users. This includes multiple types

of mean opinion score (MOS) metrics, such as voice quality being

sent and received by endpoints, and network-wide voice quality

reflected in MOS data. Basic network performance metrics, such

as delay, jitter, packet loss and traffic degradation, are also factored

into QoE Monitoring Server reporting.

© Copyright 2009. Yankee Group Research, Inc. Yankee Group published this content for the sole use of Yankee Group subscribers. It may not be duplicated, reproduced or

retransmitted in whole or in part without the express permission of Yankee Group, One Liberty Square, 7th Floor, Boston, MA 02109. All rights reserved.

All opinions and estimates herein constitute our judgment as of this date and are subject to change without notice.

Yankee Group Link

Yankee Group Link membership brings clients the insight, analysis and tools to navigate the global connectivity revolution. It provides timely, actionable and

accessible research and data that analyze the impact of connectivity and the transformation it will create in driving enterprises and consumers to an Anywhere

society. The result is an experience that no other market research firm can provide.

Link ResearchYankee Group’s qualitative research forms the core of our offerings, with analysis focused exclusively on the transformational effects of the connectivity revolution.

Our research reports arm you with the insight and analysis to make the right decisions today and tomorrow.

Link Data

Yankee Group’s quantitative data analysis includes monitors, surveys and forecasts. Together with Link Research, our data connects you to the information you

need to make the most informed strategic and tactical business decisions.

Link InteractionConnect one-on-one with Yankee Group analysts to get answers to your most strategic and critical questions, as well as gain deeper insight into research and

trends. We encourage you to have direction interaction with analysts through ongoing conversations, conference calls and briefings.

Link Consulting

Who better than Yankee Group to help you define key global connectivity strategies, scope major technology initiatives and determine your organization’s readiness to

undertake them, differentiate yourself competitively or guide initiatives around connectivity change? Our analysts apply Yankee Group research, methodologies,

critical thinking and data to produce expert, timely, actionable results.

Link Events

The Anywhere revolution won’t wait. Join our live debates to discuss the impact that ubiquitous connectivity will have on your future. Yankee Group’s events—

live and online—offer our clients new insight, knowledge and expertise to better understand and overcome the obstacles to succeed in this Anywhere revolution.

Yankee Group—the global connectivity expertsThe people of Yankee Group are the global connectivity experts—the leading source of insight and counsel trusted by builders, operators and users of connectivity solutions for nearly 40 years. We are uniquely focused on the evolution of Anywhere, and chart the pace of technology change and its effect on networks, consumers and enterprises. For more information, visit http://www.yankeegroup.com/.

European Headquarters56 Russell Square LONDON WC1B 4HP UNITED KINGDOM 44-20-7307-1050 phone 44-20-7323-3747 fax

Yankee Group has a global presence including operations in North America, Europe, the Middle East, Africa, Latin America and Asia–Pacific. Contact us at:

Corporate HeadquartersOne Liberty Square 7th Floor BOSTON, MASSACHUSETTS 02109 617-598-7200 phone 617-598-7400 fax

Microsoft Unified Communications - Network Considerations for Microsoft ODS Deployments Whitepaper

Technology

Transcript of Microsoft Unified Communications - Network Considerations for Microsoft ODS Deployments Whitepaper