About Me

My Photo
TsooRad is a blog for John Weber. John is a Skype for Business MVP (2015) - before that, a Lync Server MVP (2010-2014). My day job is titled "Principal Consulting Engineer" - I work with an awesome group of people at CDW, LLC. I’ve been at this gig in one fashion or another since 1988 - starting with desktops (remember Z-248’s?) and now I am in Portland, Oregon. I focus on collaboration and infrastructure. This means Exchange of all flavors, Skype, LCS/OCS/Lync, Windows, business process, and learning new stuff. I have a variety of interests - some of which may rear their ugly head in this forum. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. One of these days, I intend to start teaching. The opinions expressed on this blog are mine and mine alone.


SfB Patch/Upgrade Outline

Skype for Business (SfB) Server 2015 embodies several server-side enhancements beyond Lync Server 2013. The patching cycle for the SfB environment will need to be modified to allow for these enhancements. SfB contains five layers of servers, each of which will need to have separate handling:

  • Front End Pool Servers
  • Persistent Chat
  • Edge Servers
  • OWAS (Office Web Apps Servers) Servers
  • SQL Server and File Shares.

Host Server updates also need consideration – primarily because rebooting SfB servers can cause Windows Fabric errors that can affect the ability of the SfB server to recover into a running state.

Host Servers need to be patched to corporate standards; however, the application host servers cannot just be rebooted at will. Rebooting servers that host SfB services will result service outages and potentially in service failures where the servers may not recover services after rebooting.

Accordingly, phase one in the entire setup for patching SfB and related servers is to set the Windows Update to download but require administrator to install. For ORGNAME this may require moving servers away from containers to which GPO applies and controls WUPDATE settings.


This guidance will not apply to the SfB Edge servers as they are not domain members. However, the SfB Edge servers should be checked to ensure that the WUPDATE is set as shown.

Locate and download the latest SfB server updater from this site: https://technet.microsoft.com/en-us/office/dn788954 - as of this writing, November 2015 is the latest SfB 2015 update.  The consolidated server update installer is preferred over the individual updates. 

Note that the file name show is mostly correct, but that I rename them to help me keep track of what is what.


Place the update file in a separate folder on each front end, persistent chat, and edge server.  The update process generates log files which are kept in the origination location. Having a separate folder for each updater constrains the log file location and makes the entire thing easy to delete or verify later.

SfB Front End Servers


  1. https://support.microsoft.com/en-us/kb/3061064
    1. Find the section labeled: “Upgrade or update the Enterprise Edition pool that has at least three front-end servers” and READ IT.
  2. Read the following TechNet guidance: https://technet.microsoft.com/en-us/library/jj204736.aspx
  3. Then execute those instructions ONE SERVER AT A TIME.
  4. After each server reboots wait until ALL indicated services are running before moving to the next server in the pool. Keep in mind that these services are on delayed startup, and there could be a significant (10-15 minutes) delay before the SfB Front-End service starts.


SfB Persistent Chat Server

SfB Persistent Chat requires only that the services be running after the persistent chat server is patched and rebooted.


SfB Edge Servers

Edge servers are easy. Execute the serverupdateinstaller.exe on one Edge server at a time. Reboot if requested. If a reboot is needed, monitor the reboot process until the SfB services are restarted (about 10 minutes). Otherwise, verify the following services are running.


Do the next edge server.

Office Web Apps Server (OWAS)

The OWAS requires different handling from the other servers. See the following articles:

Assuming the two OWAS servers are hlbwowasp101 and hlbwowasp102, the following commands will recreate the OWAS farm when the time comes:

1. From server hlbwowasp101.corp.domain.com, open PowerShell as administrator, and execute the following (command wrapped):

    • new-officewebappsfarm -internalurl https://hlbsfbowas.domain.com -externalurl https://hlbsfbowas.domain.com -certificatename sfbwebext

2. From server hlbwowasp102.corp.domain.com, open powershell as administrator, and execute the following command AFTER the previous command on the other server:

    • new-officewebappsmachine -machinetojoin hlbwowasp101.corp.domain.com

After patching, reboot, and recreation of the WebAppsFarm, verify the following service is running on each server:


