Since switching to our Lync phones, I have wanted to use my Jawbone Bluetooth headset with the soft phone on my computer. The soft phone could be very useful when onsite with a customer where I may not have a cell phone signal, but can connect to the customer’s Internet. My headset would connect to the built in Bluetooth radio in my laptop, but would not show up in Lync. I had a USB Bluetooth adapter and decided to install it and see if I could then use my headset with Lync. Using the USB Bluetooth radio, I can connect my headset and use it with Lync. It appears that Lync only allows devices connected to a USB or mic/speaker port to be used with the soft phone. Here are the steps I used to connect my Jawbone Icon to my laptop and use it as my mic/speaker for Lync. [more]
in the bottom left corner of Lync and it should be called Custom Device
The Polycom CX600 phones currently deployed in the office are all running a special OS of the Lync Phone Edition. As will all Microsoft Products, updates are periodically released to the software to enable new functionality or fix buggy or security issues. The Lync server provides an easy way to deploy the updates out to all systems, but usually you would want to deploy it to a test device first to make sure that everything will install and function as intended. Lync also provides the ability to create a test device that can be used for updates.
Any updates that you have installed (regardless of the approval status) will now be automatically installed on your test device. Once you’ve determined the test device functions as intended, you can approve the updates for everyone. According to many sources, the update check-in happens within a minute or two after the phone goes idle and installation within 10 minutes after that. From our (impatient) testing, however, this didn’t appear to be the case. Granted, your mileage may vary and we may just be very impatient people.
I have been doing some testing on a Lync phone system specifically with response groups and call queues to try to figure out the most appropriate way to design our incoming call routing once we completely migrate to the Lync phone system. The response group features provide most of the features that you need to create basic call center-ish call routing, queuing, and end-user call route feedback. You can configure your response groups to pick up an incoming call and then play a recorded message. You can then configure the response group to provide callers with routing options (like press or say 1 for sales….press or say 2 for support…stuff like that).
My goal was to imitate the current phone system setup as much as possible. Right now, when someone calls the main number (during business hours), it just rings back to the caller until one of the call operators answers. One of the operators must be “online” to receive the call. In Lync, the equivalent of this functionality is to have a response group configured to receive the inbound call and then ring all users who are “logged in” to the response group. The desire was expressed to make sure SOMEONE (not something) be the first to answer the phone. So, from the Lync configuration side, this is basically a response group with no recorded greeting and no user call routing options….the incoming call rings, Lync answers and places the call in the response group for someone to pick up.
The problem is that when Lync picks up the call and transfers it to the response group, it terminates the ring-back to the caller and since the call was transferred to the response group, it starts playing music on hold.....(it’s nice music on hold but could be very confusing to the caller). I struggled with how to fix this and still have the caller have the impression that they were not “talking to a machine”. The solution is somewhat lame, but what the ears hear, the mind believes. Basically, I called into our current phone system, put my phone on speaker and recorded the ring-back with my cell phone. Then, I created a .wav file of the ring-back and set that .wav file as a looping auto greeting for the response group. So, when an incoming call comes into the response group, the caller gets the impression that the phone is still ringing…just waiting for someone to answer. Problem solved.
I’ve been upgrading our internal Office Communication system to the new Lync 2010 environment. Everything I had been reading showed the two servers can run side-by-side, albeit with different pools created. Running side-by-side allows for easy testing and migration rather than switching everyone over and hoping it works. Unfortunately, what I didn’t realize was the two servers use some of the same database names. While Microsoft has documented this, you have to dig a little through the documentation to find it.
I discovered this travesty soon after I hit the magic “go” button. This button (also known as “Publish topology”) started the deployment of the Central Management Store into my SQL instance. This process involves taking existing databases and placing them into restricted mode. Then the installer attempts to drop the database and recreate it. Since these were OCS R2 databases, however, the Lync installer had problems recreating over the existing table layout. The whole process choked, leaving the databases in a funky, inconsistent, restricted state and communicator non-functional. I was able to connect as ‘sa’ and remove the restriction, but the databases were pretty much a lost cause. Restoring from the previous night’s backup allowed everyone get back online.
Moral of the story: Here’s yet another Microsoft product that does not warn you before dropping databases. Be wary when installing applications that automatically set up databases as part of the installation procedure.