Using the Lync 2013 client with an OCS server

I have to admit that this one is not something I found myself: one of my team alerted me to the fact that I could use the Lync client against an Office Communications Server (OCS) 2007 back-end with a few configuration changes and it’s been very handy. It’s not always smooth, but it does the job and might be useful for others:

First step is to make the following registry change:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Office\15.0\Lync]
"DisableServerCheck"=dword:00000001

Then, in the advanced connection settings, set the OCS pool manually.  The value there will depend on your organisation’s infrastructure.

Lyncing to Asterisk

I’m seeing increasing interest from customers in the enterprise voice functionality in Microsoft Lync – particularly for customers who already have an investment in Microsoft products for email, instant messaging and presence (Exchange and Office Communication Server or Lync).

One of my colleagues, Garry Newsham, shared an interesting link with me recently about integrating Lync with the open source Asterisk platform. Whilst this isn’t something I expect many enterprises to be looking at, it might be a project for smaller organisations.

As for me, maybe I’ll have another go at getting IP telephony working in my house, linked to my Office 365 Lync subscription…

Logging in to Lync 2010 with the Windows Phone client

Earlier today, Microsoft released the Lync 2010 client for Windows Phone (clients for Android, iPhone, iPad and Symbian are on their way).  And, as I’m an Office 365 user and I bought a Windows Phone last week, I decided to take a look.

Installing the app is straightforward enough but I was struggling to log in using the normal credentials that I use for other Office applications (like Outlook Mobile). From looking at the ratings on the app, it seems I’m not alone – with plenty of people saying “it doesn’t work”.

Microsoft’s advice for setting up Lync on Windows Phone is incomplete but the required DNS settings are documented in the Office 365 community wiki.  The missing piece of the puzzle came from Ben Lee – it’s necessary to specify a username (in the format user@domain.onmicrosoft.com) and an External Discovery URL of https://meet.lync.com/Autodiscover/autodiscoverservice.svc/Root.

Once those additional settings were configured, Lync jumped into life!

(For full client configuration details, with screenshots, check out Ben’s post.)

[Update 21 December 2011: It seems this also works with the iOS Lync client, except that also seems to need an Internal Discovery URL before it will allow sign-in (I used the same URL for both internal and external)]

Defining custom presence states for Office Communicator 2007 R2

Late last year I wrote a blog post about defining custom presence states for Microsoft Office Communicator. Unfortunately, when I updated my client to Office Communicator 2007 R2, the custom presence states stopped appearing.

One of my colleagues told me that by default, Office Communicator 2007 R2 doesn’t support reading the custom presence information from a local file and that it has to come from a secure web server. I tried that without success (using Windows Live SkyDrive to serve the file as HTTPS) but the fix that eventually worked for me was to add another registry key – a DWORD value for EnableSIPHighSecurity (set to 0), in the same location as the CustomStateURL:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Communicator]
@=""
"CustomStateURL"="file:///C:/Users/username/Documents/presence.xml"
"EnableSIPHighSecurityMode"=dword:00000000

Whilst I’m revisiting this topic, it’s probably worth highlighting a couple more resources:

Interact 2009

Interact 2009I spent yesterday at Microsoft’s Interact 2009 event, which was a fantastic opportunity to meet with representatives from the Exchange Server and Office Communications Server groups at Microsoft as well as to network with MVPs, key customers and other people that Microsoft considers influential in the Unified Communications (UC) space.Delegates network at Interact 2009 (UK event) Through 7 hours of workshops, a variety of topics were covered (some live, some via video links) providing feedback to Microsoft on product direction as well as receiving guidance on implement the technologies.

Yours truly at the at Interact 2009 (UK event)Those who know me of old (long before the days of blogging) will remember the youthful consultant who used to know a fair amount about Active Directory and Exchange Server. These days I’m more of a generalist (with less hair, slowly turning grey) but I still enjoy going back to my messaging roots and Interact allowed me to bring myself up to speed around the upcoming release of Exchange Server and the current release of Office Communications Server (OCS).

