About Me

My Photo
TsooRad is a blog for John Weber. John is 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, 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.


Frontier FIOS and static IP


About four months ago, I made the decision to extend my lab, Tsoorad.net, out to the larger world of the internet.  I have several reasons for wanting to do this; most of them selfish, but a surprising number of them are for client testing purposes.  I need/want to implement a full SBC for a SIP trunk, which leads to needing a SIP trunk, et cetera.  So for this exercise I need more than one (1) static IP.  I could probably figure out a way to futz with ports per service and get something worked up, but I want to be able to duplicate customer scenarios.  Internally I have plenty of network.  Externally, I need a static IP configuration.  And with needing at least three IP externally, the logical choice (see how I justified all that?) a /29 seemed to be a good fit.

Enter Frontier FIOS

I have been a fan of FIOS since the halcyon days of Verizon replacing my DSL with fiber to my house.  Awesome.  None of the crap that you put up with if you use cable.  I don’t share my bandwidth with the rest of the neighborhood.  Nice and consistent on the speeds up and down.  And the 15/5 package is more than sufficient for my 2 person internal domain and my lab domain. 

But, it turns out that FIOS has this ONT thing (Optical Network Thingy)(actually, Optical Network Terminal) mounted to the side of the house.  Which leads us to the The Problem.

The Problem

On the Frontier side, the sales folks sold me.  I know, I should have been smarter.  I should have known.  Sales types around the world have a mantra:  “yes yes yes, please sign here” and they are compensated on their ability to get the signature.  I get it.  But I hate misinformation. 

Knowing that I was going to need at least three of the /29 workable, asked the obvious (and brilliant) question: “Will the Frontier supplied router be able to handle a /29 or will I need my own firewall/router?”  I should have heard the alarm bells go off when I had to explain what a /29 was and why I was asking the firewall/router question.  But, I was assured, by someone who assured me that they worked on the business provisioning side of things, that the router supplied on the install would handle the requisite services.


When the Frontier install tech showed up onsite, he expressed his doubts.  But, armed with the knowledge (however faulty) of the sales professional, we moved forward.  The actual connection part was easy.  When I first moved in, I had the technician run Cat5 from the ONT to the internal drop.  There are pluses and minuses to this approach.  But seeing how I could care less about the TV service (I use a popular satellite vendor), using an Ethernet drop versus coax was a no brainer.  As it turns out, a necessary one as we shall see.

Firstly, if you have coax to your local demarc, then you will need to use the Frontier-supplied router/modem.  The Frontier-supplied unit, an Actiontec MI424WR, certainly LOOKED like it should handle things.  In the network definition section in the setup, there is a place to put in IP’s, and it would take the full definition complete with mask and gateway.  But, we could not get more than one address working.  At one point we had a second address working, but it abruptly quit after a few hours.  For reasons we shall see, this was caused by the ONT and in the end, had the Frontier Tier 1 non-help desk been more informed and less script-driven, I might still be using the ActionTec.  You see, the problem, while it appeared with the original Frontier-supplied router, might not definitely indicate that the ActionTec won’t work.  However (on the flip side) I did have a longish chat with an Actiontec “engineer” who blithely told me that their router would only do 1:1 static NATs, and not dynamic 1:M NAT.  I am also not sure if the Actiontec would be able to do 1:1 AND 1:M NAT at the same time.  I suppose that particular test will be done at some point in the future when I am snowed in or can’t sleep at 0230.


Next, having proved over and over that we could get all 5 IPs working off a switch on five different pieces of gear, and all at the same time, we started looking at how the network was delivered from the Frontier side of things.

<Cue creepy techno-vibe music from CSI with lots of tracert, pathping, and telnetting with multiple interfaces on different machines for configuring the various firewalls and other appliances>

Back to the Frontier Tier 1 non-help folks who (reading from their script) had me retest everything again, and then proclaimed that I had a DNS issue.  <sigh>

Over and over this went.  Then it turns out that the network technician who was advising the Tier 1 person was reading from the standard, world-wide network engineer script that goes something like this:  “Everything is good here.  You have a problem.”  And the idiot user (me in the case) is not allowed to speak directly to the actual network technician – so you have this wonderfully frustrating back ‘n forth between the idiot (me), the non-support Tier 1 person, and the network technician who blindly insists that all of their gear is provisioned correctly.  Because I was asking for support for something that was not common to their network, this entire effort failed because I was off script.

