Populating the Lync LIS database with Meraki BSSID's, but where are they hiding!?!

If it’s never setup then you don’t miss it, but once you’ve started to use it and have it embedded in your culture it becomes invaluable. What am I talking about? Presence? Well of course – but what I’m talking about is the Lync Location Database.

As I’m in the UK we don’t have to worry about the E911 service here and where I have seen it the most is for seeing where someone is within a building/campus.

Usually the main thing that you use to differentiate the network you are on is the IP address your host has - different subnets for different buildings. But the other powerful area is to have your location automatically update as you move between wireless access points ("Tobie is in meeting room 5").

This is achieved by finding the BSSID of the access points in you organisation and then using the Set-CsLisWirelessAccessPoint PowerShell cmdlet and supplying the relevant details.

Recently a client moved from an HP ProCurve network to a new Meraki setup. This meant that all of the BSSID’s that where in the LIS database where now redundant and needed to be repopulated. But – where to get the BSSID’s from? In the ProCurve Wireless Edge Services controller you could see them but the Merkai dashboard does not show them (I’ve added it as a feature suggestions so hope it gets included in a future sprint), so instead you need to do some extra work.

I emailed Meraki support a few times and didn’t get a satisfactory answer on how to ID the BBSID <> AP relationship so eventually picked up the phone and got through to a brilliant techie, who after explaining my problem found some information in an internal Cisco document that shows how the BSSID is created:

2.4 Ghz (r0): +02x0 to 1st octet; +40x0 to 3rd octet
5 Ghz (r1): +02x0 to 1st octet; +50x0 to 3rd octet
1st: No change
All others: +01x0 to 6th octet for each subsequent SSID

2.4 Ghz Radio 5 GHz Radio
SSID 0 02:00:40:00:00:00 02:00:50:00:00:00
SSID 1 02:00:40:00:00:01 02:00:50:00:00:01
SSID 2 02:00:40:00:00:02 02:00:50:00:00:02...

So what does this mean? Well, first you go to your Meraki Dashboard, navigate to:

Monitor - Access points

and grab the following information:

AP Name and MAC Address

Access Points and MAC addresses in Meraki

Now navigate to Configure - SSID and click Show all my SSIDs (you need to do this as this shows which slot your wireless network is in, the first page shows configured ones but not necessarily the slot that the wireless network occupies):

SSID's shown
You can now perform some old school masking by hand to try to sort out your network......

........or use my handy Excel Spreadsheet to do it for you automagically (thanks Daniel Mycock for helping to write the magic).

Simply add in the names and MAC addresses into the table and select the "slot" that the SSID is in from the drop down (green box).

Once you have done so you will now have the BSSID's to create your PowerShell with:

Throw that onto a server and get it working by publishing the Communication Server Location Information Service Configuration.

Now wait for the management store to replicate (thanks for the script Graham)

and log into a client to see the resulting network working :-)

Hopefully this gives enough information to get your LIS databases up to date with a Meraki network.

Sophos UTM when running on clustered Hyper-V 2012 R2 (or why is Linux is different?)

Originally my post was going to be about how painful it was working on a bug in the Sophos UTM virtual appliance. But after doing some digging I’ve realised I need to point the fingers in a different way!

What caused me pain was this:

Build a Highly Available VM using latest UTM download from Sophos (4x network cards and shared SMB storage in our case).

After built go into the console (loginuser and then su to root):
ifconfig | less

Note the eth network cards that are available
Live migrate the UTM to another host in the cluster
ifconfig | less

Note all eth network cards have now disappeared

Live migrate back to initial hosts
ifconfig | less

Note eth network cards have not come back

The system will continue to run and can be moved around hosts with no problems. The issue will only manifest itself once the UTM gets rebooted (in my case for an Up2date firmware fix).

After building a new UTM VM I did some testing to replicate the problem:

First thing - lets shut the VM down, move to the other host and bring it up, maybe the bug is in the Live migration.

Unfortunately, no, exactly the same problem, no eth cards.

A-ha I thought, so lets shut the VM down and move back to the initial host and bring it up, maybe it’s a bug in the network card stack so the cards will magically come back.

No, cards still missing

So at this point I was speaking to Donald at Sophos technical support (top guy, many thanks to him) and we had come to the conclusion it was a bug in the Linux kernel that the UTM uses.

He was going to add a bug number in and I was going to leave the UTM sitting on a single host with instructions to never move it!

And there might have ended the story and I would have gone away thinking that I’ve found a bug but I started to do some Googling Binging and hit the answer……

Those of you who have been using Linux on Hyper-V will have seen the problem straight away.
(for this part please forgive my lack of Linux knowledge, this is how I see the problem – but I really don’t want to start a flame war!)

And it’s all down to how Linux binds its network cards to the MAC address of the virtual machine. Windows boxes will happily use any MAC address it is given on boot whereas the first MAC address that is given to a Linux box will get hard coded into the config files and will always be used. This means when the virtual appliance (because to me that what it is) migrates between hosts the MAC address changes and Linux gets unhappy.

I’m sure that there are some people who will read this and say “surely you should have read up on the Microsoft documentation for running Linux in Hyper-V

I’ll counter with, “nope, I was running an appliance. Not a Linux box so had not thought of even reading up on this, and don’t call me Shirley

My plea to vendors who say that they have an appliance that will run in your virtual environment is that they make it clear in their documentation that this could happen so other hapless “Windoze” geeks like myself are not caught out in this way in the future.

And me – I destroyed my VM (for the 5 time!) and rebuilt it – this time with the MAC address set to a static address (side note: if you do not type a MAC address after setting a static one then Hyper-V will assign you one automatically) and live migrated my Linux VM Appliance to my hearts content.......

……..or so I thought: By setting the MAC to a static MAC on our WAN interface stopped all traffic over the WAN, so with time against us we had to set the WAN back to being dynamic, this means if the UTM moves hosts it’ll need a reboot and config changes to get the WAN interface back onto a the virtual NIC……

The story will continue if I get an answer back from Sophos prior to me moving to my new job!