SfB File Shares

ORGNAME runs the SfB file share (\\corp.domain.com\sfb-fileshare ) on the OWAS servers. Care must be given to handling the DFS in that the entire environment is relying on the sfb-fileshare for various functions and downtime on the OWAS servers will affect all other servers. Other than the update process shown above, the OWAS servers should only be updated one at a time.


ORGNAME is using a single SQL server. This server should be patched along with the other SfB infrastructure with the following caveat: The SQL needs to be back online within 30 minutes or there will be impact to the users. The impact will be the clients entering “resiliency mode” due to the SQL server not being available to the front end servers. For more information, see this: https://technet.microsoft.com/en-us/library/jj205184.aspx.

If you have mirrored SQL or perhaps Availability Groups in SQL, then you will need to investigate the SQL patching process from a slighlty different aspect – namely, keeping the active node where you want it.


SfB has changed the patching process from how it was done in Lync 2010 and Lync 2013.  Each layer of the system needs something that is just a little different from the other layers of the system.



Netgear ProSAFE and Skype for Business

What are talking about today?

We all know how strapped the small business can be when it comes to resources. Staff, cash, cash flow, technical skills, and time. Another item is IP space.

When it comes to trifecta of IP space, cash, and technical skills, and then throwing the desire to have Skype for Business (SfB) deliver all communication modalities things can get a bit dicey. Between the need to communicate and the need to conserve cash, what usually gets hammered is the technical skills. So a pricey consultant is called in, who promptly tells you that you need to spend huge wads of cash on a firewall that will accept and deal with larger IP address space. This is counter-productive you might think, and you would be right.

But, Netgear has some answers, and combined with some judicious telecom provider shopping, you may be able to find the answers in the form of a /29 CIDR block.

I won’t try to answer all the questions here, but I do want to illustrate the configuration of the Netgear ProSAFE to support SfB. My issue is that the stock documentation for the Netgear ProSAFE is a bit shy on details. Past the statements that it supports multiple IP’s there is not much in the way of “how to do it” and if you think your ITSP provider is going to help, think again.

Tsoorad to the Rescue

As you might have guessed, Tsoorad.net falls into this category. First off, I am a cheap ba$tid. Second, I have particular needs what with the technical lab and all. Finally, I face the ca$h situation just like everyone else, and when combined with “first off” I decided against purchasing the more expen$ive “indu$try $tandard $olution$.” Still with a bit of reading and learning and poking your nose where the vendors don’t want you to poke it, you can make your system play well with others. I will NOT cover the SIP trunk provider or the reverse proxy stuff here; that you can get elsewhere in other articles.

IP Space

SfB, if you want the full suite of operations and features, is going to require a minimum of two (2) public IP addresses. No way around it. One (1) for the external side of the SfB edge server, and one (1) for the reverse proxy. You can do away with the reverse proxy address, but you will give up inviting outsiders to your web conferences and forget about your mobile clients working. As a side note, you may be able to piggy-back your reverse proxy needs onto an existing IP with 443 and content redirects, but that is usually well past internal SMB technical chops and will have you calling in a provider or con$ultant.

If you want to investigate the minimum IP requirement solution, see this section of the SfB documentation. You can also work up this requirement using the SfB Planning tool. For those tech heads out there, you should be reading this first. Adelante!

The biggest problem with the minimum IP space solution is using port 444 for web conferencing. In my experience, most larger environments will not allow port 444 outbound willy-nilly. Which will mean that crucial web conference that you are hosting on your minimum IP space solution will most likely not have any large corporate attendees.

Enter the /29

Offering 5 usable addresses, the /29 CIDR block is the smallest block that is usually provisioned by providers – other than giving out singles. I use a /29. One IP for general use, one IP for my SIP trunk with Intelepeer (they are great), and three for SfB. For my lab use, I have Office 365 in hybrid, and I also bring port 25 into one of my SfB-assigned addresses and use the firewall to pick off the SMTP traffic and send it to the proper internal server. Works great, less filling. And yes, the Netgear ProSAFE can be configured to support all of this (see how I worked around to the beginning thesis?)

ProSAFE Configuration