Today, is the day when Microsoft will officially announce Exchange Server 2010 (formerly known just by its version number – Exchange 14), along with general availability of the beta and, time-permitting, I hope to write a few posts over the coming weeks with a general UC (Exchange and OCS) focus, starting out with an overview of the new features in Exchange Server 2010.

PubWorld at Interact 2009 (UK event)Finally, for this post, I thought I’d share some pictures from yesterday evening’s event in Reading (which, along with the other pictures in this post were supplied by Microsoft UK courtesy of Eileen Brown). I don’t know what was planned for Redmond and Boston but, over here, one of the meeting rooms in building 3PubWorld at Interact 2009 (UK event) on the Microsoft UK Campus was converted to a “traditional English pub”. We had a bar serving warm beer (in the form of bottles of London Pride), which caused some confusion for at least one senior ‘softie from “Corp” (there was chilled lager available too, as well as wine and a selection of soft drinks!), as well as a simulated fireplace, a darts board, various items of pub paraphernalia, picnic tables on a “terrace” outside and also some modern accompaniments – such as Xbox 360 kiosks, Air Hockey and Table Football – with a 1950’s jukebox thrown in for good measure!

Defining custom presence states for Office Communicator

Custom presence states in Office CommunicatorLast night, Garry Martin pinged me on Office Communicator and was very excited about something… as it happened, that something turned out to be the new features in Office Communications Server 2007 R2. He was also keen to show of the new custom presence tags he’d created and even I (the great instant messaging cynic) have to admit that they are pretty cool (I may find IM a distraction but presence awareness is a valuable tool).

Why bother? Well, if you have to ask that question then this mod is probably not for you but I do find that there are different levels of busy in life and sometimes the default states are just not enough.

I decided to implement this on my PC too and it’s quite simple. First up you need an XML file:



Coffee Anyone?


Yes, I really am busy…


Customer Presentation

In my case, this is called presence.xml and I’ve saved it in my Documents folder.

Then you need a registry key to access it:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Communicator]
@=""
"CustomStateURL"="file:///C:/Users/username/Documents/presence.xml"

Restart Office Communicator and the new states are there for selection.

I can’t claim any credit for this – the original details came to me from Tom Laciano (aka LCS Kid)’s blog post on OC Custom Presence States and Brett Johnson’s post which highlights the availability of an HTML application to do the hard work for you, via Garry. Tom’s blog post also mentions a couple of limitations in that you can’t have yellow (away) custom presence (why not?!) and that you have to sign in with one of the default states before selecting a custom one.

At the moment I just have the three custom states that are in the example XML above but, after the day I’ve just had, I feel like adding another one – “Trying to process my Inbox to zero”…

Microsoft Unified Communications: part 5 (notes from a real deployment)

Over the last week or, so I’ve posted several articles on the Microsoft View of Unified Communications (UC), looking at

  1. An introduction to UC (from a Microsoft view).
  2. How UC can change the ways in which we work.
  3. How the various Microsoft UC components work together.
  4. Some of the things to know about Cisco’s UC solutions, QoS and codecs.

