Lync Mobile for Android Updated!

When the full suite of Lync mobile clients first came out, the Android experience was less than thrilling.  One key feature missing was the ability to use the mobile client to make the Lync server call your mobile phone and then connect you to the person you are calling (call-via-work).  All the other mobile clients had that feature, and the reason given was that it was difficult to program in Android's fragmented OS space.  Fair enough, but it certainly wasn't a barrier to the hundreds of thousands of other apps that are available for Android.

It seems as though someone at MS finally got the message and they've just released a Lync Mobile update for Android in the Market.  When I was at the Lync 15 Airlift last week, they said there would be an update "in a few months".  Happily, they should have said "a few days".  Wish this were the way for all upcoming MS products.  The details for the update are as follows:

What's in this version:

1. Enabled call-via-work – allowing Enterprise Voice enabled users to make and receive calls using your Enterprise Voice (Lync ID) number only. Connect with others using a single identity.
2. Added user controls for adjusting the sound/vibration for incoming notifications
3. Improved the Lync status icon : know if you can receive IM messages
4. Enabled copy of IM text to the clipboard
5. Multiple bug fixes

Of course, I installed the update and had a poke around.  Right off the bat, Lync Mobile asked me to verify my mobile number to be used for Lync to phone me back when using Call-via-Work.  Immediately, it seemed as though the client was more responsive than before. This could just be wishful thinking, but it did seem snappier.

The My info screen now gives the ability to change your call forwarding settings, in addition to the usual ability to change my status from Available to Busy/Away etc.

Clicking on Call forwarding takes you to a screen where you can edit your settings.  Any changes you make here are immediately reflected in your Lync desktop client.

The Options screen has new options for changing sound and vibration settings.  When you select those options, you are able to change it to System settings or Never.

The Contacts screen looks the same as before.  Status updates did seem quicker than before, so maybe that was part of the bug fixes. Clicking on a user brings up the same screen.  No changes to the UI were noted here.

Before the update, when you clicked a phone number, it would just use your mobile phone to make the call. There was no integration with Lync.  Now, when you make a call, Lync will notify you to answer the next incoming call.

The next call will appear to be coming from your office phone number, which you should recognize.  As soon as you pick up the call, you'll hear it ringing the other end.  That user will also see your office phone number.  This effectively hides your mobile number from other users and will also be useful in situations where incoming mobile calls are free or where a call would be cheaper when being made through the Lync server PSTN connection.

There is a new screen called Keypad.  From here, you can dial a number directly.  As with the previous example, the Lync server will call your mobile number and then connect you to the number.  One thing I noticed is that the normal normalization rules don't seem to kick in. So, I have to dial the full 11-digits instead of 10-digits like I normally do (Lync adds the 1 for me).

The most welcome addition for me was the ability to do one-click meeting joins from my Android phone.  Before the update, I would have to manually enter the conference ID info, which would mean memorizing or writing down the confID and then entering it.  Tough to do when you're trying to join a call from a car.  Now, you can just click the meeting invite from your email, and it will call you and connect you to the meeting seamlessly.  Even better, when I tested this feature while I was already joined to a meeting via Lync on my desktop, it dropped the desktop audio and seamlessly joined me via my mobile.  So, if you have to leave, you can transfer to your mobile without missing a beat.  Very slick and impressive!

The notification icon has also been updated to be more informative.  While Lync is running and actively connected, you'll see the familiar Lync icon in your notification bar.  When Lync is disconnected, the icon will show a little X (as highlighted in red below).

Since there isn't a Lync push notification service for Android, you won't get conversation updates when disconnected.  However, if your phone works like mine (using JuiceDefender), the phone will shut off all network connectivity when not being actively used, but will periodically do a check. At that point, you will get any queued notifications. The user at the other end might get a failed delivery notification, so this isn't a very clean way to operate.

Even with the downsides, these updates are an extremely welcome addition to the Android Lync client.  This brings Lync for Android up to near-feature parity with the other mobile clients.  This Android fan is extremely happy!

