About Me

My Photo
TsooRad is a blog for John Weber. John is a Lync Server MVP (2010-2013). 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, 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.


Project Failures

Disclaimer: I have no idea who authored this blog, or which organizations website hosts the blog. 

As I read through the following article, I was faced with the classic introspection question: how does each of these apply to me?  http://calleam.com/WTPF/?page_id=2338

In the midst of some business process research I ran across this and it proved to be very interesting reading.  As a consultant, I participate in both sides of the sales process and on all sides and phases of project delivery.  I found comparing the failure attributes to projects in which I participated was very insightful.  Not every reason listed may apply to every project – but the level of detail and the implied attention to detail required of the consulting engineer is an excellent starting outline for necessary professional skills,and demonstrates the depth and breadth of knowledge and experience required to successfully deliver IT projects.



Lync 2013 Server 2012 replication issues

A slightly different twist on an old issue


I had a client using Windows Server 2012 as the OS for a Lync 2013 deployment.  Replication between the Edge and the Front End Enterprise Pool was not working. Everything appeared to be set correctly, you can browse to the replication location for the Edge (https://serverfqdn.domain.com:4443/ReplicationWebService), you can telnet to the Edge server on 4443.


The Fix

We are using all public certificates from a well-known CA (GoDaddy), so the certificates not being trusted from domain member to non-domain member was clearly not the issue.

After a bit of searching you find that adding some registry changes to the SCHANNEL on the edge servers and the Front End Pool members will resolve the issue. 

Like so:


Or, for you PowerShell freaks out there: (lines wrapped)

New-ItemProperty -Path HKLM:\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\ -Name ClientAuthTrustMode -Value 2 -propertytype "DWord"
New-ItemProperty -Path HKLM:\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\ -Name SendTrustedIssuerList -Value 0 -propertytype "DWord"

If you want to get real fancy, you can affect multiple domain servers using remote PS.  For my current project I did this for 20 servers, 12 domain members and 8 out in the DMZ.

$credential = Get-Credential -Credential domain\user
Enter-PSSession -ComputerName FQDN -Credential $credential
New-ItemProperty blah blah blah
New-ItemProperty blah blah blah

For you reg /s fans, copy the following to a handy file of your own with a .reg extension and click away.

Windows Registry Editor Version 5.00


As always, YMMV


Logitech ConferenceCam CC3000e review

I have been living the good life.  As proof, look what showed up at my door!


Seeing as how I am feeling a tad lazy, here are the official specifications.

What comes in the box


Looking at the contents of the box, we can see that this will not be the simple task I first thought.  Taking a quick inventory shows that there will be a least one session of “build this thing” and another of “how does this work” followed by “where to put this thing.”  Luckily, I had my handy-dandy Setup Guide that also came in the box.  But first, I will of course, attempt to assemble it without reading the Setup Guide; after all, what fun in life if you can’t ignore the instructions just once in a while?  And who knows, I might get it first try.  Hey even *I* can follow these instructions!


OK, I am back.  Not reading the instructions appears to somewhat successful.  I got the electrical part figured out quick enough (go me!) but the bracket thingy with Velcro pads and other mediaeval accoutrements got me puzzled.  It turns out the bracket thingy is wall mount; nice bit of thinking ahead, Logitech.  Having already cheated once, it became much easier.  So I gave in and read the instructions.  There, I said it.

Cables for the system are quite long – allowing me to place the various components where it made sense to my office feng shui.  Using the cubit and hand method, the camera and control unit cables are a good 18 feet long (the “official specifications” say 16 feet – OK, I believe them.  But my method is more fun). The power cable is a good 10 feet also (appreciate the included cable-ties.  A nice little touch). Clearly, the target implementation of the CC3000e is not your office cubicle.  This thing is meant for a medium sized conference room.

It Slices, It Dices…

Initial setup into my laptop did not go well.  When I plugged the unit together, the camera did the R2D2 thing, when I plugged in the USB, the camera did its thing again, but then I got this:


Uhm….I checked the box again.  Yes this is a Logitech.  And Logitech not working with USB is sort of unheard of.  Sure enough, from the Logitech support site comes this nugget.


Looks like I will be rebooting.  After a reboot, all seems well. I have to say, that is the first time I have seen that little routine from a Logitech USB device ever – so I will chalk this one up to my laptop being sideways (and it has been since the last round of Windows and Office updates).

A few more run-through gyrations with disconnecting USB and getting Skype out of the way and things were looking pretty good. I now have the following in my Lync client.


Now let’s do a little test video call just to see what is what.  Audio quality is the expected excellent.  Good tone, good volume.  I can see this unit filling a medium conference room.  I bet most folks would miss the the satellite microphones you find on most conference room units.  But in my test, the volume and pickup even from across the room (10-12 feet) was very acceptable if not excellent.

I could play with the R2D2 camera head for a long time.  The remote has full control, and according to the setup guide, you can do “far end control” also but that requires a small download.  I did not do this, but I expect that the ability to control the camera from something other than the remote or the base unit might be warranted in a situation or three.

Field of view at about 10 feet is pretty nice, great resolution on the camera, and did I mention you can play with the zoom, pan, and tilt via remote?  Fun!  At any rate, with me (the dork in the red hat) in the frame for sizing, you can see where this unit will cover the FRONTAGE of a conference room let alone the long axis.  Pretty nice, IMHO.


At this point, the zoom can also be demonstrated…


I had it pointed at my whiteboard across the room, but I did not want to erase the board, and it was FULL of secret squirrel data, so you will have to take my word for it that from across the room, the CC3000e will easily resolve a whiteboard.

Bottom Line

Lync integration, once I got past my laptop’s USB psychosis, was seamless.  Lync simply views this device in a native state and uses it for a speaker phone and a video source.  With a remote.  All with that wonderful Logitech build quality.  For my tired eyeballs, the video quality was also excellent, good field of view, detail resolution is wonderful; but there could be some time spent with contrast controls – as you can tell from the pictures, the overhead lighting coupled with outdoor daylight played hob with the contrast (see the pictures above).  As far as I can tell, Lync and the CC3000e pair up very well.  Skype also seemed to think that the CC3000e was pretty slick.  Even with my lack of reading skills, the total time from ‘open box’ to doing a full Lync conference call with the CC3000e was about than 30 minutes. 

If you are wanting a low cost solution for those mid-size conference rooms and don’t want to spend a small fortune, the Logitech CC3000e should be on your short list.

You can get one right here.



Unable to launch device manager

ASA ADSM won’t launch.


and then this:



I read numerous articles.  I went through the upgrades and downgrades of Java.  I did the various CLI on the console to enable the http, make sure the subnet I was on was authorized connection per the interface I was on.

Then I read some little blurb about Firefox.  D’oh!  Immediately worked.

Chalk up another one against using IE v anything.

Sad smile



NextHop Archive


If, like me, you have stretches of your life where you are living under a rock, you may have missed the notification that NextHop is being moved and phased out.  As noted in this article posted on NextHop 1 May 2014, NextHop content is frozen, with no new content to be added.  While there is a stated plan to migrate SOME NextHop content to its’ new home, I think it is very possible that not ALL content will migrate.  In addition, there are sub-contents (such as DrRez) (and the absolutely awesome Haiku material) that may not make the jump.

In an effort to preserve this data, I archived the entire NextHop site.  DrRez included.  You can find the archive here:




AudioCodes 440HD SIP Phone Review

I have been working with an AudioCodes 440HD SIP Phone for a few days now, and am finally prepared to make some comments.

Background Reading

First off, let’s look at the market-speak.  Here is the official blurb. And you may want to review my comments vis-à-vis the AudioCodes 420HD which will save me from repeating my comments on build quality, audio quality, and Lync support.

image [image%255B3%255D.png]

(for those who need to be told the 440HD is on the left)

The biggest difference between the two unit is the obvious; a built-in side-car with 12 programmable buttons which allow you to pre-set speed dials.The display is also larger; although not in color or touch. Me, and a bazillion other folks in this world like color.  Except that color and touch costs.  And the LCD functionality of the 440HD is clear, crisp, and legible.  And touch screen phones that I have had the privilege of using are sometimes finicky, picky, and near schizophrenic when it comes to the touch screen.  The 440HD is none of that.  The buttons are large, well-marked, they light up, and pushing the button elicits the response you expected.  Overall, a compromise solution that I understand and endorse.  Well done, IMHO.

A Few Gently Worded Observations

On the plus side, the built-in switch is GbE.  Sweet!  In addition, the 440HD will support the upcoming BToE firmware.  For information purposes, my 440HD updated itself to the newest beta BToE firmware with very little effort on my part.  I dropped the image into my FTP, and on the next power-cycle, the 440HD updated itself.  Painless. 

According to the official user guide, the 440HD also has a built-in busy-on-busy feature.  As a comment on the “official documentation” I will note that the screen caps in the documentation do not exactly match the displays on the phone.  But they are close enough to enable someone with more than a few operational brain cells to figure it out.  Having only two of those myself, I had to read stuff twice to make sense of it all.

Here is the doc


And here is the actual device


I strongly recommend reading the user guide, with 6 lines, 6 multi-function keys, 4 programmable keys, and 12 speed dial keys, the number of options on how to use this Lync phone, if my math is correct, approach the 1440 level. When you throw in the idea that you can also set sub-options, both of brain cells started to overflow. If that is not enough to cause your users to ask questions of you the expert, I don’t know what will.

Like the 420HD, the 440HD also supports location information; if your Lync environment is configured for location, you can choose a location as defined by your administrator so as to support E9-1-1.  Convenient if you want the emergency providers to show up at your door in Portland, Oregon, instead of the corporate headquarters in Chicago, Illinois.

The speed dial keys assignments can be selected out of the corporate directory!  Score!  And if you select the default call type (speed dial + BLF) (BLF = Busy Lamp Field) you can have the presence shown on the phone. Very nice.  In this finely focused picture, you can see four speed-dials configured.  The top one I have to use occasionally Disappointed smile, the second is without the BLF, the next two coincidentally show a busy and an available.  Ain’t that purty?


As a documentation note, if you are a norteamericano user, some of the terminology in the supporting documentation may be either amusing or confusing, depending.  For instance, to edit the aforementioned speed dial, here are the instructions:


I get it.  But, you have to know that I almost went and dug out my drafting supplies looking for my protractor set.

If you don’t want to use the keypad for login, and you are an external/remote user (like me), you have two options for login.  You can use the BToE (when it emerges from beta), or you can go into the web interface and enter your credentials.  BToE is covered here.  Let’s take a look at the web interface.

Press the menu button, then scroll down to the “Status” option. Under “Network Status” you will find the IP address that is assigned to the phone.  Using a standard browser, open http://whateveryouripis


With no-one is signed into the phone, the username is Admin and the PW is 1234.  Then select Configuration and Quick Setup.


Then simply fill in the data and click submit.


Logoff the web interface, then go to the phone and select “Status” and “Sign-in” and you should sign in.  For some reason, the phone does not like having you sign out; if you do, don’t be too surprised to have to go enter your password again.  I don’t understand why the phone does not hold the password in that scenario, but I will assume that an engineering decision was made that if you sign out of the phone then you don’t want to sign back in.  Which is a royal PITA for those of us who cannot use ext+PIN for login.  Adelante!


If you are looking at SIP phones, then this unit should be on your short list. The AudioCodes 440HD (their entire phone line actually) demonstrates very high quality in terms of packaging, build, and function. Audio quality is top-notch. In terms of price, very competitive.  A winner.


Jabra Motion UC+ MS Review


More toys!  First up is the Jabra Motion UC+ MS.  Here is the market speak straight from Jabra.com.  Please note that the tested unit is the “…with travel and charge kit”


What’s in the box

First off, build quality is typical Jabra, right at the top of the pack. While the microphone boom folds and unfolds to provide the on/off function, it did not feel flimsy like the old Motorola HD devices did.  The Jabra feels substantial.

A nice half-moon, hard case that holds everything except the wall charger.  Everything includes the USB dongle, a USB cord, two extra ear-piece adapters, and the Jabra Motion itself.  The case itself is pretty nice; well made and provides a single spot to hold everything needed.  Well, except for the wall charger.  But, if you are on the road, most likely you will have your laptop and you can charge from that using the included USB cable.


The market speak (see above) claims 8 hours of talk time and 360 hours of standby.  I have been using this device for two straight days and it is still going.  When a call arrives, putting the unit into your ear answers the phone without having to push any buttons.  Nice.

Jabra claims a 100 meter range from base to unit.  I don’t know about that.  My cell phone would disconnect at about 30 feet (I assume the difference is in the BlueTooth version on the cell) and I don’t have a 100 meter known-distance-range to test the dongle range – but it seems to be pretty good.

I could not test the NFC pairing feature because my iPhone does not have that.  Hello!  Apple!  Are you listening?

An annoying?  nice?  feature:  power off if not in use.  But it resumes immediately upon speaking – whereby you get an aural notification and the device reconnects to the phone.  This feature uses the same motion sensors used to pick up the call when you put the device up to your ear.  I will note that in testing, when the device announces power off, it also seemed to resume aurally.  However, it only did that once, so I cannot comment further – maybe my head was shaking or something.  Either way, when in auto-power-off, the device resumed immediately.

Audio Quality

On the TsooRad Goodness scale, the audio of this device ranks at a 9.5 of 10.  In other words, nothing is perfect.  But I could not find any fault either.  Solid.  Good timbre, good volume, sound reproduction is crisp and accurate.

Lync Compatible

Note that my interest in this unit is the ability of the device to pair to my cell (an iPhone in my case) and my laptop at the same time.  How does that work?  Seamlessly.  Literally.  With no further effort on my part other than being logged into my Lync client and plugging the included USB dongle into an available port, I was making and taking calls with Lync but now I had the audio in my ear; at the same time, my cell operated as expected.  So nice.  Jabra also supplies a downloadable software package to further customize the user experience; I did not go that far – if it works just fine as is, why bother?


A very nice unit.  If you are looking for a travel device that connects to both laptop and cell so as to minimize your packing list, this should be on your list of contenders.


You can get your very own Jabra Motion UC+ MS right here.



AudioCodes BToE Preview

I was offered the opportunity to take a look at the upcoming release of the AudioCodes Better Together over Ethernet beta.  Comments here are related to that beta, acknowledging that this is a beta, and I was asked to run it through the ropes (as I see them) and comment.

What is BToE?

BToE is part of the AudioCodes One Voice – a comprehensive offering of tools and devices that enhance the Lync Server environment with gateways, devices, and management to provide (a single neck to choke) an end-to-end set of solutions.  Simply, BToE allows the desktop Lync client to connect to the AudioCodes desk telephone (400HD series) without a USB tether.  There are some phones on the market that do a full USB tether (Lync Phone Edition) – but not everyone wants to spend that type of money for all of their users – one of the key points for Lync is reduced cost.  BToE allows the user to connect the phone to their desktop and essentially make the phone an extension of the Lync client enabling concepts such as click-to-dial and controlling the phone login from the client.

The provided documentation explains BToE thusly:

  • Lets users pair their AudioCodes IP phone with their Microsoft Lync client on their PC or laptop,
    over Ethernet, and from their PC or laptop control phone operations such as answer incoming
    calls, make outgoing calls (click-to-dial), hold and resume calls, and initiate/join an online meeting
    or Lync conference using their Lync client.
  • Allows mirroring of each call on both the AudioCodes IP phone and the PC, so that calls can be
    controlled from either the IP phone or the PC, adding substantial value to AudioCodes unified

Diving in

AudioCodes provided me with application drivers, pre-release firmware and application documentation, and firmware updates for the 420HD, 430HD, and 440HD phones.  I used a 420HD which I happen to have handy right on my desk.  I tested with my corporate account, not using a VPN.  The phone needed  the firmware update, the computer needed the application install, and my brain needs more operation cells – the two I have are already full.  Hey, and this time, proving that even *I* can learn, I actually read the documentation prior to pushing buttons.  Go me!

The firmware upgrade (on a 420HD) was seamless.  Setup an FTP server (I use FileZilla) (you probably already have this in some flavor, or a TFTP if you are running more than a few AudioCodes phones – or anyone else’s Lync phones), setup the DHCP option 160, and away it goes. At phone boot time, the phone reads the DHCP Option 160 data, connects, and upgrades itself, reboots itself, and then it is ready. This took about 2 minutes. Nice.


As a side note, I did not have this setup completely in my lab, which requires a different domain name; I set this up in my operational environment so I could test against a fully live corporate account.

With the phone sitting there waiting for login, I then installed the AudioCodes BToE application. I initially tried to install on a Windows 8.1 – I even tried compatibility mode on the msi.  Nope.  This caused me to open a virtual machine for the remainder of this test. The install was flawless, but only on Windows 7. Oopseyo!.   What about Windows 8.x?  I will assume that this will be addressed prior to actual release – I am not back-revving my core laptop just for this.

Once the application is installed, the documentation walks you through getting the pair code from the phone – according to a briefing given by devs at AudioCodes, this pair code is essentially the phone’s IP address.  Once entered into the application, the code does not go away (nice), but be aware if the phone ever changes IP, that code won’t work anymore.  Also not clear in the documentation was the need for the Lync 2013 client to be logged in first before pairing the phone – or at least that was my experience.  I could be just looking at the process wrong also; but maybe something to be alert to?

(beta) Findings

I would like to see the app minimize to the system tray instead of the task bar, but that could just be me.


For a non-domain joined machine, the BToE application which logs you into the phone did not pick up the need for a separate domain name (in my case my SIP address is different from my UPN).  However, I was able to add it in the dialogue box, at which point the phone just worked.  Login was quick and painless at that point.  Disconnecting the AudioCodes BToE application did not cause the phone to log out.  So you could use this little app to make the phone login much easier as the dial pad data entry can be a real pain.  And remote/external users cannot use PIN auth login like an internal user which forces them to do the dial pad routine, so this app could be right handy in those situations.


Logging out of the PC Lync client left the phone logged in and fully functional.  Nice.  Disconnecting the application from the phone left the phone logged in also.  Nice.

Not so nice, after observing that the Lync client needs to be logged in before pairing the device is that I closed everything, disconnected from the phone, and then rebooted my test Win7 VM.  On restart, the AudioCodes BToE app was already connected to the phone – BEFORE Lync logged in.  This might be because on my test VM I don’t have Lync starting with Windows.  Maybe the app could have a few lines of code added to detect Lync status prior to connected to the phone automatically?

According to the documentation, video calls will not work when BToE paired.  I sure hope this is resolved soon; I am a confirmed video call user – especially when working with customers.  OTOH, click to call works perfectly; start the call using the desktop client, complete the call using the phone device.  SWEET!  The desktop client shows the video device is there; you can use the appropriate Lync buttons to start a video call, the call actually hooks up as expected, but….no audio.

Disappointed smile

All other claimed features worked as advertised.  Click-to-call, transfers, holds, etc.  I really liked be able to click in the PC Lync client to start the call and have my phone functional for the actual call. So nice for us speaker phone talkers.

As an enhancement, and I have no idea how this would work, but if the phone is BToE paired to a full desktop, it would be really cool if the phone’s “personal” directory picked up the clients contact list.

How did it go?

Overall, this beta is impressive in that it delivered (with some minimal hassles) what amounts to a USB phone tether.  Video calls aside, my testing showed that my phone now becomes a fully-enabled Lync device.

One highlight is the ability for the BToE concept to get around the login terror for the remote/external user. This item alone make the AudioCodes BToE worth consideration for those users forced to login to the phone using the traditional phone keypad which requires dexterity, close attention to detail, and brain cells that are not already at capacity.

I could use the BToE right now, even as it exists in this beta.  I saw no stability issues, the app handled the phone as expected, and with the proviso that the app installs on Windows 8.x, I see a net gain for the administration side as well as the user side of the Lync experience.



Lync 2013 Disable Video

So, the customer, for various reasons, wanted to disable video but leave audio enabled.  Usually, the request is to disable audio AND video.

Disabling the audio AND video is pretty straightforward:

set-csuser john.weber –audiovideodisabled $true

But we wanted the audio to be enabled, with just the video turned off.  And we did not want to go mucking around with users disabling cameras, or setting a GPO to turn things off at the driver level, or some other esoteric solution.  What we wanted was to not allow video but allow all other modalities.  And we wanted to be able to undo this solution when the time came to turn video back on.

It would seem that using a Conferencing Policy would be a good choice, but the options offered up by the Lync Control Panel merely control what is available for the conference, not what the individual user can and cannot do P2P or in conference.  Here is what the Lync Control Panel offers:


Handy, but setting this to “Enable IP Audio” did not stop the user from starting a video call in a P2P scenario.




Indicates whether or not computer audio is allowed in the meeting. The default value is True.

This setting applies to the user who organizes the conference: if set to False, no conference created by a user affected by this policy will allow IP audio. However, the user can take part in other conferences where IP audio is allowed.




Indicates whether or not computer video is allowed in the meeting. The default value is True.

This setting applies to the user who organizes the conference: if set to False, no conference created by a user affected by this policy will allow IP video. However, the user can take part in other conferences where IP video is allowed.

But, to Lync, everything is pretty much a conference of one sort or another, so maybe Conferencing Policy can still help us?  Looking down the list of options for a Conferencing Policy we see this little gem:




If True, users will be able to take part in peer-to-peer video conferencing sessions. The default value is False.

This setting is enforced at the per-user level. That means that one user in a peer-to-peer communication session might be allowed to use video while the other user is not.

Now we be cooking with gas!  Be aware though, setting this at the conference policy level DISABLES the camera options in Lync for the users that have been granted the particular policy in question.  As in the video button in the client is gone.  Not just greyed out; gone.

This approach met our needs, but you need to examine the possible impacts to your users – this totally disables video.  With this set to $False, the affected users cannot use video at all, in any modality – even if the Conference Policy is set to “Enable IP audio/video” this attribute disables the local camera and any video.  The user will still get the audio portion of the conference, but no video at all.



Lync and Exchange on a single IP


First off, many kudos to fellow MVP Michael Van Horenbeeck, who published this article that got me started down the road to success.  Then, I suggest reading the NextHop article on the very similar subject.

Then, just to make sure everything is understood, read the official Lync documentation on Reverse Proxy.  Once you wade through that, you will also need to get a solid re-read of the Van Horenbeeck piece.  Because we are going to be using Kemp LoadMaster for this exercise, I strongly suggest reading the following:

Further reading here may help you out also.  However, with any luck this will not be an issue if you keep current on your Kemp firmware.

Scenario – what is the point?

As IPv4 address availability becomes tighter and tighter, more customers are starting to seriously push the question: “are all those public IP addresses REALLY needed?”  Most, if not all, of my clients already have an external IP being used for Exchange services.  Well, the answer is, no, not really, but it depends (as always).  For a smaller deployment, a single external IP can work.  I would prefer to see TWO (2) external IP, one for Lync SIP, WC, and AV, and one for Reverse Proxy.  While we can use the external IP already serving Exchange web services, this article will demonstrate a single external IP for all Lync and Exchange. 

As a huge point; this is an exercise in proving something can be done.  There are parts and pieces that I hope will be useful to someone else.  However, this solution may not be well suited for an actual environment because the Lync Edge ports have moved away from something that a corporate firewall will typically allow.  Specifically using 444, 446, and 447 for Lync Edge services will usually cause federation to other entities to fail.  Using this solution set for Lync Edge may also cause issues with Audio/Video media traffic. If you don’t need/want federation, then the entirety of this may be on target.  That is not the norm for what *I* see and I caution you to think this through before trying this in a production environment.  Remember my comment above about how I would want two public IP’s?  This is the reason.  YMMV.

As a final explanation, what I will demonstrate here is probably NOT a supported configuration per se, but there is no reason to think that anything here is unsupported just because this configuration is not explicitly called out in the documentation.

If you read between the lines carefully, you will also see that the existing Exchange web services IP could easily double up for the Exchange and Lync web services. You may also note that I have two complete Exchange organizations being supported with this environment- one with Lync, and one with no Lync. I will not cover the setup of the routing for the core Lync Edge services, but if you take a look at the following environment diagrams, you will see what is needed there and this article will concentrate on the configuration of the Kemp (or any other HLB) to handle the web services.

As a side note, I use Kemp because of the ease of deployment.  I find that the configuration and deployment tasks are very straightforward.  This is not to say that an existing HLB can’t accomplish these tasks, but I don’t have specific knowledge of those other devices.  The concepts will be the same, but the tasks to achieve the same outcomes on different hardware will be different.

If you have gotten this far, and you still want to move forward, let’s do it.


Here is our exercise environment to accomplish what we want. Note that I have ignored some of the traffic streams in this view; what is important is understanding the relationship between the domains, the load balancer/reverse proxy, and the subnets.


Once you have that digested, take a look at this one, and then go back and forth until you have a solid understanding.  This has a good deal more detail; it shows all the ports and traffic types.  As a logical diagram, the load balancer is sitting in the middle of all this; specifically dealing with all the web-based traffic and parceling out the traffic based on rules.  The load balancer has one leg in each network; its’ default network is the net and the default gateway is, as expected, on the default network.



As you might think, the load balancer is going to want a certificate or two so that it can represent itself to clients as the service requested, decrypt the SSL stream as needed, and then re-encrypt before sending it down to the real servers that make up the virtual service.  Because these certs were wildcards and my intent was only to use them on the load balancer, I used the Digicert Cert utility (what a nice piece of gear) to create, import, and export the certificates.  The Kemp does not seemingly care about trusted roots so both of my internally generated certificates worked just fine. In my case, I generated two wildcard certificates, one from the CA in each domain.  In a real world situation, I think that a public wildcard would work better.

Here are the PKI certificates installed on the Kemp.  Note that the domain1 certificate is only assigned to the one Virtual Service while the domain2 certificate is assigned to both.  This is because the VS on the network needs to handle URL’s from both domain1 and domain2, while the VS on the network only needs to handle domain2.


Content Rules

At this point, the content rules are needed.  You did read all the documentation mentioned above, yes?  If not, I suggest you do so now.  We’ll wait right here until you get that done.

Here are the content rules needed. Notice how some of them appear as both .net and .com.  I have two separate Exchange instances running so I need to differentiate – hence some of the content rules get doubled with the not-so-subtle URL change between .net and .com.  You can refer back to Mr. Van Horenbeeck’s article and get really fancy with these rules, but I went with the brute force simple method.


Virtual Services

Now we get to make some Virtual Services.  Did you really read all that documentation?  Good. I am horrible on reading documentation, and it bites me almost every time.  You would think that I would learn, eh wot?  Apparently not.  Adelante!  Here is the VS construction.


Note that VS 3, 4, and 5 are blue?  Because they have subVS instances living under them.  Here is the same stack, expanded.


Observe that while the far left column indicates the landing spot of the client on 443, the “Real Servers” column indicates the underlying server and the port changes, if any.  I think the virtual services homed on the net are self-explanatory – well, except for maybe #3.  So let’s look at that one, and once you understand that, I think the VS will make sense also.  Remember that external URL requests landing on the external VS need to be translated from 443 to 4443 and from 80 to 8080.




The interesting part is the “Advanced Properties” section where doodly-squat is done until AFTER the subVS object are created.  At which point you need to cycle back to this level and enable content switching.  You did read that stack of documents, yes?  Oddly, when creating the subVS objects, I had some inconsistent results when assigning the content rules which sometimes necessitated enabling the content rules at each level in reverse order, and sometimes as described in the documentation. Perhaps it was just me.  But know that, in the end, the Kemp needs to look like this or traffic will go nowhere even if the VS does ping back at you.

Here is subVS “LSWebInt” in detail. And yes it looks very much like the top level.  And is configured with the same items and settings.  Except note that the certificate is now missing.  Because the top layer is handling that slice of life.

Another important piece is for you to start comparing the “Selection Rules” as indicated in the pictures.  Note that the numbers of rules match up.  Now, I would have thought that assigning a rule at the bottom level would trickle up through the construction and be reflected at each layer above.  But….NO! So, when putting all this together, make sure you know what goes where; the Kemp WUI is not going to keep track of it for you.  If you add a rule at the subVS level on ONE of the real servers, do not expect the other server to know about it, don’t expect the Advanced Properties to magically catch on to things, and the high level VS won’t get it either.  Conversely, if you assign rules at the top, do not expect those rules to flow down logically just because there is an underlying service.



Grrrr.  Make yourself a table that lays out what you need, where it comes from and needs to go, and what content rule controls that.  You do document things, right?  If not, don’t come crying to me later not knowing what you did several months back and now don’t understand.  Adelante.

The Big Picture

You might be interested to know how I am running both sets of SMTP traffic through only one port 25 connection?  External Relay domain from domain1 to domain2.  A tad clunky, but hey, I only have one IP to work with (I’m cheap but not easy).  And I want to reinforce the Lync Edge in all this.  I am using single IP Edge, with ports 444, 446, and 447 for SIP, WC, and AV services.  And again, this is NOT recommended if you are expecting ubiquitous federation to work.  Most of the world will expect to be able to talk on 443 to your domain, and this construction is snaking all 443 to the load balancer for Exchange and Lync web services.

With all 443 traffic landing in one spot, we can use Kemp (or any other load balancer or device/appliance that supports this concept) Content Rules to send the URL to where we need it to go.  Routing and network relationships need to be figured out in advance, as do the Content Rules and the subVS’s that are actually handling the traffic.

While this exercise did a bit more than is normal for an organization, what with two Exchange organizations and only one Lync environment and using only one public IP, I think the point is made about bringing all 443 traffic to one spot and having (Kemp in this case) something decide where to send the traffic based on requested URL.  If I had more resources, and wanted to do this for a real organization, I would use one IP for Lync SIP, WC, and AV, and use another public IP for all 443 traffic.  Thereby saving precious IP resources which was the original goal.



Kemp 7.0.12a Two Arm bug

Update: 14 March 2014

According to Derek Kiely (Kemp), the fix will be in a 7.0-14 firmware release due out this month (see his comment below).


The Issue

Working in my lab making sure I know what I am doing with a two-arm Kemp LoadMaster configuration.  Here is what I am attempting to setup:


I am using a Kemp VM100 (firmware 7.0.12a) with content rules to redirect 443 traffic to various target virtual servers.  Specifically, the LM has one leg in and one leg in  HTTPS comes into a Virtual Service on one single IP ( and uses various rules to redirect traffic to either a network host or a network host.

According to the super-helpful folks at Kemp support, there is a bug in Kemp firmware 7.0.12a that results in abysmal failure on this setup.  Apparently, the traffic is landing on the service correctly, and heading off to the underlying real server correctly, but it is arriving at the (my Lync WAS test case) as a source when it should be showing up as a 1.1.1.x source. 

But what do I do NOW?

The fix is to put a static route into the target real server.  Here is my LyncWAS server ( route table with the fix in place. If you are curious, the command is (from an elevated CMD):

Route add –p

This identifies the traffic from the virtual service on the LM and send responses back to the LM on which knows what to do with the traffic.


Why does this work? 

Well, the traffic shows up on the LyncWAS ( but appears to be originating from the KempLB but from the address (which is correct from one point of view).  But the server thinks that to get to the network, it needs to talk out its’ default route of  And your connection fails because the real server is sending responses out the wrong gateway.  By adding the static route for the expected source IP, and pointing it to the KempLB, we now have a coherent route for the traffic.  A bit clunky for now, but it works.

My thanks to Kemp Tech support for identifying this issue.  Kemp is providing a fix in the next release which is due out shortly.



Blync–Busy light for Lync

Toys!  I got a new toy in the mail today.  Blync.  I bet that has something to do with Lync. What a clever name.  I must try it!

Very similar in function to the BusyLight, but a different shape.  USB connected.  Blync needs a software download. Here is what comes out of the box.  A masterpiece of packaging, someone has been paying attention to the Surface Pro packaging or the Apple packaging.  Very minimal, but more than sufficient to the task.


Here is the official market-speak for why you want/need this little gem in your environment.  No big surprise, it reads very much the same as the Kuando BusyLight.  After all, they do the same thing for you and your Lync users.

Once plugged in, and after the software is installed, the Blync lit up as a color match to my Lync client.  Here are the options presented by the software that controls Blync.


This puppy is bright.  On a dark night, you could almost use this as a reading lamp.  The color changes are distinct.  Did I mention it was bright? The last pic on the right should be yellow, but my high-quality camera washed out.  I did say it was bright, didn’t I?

 image image image image

The Blync - duh… blinks – on incoming calls.  Incoming and outgoing calls blinked.  Sort of like watching an old movie with the dark of night scene that has a neon light in the all-night diner that is flashing.  Bright. But missing the bzzzzzzzzzzzzzz! sound a neon sign makes when it is shorting out.  I will note that the competition has a speaker that does ringtones; but their light is not as visible as the Blync even if it does pulse.  I think that Blync would be visible even in a well lit cube-farm type office.

You can get your very own Blync right here.



Lync–Skype Audio Calls

As outlined at the Lync Conference, and reinforced on the official Skype blog, Lync-Skype audio is now available.

I just tested that with a client implementation and it works very nicely. Great quality.



Jabra Speak 410 MS

A while back, I reviewed the Jabra Speak 510 MS – clearly a superior piece of gear.  While at the Lync Conference 2014 last week, I got handed another Jabra speaker phone, this time the Jabra Speak 410 MS with a March 2014 label on it no less. 

Here is the official Jabra Speak 401 MS market-speak.  Note that it appears in many respects to be the same as the aforementioned 510 model.  In fact, to me they look identical.  However, there are differences.  The 410 has no battery, all you need is an open USB port.  No charging means no dead battery at a bad time.  There is also no Bluetooth, so no dongle to lose.



Past those differences, everything I said about the Jabra Speak 510 MS applies to the Jabra Speak 410 MS.  My laptop went ding! when it connected, then Lync just took it.  With no battery the 410 was instantly operational.  Nice sound, good volume control, excellent microphone, great controls.  And I love how the cord wraps into the base of the unit – right down to some handy engineer designing the USB  connector to be a tad squishy and shaped just so the base and the connector conflate just a tad and the cord stays neatly wrapped.  A great touch for an outstanding speaker phone that works seamlessly with Lync 2013.

Just checked the price and availability for these units. Prices appear to vary depending on where you look.  Some consideration should be given to the feature differences before you choose the 410 or the 510.