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.


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.


Kuando Busylight UC for Lync


update 2014-0306 – new driver released with the following features:

New Features and Functionality include:

  • IM Alert (you can have it flash or flash with an audible alert)
  • We included some basic FonComfort tools as a bonus:
    • Busy-on-Busy Suppression
    • Hot-Keys (Call Answer and Fast Dial-out)
    • Cleaned up some bugs. (e.g. some issues with docking stations)

Wow.  Such a title for such a little piece of kit.  And it has a serious claim of enhancing workplace productivity.  You can read all the market-speak here.  Specifically the claim is to reduce co-worker/teammate interruptions.  I tried one of these a long time back when they first appeared – and I did not like it.  The required software was unstable; my laptop started crashing and removing the Busylight software solved that – ergo, bad software. Why try it again you might ask?  Well, flat out:  I was asked to.  And why not?  Let’s take a run at this and see how it does this time.

Here is what comes out of the box.


I installed the unit by plugging it into my USB hub.  And waited.  Maybe I should read the documentation?  Ah.  Download needed.  You can get it here. OK, moving ahead, I installed the software.  While doing that, I noticed a few PDF’s that are available for your edimication.  The datasheet and the quick guide.  The datasheet makes some pretty serious claims. The quick guide has the install instructions (repeats the included slip of paper) and also explains functions like what color means what, how to change the colors, ringtones, and volume.

Once the software was loaded, I set the unit up above my desk at Tsoorad Central.  While I don’t like market-speak, I must say that the appearance of the pulsing red “in a call” stopped several people in their tracks.  The cat still walked across the desk, but I am not sure the feline in question cares too much for human activity except for food procurement.

Ringtones from outside my laptop are most welcome – I usually have the stereo playing and the laptop speakers are not the most powerful units known to man.  The light flashes blue to indicate the incoming call – definitely easier to see than the Lync toast that is usually buried under open apps. All in all, the Busylight did what it advertised it would do for Lync, and while my statistical sampling size was not large enough to represent a large environment, the Busylight did indeed cut down on interruptions.  And the software seems to be fixed.

You can get one right here


Kemp HLB as Reverse Proxy

Interested in using content redirects and Kemp to provide Reverse Proxy services on the minimum amount of IP addresses?

I have been using this as a reference:  http://michaelvh.wordpress.com/2014/01/03/publishing-multiple-services-to-the-internet-on-a-single-ip-address-using-a-kemp-load-balancer-and-content-switching-rules/.  Written by Exchange MVP Michael Van Horenbeeck, this article lays out what is needed to get Lync and Exchange operating on a single IP.

Up on NextHop, as of 14 February 2014, we also have this:  http://blogs.technet.com/b/nexthop/archive/2014/02/14/configuring-reverse-proxy-access-to-microsoft-lync-server-2013-using-kemp-loadmaster.aspx

Of note in the NextHop article is the little blurb at the top mentioning the certification process – nothing like having a reference to the OIP to make customers happy!  Also, the official Kemp configuration guidance for Lync 2013 is referenced in case you have a hard time finding that piece of arcana.  “If you need details steps or would like to manually create these services, you can refer to detailed instructions provided in “LoadMaster Deployment Guide for Microsoft Lync 2013” located here: http://kemptechnologies.com/files/downloads/documentation/7.0/Deployment_Guides/Deployment_Guide-Lync_2013.pdf



AudioCodes software E-SBC now certified

I had a great time at the Lync Conference 2014 last week.  Among other news, AudioCodes tells me that their Mediant Virtual Edition and Server Edition SBC is now Lync OIP certified.  AudioCodes tells me that it will take a bit for the OIP to get updated, but I think this is great news – especially for those who are doing straight SIP trunks.



Windows 8.1 Store app with local account

Playing with the Windows App Store and Windows 8.1.  By default, the operating system wants to push you into the cloud.  I am not a fan of that.  I don’t want my stuff being synced to Microsoft so they can share it with whoever they want or dissect my usage patterns or look over my shoulder.  They do enough of that already.