Ignoring the unboxing and basic connection steps, the first thing you need to do is configure the firewall for your public IP space.


Next, you may wish to change your things to match your internal subnet to which you are connecting.


Now onto the real fun

SfB has a variety of port requirements.  You can refresh your memory here. Assume the following

  • IP #1 = SIP
  • IP #2 = WebCon
  • IP #3 = AV
  • IP #4 = reverse proxy

So, IP #1 needs TCP 443, 5061, 5269.  Depending on your DNS source, opening TCP/UDP 53 may be needed – this is the for CRL check.  IP #2 needs TCP 443.  IP #3 needs TCP 443, UDP 3478, and optionally TCP/UDP 50,000-59999.  Simple, right?  IP #4 needs TCP 443 and 80.  If you are confused about the 50k range, see this.  Nothing has changed here since Lync 2013.

The Netgear issue

Netgear, like any firewall, blocks by default.  So we need to poke some holes.  Netgear, like almost everyone else, also provides some predefined services – and you can use them; like HTTPS or SMTP.  No sense in re-inventing wheels, eh?  The other issue with the ProSAFE is that ALL traffic, by default, goes OUT on whatever IP you assigned as the device primary in that first screen shot.  The solution here is to create outbound bindings so SfB traffic goes out on the IP that is expected.

Create Services

Because we are going to use the pre-defined HTTPS service, here is what is needed.  I feel that the construction of these services is very self-explanatory.


Inbound/Outbound Services

So here is where the rubber meets the road, or, to not mix metaphors and to maintain our focus, where the electrons meet the transistors. When creating your new outbound rule, what you need to know in advance, is what your NAT is that matches the service to the IP. Enter an IP that is valid for the your CIDR mask and it will work.  Typos count against you.


For the inbound service you need to know the exact same thing, and guess what, it looks pretty much the same.  A few things of note here.  First, you need the NAT information in advance.  Also, see the “WAN Destination IP Address:” thing?  This is where the Netgear documentation falls flat.  Doing multiple IP is simply not mentioned as to HOW.  But here you go.  Enter an IP that is valid for the your CIDR mask and it will work.


OK.  Now that we have that sorted, here is the full outbound rule set…


…and the full inbound rule set.


But wait!  The sharp-eyed critic will notice that the rules appear to be doubled-up for the HTTPS and TCP/UDP for WebCon and AV.  Yes, they are.  Inbound rules are dependent on External DNS resolution, and the outbound rules are dependent on the sending entity having an IP that matches the rule.  I keep my lab ready to demonstrate for the unbelievers that doing a single IP SfB (or Lync) edge will result in THEIR environment not being able to connect to a web conference hosted on a single IP Edge server (because of the port 444 thing).  Which usually brings them out of the dark into the light which is the greater good. I can live with some topology builder work and some server re-ip – it only takes a few minutes, and saves much teeth-gnashing later.  And the firewall don’t care if it has a few rules that aren’t in active use.

Furthermore, the really critical reader will complain that I have said squatoosh about the reverse proxy in all of this.  Here’s why:  Inbound rule #4 lands on my HLB, which is, by definition, a reverse proxy.  I bring ALL miscellanous web traffic for my domains to this one address, land it on my HLB layer, and use content redirect rules to parcel things out to the appropriate target service/server.  Works very nice, is totally less filling, and makes me wonder why anyone does anything else.

Let’s Wrap This Up

Netgear ProSAFE can be a great solution for the smaller SMB.  Skype for Business can also be a great solution for the smaller SMB.  But, to get all that both offer, you need to dig a little deeper than just throwing things at the wall to see what sticks.  Single IP Edge works, but it may not be the best choice.  Finally, we demonstrated how to make a ProSAFE work with a CIDR block, and also showed the rules needed to enable all of SfB through a ProSAFE device.



Skype Office 365 File Transfer

We all know and love file transfer within the Lync 2010, Lync 2013, and SfB client.  OK, while you may not think it’s so hot, *I* love it.  Therefore, YOU all love it too.  Simple logic.  No?

The Ask