This went on for several months.  In that time I tried, in order of implementation, the following firewalls:  Cisco PIX 515e, Cisco ASA 5520, Cisco ASA 5505.  Nuttin’!  All this time, each time I called for some more non-help to be told how everything was peachy on their end, but gees, maybe you could clear your ARP tables please, I was told how the issue had to be on my gear being misconfigured.  Now, I am not in any fashion a Cisco ASA expert.  But I have some knowledge.  So when it came to about 1/2 way through the 5520 efforts and for ALL of the 5505 efforts, I trotted out the hired guns.  Namely a completely certified (he is really out there) Cisco dood – who lives and breathes Cisco security as his primary job.

As a side note, this guy was awesome.  But clearly, in the end, he was clearly puzzled as to why what works for the rest of the civilized world refused to work for the TsoorRad environment.  And he did this several times.  We had nothing wrong.  My network is solid.

The Fix Begins

At about this time, I am starting to doubt my sanity.  Stupid thing should be working but it is not.  I think that I have eliminated any possible error on my side – Yet Frontier network techs still insisted that there was nothing wrong on their end.  However, if you read some of the material to be found online which I magnanimously have provided here:






…you can see that I am NOT the only one.  However, in defense of fairness, in some of the research the firewalls were called into question.  So, I will try one last time.  I purchased a NetGear FVS318G.  Same results as before.  I then discovered a piece of the Frontier website that allowed me to find email addresses for executives in my area.  So I fired up my email and sent a politely worded notice of my dissatisfaction.  Several.  But the first one got serious attention.  So the buck does stop somewhere. 

So now I have Frontier calling me, managers, technicians, and technician supervisors all have been told to fix this.  About time.  But guess what?  The network team on their side is still insisting that their configuration is perfect.  Here is a little blurb of the back-n-forth:

“…the ONT cannot (empirically) deliver the entire /29 all at one time to one device such as a firewall.  This is not acceptable. 

It would appear that something in the ONT is not able to send the entire /29 block to one device.  I have now used 4 different firewalls, ranging from bottom end business class (netgear fvs318g) to industry standard business class firewalls (PIX 515E, ASA 5520, ASA 5505) and they all do the same thing – specifically, the devices work just fine on one IP address, but the ONT fails to deliver the entire block to the single device.

I think that the ball is back in Frontier’s court.  Something must be able to be done to the ONT to bridge my entire /29 to the Ethernet so that what I paid for, namely business class service, is actually delivered to me.  Bridge the ONT, tell the ONT to handle multiple IP’s, upgrade the firmware on the ONT to do this, SOMETHING…”

The Fix is IN

As it turns out, the ONT not being able to deliver all the addresses was the issue all along.  While I cannot get direct information as what EXACTLY was done, my service now works with a complete /29.  Somebody up in Frontier-land did something to either the ONT (several folks did several things, all very hush-hush) and then an upper-level regional engineer did something to the upstream router (from my service perspective) and magically the NetGear FVS318 is cranking on all five cylinders.  I cannot verify the regional engineer thing, it was only mentioned once, and then when I enquired about it again the subject was changed very quickly.

Here is what Frontier told me was the issue:

“Our Gateway Router sends out an ARP request every 6 hours or so to see if the same MAC address is still using an IP address.  It sends it out on and if it does not get a reply, it shuts down that IP addresses' ability to get online.  The reason this happens is because many firewalls identify an incoming request on as an attack.  So the Firewall sees it and then discards the packet.  The discarded packet never gets back to the Gateway Router, so the Gateway Router in essence says: don't let this IP address get online, I cannot verify the Mac Address.

At the time you were experiencing this problem, we were introducing a new optical network terminal (ONT) into our network; Calix.  It operates much different that the way the Alcatel Lucent system operated.  We plan on exclusively using the Calix ONTs for small business customers where it has been added, which is about 95% complete in the Oregon FiOS markets.”


  1. Remember the Actiontec that did two addresses but then quit?  IF the ONT is configured correctly, maybe, just maybe the Actiontec CAN handle a /29 like the original sales person stated?
  2. The ASA is a multi-talented device.  Dang did I learn a lot.  But in the end, not able to work for me.  My buck-twenty NetGear POS is working just fine.  Complete with SIP trunk.
  3. Frontier has assured me that the process has been changed as any business-class (fixed IP) service will require the new Calix ONT (mentioned above).
  4. Sales types are a necessary evil.  Business doesn’t work without them.  Caveat Emptor.  Be educated for yourself.  I don’t know if I could have done anything different, but I will be thinking about it for future actions.
  5. When I got ahold of the correct layer of responsibility inside of Frontier, things went very smoothly, and I was treated much differently.  Like maybe I knew just a little of what I said.
  6. Network technicians need to learn to look a tad past the CLI on their screen and stop assuming that “everything” is correct on their side of things.