I wanted to download a simple free app.  Yet the default was to convert my Surface Pro 2 to a microsoft online account.  NOT!  I did not run into this before as the 8.1 install was an upgrade from 8.0 – which apparently does not do this so nefariously.

After a bit of searching, I found this blog article that explained how to accomplish what I wanted.  A local login, which uses my live.com account to access the store, but never try to convert my local account to a Microsoft online account with everything syncing to the MSFT cloud.

I understand the push to the cloud, I really do.  But I don’t think I should be gerrymandered into accepting what appears to be an underhanded policy to make the cloud the default.  As a suggestion for Microsoft – if they ever read this and actually think it through – please make the options outlined in the reference blog more visible as options instead of ASSuming that we all want to jump into the cloud and let you own my data and information.



Sennheiser SC 660 USB ML

Toys! I like toys! I match the “children” part of the top definition, and #3 also applies…


But I digress.

The object of desire – at least for this article – is the Sennheiser SC 660 USB ML.  I also have an SC 630 USB ML, which appears to be, and functions just like, the 660, except that it is only a one ear (monaural), while the 660 is a stereo.  As mentioned here, monaural headsets are NOT my favorite.  Give me stereo or give me….uhm….silence?  At any rate, I have actually played worked with both the 660 and the 630 and comments on the 660 should be applied to the 630 also.  Except of course, for hearing things in only one ear which drives me crazy.  Also, musack through the 630 was decidly less good due to only one ear getting sound. It’s hard to enjoy Green Day or Johnny Winter if only one ear is getting rocked.

Manufacturer Market-speak

SC 630 USB ML – hear what’s going on around you – “A premium single-sided wired headset optimized for Microsoft Lync, with built in call control unit for quality-conscious contact center and UC professionals requiring outstanding sound performance while maintaining contact with their surroundings.”

SC 660 USB ML – stereo sound for maximum focus – “A premium dual-sided wired headset optimized for Microsoft Lync with built-in call control unit for quality-conscious contact center and UC professionals requiring outstanding sound performance in noisy environments and best quality stereo sound from dual-sided neodymium speakers.”

660 OOB:


630 OOB:


Build Quality

Face it.  In the world of headsets and stuff like that, Sennheiser has a pretty good rep.  And the 660 just reinforces that rep.  Cables were solidly attached to the headset, the inline module, and the USB connector.  Nothing flimsy here.  The microphone boom had a very clever (and obvious?) solution to swapping the lefty-user to righty-user which was tight without being loose.  Overall, the test units I had were most excellent in build quality terms.

Lync Functionality

Sennheiser is claiming “Optimized for Microsoft Lync” on these units.  So, in theory, I should be able to plug in and go. Which is exactly how it went down.  I did see a quick blip as the drivers installed, but in general, a seamless integration into Lync.  The inline module has the expected controls and they function as you would expect.  Audio quality was excellent.  Noise cancelling appeared to be outstanding.  I made several calls while in a noisy cafĂ© environment and the far side of the call did not hear the usual background clutter.  IMHO, the marketspeak is spot on.

What I did not like

The cord on the 660 must be 7-8 feet long.  That would be 201 – 244 cm for the EU folks.  What a tangled mess. No matter how neatly I wrapped up the 660 before it went into my backpack, when it came time to take it out, I spent the next 5 minutes getting it straightened out.  It could be that with some more usage the cord will lose the ‘every three inches’ bend it has from coming out of the box, but I am not holding my breath waiting for that.  I would rather have a more substantial piece of wiring and put up with the bulk than have this mess each time. 

What I did Like

The 630 is only one ear, so this comment does not apply to it. 

The 660 has some serious audiophile roots.  Flat, balanced, realistic, great response.  Wow.  No frequency band overpowered another.  Excellent spatial distinction.  WOW.  All while sounding excellent with Lync Voice. I did not try the 660 on anything but Pandora, but my Catfish Blues station sounded absolutely excellent.  FWIW, everyone should listen to the Jelly Roll Kings once in their life. This lead to Meat Loaf and Journey and Indigenous; all reproduced in a most excellent fashion! <RantOff/>

