Recently I built a new OCS 2007 R2 Enterprise Edition pool for a customer, consisting of 4 Front End servers deployed behind a F5 BIG-IP hardware load balancer to provide IM and Presence and Web Conferencing to a few thousand users. You’d think “no worries right, follow the Deployment Wizard, she’ll be apples”.

Not quite in this case. From this, I learnt a lot more about what it takes to get things off the ground in a large, highly regulated and distributed Active Directory and LCS/OCS environment.

So the objective of this post is to share a few tips with you to help mitigate delays in your deployments in the future.

Back End SQL Database

Make sure you have necessary permissions on the SQL Server (cluster) for the account you are using to create databases in the instance you’re going to use. Note that a SQL Server instance that currently hosts LCS databases cannot be used to deploy the databases for OCS 2007 R2.

Also check with your DBA to see if any minimum database size requirements are in place as part of an existing new database template.

Forest Level Universal Group Memberships

As well as having Domain Admins group membership in the domain you’re deploying the pool in, to create the Enterprise Edition Pool you’ll need either membership of the RTCUniversalServerAdmins group at forest level (the parent domain – created during Forest Prep) or be a member of a group that has had these effective permissions delegated to it (see John’s post for more details).

Service Accounts

Once you’ve created the Enterprise Pool and entered all the necessary FQDNs, specified the back end server and the file shares to use, you’ll want to started installing OCS 2007 R2 on your Front End Servers and adding them to the pool. A few things to watch for here service account wise that you may require change control/approval on.

• The RTCService you create (or utilise from an existing deployment – same name or not) during Front End Server activation must be a member of the RTCHSUniversalServices universal group in forest root.
• The RTCComponentService account must be a member of the RTCComponentsUniversalServices universal group in forest root.
• The RTCGuestUserAccess account you create during Front End Server activation must be a member of the RTCUniversalGuestAccessGroup universal group in forest root.

These are all things that are usually taken care of during the entire deployment process, but could snag you up in a more complicated environment. So when you submit that change request to get RTCUniversalServerAdmins group (or equivalent delegated) membership, send through the names of the service accounts you intend on using also.

Issuing certificates to servers when using the Certificate Wizard isn’t an option

Generally once each Front End Server is installed, added to the pool and activated, we kick on with assigning certificates to these servers. We do this using the Certificate Wizard included with the OCS 2007 R2 Admin Tools.

If you don’t have the necessary rights to wanton request certificates from the CA (e.g. you might only have rights to issue certificates from one particular template) or you can’t request using the Web Server template that the OCS Certificate Wizard uses, you’ll need to either submit CSR files or get your certs from the CA’s web enrolment page. During this deployment, I opted for the later.

Because we generally need to specify a SAN (Subject Alternative Name) or two for things like pool FQDN, machine FQDN and External Web Farm FQDN, we need to make sure these get on the cert. This works a bit differently than in the OCS 2007 R2 Certificate Wizard.

