In a recent Enterprise Voice deployment I struck an issue where a small number of users couldn’t place a call on hold. When they tried, the Lync client errored with “Failed to place call on hold” and instead put the client’s mic and speakers on mute. Removing this mute sometimes worked and sometimes resulted in a dropped call.

All users in this particular deployment were subject to the same client policy, same client version, same voice routing.. generally, everything was the same from one user to the next.

After running some S4/SIPStack trace logs on the gateway, and analysing the SIP Options packet that was being sent to the SIP gateway, I could see that in a working request, the SIP Invite that got sent included a=inactive (which is normal), whereas in a failing request, the Invite sent a=sendonly instead. What I couldn’t figure out was why two clients with the same settings/policy/routes would send two different hold methods. What made this particularly odd was that the user that was having the issue could log on to a different computer, and placing a call on hold would work fine.

So, issue had to be client-side.

One of the things I looked at during the debug process was the Lync registry entries. After painstakingly comparing registry keys line by line, I found that only one of the clients had the MusicOnHold registry keys listed – and it was the one that wasn’t working. Looking at the client options (Tools > Options > Alerts) showed that both had the same options selected (in this case, ‘Enable Music on Hold’ was ticked and greyed out (managed by policy), and the hold music file was populated with the default wma file), yet on the client that was working fine, the two MusicOnHold registry keys (below) were completely missing.

[HKEY_CURRENT_USER\Software\Microsoft\Communicator]

“MusicOnHoldDisabled”=dword:00000000

“MusicOnHoldAudioFile” =”C:\Program Files (x86)\Microsoft Lync\Media\DefaultHold.wma”

After backing up the keys, I deleted the MusicOnHoldAudioFile key, and rebooted. Bingo. Problem solved.

Tried reinstating the key again, and sure enough, problem returned immediately.

I have come across one other customer having the same issue, and they apparently found the problem disappeared when they apply CU5, however I haven’t been able to verify that completely with them, and when I tried the CU5 update, the issue persisted.

Why exactly this happens is soon to be the subject of a support ticket with Microsoft. When I get an outcome from that, I’ll be sure to update this post.

If you’re implementing Lync, or already have it, chances are user training is/was part of the implementation. Great. But what about those “remind me how I..” and “what does this do again?” that you know will come up?

Microsoft have done you a huge favour here.

I personally think Lync is hands-down the most superbly well documented product ever to roll out the doors of Redmond. Sure there’s stuff that could be better documented, but the planning, implementation, support, and (yup) training material available is beyond compare.

There is a huge list of pre-canned resources available at http://lync.microsoft.com/Adoption-and-Training-Kit/rollout-and-adoption/Pages/Resources/Intro-to-Resources.aspx that includes the likes of reference sheets, training decks, and videos, but what I really want to flag for attention is the ‘How To Guide’. Quite simply – it’s brilliant.

The guide is a Silverlight and/or HTML web application that contains a huge range of common (and not so common) Lync user tasks, presented in a sensibly structured manner that any user should have no issue following. It even comes with a handy set of instructions that outlines how to easily add your own items to the list – useful if you perhaps have a custom app integrated with your Lync platform.

The package can be downloaded from http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=5735

Setup is a peice of cake, and should take less than five minutes. Here’s the basics for IIS7/7.5

• Create a folder on your webserver
• Extract contents of the zip file
• Create an IIS site and point it at the folder you created
• Define your default document as either rolodex.html (for Silverlight version) or jQueryRolodex.html (for the HTML version).
• Configure your host headers and DNS entries
• Done

The only difference if you’re doing this on older versions of IIS is you need to manually create a MIME type for .xap extensions, defined as application/x-silverlight-app