The Lync 2013 client simplifies the work place and one of the cornerstone features is the ability to use click-to-call. For an Enterprise Voice user like myself, I cannot remember the last time I picked up a handset and dialed a user. And I certainly never use the “dial-pad” that is provided in the client. Rather, I use click-to-call for all conversations. One of my co-workers recently asked me a question related to the click-to-call. “Can you force the client to always use Lync call by default?” They never want to see this:
The question seemed straight forward enough so I started to do a little digging around the Lync 2013 client for the details. (NOTE: Although this post is about the Lync 2013 client, the settings and behavior appears to be exactly the same in Lync 2010, the registry information is simply in a different place.) Client Policy There are plenty of people (here, here) who have discovered the EnableVOIPCallDefault option as part of the client policy. But what is important to note is that, this is simply the default option for the client for click-to-call. If a user selects another number (work, mobile, etc.) this information is than saved and changed to the default. So while this is an important first step, this doesn’t solve the entire problem. Therefore you should execute: get-csclientpolicy | set-csclientpolicy -EnableVOIPCallDefault $true More to the Story Although that client policy is a nice setting, the moment a user does a click-to-call and selects anything but Lync Call, the client is now going to remember that information going forward. If you simply click the call button (without using the drop down – which is frankly too hidden the Lync 2013 client) than the call will go to the wrong location. Where does this information get saved? Thankfully, this is stored in the registry on each workstation and simply deleting this information resets back to the default.
Options Thus far I’ve found two options. Option #1 – Restrict Access to the Key In my first scenario I simply restricted my user account from being able to read/write to the ContactStatusChachU key. The client displays no errors when I make phone calls and select something other than Lync Call, and even in my scenario where I already had information stored in the key it still defaulted back to Lync call.
Option #2 – Delete the Key The second option I’ve thought of was simply deleting the key on log out. The trick here is that you will need to write a script that will only delete the contents of the ContactStateCacheU directory. Since this key is stored within a key that has the users SIP domain as a parent key, we will need to loop through the registry keys and delete only that key. I’ll update this post once I spent a little time to determine the best way to script this out. I could simply write a quick C# application that runs on log-off but maybe that is a bit much? NOTE: I guess this goes without saying but you should test this out in your environment and editing the registry is one of those “use at your own risk” scenarios.