Navigate to the Web Enrolment page of your CA (generally https://serverhostname/certsrv) and click through (in order) the Request a Certificate, Advanced certificate request and Create and submit a request to this CA pages.

Specify the certificate template (Web Server ideally, but if you can only use a certificate template that grants the equivalent or greater specs than this, select that). Fill in all the usual details like you would in the OCS 2007 R2 Certificate Wizard.

Now, here’s the cool part. In the Attributes box at the bottom of the page, you can specify the additional SANs you need. Your string should take the following format:

(san:dns=SN FQDN&dns=SAN FQDN) e.g. san:dns=hostname.domain.com&dns=poolname.domain.com&dns=abs.domain.com

Note that each SAN FQDN is separated by a & (ampersand) sign.

Once you’ve specified your SANs, click Submit.
If the CA is not configured to issue certificates automatically; a Certificate Pending page appears and requests that you wait for the CA administrator to issue the certificate that you requested.
Otherwise, the Certificate Issued Web page appears and you can click Install this Certificate to install the certificate.

This step installs the certificate to the User container in the Certificates MMC snap-in, so make sure to properly move it to the Machine container so you can assign it to your Front End servers.

Conclusion

You won’t come across a lot of these issues in every Enterprise Edition pool deployment you do, but it’s worth being aware of them for those peskier, more locked down environments.

If anyone has any questions regarding anything I’ve mentioned, feel free to post it in the comments section.

- Justin Morris, Modality Systems

For two years now Microsoft has been building its assault on the global corporate telephony market. What appeared to be a bold, new approach has now been ratified by the latest Gartner research.

Some may say that the big news is Microsoft making it on to the Gartner Magic Quadrant for Corporate Telephony – (report published on 8th August 2008) – albeit only in the “Visionaries” quadrant. However, the real news is in the text of the report itself.

The report’s introduction immediately positions the importance of Unified Communications as a framework in which Telephony is merely a component. This is a critical distinction that should not be overlooked.

“…decisions to invest in unified communications take precedence over telephony”

“…although companies are still deploying PBX and IP telephony, most should make the decision in the context of a broader unified communications strategy”

With respect to Microsoft, the report is specifically talking about Microsoft’s Unified Communications platform product Office Communications Server (OCS) 2007 emerging as a credible contender for corporate voice communications, while cautioning that OCS does not offer a like for like replacement for PBX and IP-PBX solutions.

This should come as no surprise to anyone following the entrance of Microsoft into the Voice market. Gurdeep Singh Pall (Sr. VP of Microsoft’s UC division) summed it up at Voicecon last year by saying “Microsoft is not building a replacement PBX, it is building an alternative to a PBX”.

Microsoft’s placement in the visionaries quadrant is a powerful statement and will surely guarantee their inclusion in future voice RFP’s and tenders – but is the position as a Visionary while scoring low on the “Ability to Execute” axis a major concern? The report also cautions that OCS 2007 “lacks key [PBX] functionality, questions scalability and considers OCS 2007 expensive as a voice only solution.”

Our opinion is “absolutely not.” The report talks about the changing role of the IP PBX and highlights 2010 as the year many users will be using an integrated set of collaboration tools beyond telephony, encouraging companies to consider their telephony partners in the broader context of a UC strategy.

It’s only been 10 months since OCS 2007 officially shipped, so it’s not surprising that widespread adoption has been a slow burn rather than a wildfire. History tells us that Microsoft is extremely good at iterating on a product strategy over multiple releases and any questions around functionality and scalability will be addressed over time.

One cannot dismiss the significance that Microsoft, as the industry leader in corporate desktop software, will play over the coming years with current and future versions of Office Communications Server. If you’re serious about a long-term UC strategy that includes telephony, it’s time to give that OCS pilot project a kick start to see what all of the fuss is about.

Note to self:  When starting a company with the potential for global market reach, don’t put the name of a specific country in the company name.

Chart courtesy of EQO.  Thanks to Om for picking this up and posting it.

-John Lamb, Modality Systems

Straight to voicemail

The New York Times brings us news about an innovate new communications technology:

Don’t Want to Talk About It? Order a Missed Call
“The technology, called Slydial, lets callers dial a mobile phone but avoid an unwanted conversation — or unwanted intimacy — on the other end. The incoming call goes undetected by the recipient, who simply receives the traditional blinking light or ping that indicates that a voice mail message has been received. Ms. Gorman used a test version of Slydial that has been available for months. But since the finished product was unveiled to the public last week, more than 200,000 people have used the service…

The article goes on to state that the concept may sound like the antithesis of interactivity, but “[products like] Slydial turn out to be only the latest in a breed of new technologies that fit squarely into an emerging paradox: tools that let users avoid direct communication.” 

The tools it’s referring to are things like email, blogging, twitter, text messaging, etc, which allow users to publish communication asynchronously while avoiding 2-way synchronous communication entirely.

So is Voice Mail just another communications modality?  Why shouldn’t the caller be able to choose “straight to voice mail” in the same way that the call recipient can do so today?  This balances the power to avoid far more equally.  After all, one person’s ability to communicate is another person’s ability to interrupt.

Software, like any good tool or product, should encourage appropriate behaviour through its design.  I won’t begin to pretend that this sort of thing doesn’t happen at work, but there’s no need to lower productivity.  Text-based systems are a far more efficient way to avoid someone.   

-John Lamb, Modality Systems

Technorati Tags: voice mail,unified communications

At Modality Systems, we like to experiment with technology.  (Actually, that’s not exactly true – we like to abuse technology.   You don’t get good orange juice by being nice to an orange.)

One of the things that’s captured our fascination recently is the utter elegance and simplicity of the software and hardware coming out of Cupertino.  The "creative types" have known this secret for quite some time, but as a Enterprise-centric company, we’ve had our heads in the sand to some extent. 

James decided to buy an iPhone recently and we’ve all be wowed by the web browsing experience.  Outlook Web Access looks so good on this thing that he’s not entirely missing Active Sync yet.   With ActiveSync on the roadmap for the iPhone, it begs the question:  Will the iPhone become the de facto corporate communications device?  It’s not unthinkable.

For us, the important question is how this will integrate with your Unified Communications infrastructure.   There is no Communicator Mobile software for the iPhone, so the logical the logical question is how well web-based UC applications will work.

We started by running Communicator Web Access.  After you manage to get pop-up blocking disabled, it runs really well in the iPhone’s Safari browser.   The contact list doesn’t appear for some reason (though CWA works fine using Safari on a Mac or PC), but the search function works nicely and allows the user to look up a contact and send an IM.

We’ll continue to test the Microsoft UC stack on Apple products and report back our findings in a series of posts.

-John Lamb, Modality Systems

On Friday 27-March, The Daily Telegraph had a 7 page pull out section all about Unified Communications… but not as we know it. 

It looks to be heavily influenced by Nortel, but has comment from Cisco, Siemens, Alcatel and more.  I will leave you to read the full article if you wish, but the main thread is that all things PBX and the move towards Convergence is now called Unified Communications.  The cover story is about Gloucester Rugby Club deploying UC – which when you read closely, it appears the solution is simply an Avaya IP Telephony (IPT) system – and no more.   Not to dismiss the value of IPT and the great work of our friends who design and develop these systems, but a rose by any other name is still a rose.

Microsoft’s OCS and IBM’s Sametime software based solutions are only mentioned on page 7 under “Collaboration”.  The article goes on to say: “Unified Comms really come into its own when IPT is combined with a Collaboration platform like Microsoft OCS or IBM Sametime.”   That’s one way to say it.  Another way to say this is “IPT is just another phone system until you integrate it with information systems and desktop applications.”

A week a later, I attended two industry events in London.   The same theme of IPT as UC was pervasive. 

There is a big effort from PBX vendors here to make sure UC is the new name for IPT.

From the EETimes report on the recent Mobile World Congress in Barcelona….

 

The panel, whose title was It’s the User Experience, Stupid agreed that [Apple's] iPhone represents a model for mobile operators to follow, but they reached little agreement on how to follow.

Anup Murarka, director of technical marketing for Adobe, cited a study showing that 77 percent of iPhone purchasers described themselves as “very satisfied” with their user experience.

In an ominous note for mobile operators, the iPhone respondents credited their happy experience not to AT&T, the channel through which iPhone services were delivered in the U.S, but to Apple, the device maker.  

http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=206504012

 

The parallels to Enterprise Architectures (and Enterprise Telephony/UC) are interesting.  If you define success based on user acceptance and user satisfaction, then it makes sense to care about the user experience.  I often find that far more $’s and cycles are spent on having a highly-rationalised network/server/services architecture (IMS in the carrier space, SOA in the Enterprise space, QoS at the network layer) without an equivalent effort spent on the end-user experience. 

Are we so concerned with modularity and extensibility that we miss the forest for the trees?  Does a highly-coupled client/server service offer a better result in terms of user experience and time to delivery? 

Almost every new product in the UC world is based on the Session Initiation Protocol (SIP).  For the un-initiated, SIP is one of the most commonly used protocols for signaling real-time sessions – like setting up voice and video calls – over IP networks.

For newcomers to the space, SIP may seems like an obvious choice, but this was not always the case.  In the early days of unified communications at Microsoft, David Gurle (now VP of Collaboration at Reuters) was a champion of  SIP as a strategy to simplify and consolidate a diverse set of protocols and products into a coordinated and standards-based technology platform.   This decision paid off and paved the way for what we now know as Office Communications Server and Office Communicator. 

To understand the industry battle that SIP had to fight over entrenched protocols like H.323, it helps to understand the strengths a weaknesses of both.

SIP vs. H.323

Over at Cisco’s Technical Help blog, there is a really good post “H.323 versus SIP: A Comparison“.  The article gives a blow-by-blow account of the relative strengths and weaknesses of each.  

The article raises very good technical points.   I won’t go through each of them – you can read it for yourself – but the gist of it is that H.323 is a better controlled standard and therefore provides better interoperability between products.

When I worked at Microsoft, I was involved in the development, testing and support of systems using H.323 (Microsoft TAPI, Microsoft NetMeeting and the now defunct Exchange Conferencing Server) as well as SIP (LCS, OCS, and Office Communicator).   The bottom line: as a product developer, I would choose SIP any day of the week over H.323.

Why?  This seems to contradict the point made by the other article about the robustness and tight interoperability of H.323 based products.  In simple terms…

My protocol is better than your protocol

SIP is “Internet-like”.  Since it’s standardised by the IETF, you can easily develop specs to extend it, and ratification of extensions occurs relatively quickly.  Also, it looks like HTTP on the wire.  The messages are text based and that makes it very easy to understand and troubleshoot.  This opens the playing field up to an entire community of developers may otherwise not get involved.  

H.323 is “telephony like”.  Its standardised by the ITU, which is a much more rigorous and process oriented standards body.  This improves interoperability between different vendor’s products but slows down the pace of innovation.  Also, it’s use of ASN.1 (binary) encoding for messages means that you need special parsers just to read the messages if you are debugging problems.    

The implied technical superiority of H.323 is neither here nor there.  If you were starting a new company building something on H.323, you’d be building something that’s already been built before.   It’s the extensibility of SIP that makes it so appealing to developers.

The Spectrum: Proprietary to Open Standards

The real discussion should be between standardised protocols like SIP and H.323 and proprietary protocols like Skype. 

A Skype representative at the VoN conference this year said it best: “My mother uses Skype – why bother with standards?” http://von.blip.tv/file/191288

The best way to think of this is to view the technical landscape as a spectrum.  Proprietary protocols are on the ultraviolet end of the spectrum – They will give you ultimate flexibility, but zero cross-vendor interoperability.  If you want to build something completely new, you may have to invent your own protocol.   This removes a lot of initial technical hurdles but transfers the challenges to the business – you’ll need to build your own network and ecosystem since no one else interoperates with you.  As the ecosystem grows, you’ll need to build everything in the ecosystem yourself. 

H.323 is closer to the other end – It has less flexibility, but great interoperability.  

So Why SIP?  In a Nutshell…

SIP strikes a good balance between flexibility and interoperability, and that’s why it’s so popular. 

The momentum of SIP is real.  SIP is being used as a de facto standard within IP Multi-Media Subsystem (IMS) architecture.  In the UK, BT’s pervasive 21cn network will use SIP exclusively for signaling (that’s that plan anyway). 

If you’re going to build a new product, why not choose a protocol that let’s you have your cake and eat it too?  After all, its not the protocol, but what you do with it that counts.

-John Lamb, Modality Systems

A Guide for Enterprise IT Decision Makers

We’ve developed the following tenants to keep in mind when evaluating or implementing a UC product or solution in your company.   A good UC strategy will will address all of the tenants in a way that meets your business needs.  

1.  Strong Identity Management

A user’s Identity must be authenticated and enforced by the back-end system.  One of the many advantages of the current telephony infrastructure is that its extremely difficult to spoof identity.   Short of stealing someone’s phone (or mobile SIM card) it’s nearly impossible to appear to be calling from a phone number that you don’t own.   With a UC device-identity portability infrastructure (see our post on “What is Unified Communications”), both the sender/caller and the receiver must be authenticated in order to prevent identity spoofing.  Once authenticated, the user’s display name should system-defined rather than user-defined to ensure professionalism and appropriate identity use. 

2.  Security

The UC infrastructure must systematically incorporate security features.  Another advantage of the current telephony infrastructure is that it’s inherently very secure from inappropriate access and misuse like wiretapping, interception, replay and redirection attacks.   This can be addressed in a UC system using well-known security techniques.  Encryption should be used at every hop in the communication (for both signaling and media traffic).  Authentication must be enforced, not only for users, as mentioned above, but also for system to system (server to server) communication.   

3.  Network Abstraction

The physical and network layer infrastructure should be an abstraction.  The network must be there and it must have certain characteristics, so it can’t be ignored – but, the details of it’s implementation can be abstracted.  This allows the UC solution to work across different networks without significant changes to the user experience.  A user should have the same experience whether connected to a high-speed corporate IP network, a branch office, a hotel wireless access point, GSM, 3G, WiMax, or the PSTN. 

4.  Device Abstraction

This is a similar concept to what is discussed above in the Network Abstraction section.  The devices are critically important, but the fundamental experience should not change from device to device.  The video conferencing experience on a PC at your office (or in a specially designed video conferencing suite) will be radically different from your experience on a mobile phone, but the user entry points for communication should remain consistent and intuitive.   Software based solutions are the best way to ensure a consistent experience since the user interface can easily be made portable. 

5.  Encompass both mobile and non-mobile scenarios.

Any service deployed only to the edge of the Enterprise will have limited usefulness in the modern world of mobile workers.  Various devices and techniques are now readily available that enable NAT and Firewall traversal of real-time multi-media traffic such as Session Border Controllers (SBC’s) and media relay servers that incorporate technology like the Interactive Connectivity Exchange (ICE) protocols.  These can enable the UC solution to work from any location with a basic Internet connection.  Recent improvements in media codecs also mean that high-quality bandwidth at the edges of the network is no longer essential for voice and video calls.  

6.  Simplify the user’s experience 

Using Presence:  One of the major benefits of a UC solution to simply the user’s experience and enhance a user’s productivity.  The keystone of any modern UC system is “presence”, which enables the caller to have information about the contactibility state of the recipient.  Gurdeep Singh Pall of Microsoft likes to say “Presence is the new dial-tone” and this is absolutely true.  Why bother calling someone if you know ahead of time that they’re on the phone? 

Using a Friendly Identity Format:  A UC solution that provides a URI-based identity schema (e.g., the user-friendly user@domain format) is also a big step in the right direction.  Anything that uses phone numbers as the primary user ID or replicates the 3 x 4 telephone keypad on a computer screen as the primary user interface should be a red flag. 

7.  A Platform

Finally, a UC system should be a platform.  That is, it should have a rich set of API’s and protocol-level interfaces that allow developers and systems administrators to connect it to other systems that know nothing about UC.  For example, your UC system should integrate seamlessly with your company’s electronic directory and line-of-business applications through simple and straightforward API level integration.   We should also be able to extended the capabilities of the platform using customised software (such as like developing call-center applications or automated agents) and devices (like hooking up advanced video conferencing hardware).

-John Lamb, Modality Systems Ltd.

From a terminology perspective, the concept of “unified communications” is currently at the center of a swirling vortex.   To some extent, this is because the term itself is overloaded, but it’s also because there are actually a lot of moving parts that are intersecting in fascinating but complex ways.   In order to develop a definition, we need to explore the constituent parts, and  from there we can begin to get idea of what we are looking for in terms of an overarching concept or strategy.

Network Convergence?

If you make or sell networking equipment, the word “convergence” is used a lot in conjunction with UC, and the two terms are sometimes interchangeable.  From this viewpoint, we are looking specifically at convergence of the network layer, whereby voice and data traffic will travel over the same IP infrastructure.  This can of course be extended to include not just voice, but any real-time traffic such as text messaging and video conferencing.

The general consensus is that network convergence is the inevitable conclusion in both Enterprise and Carrier networks for the simple reason that there is a lot of opportunity to generate significant cost savings by converging data and legacy telephony networks.  These cost savings are driven not only by consolidation of infrastructure (which has direct impact on COGs and installation costs), but also consolidation of operations and maintenance (which are more indirect “ROI” type cost reductions).  

Network convergence will dramatically change the economics of the of the underlying communications network infrastructure.  However, equivalent changes in end-user experience do not necessarily follow.  If the goal is to unify communications, network convergence is a good and necessary tactic, part of the strategy – but not the strategy by itself.   

Device Convergence?

If you make or sell end-user devices and software, such as mobile phone handsets, desk telephones and PC’s, again “convergence” of features and functionality becomes important at the endpoint.  The mobile phone I use today is capable of delivering email, voice calls, text messages, pictures and downloading and listening to music.

We have these smart devices, but they also exist alongside less-than-smart devices like traditional telephones.  They also exist alongside much smarter devices like PC’s and laptops, which provide far greater capability and better user experience, but at the expense of portability.  

Do users want convergence of the end-point?  Maybe.  The argument for device convergence is strong in the case of mobile devices, especially when the user is traveling away from home or workplace.   The obvious benefit here is the portability and simplicity of feature access, but it usually comes at the expense of the feature’s fidelity.  Video conferences and spreadsheets will always look better on a big screen.     

For non-mobile devices, the case for feature convergence is far more suspect.  I’ve yet to see anyone seriously get excited about using the index card-sized screen on modern business telephones.   Factory floors and building lobbies aside, any user that has a US$500 (£250) phone on her desk will also have a PC with a 19″+ LCD screen.   Would she want to view data or images on that gorgeous new LCD monitor – or on the small and pixilated telephone screen?  For me, the choice is clear.

Software (and the Device-Identity Portability Problem)

If you make or sell software, much of the UC world is about gluing communications channels together in clever and intelligent ways.  Microsoft, Cisco, IBM, Nortel and a host of other vendors are now developing UC software for the Enterprise/Business market. 

When you approach a problem from a software point-of-view, two important things happen:  1.  It’s less expensive to make radical changes in the fundamentals of the approach when compared to developing a new hardware based system , and 2. A lot of lessons can be applied from similar software-based communications technologies that have tried this before, like email and instant messaging.

For example:  would you sign-up for an email service if they told you that you could access the account from only one device?  Would you buy a device that lets you access only one email account?  This concept seems ludicrous in the context of Internet based technologies, but this is what we put up with our current telephony infrastructure.  I have a phone at home, one at work, and a mobile phone.  Each device has its own phone number (identity) and without setting up complex call-forwarding options, each device can only represent that single identity.  

What if I could sign-in to any telecommunications device as both john@company.com  and john@personal.com.   I could have different communications profiles for work and personal communication – and I could get access to all of these communications (voice calls, voice mail, email, instant messages, and video conferencing) from any device.   So if I’m in a hotel, I should be able to sign-in to a phone as “me” and start making and receiving calls.   The “phone” could be something that looks like a phone, or it could be another device like my laptop.  If I’m on the road I should be able to use any of my mobile devices to do the same.

The Definition:

The trick is trying to distill all of the above into one sentence!  This isn’t 100% perfect, but a good start for discussion.

Unified communications refers to system whereby users can access all of their communications modalities (such as email, voice, voice mail, text messaging and video conferencing) from any class of device and from any location through a consistent and intuitive presence- and capability-based interface.