You can get the 660 and the 630 right here.



Lync AIM Direct Federation

If you have been hiding under a rock (like me) then you might not know that as of June 2014, Lync federation to AIM will no longer go through Microsoft.  To whit:  “For Microsoft Lync customers, establishing a direct relationship with AOL is the only way to federate with AIM once our agreement with Microsoft ends in June 2014.”

You can read up on the official AOL guidance on how to continue forward with your AIM federation right here.

As always, YMMV.


Sennheiser Earbuds

Toys!  I love toys.

This time it is the Sennheiser MM 30i and the CX 275s.  I wanted to look at these two items for one big reason.  I fly.  And on the plane, I want some nice noise-cancelling ear buds, but I also want them to sound great and provide a microphone so that I can make a phone call without having to dig out my Bluetooth earpiece.  Just go from musack to talking on the cell without changing parts.

Here is the Sennheiser market-speak for these two items:

MM 30i -  Realize the full audio potential of your iPod, iPad or iPhone with this high quality ear canal headset. A smart inline remote conceals a microphone and included adapters customize the fit.


CX 275s - Empower all your music, calls and gaming on your smartphone or tablet with awesome stereo sound. CX 275s universal in-ear headset features a smart remote and microphone. Adaptor cable included.


All manufacturer hype aside, and desiring to have my aural canals rocked by good (well, as good as it gets with earbuds) musack while retaining a good call quality, I plugged up and played.


The MM 30i is, for me, better.  For starters, the MM 30i is iPhone specific.  The inline control is actually able to control the phone.  Nice.  The CX 275s had better sound I think, in the bass sections.  The CX was touted as being able to build more decibels, and that proved to be true.  I only had the volume up to the point of making my ears bleed once with each, and the CX certainly provided more pain. 

But the control on the CX inline thingy was marginal. Maybe I need to read the instructions, but my eyes are not that good. Dang but that print is SMALL!  Or maybe I should get my boss to obtain me (yet another toy!) a Droid to test with.

Either set demonstrated very nice music reproduction while not sounding too musicky (?) for voice purposes. As to comparing to the Apple-provided earbuds, either of these are far and away better in both sound and fit.


Comfort out of the package was quite good.  Both sets come with three sizes of cushions.  Seeing as how both the MM and the CX are “in the ear canal” designs, this is important.  I guess I am boring, the middle size (as shipped) worked best for me. The smalls were too small, while the large size simply would not fit.  Over the several hours of playing with both of these, I was impressed by my ears not feeling like a bearing puller was trying to extract a press-fit from my inner ear.

The Lync Connection

When using the earbuds with Lync 2013 Mobile Client, I had excellent results.  ‘Nuff said. 

Last Thoughts

All in all, in the vernacular of the 60’s, groovy. I had to forcibly remove the CX from the hands of my Droid tester.  Apparently they rock a Droid. Now I can’t wait for my next project that requires airline travel so I can give the MM 30i a more comprehensive trial.  In closing, these are the best ear buds I have heard yet.

You can get yours right here:  MM 30iCX 275s.




AudioCodes M9000

AudioCodes has just released its Mediant 9000, a high capacity SBC with capabilities tailored to the Enterprise market. This device is suitable for both Cloud/365 or On Premise deployments. My sources indicate that the Mediant 9000 is close to being Lync qualified. Here is a link to the press release for more details.



W32tm Server 2012

I just fixed a Server 2012 NTP issue in a manner I don’t like, but circumstance made me do it.