In the end, I am happy, but I sure wish this had not taken so long to resolve.



Lync Mirror RPC Server is unavailable

Don’t ask me why, I just know what I did to work around it.


I was engaged in establishing a database mirror for a new monitoring database for an established Lync 2013 CU4 EE pool.  When it came time to publish the topology and install the new databases, the mirror refused to instantiate with an error of:

An error occurred: "System.Runtime.InteropServices.COMException" "The RPC server is unavailable. (Exception from HRESULT: 0x800706BA

Lovely, eh wot?

The Fix

The SQL server version for all three servers in question is SQL 2012 SP1. I went through the usual routine of checking the services, the firewall rules, the rights and permissions on the SQL primary, mirror, and FSW.  All of that looked as it should.  Here is a good outline for you to follow should you need it.

What fixed it for me?  We turned off the firewall for all interfaces on all three SQL servers.  I know, but don’t ask me.  After the successful mirror activity, we turned the firewalls back on for all interfaces on all three SQL servers and everything seems to be happy.

Go figure.



SharePoint Foundation compatible application could not found


Do you get these zippy error messages when you try to open a document in SharePoint (or should I say non-SharePoint?) and are thoroughly confused as to why it worked the other day but not today?



I got these errors today, so off to UofB and UofG to find an answer.  Searching on the phrase “edit document requires foundation” or “The document could not be opened for editing. A Microsoft SharePoint Foundation compatible application could not be found to edit the document” which were two of the other error messages I got resulted in a boatload of links both MS forum and other locations. 

These links were full of advice - all of which failed.  Towards the end of my search I found a spot that mentioned doing a full repair.  I thought  - “maybe, but I just (stupidly) ran Windows Update the other day and ran about 30 updates in – which included a bunch of Office 2013 updates” and the last part convinced me that I had nothing to lose.  So off I went and did a repair.

Voila!  My sacred OneNote file is now able to open and sync and be edited.  WHY? 

I don’t know what caused this, but I suspect, as it was working a while ago, that the updates the other day borked things up somehow. If it matters, I am running win8.1x64, Office 2013 x64, and a variety of other crap that is both Microsoft and other vendors both x86 and x64.



Lync Server 2013 CU5

Released – later than I thought it would be, but nonetheless, we have an update.

http://www.microsoft.com/en-us/download/details.aspx?id=36820&751be11f-ede8-5a0c-058c-2ee190a24fa6 for the downloads.

http://support.microsoft.com/kb/2809243 is the detailed installation instructions.



Lync 2013 Test Plan

For some reason, the concept of conducting full function tests prior to ending the Lync POC or pilot project has come up again and again.  Those pesky customers just keep insisting. 

Usually, the customer has already come up with a fairly exhaustive test plan on their own and all I need to do is help them revise or add expectations. If they have not developed their own test plan, I first point them to the Lync 2013 RASK. 

The Lync Rollout and Adoption Success Kit can be found here.  If you poke around the semi-convoluted structure you will eventually divine the logic, but you are probably better at that than I am.  At any rate, eventually you will find stumble upon this link:  http://www.microsoft.com/en-us/download/confirmation.aspx?id=37031 which is the download page for the Lync 2013 Rollout and Adoption Success Kit (RASK) Resources package.  A very nice piece of kit.  This download has the following format:


I have taken the liberty of showing the location of the subject for this article – the “Sample Pilot Test Plan.xlsx”.  What you see below is a modification of that fine piece of work. In its’ base form, the RASK test plan has saved me many hours of skull sweat – and most likely saved my customers many hours as well.  For a simple Lync deployment, you may be able to use it as is.

But the real value of the RASK test plan is to get your head into the game.  Accordingly, my modifications are just that, MINE  - as needed for a project, and then modified past that to serve as my personal baseline test plan.   

If you were to run a full system test and that included HA and DR, you would also iteratively fail Front End Pool members and run full-tests per this matrix with each pool member offline in turn.  And then you would need to create the same set of tests with perhaps one Edge Server offline and then consider your other environment details. And then loop through for each pool member off in turn et cetera. You may end up with a matrix with a considerable number of test cells to complete. I one time did a project where the core HA/DR test matrix resulted in 900+ individual test cells.  Each cell was one complete test that contributed to the overall upper level test.  Fun! But in the end, if someone asks you, you can show them, yes, we tested.

I try very hard to accomplish the testing inside out and and using this order of tests:

  1. Test the FE pool level -  this may include monitoring, archiving, persistent chat, and Office Web Apps Servers
  2. Test the Edge (Edge servers and reverse proxy)
  3. Test mobility clients
  4. MPOP scenarios

