Lyncing up Mitel VOIP

Slight confession, I wrote this post a while back before the name change from Lync to Skype for Business but the title sounds snappy so it stays!

Introduction

Lync, like SharePoint is one of those products that become much easier to get off the ground now that they’re available as a cloud service on Office 365. We’ve already been using Lync for its IM and video-conferencing abilities but also wanted to see how it could be integrated with our phone system.

Whilst some people have gone all the way and replaced their PBX completely with Lync we already had a fairly recent (and substantial) Mitel system in place so for now integration rather than replacement is the primary focus. During a recent project we were informed of the availability of a Mitel plugin for Lync (including the cloud-based version on O365) that would bring the two systems together and give us the best of both worlds.

The product itself is called Mitel MiVoice for Lync and connects to the MAS server in your environment.

http://www.mitel.com/product-service/mitel-mivoice-lync
http://www.ati.com.ph/mitel/pdf/mivoice/MitelMiVoiceforLyncBrochure.pdf

This video on YouTube (not mine) gives a live demo of the product in action

Usernames and LDAPS

In order to use the MAS applications users need login credentials. Initially this looked simple to hook up to Active Directory until we saw that the MAS server was a bit particular about how it wanted to connect to the directory. LDAPS is required, which means you’ll need a Certificate Authority and the cert imported onto your domain controller in order to create the secure connection required by the MAS.

Enabling LDAPS with Microsoft CA
Enabling LDAPS with 3rd party CA

Once that’s done you’ll be able to sync with Active Directory, select the users you want to enable for the MiVoice functionality and set an appropriate role (in our case a choice of Lync+Voicemail, Lync only and Voicemail only)

Plugin deployment

The documentation for MiVoice only seems to give the option for a manual installation where it’s down to the user to enter the correct vMAS server address during the process. This is far from ideal and seeing as the installer is an MSI anyway it seemed worth having a bit of a closer look at what else could be done.

Installing through the standard /qb switch worked but when the plugin started up it wasn’t able to login to the vMAS server. I was expecting that seeing as a step had been effectively missed out but soon found the setting stored in a config file.

C:\Program Files (x86)\Mitel\MiVoice\UCA.exe.config

Running an additional action after the install to copy the file across seemed to work but still felt a bit clunky though. Knowing that the server address is an option passed through the installer it’s highly likely that it could be specified as an MSI property. Trouble was knowing what one, that’s where MSI logs come into play. You can create a log of the installation using the following syntax:

msiexec /log logfile.txt /i installer.msi

Ref: http://thoughtsofmarcus.blogspot.co.uk/2010/10/find-all-possible-parameters-for-msi.html
Ref: http://stackoverflow.com/questions/7302251/determine-if-msi-exe-supports-certain-flag-argument

Searching the log for the vMAS server address soon turned up the string I was looking for is called UC_SERVER_HOSTNAME

With the last piece of the puzzle found running the command below will install the MiVoice plugin silently

msiexec /i MitelMiVoiceForLync.msi /qn UC_SERVER_HOSTNAME="vmas.yourdomain.com"

One thing I did notice was that sometimes the Mitel plugin wouldn’t fire up with Lync on the first launch after installation, it seemed to be hit and miss on the manual install and never worked at all with the silent method. With that in mind I added a reboot prompt as a final cleanup step to make sure the plugin behaved consistently.

Lync contact card behaviour

Whilst testing the deployment method on a generic VM I thought I’d broken the plugin when it wasn’t dialling contacts correctly from the right-click “Make a voice call” option as I kept getting an error stating “No number found”. However when I used one of my colleagues as a guinea pig it worked first time. Around the same time I decided to right-click on the contact I’d tried to dial from both machines and noticed a difference in what was being displayed.

On my VM the contact card only displayed a basic profile (name, department and job title) but no phone number or email address whereas on the desktop machine a full range of information was shown. There was also a little status section stating that Outlook was source of the contact card. Now the difference in behaviour started to make a bit more sense as my VM didn’t have an Outlook profile configured. Lo and behold once Outlook was set up on next launch Lync on the VM showed full contact information and I was able to use MiVoice to dial.

At that point I decided to try and figure out what the design logic was for syncing \ displaying contact information in Lync as in theory it should’ve been using Active Directory as the data source so it seemed odd that the Outlook GAL was having any bearing on the search results.

I also noticed that if a manual contact had been created in Outlook with a different number (e.g. mobile phone or the internal number expressed as an outside DDI) that would appear in MiVoice instead of the internal extension number, resulting in a failed dial.

Ref: http://getucinfo.com/lync/lync-2013-address-book-not-updating-information-from-active-directory.html
Ref: http://y0av.me/2012/02/23/normalize_ad_numbers
Ref: http://ucryan.com/2014/11/15/lync-contact-merge/

Basically it seems that Lync will ignore the phone number field in Active Directory if it isn’t in the E.164 format (i.e. starting with a + sign) as per this Microsoft KB article

http://support.microsoft.com/kb/2658120

At which point you have to decide how to proceed:

1. add the required + sign in front of all numbers in Active Directory
2. work on the assumption Lync users have Outlook configured

At present we’ll probably go with #2 as all our staff machines have Outlook installed.

Personal extension number

One final hurdle to get over is that all staff who want to use the plugin need to have their own individual extension number as two users trying to control the same phone at the same time isn’t going to end well! To that end we’re likely to start issuing each member of staff with a “hot desk” extension number that’s assigned to them when their network account is created, rather than extensions based on location.