Controlling Click-to-Call

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:

pic1

Client has default to Mobile call because that was the last one used.

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.

pic2

HKCU/Software/Microsoft/Office15.0/Lync/user@domain.com/ContactStatusCacheU/sip:usercalled@domain.com

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.

pic3

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.

Share

9 comments on “Controlling Click-to-Call”

  1. Pingback: NeWay Technologies – Weekly Newsletter #80 – January 30, 2014 | NeWay

  2. Pingback: NeWay Technologies – Weekly Newsletter #80 – January 31, 2014 | NeWay

  3. Pingback: Lync Click-to-Call Script

  4. Pingback: Controlling Click-to-Call follow-up…

  5. Ian Reply

    Is it possible to do the opposite – set your own client to always call via Lync (or corporate policy defaults to calling a landline)?

  6. Pingback: Looking up published telephone numbers in the database.

  7. Daryl Sensenig Reply

    This is a fantastic tip that I use in our entire organization. Thanks so much.
    It’s stopped working since our upgrade to Skype for Business. Any idea how to accomplish the same thing in Skype for Business

    • Richard Brynteson Reply

      The location just changed to 16.0. Still works for me when I change it there.

  8. Pingback: Useful Lync resources – Henry Yang's Blog

Leave a Reply

Your email address will not be published. Required fields are marked *