At any rate, I was recently asked to kill two features in an Office 365 Skype for Business deployment.  To whit, the conversation history, and surprisingly (for me) the file transfer.  As you can guess, some legal issues come into play here, and compliance dictates that these features be off.

OK, the first was pretty easy. If you do some google-fu (bing-fu works also) on “Disable office 365 Auto Archive Skype” you will surely find this article. You should have no problems doing this little magic trick.  Even my shadow did it very well.

But, let’s talk about disabling the file transfer.  As we all know, file transfer is part of the conferencing policy granted per user.  OK, but I don’t want to apply a conferencing policy to each user as we migrate them up into Office 365, or at least I don’t want to do it one at a time via the GUI.  Maybe there is another way?  It turns out that maybe there is – or not.

My first effort was doing this:  In the Skype for Business Office Portal, under the users, and having a user selected, uncheck the indicated item.  See this for reference.  You can see why I tried this.


Guess what, it don’t work.  Don’t know why, but 24 hours later, the users we tried it on were happily doing file transfers and thumbing their noses at the corporate legal hacks.  If you read my reference up there, you will also note that this is one user at a time, AND wants a hold via Exchange to be placed on the user.  Another solution was needed.

The Solution

Thinking to identify which conferencing policy to use, if you do a remote powershell into your Office 365 tenant, and then a get-csconferencingpolicy you get the following list from hell – none of which you can change. I changed my font in PowerShell to get as much into the graphic as possible, and I still don’t have them all there.  You get the idea.


There must be a better way.

Enter, stage right, the Knower Of All Things, Bob Wille, who pointed out to run

get-csconferencingpolicy –applicableto –identity

which works out to this for my North American user object:


Way better.  Again, font reduced to fit things onto screen, and at least this time they all fit.  And, you are welcome, I have highlighted the one to use.

Now, a simple

grant-csconferencingpolicy –policyname tag: BposSAllModalityNoFT –identity martin.luther@tsoorad.net

and we are done.  And for your information the above line has a space between the ‘:’ and the “B” because of the totally unasked for emoticon that combination creates Sad smile.


You can also imagine that doing a get-csonlineuser and piping that into the grant-csconferencingpolicy would quickly apply this to all of your users.


Inter-pool Dial in Conference Transfer (SfB)

The Scenario

Doing an upgrade of the entire environment, Lync 2010 to Skype for Business Server 2015 – on-premises.  The existing dialin conferencing was ITSP to Avaya 6.3 SM to Lync 2010 Mediation server.  In this case the mediation servers were a separate pool from the FE pool.

The Issue

When we moved the first pilot users to the new pool and then tested against use cases, the dialin conferencing failed.  Oooops!  Some tracing and sharking of wires, along with looking at the client-side logs was pretty clear.  The call landed on the Lync 2010 mediation server just fine, the conferencing attendant on the Lync 2010 FE (and the proper one at that) picked up the call, but then promptly dropped the call during the conference identification phase. 

The Fix

I have seen this issue before, back in the murky days (daze?).  But usually you see this with simul ring or call forwarding out of the system to the PSTN.  See this here for some background.  I had thought this was fixed in Lync 2013 as I had not seen this for a long time.  And then, for some reason I thought it had been fixed in SfB.  But, apparently maybe not.  And specifically, if you are doing 2010 pools to SfB pools.  See this here for the exact error (or at least a reasonable approximation).

So off we went to the trunk configuration, set the refer support to NONE, and magically our dialin conferencing calls worked as expected.  We got by with doing the global trunk configuration, you may need to be a bit more granular.




VMware and SfB/Lync

In attempting to answer some customer questions, I ran across this document from VMware.  Interesting reading, don’t know why I have never seen it before, but maybe the rock I live under blocked the transmission…


SfB Conferencing Fails

Disclaimer:  While I found the failures, I did not initially get the fix.  When I saw the fix, I then remembered what I had forgotten.  Dang do I hate it when that happens.

The Scenario