Re-routing Incoming Lync Calls to AutoAttendant Using MSPL Scripting

Many companies assign extensions to their users rather than dedicating a full external phone number.  In companies with thousands of users, this is often the only option, plus it can save significant amounts of money.  If you've followed my Enterprise Voice Best Practices for extensions, then you know that I recommend you assign phone numbers to Lync Enterprise Voice users using the main office number as the base followed by the extension, using the format tel:<OfficeNumberinE164Format>;ext=<Extension>.  For example, if your main office number is 15553334444, and your extension is 222, then your Tel URI would be tel:+15553334444;ext=222.  You then create a normalization rule that takes the main office number and routes it to an Exchange autoattendant at an unused extension, such as tel:+15553334444;ext=999.  When someone calls the main office number, the phone call will be routed to the Exchange autoattendant where they can enter the extension of the user they wish to reach.

This works fine in many deployments, but in situations where the incoming phone number is already formatted in E.164 format (as with many SIP providers), it breaks down.  When Lync sees a number that starts with a +, it assumes the number is normalized properly and does not apply normalization rules, no matter how hard you try.  Users get a busy signal and if you do a log trace, you'll see the error 485 Ambiguous.  Lync sees many users with the same base phone number, and doesn't know where to send the call.

In many of those cases, you can either set your PSTN gateway (if you are using one) to not send the + to Lync, or you can ask your SIP provider to drop the +.  If neither of those options are available, then you can employ MSPL scripting to re-route the incoming call to the appropriate autoattendant.

MSPL scripts are simple text-based programs that can do custom message routing and filtering in Lync.  They can be very powerful, if you know how to create them.  Now, having exactly zero experience with MSPL scripting, I turned to the only way I know how to program:  Google/Bing for examples.  Thanks to some excellent blog posts by Michael Greenlee (which made me hyperventilate because most of it was totally incomprehensible to me) and a terrific example by Lasse Wedø (where he did the bulk of the work for me), I was able to figure out how to make this work in my specific example.

