Like a lot of companies that drink the Microsoft cool-aid I work for a place that uses Skype for business for text chat/voice communications… it generally works pretty well.
A few colleagues of mine have Blynclight status lights above their monitors as a visual indicator to visitors and/or other people around you that you are free/busy/uninterruptible. The concept itself looked pretty simple to build so I thought I’d give it a go… My project is called SkypeSignal (I’m not very good at names):
My solution comprises of two main parts:
An Arduino nano connected to a couple of RGB LED lights
A .NET application which uses the Lync client SDK to send commands to the Arduino via serial (over USB)
The parts list for the actual build is pretty minimul:
A few RGB LED’s (supports a PWM driver [i.e. WS2811])
a 330 Ohm resistor
I went for LED’s using the WS2811 chip to drive them; this means that we only need 3 wires to run the whole thing, the below design can be modified to chain LED’s together and address them individually or alternativly run them as single LED’s by sharing the same digital input.
The operating workflow:
Device connected to USB
Relevant COM port set in SkypeSignal.exe.config and application started on PC
A thread is started to run a small tray application on the windows task bar
A thread is started to subscribe to Skype/Lync client events using the client SDK
On client status change, a numerical command is sent down to the Arduino where it switches the light to the colour/pattern representing the presence of the user.
It would be trivial to add new features to this and I may look at adding some of these in the future:
Have the .NET app send a PING to com devices and using device on com port that responds with expected value
Flashing on missed notifications
Strobe + Audio Alerts on Incoming call (I’ve included a speaker in my version for future use)
Look at pulling the status over IP using UCWA to have a headless status device.
A quick note to those with Group Policy-based QoS for Lync/OCS that I thought worthy of a blog post:
The Lync 2013 client executable file name has changed from communicator.exe in OCS and Lync 2010 to Lync.exe.
So, why does this matter – If you are applying QoS DSCP markings on Lync traffic for specific port ranges for communicator.exe (using Policy-Based QoS), you’ll likely find no markings applied to Lync 2013 client traffic. As a result, there is a possibility that call quality can be reduced or other Lync functionality slow due to a lack of traffic prioritisation.
If you’re currently running a hybrid of both clients it would be worthwhile updating these GPO’s to add in the new executable name… or replacing it if you have finished upgrading 🙂 .
When deploying a Lync Server the other day I spent a good 15 mins (stupid me) trying to figure out why I couldn’t open the Lync CSCP control panel from the Lync Server – I kept getting:
HTTP Error 401.1 – Unauthorized
You do not have permission to view this directory or page using the credentials that you supplied.
I had defined an Admin URL when establishing my topology (and published it), plus I had set the appropriate DNS records within my domain to make the CSCP site resolve – still no Dice. I finally ended up trying from another server which had Silverlight installed… It worked!?!
So what was the cause?
Back in Win Server 2003 Sp1 (and subsequent versions of Windows) Microsoft introduced a loop-back security check. This feature prevents access to a web application using a fully qualified domain name (FQDN) if the attempt to access it takes place from a machine that hosts that application. The end result is a 401. 1 Access denied from the web server and a logon failure event in the Windows event log.
A work around for the issue if you really want to access the Lync CSCP from the Lync server itself (using anything other than https://localhost/cscp):
Logon on to the Lync server with an account that is member of the local admins group
Navigate and expand the following reg key “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters”
Right-click Parameters, click New, and then click DWORD (32-bit) Value.
In the Value name box, type DisableStrictNameChecking, and then press ENTER.
Now navigate to “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0”
Right-click MSV1_0, point to New, and then click Multi-String Value.
Type BackConnectionHostNames, and then press ENTER
Right-click BackConnectionHostNames, and then click Modify.
In the Value data box, type the host name (or the host names) for the sites that are on the local computer, and then click OK.
Quit Registry Editor, and then restart your server
You should be good to go 🙂
For more reading + another possible (and less-secure) work around for a lab environment see KB896861