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
Register