Server 2012 DC with Hyper-V.  Because of the Hyper-V I did not want to reinstall or nuke, I needed this server to work as NTP.  Netstat and Cports (http://www.nirsoft.net/utils/cports.html) showed that the NTP (w32time) service was not listening on UDP 123.  I tried the following to fix the issue:  http://technet.microsoft.com/en-us/library/bb727060.aspx, http://technet.microsoft.com/en-us/library/bb727062.aspx, http://support.microsoft.com/kb/816042/en-us.

I added Windows firewall rules, I deleted Windows firewall rules.  I disabled and enabled built-in Windows firewall rules. I disabled the Windows firewall.  All to no effect. I tried registry; I tried the spate of w32tm command line fixes.  I stopped, I started, I rebooted.  Nada. I went to UofB and UofG and read all manner of suggested fixes and forum discussions on the vagaries of Server 2012 NTP.  I compared Server 2012 NTP to my lab, which is 2008R2 DC NTP (which works flawlessly and is why I started looking at my 2012 DC); and I add that the 2008 R2 NTP in registry does NOT look like the Server 2012 NTP in registry – well, at least MINE does not.

I consulted other MVP’s, my Technical Architect level folks; I even talked to the darkside (peers in other companies).  Nothing helped.

Further Background

I noticed this issue because a Polycom VVX 600 phone connected to my outside DC (the aforementioned Server 2012) refused to set itself to the correct time. The same device plugged into my lab worked just fine. My efforts with DHCP setting the time zone worked well.  But the VVX would not get proper time (an AudioCodes 420HD on the same switch showed the proper time). Setting the VVX manually (via web interface) to explicitly look at my server did not help. So I went looking and discovered that no matter what I did, my Server 2012 would not listen on UDP 123, which, of course, makes it non-functional as an NTP source for non-domain machines. 

While this NTP issue existed, the PDC NTP domain functions appeared to be operating correctly. Using a domain workstation and running “w32tm /stripchart /computer:fqdn /samples:5 /dataonly” looked normal.  Domain workstations were all within a minute of each other.  Servers in the domain were all within a minute of the DC also.  The server itself showed NOTHING in the event logs.

Finally, ratting through ProcMon (www.sysinternals.com) showed that the server thought that svchost was starting the time service, but nothing ever worked.  The server never came up on UDP 123.  DNS came up on 56123, but that was the ONLY *123* string in a port sweep on that server.

The Fix

I went here and downloaded, installed, and configured a separate NTP server – which disabled the w32time service native to windows.  But now it works.



DHCP option 002 for Lync phones

Maybe I have been living under a rock… but I have been doing this manually… finally found a nifty chart so I can stick it in OneNote instead of having to figure it out each time – complete with instructions on how to calculate manually.  I take no credit, this is blatantly cut from a Cisco website source.

Standard Pacific time is GMT -8. This is a simpler way to calculate GMT with negative values:

1. The number of seconds equivalent to - 8 hours = - 8 hours * (3600 seconds / hr) = - 28800 seconds.

2. With a scientific calculator, enter the number -28800 in the calculator with decimal values. The (-) sign is very important. In order to get the negative sign in front, press the +/- key.

3. Choose Hex. This gives you FFFFFFFFFFFF8F80. This is because, by default, the calculator has Qword enabled.

4. In order to get rid of the extra Fs, choose Dword. This produces the value FFFF8F80. If you do not have this option in your calculator, use only the first eight digits from right to left.

5. The value placed in the DHCP pool configuration now becomes option 2 hex FFFF.8F80.


Table of Conversion of Different Offset Times into Hexadecimal

This table gives the conversion of the different time zones around the world. The hexadecimal values are set to have a fixed length of 32 bits as specified in Option 2 of the DHCP RFC 2132. For a world timezone map, refer to World Time Zone Map.

GMT offset (in hr)

GMT offset in seconds

GMT offset in Hexadecimal










































































Pacific Time Zone = GMT –8

60*60*8 = 28800.  Change sign. Now we have –28800.


Click the Hex button.  Now we have


Click the DWord button.  Now we have


Here is the value in the DHCP Server Options. Note that we take the DWord value and append “0x” to it.




AudioCodes 420HD Lync Phone Device Review


Initial Impressions

Great packaging; Clever base construction – not rickety, solid connection to base with a good angle sitting on the desk; Construction seems to be top notch – typical AudioCodes quality.  Cabling connection locations don’t get in each other’s way.  Switch ports for workstation/laptop pass-through well marked; the setup documentation (420HD IP Phone Quick Guide - included in the box) matches the actual contents of the box – something that seems to be lost on other vendors.


The phone needs to have power before the built-in switch works. Plugging the 420HD into my network between my switch and my laptop, but with no power, resulted in my laptop coming up on the local WAP (as it should).  Maybe I am making too much of this. If you have PoE, this is probably a moot issue.  But for those of us without the fancy-schmancy switches in the network and are using the power adapter, this may be a environment item to consider.  For what it is worth, this phone is firmware version


Built in support for Lync

Take a gander at the deployment guide…pages 9-11 outline what is needed on the Lync side.  Trusting that my corporate peers had configured things correctly, I chose the “Sign in” option, and the phone simply queried me for login name, network user name, password, and in I went.  Very nice.  Assuming that the Lync environment is setup properly, this phone will just work.  Noted also is that I am in Portland, Oregon, and the server I connect to is in Chicago, Illinois.  This means that I am a completely remote user, and I unboxed this unit, did the setup and connected with no need for corporate IT to be involved.  SWEET!    I was up and using the phone with great results with Lync in a very short time frame.


Volume control and volume itself was very good.  Great audio quality. Clear, with good voice tone. The phone does not sound tinny or cheap at all.  It sounds very robust. Single button for voice mail.  Nice. As noted below, if the power fails and the phone drops off line, when the power comes back you auto-sign-in.  If you sign out, then you must enter domain credentials.  So, I see this as a positive – but an item for user training if you want to avoid help desk calls.

You can use this phone to sign in with a UPN and password, or you can use an extension number and PIN.  Again, see the referenced pages of the deployment guide


The 10 key + softkey choosing-which-buttons-to-use routine was less than optimal.  However, I read absolutely zero documentation and still had it working in a very short time frame.  Buried on page 13 of the deployment guide (see below) is what you need to know to help out your co-workers.  In my case, the “…and 1 for the special characters @ and .(dot)” – I figured it out, but it would be nice if that was in the USER MANUAL (see below).


Oh wait.  I just found this on page 21 of the User Manual…


I guess I should start reading manuals again, eh wot?  In my defense, I don’t find this to be very clear.  Or maybe this type of stuff should be in the first few pages where a typical user might look.  Yes, I know, I am defending myself to some degree, but still…

Link to user documentation LTRT-11881 420HD IP Phone User's Manual Ver. 2.0.2

Link to Lync 420HD deployment guide LTRT-21920 AudioCodes 420HD Lync-Compatible IP Phone Deployment Guide.pdf


Searching the corporate directory

Having to type names in with the 10 key+softkey routine (as mentioned above) was a tad tedious.  After consulting with my friendly AudioCodes support engineer, it would seem that there is “something” not quite right, because according to the documentation, I should be able to enter a single letter – J for instance, and have the phone return all matches in the corporate directory that start with “J.” – We are looking into this and I will update as a resolution is found.

Device Passwords

The default admin password ‘1234’ did not work.  It seems that when the phone logs into the Lync environment, the user’s domain account and password take effect.  So, in my case, I had to use “John” and my domain password to get it to work.  Note that I did not include the full UPN, and not the NETBIOS format of domain\user; just username.  Odd.  How does that equate to an administrative login?  I ask this because the phone is logged in with my creds, and at that point a regular admin cannot access the phone’s web interface using the admin user and password.  And while I am noting that, pulling the power off the phone results in a dead phone (duh) but when the phone gets power again, it logged back in as me.  Without asking any questions.  It just logged in.  I can see where that might represent a security issue to some folks.  If anyone in AudioCodes-land reads this and can correct me on that supposition, I will gladly update this article.

D’oh! category

After some poking around, I “discovered” that if you sign out of the phone – THEN the default user name and password works  -  ‘admin’ with “1234’ – if you are signed into the phone, the only login that works is your user name and your domain password – and then all you get is the “user” subset of the web interface – none of the administrator level functions are exposed.  I don’t think I would be telling users that the web interface even exists, let alone telling them how to get into it, but that might be just me.

BTW, the user and admin logins can be changed…...


While I am using the device with Lync, here is the “OOB” support – it would seem that AudioCodes would like to have a larger market than just Lync.


Nit Pick

The web interface was clearly designed by someone using a large display.  It does not resize.  On my laptop with a 1920x1080 resolution, if I did not have the web interface full screen I had to scroll around in it to see important things like the “Submit” button.  Is it too much to expect to have a developer allow for dynamic resize?  This comment is not directed just at AudioCodes, but at others also.  You know who you are.  Not everyone has a 32 inch plasma for their primary display.

Checking out the internal dial plan on the phone

^(\d{11})$=+$1;^(\d{10})$=+1$1;^(1\d{10})$=+$1;^([2-9]\d{9})$=+1$1;^9(1[2-9]\d{9})$=+$1;^9([2-9]\d{9})$=+1$1;REDACTED AT THIS POINT to protect internal data.

That is a serious Regex one-liner!  Before I redacted, the phones’ internal dial plan went a good 15 lines down the page – all one string.  We could all be learning something from this.  I see phone strings in there that would indicate that this regex is being picked up from Lync.  Based on my understanding of how Lync clients work, this is how it should be.  In testing, dialing 5 digits and then waiting for the time out resulted in the phone dialing a correct number.  Nice.  In the stupid tricks bracket, I could call myself.  Entering my extension resulted in my Lync client toasting, my mobile getting the simulring, and when I ended the call, my Outlook getting a missed call notification.

Overall impression


Total setup time from looking at the box, to setting up the phone on the desk, to login and being connected to the office was less than 30 minutes.  I did nothing to my network, I did nothing to my account (I was already EV enabled).  I am a total remote/external user, so I pretty much expected this phone to work, and it did.  Mission accomplished. 


Quality is typical AudioCodes.  Solid feel, buttons are clearly marked and press cleanly, ports are labeled, while the audio quality and volume are excellent. I think that this is a clear winner

Lync Functionality

Works out of the box with no fiddling with the phone.  ‘Nuff said there.  I like it.


You can get your very own AudioCodes 420HD right here.



Exchange 2007 mailbox users Lync EWS



During the transition to Exchange 2013 from Exchange 2007, Exchange Web Services (EWS) integration for Lync will be unavailable for users whose mailboxes remain on Exchange 2007. 


The Bad News

Jeremy Silber has an excellent blog article on this issue.  It bears reading if you fit the above scenario.  Jeremy shows in extremely clear detail what is going on, and why. Unfortunately, he also shows that there is no fix.  Here is the article:




Ex-OCS2007R2 user unable to login to Lync 2013

The Scenario

A recent project was an OCS2007R2 migration to Lync 2013.  The environment had two central sites.  At the main central site, “somebody” had already installed Lync 2010, migrated most of the users, while the other central site was still R2.  Users had moved between pools in both directions.  Edge services were supplied by the Lync 2010 pool.  Users were homed on a variety of OU’s.  The CSAdministrator and RTCUniversalServerAdmins groups were not domain admin enabled.  The Lync 2013 environment was also two central sites.  Users from each site moved to their respective 2013 pool.

Everything went pretty well until we went to move users.  All the users eventually moved, but due to a really hosed up Active Directory, we had “issues.”  After the user move, the R2 components were decommissioned as were the Lync 2010 components.  THEN we discovered that a small subset (about 200 users) of the total user population could not login.  These users were all coming from domain-joined machines.  We tried disabling the users from Lync, waiting for 24 hours, then enabling from scratch. Still had issues.  Move the user to the other pool?  Nope.  Still no good.  Different workstation?  No.  Login from mobile works maybe?  Not a chance.  The various Lync clients simply said the user account information was no good.  Over and over.  Not a certificate issue, it was behaving like the username or password was fat-fingered.  But the user was already had a valid login to the domain. Grrr. Worse yet, Lync 2010 or and R2 client would login. Around in circles we went.

To be very clear, this was NOT an AD issue, this was an issue with SOME users that moved from an OCS 2007 R2 pool or a Lync 2010 pool to a new Lync 2013 pool.

At which point we decided to nuke the users from the database.

The Fix

Before you go much further – this is a one way procedure.  When you get to step 4, there is no getting it back without going all the way through.  So, you might want to consider if you have exhausted all your options before you take this route.  There is also a slight chance of thoroughly borking up the RTC database when you do this.

  Proceed at YOUR OWN RISK 

You may want to verify that your environment is replicating properly before you go much further, because we are going to force the issue down in step 3.  Get a PowerShell window open and run “get-CsManagementStoreReplicationStatus” and be checking for all servers showing TRUE.  If not, then you may want to fix that first.  You do check for this on a semi-regular basis don’t you?

OK. 7 steps to success.  Here we go

Let’s assume this user is totally unable to login to Lync 2013, even though EVERYTHING looks like it should work, and credentials work just fine in the domain for everything else.


Step 1 - Export user data

Execute this either on a remote PowerShell or on a Lync PowerShell on the server itself.  This will save contacts, but not meeting/conference information.

Export-CSUserData –poolfqdn poolfqdn –userfilter “username@domain.com” –filename “whereyouwantthefiletogo”

Like so:


Step 2 - Remove the user from Lync Server

You can do this from the control panel, or get fancy and one-line it from PowerShell.  Here is the Control Panel method:


Step 3 - Invoke replication and wait for replication status to show true. 

Let’s hope your replication process is good, eh? - Invoke-CSManagementStoreReplication, wait a bit, then get-CsManagementStoreReplicationStatus


Step 4 - Clear out the entry of user object from the Front End server local database

We used the SQL Management Studio for this. If all you have is an Standard Edition (SE) or two, then you will have to either be a SQL wizard, or go install the SQL Management Studio somewhere.  I have an Enterprise (EE) pool, so I have a SQL Backend with the Management Studio. If you have an EE pool, then you need to do this on all pool FE servers BEFORE moving to step 5.

Open SQL Management Studio. Once you have that open, connect to each FE server RTCLocal database instance in question.  In this case, we have two EE pool servers, so we connected to both, each to the RTCLocal instance.

image  image

Now, open up the individual instance, select the ‘rtc’ database…


Now, select “New Query” from the tool bar…


…and you should have something that looks like this – importantly, the database little indicator window thingy should have lit up…notice you have a new tool bar that sprang into being when the mighty admin-mage invoked the Query…


From here, in the SQLQuery pane, we want to enter the following – and this is CASE SENSITIVE

execute dbo.RtcDeleteResource ‘username@domain.com’

Here is my example.  Note that the user name is SPECIFIC and it has SINGLE quotes and it was the SIP ADDRESS not the SAMAccountName or UPN or NetBios format.  SIP ADDRESS!  Oh, did I mention the stored procedure is CASE SENSITIVE?


When you get that EXACTLY right, click on the “Execute” button as indicated.  Should you have done all of this correctly, you will see this:


Now, what does it say on the shampoo bottle?  Lather, rinse, and repeat as necessary.  If you have 10 users that are borked, then do all 10.  And make sure the process is run against all applicable pool servers.  If you have 4 EE servers, then you must do this for each user on each server. 

Step 5 - Enable user

You don’t need me to illustrate this do you? Use either PowerShell or Control Panel and enable the user that you just got done (hopefully) nuking from the system.

Step 6 - Import the user data from the backup file

Import-CsUserData –poolfqdn poolfqdn –UserFilter "username@domain.com” –filename “sourcefile”

Like so:


Step 7 - Restart the FE service

I use a cmd line window.  “net stop rtcsrv && net start rtcsrv” but you can get a services.msc window open and do restart from there…takes about 3 minutes or less to restart – any user on the server when you do this will get dropped with no warning.


On the nice side, when the server comes back, they should sign back in automatically.  If you did the rest of your work correctly (read DNSLB), they might have already signed in to another pool member.  Just to get dropped again when you restart the RtcSrv on the other pool members.  Maybe you should do this after hours.


We stipulated some users that could not login, even when we KNEW the domain credentials were good.  With all hope for world peace exhausted, we proceeded through a seven-step process that nukes the user from the system, resets the system, and in theory gives you a new user, with their old contacts (but not their conference information).