This final post in the series has been part-written for over a year now (ever since I got involved in a UC pilot project in 2007). Even though I was a Microsoft Certified Technical Specialist (MCTS) for Live Communications Server 2005 (the predecessor to Office Communications Server 2007) and have worked with Exchange Server since 1996, I haven’t carried out a real LCS deployment and unified messaging is a new feature in Exchange so the project involved a steep learning curve. This post summarises the points that I learned along the way (with more than a little help from colleagues) – not so much a product review as a collection of notes that I made that might be useful to others.

  • DNS is critical to a successful UC deployment as OCS relies heavily on DNS for name resolution. Specifically, it uses SRV records to hold details of key servers within the organisation for automatic logon (_sipinternaltls for TCP connections over port 5061 to sip.domainname.tld). If users are having problems with OCS, start off by checking the DNS event logs.
  • Other services that are required include Microsoft IIS and ASP.NET.
  • Secure communications require a certificate service. For internal deployments, it might be possible to get away with a self-signed certificate (especially if group policy can be used to ensure that all the clients trust the entire certificate chain); however for external deployments it’s best to get a certificate from a known trusted source. Certificates from well-known and trusted organisations like Verisign are pretty sure to work whilst providers of free certificates may not be trusted (so offer little advantage over self-signed certificates); there is a middle ground though as low-cost certificates can be found which are trusted by default in many browsers. Subject alternative name (wildcard) certificates are also available (e.g. for *.domainname.tld).
  • Like some other products (e.g. Exchange Server 2003), OCS uses a wizard-based approach to deployment, guiding an administrator through each of the stages depending upon the type of server that is being installed.
  • If an organisation is nervous about making schema changes OCS may cause some issues as it requires a schema update (as does Exchange Server). This is often made out to be a bigger problem than it really is.
  • OCS does require the domain in which it is to be installed to be running at Windows Server 2003 functional level.
  • Location profiles can be used to normalise numbers into the correct format.
  • Web conferencing (e.g. for Live Meeting) is enabled in the OCS global properties.
  • OCS contacts are stored in Active Directory in a container called RTC Special Accounts (visible with advanced features enabled).
  • During our deployment, we used method 2 in Microsoft knowledge base article 951644 to get around Outlook integration errors because our OCS signon address did not match the e-mail addresses use in Outlook. The Office Communicator team has published some good advice for troubleshooting Outlook integration and address book errors.

OCS is only one of Microsoft’s unified communications technologies and another key element is the new unified messaging (UM) role in Exchange Server 2007. Note the distinction between unified communications (bringing together multiple forms of communication along with presence awareness) and unified messaging (one inbox for all message types – e-mail, fax or voicemail – for a more detailed explanation, refer to part 1 in this series of posts).