Resist the urge to use real users.  Gin up a set of test accounts, per pool, and use those accounts for the testing.  If you MUST use real accounts, be in control of the testing flow or you will be like this when things don’t go exactly right and the testers start veering off into the own little interest area.

So, without further ado, here is a sample what I use as my baseline in screen cap format – a download link can be found at the bottom of this article. 


Here is the download link.



A duplicate name exists on the network

There I was, doing some menial tasks associated with validating a full HA, multiple geographical site deployment.  We had just got the final Edge pool up, and were checking mobility client connections and functions.  In walks my client counterpart and he wants to deploy the monitoring server databases.  Previously the customer had modified the topology to include monitoring per pool, published the topology, and had reported that the databases did not install.

Easy-peasy says I.  So we opened the Topology Builder and worked through the process to deploy just a database.  We carefully chose our target server, changed the default locations for the data and the logs. For those readers who are dying to know how to accomplish this after having the pools already installed, here is a quick primer using Topology Builder.

(by no means is this an authoritative guide to installing monitoring databases – if you need that see this)

Adelante!  From the Topology Builder….


Select the SQL server you want, make sure it is highlighted, then click on advanced.


If your DBA does not care, you can leave these fields blank, if the DBA does care, then you will need to get with him/her and figure this out:


At this point, you are ready to go:


…and we were rewarded with the following announcement.

“You were not connected because a duplicate name exists on the network.”

In defense of our failure, the error message was in a very nice color of red.  In honor of that detailed bit of programming, you will note that I have colored my error message in the same brilliant hue.

We were using a service account that was a domain admin, had local logon rights to the target SQL server and was an SA equivalent on the target SQL server.  We double checked membership in the CSAdministrator and RTCUniversalServerAdmins groups. The SQL server was pingable.  The environment is using an alias for the SQL server FQDN.  So we verified that the FE pool member from which we were running PowerShell could see and ping the SQL server by FQDN, IP, and CName.  All good.  We also did a little judicious DNS peeking to make sure that a duplicate name did not exist.

So we tried the process again, but this time I brightly used the PowerShell cmdlet.

Install-CsDatabase -ConfiguredDatabases -SqlServerFqdn SQLServer.FQDN –Verbose

Failure, but the verbose option gave us another pretty red error with a bit more information…

WARNING: Install-CsDatabase failed.
WARNING: Detailed results can be found at "C:\Users\SVC_Lync\AppData\Local\Temp\5\Install-CsDatabase-201de519-f3ac-4f0f-a221-b0cacc897e27.html".

Install-CsDatabase : Command execution failed: You were not connected because a duplicate name exists on the network. If joining a domain, go to System in Control Panel to change the computer name and try again. If joining a workgroup, choose another workgroup name.

Not so good.

Having already checked permissions and names and DNS, we then turned to Bing’ing and the ubiquitous Google-fu.  After some detailed searching, some boring reading, and superfluous checking of various settings, I stumbled across this on Mark Menasi’s forum.  While it did not exactly apply, it was certainly worth a shot (after all, nothing else was working).  After a little discussion in which we decided on a plan to unwind this registry hack if results did not meet expectations, we did the following to the demon SQL server in question:

Value name: DisableStrictNameChecking
Data type: REG_DWORD
Radix: Decimal
Value: 1

We then were successful with the install-csdatabase cmdlet.  LCsCdr and QoEMetrics databases are installed and we have data flowing.



Where is my Lync PIN Stored?

I don’t know why this question came up, but a client asked me today: “where does Lync store the user’s conference PIN?” I hate questions to which I don’t know the answer.  A few ideas came to mind; a co-worker suggested that the PIN was in SQL somewhere.

So I went looking.  Dang!  and looked.  And poked.  And prodded.  But finally!

RTCLocal instance, RTC database.  The table is dbo.UserPinMembership.


But, when you look at it, the actual PIN appears to be a one-way hash (like AD storing passwords). 


So, even after you find the magical user PIN, do not attempt to edit this value directly or you will probably be sorry.  Instead, use the PowerShell cmdlets provided for that purpose.


Take a look at




and if you are really adventurous,

Set-CSPinSendCAWelcomeMail which can be used sort of like this for the one-offs, or you can read a csv and set everyone at once.

Set-CsPinSendCAWelcomeMail -UserUri "sip:jweber@domain.com" -From "helpdesk@domain.com" -SmtpServer vmailbox.domain.com -Subject "your PIN" -Pin "135791" -Force -Verbose -UserEmailAddress jweber@domain.com

But trust me, don’t try to change or set the PIN using direct SQL edits.



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.