My current project is to replace a seriously ill Lync 2010 deployment with SfB.  As part of Phase 3 of this project, we will be doing full EV and HA/DR.  All in all, an interesting project.
We had the SfB pool installed, and finally we got all the bits and pieces of the network, firewalls, and load balancers done the way we wanted them to be done (with the attendent convincing of network and security teams that we really did need things to be the way we wanted)(and that the errors we were seeing in the various layers where mis-configs on the network, firewall, and HLB layers) so we could move forward with doing the basic client tests.  And from there, move to the more complex testing.  Alas, this did not go so well.  And finding the fix proved to be a bit trying.

The Error

When a user moved to the new SfB pool, no conferencing worked.  This means that 1:1 worked OK, but moving to three or more users in conference bombed immediately.  Some careful testing revealed an “error 500 source 329” which I have seen before, but associated with voice calls.  MVP Greig Sheridan has a nice error message blog.
Oddly, the SfB user could create a meeting – joining which failed miserably for users on both sides of the environment.  Moving the user back to 2010 resulted in the meeting working. 

The Culprit

Because the customer did not want the 2010 environment to be fixed, we did not go past validating topology before we started SfB installs.  What we found was that the customer had never cleaned up the conference directories.  And what appears to be true for the 2010-2013 migrations apparently still holds true for 2010-SfB migrations.  To whit: having an orphaned conference directory screws up 2013 (and SfB) but not 2010.  You can read the baseline stuff here and here.  While these two references don’t exactly match what we were seeing, they were close enough to get the stupid out of my system and allow me to move forward.

The Fix

In my case, I removed the orphaned conference directory with a remove-csconferencedirectory –force command, which I sort of thought might fix things.  But I also had to run (on each SfB front end pool server)
  • enable-cscomputer
  • bootstrapper
  • rebooted the entire mess.
Retesting was flawless.


O365 E5 Licensing

It appears that Microsoft has gone somewhat live with their pricing structure for the upcoming E5 licensing.





Avanu WebMux Review

Here is a new twist on an old friend.  The Avanu WebMux line of hardware load balancers has been around on the approved list since, IIRC, OCS 2007 R2.  Here is the ancient link to that listingThe Webmux is also on the Lync 2013 OIP listing.

Avanu offered to let me try out their hardware and virtual appliances; so naturally, I jumped at the opportunity. Avanu first sent me a piece of hardware, an A500XD, which I will not specifically make detailed comments about, other than these two semi-humorous notes.

  • OMG, I have a 747 in my office!  This thing needs to go into a server room, or at least away from me!
  • Power Supply out/failed tone.  The alarm will wake the dead.  Removing the failed/disconnected power supply turns off the zombie alert, leaving you with just the 747 taxiing out for takeoff.

The A500XD oozes build quality.  A very nice piece of gear from that perspective.  And wicked fast. But, I am living in a mostly virtualized world, so Avanu sent me their virtual appliance, which they assure me (and I verified) that the interface and operation aspects of the virtual match that of the physical hardware.  So the remainder of this short article will focus on the virtual appliance and how it might work with Skype for Business Server 2015 in your environment.  You can do some light reading on the Avanu Virtual WebMux here.

Network Environment

Here is what we are going to walk through:


Pretty simple, yes?  Even so, Avanu has provided their WebMux with a set of wizards that will do most of the work for us.  So, first, let’s step through the basic networking of the applicance to get it into the environment, and then we’ll take a look at the wizard for SfB to see how that functions.

After downloading my VMDX/VMX files, and opening them with vmware, we get our first look at the virtual appliance.


I sent a quick note to the fine folks at Avanu tech support over the size of the disk… seemed small to me.  But, this is correct.  Very small footprint.  Makes me wonder what the other vendors are doing that requires all that drive space. 

But wait, it gets better.  No DHCP support, so the WebMux comes up on static addresses… and to be exact.  But which interface is which?  I learned more Linux figuring that out.  What you get in the vmware console is this:


Not exactly helpful for someone trying to figure out IP, eh wot?  But, in the best sysadmin tradition, I persevered.  It turns out that “ifconfig ethf0” and “ifconfig ethb0” gave me the existing IP (which are listed in the documentation)(but, which to paraphrase Alfred E. Newman, “What, me read?”) Ha!  For you intensely curious types, I  have vnet0 set to the net and vnet7 set to the net, and those are set to the first two virtual NICs for the WebMux vmx…