First, copy the contents of the below window into Notepad on a server that is running the Mediation Server role. <?xml version="1.0"?> <lc:applicationManifest lc:appUri="http://www.contoso.com/ReroutePilotNumtoAA" xmlns:lc="http://schemas.microsoft.com/lcs/2006/05"> <lc:allowRegistrationBeforeUserServices action="true" /> <lc:requestFilter methodNames="INVITE" strictRoute="false" registrarGenerated="true" domainSupported="true" /> <lc:responseFilter reasonCodes="ALL" /> <lc:proxyByDefault action="true" /> <lc:scriptOnly /> <lc:splScript><![CDATA[ // // // // // // // // // // // // // // // // // // // // // // // // // // // February 2012 - Application // This script re-routes inbound calls from a specific number and routes it to // an Exchange autoattendant. // // Originally created by Rune Strand for OCS 2007 // Modified for Lync by Lasse Wedø then Ken Lasko // // // // // // // // // // // // // // // // // // // // // // // // // // // // CRITICAL: Must be run before UserServices (as 3. in list from above) // When installing the app on server, use the -priority 2 switch // // // Filter out irrelevant requests // Log("debugr", 1, "ReroutePilotNumtoAA: * Inside app."); // // Process only sipRequests // if (!sipRequest) { Log("debugr", 1, "* * * * * * * ReroutePilotNumtoAA:* Not a sipRequest. Leaving."); return; // Message is not our business. Let Lync handle this. } // // Avoid processing RE-INVITEs // foreach (sessionExpires in GetHeaderValues("Session-Expires")) { if (ContainsString(sessionExpires, "refresher", true)) { Log("debugr", false, "ReroutePilotNumtoAA: * Session refreshing invite. Leaving"); return; } } // // INVITE is from a mediation server? If not, end processing // foreach (userAgent in GetHeaderValues("USER-AGENT")) { if (! ContainsString(userAgent, "mediation", true)) { Log("debugr", false, "ReroutePilotNumtoAA: * Request not from Mediation server. Leaving"); return; // Only external requests are of interest! } } Log("debugr", 1, "ReroutePilotNumtoAA: * App is processing a request - ", sipRequest.Method); // // Build the user@host from the To: header. (and some other convenient variables) // toUri = GetUri(sipRequest.To); toUserAtHost = Concatenate(GetUserName(toUri), "@", GetHostName(toUri)); telNum = GetUserName(toUri); // // Look for +15552229999@contoso.com in the sipRequest object // This is the Attendant no. // if (ContainsString(toUserAtHost, "+15552229999@contoso.com", true)) { Log("Event", 0, "ReroutePilotNumtoAA: Autoattendant match. Re-routing +15552229999 to Autoattendant", toUserAtHost); Respond("302","Moved Temporarily","Contact=<sip:Main_AA@contoso.com>"); // Return initiative to Lync. return; } // Return initiative to Lync/Default Routing. return; ]]></lc:splScript> </lc:applicationManifest>

Do a search-and-replace for contoso.com and use your public domain name instead.

Then do another search-and-replace for 15552229999 and use your main office number instead.

Finally, do a search-and-replace for Main_AA@contoso.com and replace it with the SIP URI of your Exchange autoattendant or response group.  You can determine the SIP URI by running the OcsUmUtil.exe program (located in C:\Program Files\Common Files\Microsoft Lync Server 2010\Support).  This program is used to create the necessary contact objects to connect Lync to Exchange UM.  Once you click Load Data, make note of the SIP URI for the appropriate AA, and do a search-and-replace for Main_AA@contoso.com in the script using the information you found from OcsUmUtil.

Then save the script on your mediation server/front-end in a folder like C:\MSPLScripts, calling it ReroutePilotNumtoAA.am.  If you have multiple servers in the pool, copy the script to each server.

Now, open Lync Management Shell and type the following (make sure you replace contoso.com with your public domain name):

New-CsServerApplication -Name ReroutePilotNumtoAA -Parent Service:Registrar:
<lyncpoolFQDN> -Uri http://www.contoso.com/ReroutePilotNumtoAA -Enabled $TRUE -Critical $FALSE -ScriptName c:\MSPLScripts\ReroutePilotNumtoAA.am -Priority 2

If all goes well, you should see a few events in the Lync Server Event Viewer like the following:

Log Name:      Lync Server
Source:        LS Script-Only Applications
Event ID:      30803
Description: Loading application - 'c:\MSPLScripts\ReroutePilotNumtoAA.am'

Log Name:      Lync Server
Source:        LS Applications Module
Event ID:      30208
Description: Lync Server application has successfully registered.
Application Uri 'http://www.contoso.com/ReroutePilotNumtoAA'

Open Lync Control Panel and go to Topology - Server Application and you should see the new script between TranslationService and UserServices.

If the script doesn't work you will see the error logged in the Event Viewer.  If so, click Action and Disable Application.  After a few minutes, you should see an event saying the script was disabled.  Make any necessary fixes and re-enable.  It will take a few minutes to restart.  Once you get a clean start, try calling the main office number.  You should be directed to the chosen Exchange autoattendant.

Every time the script runs, it will log a warning event saying that the number was forwarded to the autoattendant.  If you don't want to see this event, comment the line that starts with Log("Event" with a //.

What is happening behind the scenes is that the script is looking for an INVITE for the main office number.  If it sees that, it will respond to the system making the call with a 302 Moved Temporarily.  This tells the system to forward the call to the new destination.

I recommend that you thoroughly document the procedure for future Lync administrators.  If you hand off Lync administration to someone else, it will be very difficult to determine that a script is being used to re-route the office number.  It doesn't make itself known when doing a typical log trace.  If you make a call to the office number, the trace will only show the phone call is going to the AA.  It won't show the script making the forward.

Also, note that this procedure can be used to forward calls to ANY SIP URI, not just an Exchange autoattendant.  It can be an autoattendant, a response group or an individual user.

This is my first foray into MSPL scripting.  If you notice any errors, please let me know.

For more funtastic MSPL examples, check out VOIPNorm's blog.

Hardware Load Balancers in Lync

Over the past while, I've come across several Enterprise Edition Lync deployments done by other companies that utilized hardware load balancers for all Lync services.  In every case, the reason given for using the hardware load balancers was "so we could have high-availability".  They were shocked to find out that hardware load balancing all Lync services is actually not recommended in a wide variety of scenarios and they could have saved themselves a lot of time and money.

When I design a highly-available Lync deployment, I ask four questions whose answers determine where hardware load balancers are required:

1. Will the majority of internal clients be running Lync?
2. Will the majority of external clients be running Lync?
3. Do you require high-availability when federating with companies running OCS 2007 R2 or older, or MSN/Yahoo!/AOL/GoogleTalk/Jabber?
4. Do your external users need to play messages on their phone during a failover?

If the answer to #1 is "No", then I recommend against using hardware load balancing (HLB) for all internal Lync front-end pools.  If the answer to #2, #3 and #4 are also "No", then I recommend against using HLB for edge servers as well.

Before I go on, I should stress that HLBs are still required for load balancing HTTP/HTTPS traffic to the front-end servers.  Since web connections are session based, they are not suitable for DNS load balancing.  So, for your web services (which includes address book downloads, meeting content and meet/dialin URLs), you will still need a simple HLB solution, which can be provided by either hardware or even a dedicated software-based load balancer (but don't use Windows NLB, its not supported)

Using hardware load balancers in Lync can be a costly endeavour for many reasons:

• For a full HLB solution for a single Lync site with edge services, you would need an HLB for the front-end pool, an HLB for the internal interfaces on your edge pools and an HLB for the external interfaces on your edge pool.  That's 3 HLBs.
• Many HLBs are not well suited to real-time communication.  HLBs that support real-time media are much more expensive than one used only for web traffic balancing.  
• Configuring the load balancers to work with Lync is much more complicated and extends the implementation time. It can also complicate troubleshooting connectivity issues. 
• Putting additional hardware between your users and the servers also introduces additional network latency, which is something you want to minimize where possible.  
• Finally, the HLBs themselves can be a single point of failure, unless you deploy multiple nodes.

Lync can use DNS load balancing to provide high availability.  That term is misleading, because it implies that  DNS is responsible for load balancing, which is not true (or possible, since you can only do DNS round-robin in most cases).  DNS is only used to present the initial list of available front-end or edge servers (depending on if the user is internal or external).  Once the Lync client successfully connects to Lync, it caches the IP address of each server in the pool.  The user will preferably connect to the same server at each login (calculated using an algorithm described here), but if that server is unavailable, the client will automatically and seamlessly connect to another server in the pool.  The same is also true for federated connections from other companies, as long as they are using Lync for their edge servers.   

For legacy connections or 3rd party IM provider connections to a DNS load balanced Lync pool, the clients/edge server will only connect to the first IP address that is returned from a DNS lookup.  Should that server go down, they will not failover to an alternate server.  The same is true for external users who try to listen to Exchange-based voicemail messages during a failover.  If legacy/3rd party connections or external access to voicemail (and remember that voicemail messages are always accessible via Outlook) are important, then this is the ONLY reason I would deploy HLB on your edge servers.  In most cases, the company accepts the reduced potential for legacy high-availability in return for a simpler, cheaper and more reliable solution.

So before you go and drop a ton of money on hardware load balancers, make sure you understand the built-in high-availability capabilities in Lync first, so you can make an informed decision.

For more information on DNS load balancing in Lync, check out these links:
Lync DNS Load Balancing on Technet
Lync DNS Load Balancing on NextHop