While assisting our customer this Spring, we started to update the Lync UC Phone Edition firmware (7577.4366) to allow for Music On Hold (MOH) from their widely deployed Polycom CX-600 phones. Naturally we decided to test this new feature on a limited number of phones using the Test Device option within Lync. Additionally, several business units had requested individual MOH audio be played back to their customers. One option we explored was using a network share location to organize each units’ audio files and apply the setting using user based client policies.
Example Client Policy Setting:
Set-CSClientPolicy –Identity BUnit10 -EnableClientMusicOnHold:$TRUE –MusicOnHoldAudioFile “\\FileServer\BUnit10\MOH\CustomMOH.wav
Initial testing was successful in allowing for network based MOH, but only from Lync desktop calls. When the CX-600 phone places a caller on hold, I was presented an authentication challenge on the phone’s screen, expecting a username & password. This makes sense since the network share requires authentication.
This seemed pretty cool at first, however, you cannot actually type out the necessary information properly. After about 1 minute of waiting for input, the phone freezes and reboots. (Yes, this drops your PC’s network connection if connected via the phone.) For continued testing, I attempted to define Anonymous access to the file share, but this failed also.
While working with Polycom / Microsoft support to enable this functionality, Microsoft released a new firmware that ignores the setting of the MusicOnHoldAudioFile parameter of the Client Policy (7577.4387). While this does allow for the generic MOH file, it defeats our goal of hosting custom MOH based upon the Lync user.
Back to the drawing board