All of that got me to the web-based UI, so that humans (not to be confused with Linux admins) can configure the WebMux.  There is a CLI available that can whip the WebMux into shape, but dang, I am Mr. Visual.  So, we got to the GUI.

Basic Setup


You may note that I took this screen cap after I set the IP up to match the actual network.  And oh yes, you will need to educate yourself on the various network choices and their definitions.  You mean you did not read the link up above?  Here it is again but focused this time on the “Arms and Architecture” section.  If you are following along (and reading the (*&%$ doc) note that the “two-armed server LAN NAT” selection REQUIRES you to have the WebMux be the GW for the farm real servers.  Note down below that I chose for this – not a real address for anything else on my net, and one that the WebMux can float between HA instances if need be.  But, if your first efforts fail, remember that I told you to set the real server gateway to the WebMux impersonated IP.  I will wait whilst you digest that statement.

OK, so we need to choose “two-armed server LAN NAT” – got it.  And all the rest should be fairly obvious; well, it was to me.


With that out of the way, and after the reboot, let’s take a swing at the aforementioned wizard configuration.

SfB Wizard Configuration


I am going to choose the “Skype for Business” option..


This is so easy, even *I* got it right the first time…but here goes.


On to Step 2…


Step 3…


Step 4…I am a solo, no HA…so it looks like this:


Step 5…


Step 6… I don’t use the Monitoring Port, so I will use the default…


Step 7… Submit the configuration.  Yes, part of this will simply duplicate my network configuration work, but if you don’t get access to the WebMux in the first place, then you could not have gotten to this wizard unless you went through the “change the IP on a workstation” bit… chicken and egg scenario, but that is what we have to work with!


oh my, it’s rebooting!


And here we are:


Pretty slick.  If this meets your needs because your firewall is doing all the port redirects for you, then perfect. But what about the aspects of internal versus external?  I just did the external…and I need the 443 farm to be on the network and the external to come in on 443 and attach to the real servers on 4443.

Looks like the wizard might not be what we want, eh?  So we’ll have to do this manually!  Oh joy.  Luckily, this turns out to be dirt simple.

Manual Setup for SfB Basic Stuff using Two Nets

First, I blew off what the wizard put in for me.  I did not like it, and it only did my external stuff.  When I tried to run it again for the internal, I got only internal.  The reason seems pretty simple; the wizard appears to be doing the entire WebMux configuration and once things are in place, running the wizard again appears to re-configure.  Ooops!  Well, no matter, I want more control anyway.  And specifically, 90%+ of my workings will have an external facing subnet and an internal facing subnet, with certificates in both directions, so I need to know how to do this thing manually anyway.  And then wata-shi-wa get’s to be in control.  I am all about control  My SO says TOO controlling, but I let her go shopping every third month, so I think she is over-reacting.  Adelante!

Here is what I ended up with and working as expected:


A regex note

To do content redirects, you will need to get some content rules.  Here is where things get a little different – just like all developers everywhere, “they” followed a different “standard” so things look a bit “off” from what I am used to.

You want to do a host name filter you should use the "layer 7 host MIME header perl regex match" field since the host name requested by the browser is in the host MIME header of the HTTPS request.  The URI regex match field is for matching strings following the host name portion which you don't need in this case.

An example of a match pattern to allows all hosts in a specific domain would be: ^.*testing\.com$

That will allow all hosts for the domain "testing.com" to pass through that farm.

While putting together the virtual servers, keep this in mind: 

  • Each IP/Port combination must have it’s own virtual server.
  • Real servers MUST have their gateway set to the core IP of the WebMux
  • WebMux must be in Two-Arm NAT mode
  • When adding a farm, choose “service: generic no health check (TCP)”
  • The farm gets the core port, the real server gets the tranlated port (443 –> 4443 in the case of SfB)
  • If you want to do SSL other than a straight pass-through, you will need to remember that WebMux is a linux box, and it acts like one.  Holy moly!  To get your cert up into the WebMux is going to be pulling teeth.  I suggest you call them – the most excellent support folks up in WebMux-land were very helpful – and will do all the work for you if you wish.  You can read up on it here: http://avanu.com/webmux_ssl_certificate/ 


The WebMux, even in virtual living on my strapped-for-resources lab, was wicked fast.  Really excellent throughput and admin response.  The linux-based certificate goat-rope exercise was a royal PITA; but the Avanu folks are very helpful with working it through.  The WebMux is very granular.  Planning before jumping off the cliff is strongly recommended.  Did I mention the WebMux is wicked fast?



Kuando BusyLight Omega


It turns out that Kuando Busylight has a new version, a new look, new software, and one showed up at my door to greet me the other day.  Very nice to get toys with which to play.  Even better when I can say “Skype for Business” during the review – sort of ties my life together, eh?


The official name for this nifty piece of kit is Kuando Busylight UC Omega.  Dang.  Long name for a small thing.  But this small thing does a big job!  For those office environments where your co-workers are always walking up and yakking at you or interrupting you whilst you are already in a call, this device will visually keep those nearby to you, and maybe even into the next county, alerted to your status.

Just in case your browser doesn’t work so well, here is the official list of features:


I use all features except 6 and 7.  I don’t use 6 because I be an Amerikan and only need Englais.  #7 is unused because I have full admin control of this laptop and have no need to push settings to client machines. But, nice to know it can be done.


The only bad news is that what I got here is not quite available…yet.  But to whet your appetite just a smidge, here is a nifty screen cap of the unit in question.


Notice the new shape.  The whole thing lights up.  Well, not the whole thing, but the white-ish parts certainly do.  And bright.  So bright my humble cell phone camera cannot handle the colors.  To demonstrate, here is “DND” and “Available.”  In person, green is a nice bright hue and the DnD purple is extremely visible. But, you can see the color reflecting on the laptop.



SfB Features

Ring tones (that work), lights that alert (and are visible), and while the toast in SfB is visible, the BusyLight’s visibility is a much better experience.  Kuando also has a few enhanced features:  BUSY ON BUSY (woo hoo!)(finally), and missed call notification.  Short of posting video, there is no way to show this feature.  But, the BusyLight pulses blue to indicate a missed call or IM.  So, if you have your presence set to BUSY (red), then the BusyLight will pulse blue every few seconds to show a missed conversation.  In the last two weeks, this feature alone has saved my beau-tocks at least twice.


All this goodness does create a need for a software driver so that the BusyLight can do its’ stuff.  A quick download, followed by an easy install, and you are up and running.  Here is the software download.

After install, you have an icon in the system tray area:


Here are the menu options. As you might expect, the “sound” options are different ring tones and well, duh, the volume.  Bear in mind that this is for the BusyLight and does not affect the actual Lync/SfB application.


The “Colour” (note the EMEA spelling) controls the color of the Busylight.  And the BusyLight is intense enough that when you have “Busy in a a call” red pulsing away, it catches the eye - your cube buddies will definitely see it.  The remainder of the presence colors (note the Amerikan spelling) follow the Lync/SfB client presence colors.


“Notifications” is where I really like the improvements.  If the intense color, loud audio alert, and the flashing are not good enough for you, here is the compelling piece.


The BusyLight will tell you if you miss a conversation.  I have missed IM set to just flash.  But you can get audio also.  The “Missed conversation” is the part that flashes your presence indicator with a blue blinker if you miss something.  So nice for those of us who are head down and concentrating on multiple screens and just miss the toast.  Or, in my case, maybe you stepped out for some coffee.  Returning to my desk I can see the BusyLight flashing a miss.  Sold.

Last, but certainly not least, and another compelling purchase reason, Busy on Busy (BoB).


BoB is on or off.  Here it shows enabled.  My only complaint is that this thing is so good, I had to go into my call forwarding settings (on the SfB client) and increase the delay time (to 30 seconds) so that I have a chance of getting to the answer button before the BusyLight caused the incoming second call to divert to VM.  Note that you can also set custom hot keys for dial and answer.  Sweet.



I am not giving my new BusyLight Omega to anyone.  It is MINE.  You can go here http://www.busylight.com/busylight-omega and get your very own.  At some point (hopefully very soon) the various vendors will have them too.