In terms of deployment, Exchange UM is far less user-friendly than OCS and requires the use of Windows PowerShell/the Exchange Management Shell. Setting up Exchange UM to work with OCS involved:

  • Creating a new dial plan (e.g. new-umdialplan -name dialplanname -uri
    type "sipname" -voipsecurity "sipsecured" -numberofdigitsinextension 5
    ).
  • Specifying the UM server to be associated with a dial plan (e.g. set-umserver -id exchangeservername -dialplans dialplanname).
  • Enabling mailbox access for users (e.g. enable-mailbox -identity 'msuc.co.uk/Users/username' -alias 'aliasname' -database 'exchangeservername\storagegroup\database').
  • Enabling the user’s mailbox for UM (e.g. enable-ummailbox -id username -ummailboxpolicy "mailboxpolicy" -extensions voiceextensionnumber -sipresourceidentifier emailaddress -pin pin.
  • Creating a UM-IP gateway with associated hunt group and set permissions (run .\exchucutil.ps1 from Exchange Server 2007 service pack 1).
  • Creating a UM auto attendant (e.g. set-umipgateway -identity ocsserver -port 5061).
  • Get details of the OCS pool (run .\get-ucpool.ps1 from Exchabge Server 2007 service pack 1).
  • Running the Exchange UM integration utility (ocsumutil.exe /domain:dnsdomainname) to allow OCS calls to be routed to Exchange Server (for capture as voicemail).
  • Configure SSL on the Exchange Server.

Of course, the beauty of PowerShell is that this may appear complicated but can be scripted for re-use.

All of the above is concerned with deploying OCS for instant messaging/presence and integrating it with Exchange for voicemail. It should be noted that OCS is not a PBX replacement (even though it will integrate with major manufacturer’s PBXs) and that for routing voice calls to/from OCS a mediation server is required. In the pilot, we used an Dialogic IP Media Gateway 1000 but this is very much an entry-level system and there are appliance servers (e.g. the Dialogic DMG4000) that combine the role of OCS mediation server with the IP media gateway functionality. The mediation server is fairly simple to deploy, with the only specialist requirements being the definition of the listening address and gateway, along with the details of the PSTN gateway (the IP-PBX or the media gateway).

Communicator Web Access (CWA) is a potentially useful feature within OCS – providing a OCS client access from within a web browser. The only gotcha that I came across during testing was the need to create a certificate (for activation) using a tool from the LCS 2005 resource kit (lcscertutil.exe) with the web server certificate template.

A couple of other server roles that are worth mentioning are update servers (for updating OCS software on unified communications devices such as IP phones deployed within the organisation) and archiving servers (for archiving conversation history for reasons of compliance). I didn’t set these up in my environment but they complete the picture in terms of OCS deployment.

Further information

Microsoft Unified Communications: part 4 (a brief note on Cisco, QoS and codecs)

As might be expected for a series of blog posts about the Microsoft view of Unified Communications (UC), it is heavily biased towards Microsoft products but I wanted to take a brief look at another major player in the unified communications space – Cisco. It should be said that I have very limited experience of Cisco’s UC offerings (only as an end user of their IP telephony products) but it’s worth highlighting the differences between the Microsoft and Cisco approaches.

Microsoft and Cisco are partners, but they are also competitors. Some googling suggests that Cisco and Microsoft’s VoIP products can be integrated but not always without challenges (Aaron Tiensivu’s post on integrating Microsoft Exchange and Cisco CallManager is just one example of such a challenge) but it should be considered that they have come to UC from different directions.

Cisco are a networking company and they have approached UC as a networking problem for which there is a networking solution. On the other hand, Microsoft are a software company – they have looked at the overall user experience an attempted to engineer a software solution.

Whilst Cisco concentrates on providing a VoIP solution that offers Quality of Service (QoS) and has grown out of PBX technology, Microsoft relies on codecs that are tolerant of poor network conditions to deliver what they refer to as Quality of Experience (QoE). Those with far more experience than I have commented that the Microsoft approach is sensible for calls that are routed across the Internet (where there is no QoS) but less so in an enterprise environment and Ed Horley made a very valid observation that network links, particularly WAN links, tend to be under-provisioned. I have to say that using the SCCP/UCM solution at work provides fantastic call quality but I also find that the Cisco IP Phone (running SIP) on my desk at home provides a great experience too and, at a recent event, Microsoft even compared their solution with Skype, citing this as a well-known example of a software solution that provides good call quality over variable consumer Internet connections (something which I was surprised to find when I was using Skype for a video call between the UK and Australia recently).

Microsoft’s general recommendation is to let the software select an appropriate codec and Office Communicator will constantly assess the available bandwidth and select an appropriate codec, even switching codecs and/or tuning parameters as required during a call.

The main concern is with voice traffic saturating network bandwidth at the expense of data – that’s where QoS can be used effectively – to manage the network.

In the final post in this series, I’ll wrap things up with some notes from my own OCS implementation last year.

Microsoft Unified Communications: part 3 (putting it all together)

Over the last few days, I’ve been describing the Microsoft view on Unified Communications (UC), based on a presentation given recently by James O’Neill.

In the first two posts in this series based on James’ presentation, I outlined the business need for unified communications and some of the Microsoft technologies that can be used to address those requirements before examining some of the benefits to be gained thorough adaptation of communications to fit modern working practises. In this third post in the series, I finally move on to the technology, looking at the main steps involved in implementing a UC solution using Microsoft products.

It may also help to check out my post from April 2006 which provides an introduction to voice telecommunications for IT professionals.

In a traditional communications infrastructure, voice and data networks are managed independently:

Traditional (non-unified) communications

Even though there has been a move to replace telephone cables with standard CAT5/5e/6 cabling in recent years, and IP telephony has become more commonplace so there has been some convergence at the network level, the voice and data systems are typically separate (although their directories may have been integrated).

Implementing Exchange Server 2007’s unified messaging capabilities allows the removal of the PBX voice-mail system and provides voice-mail, fax and speech capabilities within Exchange, accessible via standard e-mail clients, Outlook Web Access or through a voice call:

Unified messaging with Exchange Server 2007

To enable the integration with the PBX, a VoIP gateway may be required (some PBXs may integrate directly).

Replacing any existing instant messaging systems with Office Communications Server (OCS) 2007 (or implementing OCS as a new service) can provide VoIP connectivity with the existing telephony systems, enabling both “soft” and “hard” IP phones to be used. In addition, Live Meeting can be used to provide conferencing facilities:

Unified communications with Office Communications Server 2007

With this infrastructure, OCS will integrate with Exchange and work collaboratively to route calls, present caller ID information (used in the subject of messages), perform directory lookups, etc. but for OCS to integrate with a PBX a gateway is required. A basic gateway also requires an OCS Mediation Server to be deployed whereas an advanced gateway includes the necessary technology to integrate directly with the PBX.

Effectively, there a four levels of integration:

  1. None at all.
  2. Basic gateway with mediation server.
  3. Advanced gateway.
  4. VoIP capabilities built-in to PBX.

Microsoft has partnered with a number of manufacturers to provide hardware that integrates with OCS, and the strategic gateway partners are Audiocodes, Dialogic and Quintum.

This approach allows legacy routers, gateways, PBX and phones to be maintained (after all they are a significant investment) but integrated with software solutions to adopt new ways of working, as featured in Microsoft’s VoIP as you are campaign. For organisations that are ready to remove the legacy telephony altogether (e.g. in a green field site) an advanced gateway can be used to integrate the VoIP system with public telephone networks:

Full Microsoft Unified Communications

The call path is as follows:

  • User initiates a call.
  • OCS looks for valid endpoints and sends a packet to say that there is an incoming call (including call forking, if configured).
  • An endpoint (possibly voice-mail) accepts the call and the server drops the other connections.
  • Once the call is established, the server drops out of the conversation (aside from logging the call details) and the call continues on a peer-to-peer basis.

There are a few additional points to note:

  • Where network address translation is in use, an OCS Access Proxy may be deployed.
  • If the call is routed over the PSTN, the gateway is just another party on the call (as if it were a phone).
  • In a conference scenario, Office Communicator clients only have a single channel of data in each direction and so where multi-party calls are placed, a media control unit (MCU) is required to act as a negotiator. At this point, the direct call is dropped and a new multi-party call is set up via the MCU. Live Meeting clients can send multiple video channels (plus sound and desktop conferencing on separate channels).

Having outlined a VoIP-only solution, it’s often the case that the legacy infrastructure cannot be completely removed – there are still some limitations around VoIP that OCS cannot address (at least not in the current release). For example, if there is a loss of power, then there are no network switches and there is no telephony (the same issue also applies for IP Phone systems using Power over Ethernet – such as Cisco IP Phones). As a consequence, and to meet health and safety requirements, it may be necessary to retain some traditional telephony infrastructure for emergency calls. Even if they are accessible through OCS, emergency calls present another challenge in that the call will be placed at the gateway, which may be in another city, country, or even continent to the person making the call, so dial plans need to be carefully designed.

Clearly this post is heavily biased towards Microsoft products and another major player in the unified communications space is Cisco. In the next post in this series, I’ll take a brief look at the approaches that the two vendors have taken to unified communications (and it will be a brief look, as I have very limited Cisco experience!) before I wrap the series up with some notes from my own OCS implementation last year.

Microsoft Unified Communications: part 2 (unlocking the potential for new communications experiences)

Last week I spent some time at Microsoft in one of James O’Neill‘s presentations on the Microsoft View of Unified Communications.

In the first post in this series from James’ presentation, I outlined the business need for unified communications and some of the Microsoft technologies that can be used to address those requirements. This post looks at some more of the benefits, as communications experiences are adapted to match modern working practises.

The first goal of unified communications: whenever I see a name, I also see presence

We communicate with people, not addresses, yet it doesn’t seem strange to us to dial a network address (a phone number) to speak to someone. Obviously, that’s because telephony has a long history, but it seems pretty odd today – after all, when did you last e-mail someone by IP address? That’s where directories come into play – just as on a mobile phone we tend to store contacts by name, in a corporate environment we should be able to contact our colleagues (or federated contacts) using Active Directory (possibly integrated with other directory systems – such as the internal telephone system).

Having found the right contact, we have a huge choice of media for communications, and the most appropriate medium may vary according to a number of factors:

  • Would you phone someone you know is out? Possibly – but you’d probably call their mobile phone.
  • Would an IM chat save a long e-mail exchange? This one is a little more tenuous – I often find that I’ve spent 20 minutes on IM when a 2 minute phone call would have sufficed.
  • Do you ever ask “is this a good time for a call”? Almost always!

The choice of medium is driven by presence – and when we have presence information, we can use it to make a decision.

After all, how would you connect of the person was:

  • On holiday for a week?
  • In a meeting for the next 30 minutes?
  • Around but not at their PC?
  • At their PC but with a do not disturb sign?
  • Available?

Technologies like the Office Communicator client can even set levels of permission (e.g. personal contacts may be able to override do not disturb status, certain contacts may be able to view home phone numbers but not everyone, etc.) and Office applications can also show presence through smart tags which include a “jellybean” presence icon.

The second goal of unified communications: where I see presence, I should be able to start a conversation (in the right medium)

Once I have a contact’s presence information, I can choose an appropriate form of communication. Should I contact them on a 1:1 basis or multi-party? Should I use voice, video, a data conference, instant messaging or e-mail? Then, using unified communication technologies I can let the computer place the call so that it may be routed according to my contact’s working hours, availability (presence), or other rules – possibly even allowing call forking so that two or more devices ring simultaneously and the first to be answered takes the call.

Using unified communications products a conversation can even switch modes mid-communication, for example:

(Instant message) “Are you free for a call?”
(Instant message) “Yes, but I’m travelling right now!”
(Click to call – and the call is routed to the contact’s mobile phone based on their working hours)
(Communicator-mobile voice call) The conversation continues until… “I’m in the office now, let’s transfer this to my desk phone.”
(Transfer call)
(Communicator-communicator voice call) The conversation continues until some expert advice is needed “Let’s bring Dave into the call – he’s the expert in this area.”
(Click to invite others)
(Multi-party voice call) “But what if I show you this diagram”
(Click to start Live Meeting)
(Conferencing) Each party can see a shared desktop, etc.

This example shows that the rich functionality provided by the various unified communications technologies allows for new conferencing experiences. Add in devices like the Office RoundTable and the whole feeling of a conference call changes (I’ve lost count of the number of times when I’ve tuned out of a voice conference because I’d lost track of who was talking or couldn’t hear them properly on a conference phone) – and meeting content can be recorded and stored for subsequent playback. Then there is Unified Messaging in Exchange Server, allowing voice-mails to be stored with notes in the recipient’s Inbox as well as voice access to have e-mails read over a voice call, to move calendar appointments, to access the directory and call contacts, etc.

That’s just the unified communications part – but why should web applications be restricted to e-mail and web addresses to provide contact details? tel: URIs can extend contact to voice calls, and can integrate with directory systems that use the E.164 standard for number formatting.

Incorrectly formatted phone number on Microsoft's websiteSadly, I know of at least one large IT services company that mandates the +44 (0) xxxxxxxxxx format for its directory updates (which is confusing to computers, as they will dial the +44 and the 0, rather than substituting one for the other) and even Microsoft’s own contact pages have an incorrect number which not only includes the UK (44) code in front of a full 11-digit number (including the 0 – which won’t work) but prefixes that with (011) which is the US international dialling code but is by no means universal (it’s 00 in the UK, and 0011 in Australia – hence the standardisation on the + symbol).

LG-Nortel IP8540 (Tanjay) deviceThe unified communications experience need not be limited to software either. Whilst Microsoft claim that the desk phone reached an evolutionary dead end some years back (Cisco, Siemens, et al. may disagree), they have also partnered with LG-Nortel, and Polycom to produce IP and USB phones to integrate with Microsoft unified communications software. Codenamed Tanjay and Catalina respectively, these devices either include an Office Communicator client with a touch screen and a fingerprint reader for authentication or extend the Office Communicator desktop experience to include a handset.

Hopefully, this post has helped to illustrate some of the new ways of working that incorporating unified communications technologies into the infrastructure can facilitate. In the next post in this series, I’ll move past the theory and benefits of unified communications and start to look at implementing the technology.