Logitech Wireless Headset Dual H820e Device Review

Disclaimer:  Logitech provided the device.

This article also applies to the Mono H820e. The Mono H820e appears to be identical with the exception of being only a “one-ear” setup.

What it is

The Logitech Wireless Headset Dual H820 is a DECT stereo wireless headset that has an “Optimized for Microsoft Lync” label on the box. Logitech is claiming this compatibility but the Microsoft website has not updated in a while – March 2013 appears to the be last device list update.

What the hell is “DECT” you might ask?  I know I sure did.  Here is a little blurb on DECT .  If you are just DYING for information on DECT, try this.

The documentation that came out of the box with the device was very minimal.  You can also get the documentation online.  With such minimal documentation and the claim that no software is needed, I expected to be able to just fire this thing up and ride off into the sunset.  Let’s find out.

What’s in the Box

Well, there is a bit more that comes out of the box, but I did not think you wanted to see some fuzzy pic of the Safety or Setup Guide.  Setup was dirt simple.

Does it Work?

Following the aforementioned voluminous instructions, I plugged it in, let it charge a bit, stuck the USB cable into the base and into my USB hub, and voila!  Turns out that the minimalistic documentation was minimal for a reason.  Nothing more is needed. It doesn’t get any simpler than that.

But how does it work?  Audio quality was excellent.  Lync functions were immediate.  Lync controls or headset controls muted, volumed, answered, and hung up.  And the each device respected the other’s button clicks or pushes.  The headset provided aural tones to indicate button pushes.

I used Pandora to play music through the headset.  Musically, I think it could use a bit more bass.  My daily standard is a Logitech H650e – and the musicality of that device is MUCH better.  However, how many out there in device review reader land use their business headset to listen to music?  And, the wired headset has a major negative – that wire thing.  The H820e let me wander all over my expansive office space and down the hall, and up the stairs, and out into the parking lot.  I add also that in my kitchen visit, a certain microwave device did not affect the H820e at all – something that causes my Bluetooth device all sorts of disconnects and other audible issues.

Let’s talk noise cancellation.  Wowzer!  I was on a conference call with NYC and Appleton.  I had to crank my stereo waaaaay up, and then the folks on the conference could only barely make out that the music was playing.  Nice!  Whatever Logitech is doing with that slice of life they are doing very well.  Overall, the voice quality – both directions – on the H820e is in the upper range of the the “superior” category. I give the audio for the H820e a solid 9.5 on the TsooRaD scale.  With better musical response, I would give it a 10.

The Controls

The controls are raised up from the surrounding section of the unit.  This makes them very easy to find.  Once I actually read the instructions which clearly showed what button was what and where, I had no issues and each button functioned as expected.  The charging base is a solid piece of kit.  I do mean solid. The headset, while attached to my gourd, was comfortable, the boom is adjustable, and there is a little red light on the back of the boom so people behind you can see if you are stopping at the intersection on a call.

Conclusion

The Logitech H820e both Binaural (really?  BINaural – why is that term with a “N” in it? Why not just say stereo?) and the Mono are excellent devices with excellent construction, fit, finish, and with audio in the superior category.  My limited test is continuing even as I type this – and it would appear that all Logitech claims for features, function, and audio quality are well stated. You can get one right here.

YMMV

Static MAC addresses in Virtual

With the advent of more and more virtualization, and virtualized appliances, you may run across a situation where you need to assign a static MAC to a specific VM. Some virtual appliances use the MAC of the virtual NIC to figure out their licensing, so this would be a perfect example of needing to set a static MAC for the virtual machine. If/when the image moves inside the resource pool or is manually moved to a different host, if the MAC is not static, there is the specter of the VM losing the existing MAC and having a new one assigned. At this point the virtual appliance may lose its’ ability to use the license that was keyed to the MAC on the original load. The answer is to set a static MAC for that virtual machine. As a side note, you may also need to pay attention to doing this license process with only ONE NIC assigned to the VM.

For the VMware addicts:

http://pubs.vmware.com/vsphere-4-esxi-installable-vcenter/index.jsp?topic=/com.vmware.vsphere.esxi_server_config.doc_41/esx_server_config/advanced_networking/c_setting_up_mac_addresses.html

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=219

For the Hyper-V folks:

http://www.solution-soft.com/whitepapers/Microsoft-VirtualServer-StaticMAC/Microsoft_Hyper-V_Static-MAC-address.htm

For the Server 2012 Hyper-V users, the actual screens change a bit… here is a zippy screen shot.

YMMV

Plantronics Blackwire C720-M Device Review

Disclaimer:  Plantronics supplied the device

Normally, I like to take a bit of time to play with something.  Not this time.  A winner right out of the box.

And it answers the call when you put the headset on.  And paired with my cell phone.  A corded device that connects USB to my laptop for my Lync work that pairs to my cell also?  Were these people reading my mind?  Solid-to-outstanding audio quality.  Hooked up with Lync 2013.  Optimized for Lync.  Inline module buttons worked as expected, adjustable almost everything, comfy.  The only complaint I have is that the microphone boom is on the inside of the headband.  Which is being nit-picky.

Awesome.

Just go get one. 

YMMV

Plantronics Savi W440-M Device Review

Disclaimer:  Plantronics provided the device

The Plantronics Savi W4440-M is a DECT device that works very well.  You can read the official market-speak here. It comes out of the box with a plethora of choices in wearing style:  headband over the top, wire-bandy thing around the back of your head, and a customization kit for doing the single ear thing with in-ear choices.  If you cannot find a fit using this device you must be an X-Man or other mutant.

Minus the AC adapter and the quick-start guide, here is what comes out of the box. 12 different in-ear fitting options should provide something for everyone.

Here is my mug with the in-ear setup.

Build quality appeared to be first rate, audio quality was great.  In the complaint department, the “over the head” head-band gave me a headache and made me feel unbalanced.  My SO says I am unbalanced by nature, but that is a different discussion.

Lync Integration

As with other Plantronics devices, this thing just worked right out of the box.  I plugged in the dongle (to a USB hub port no less), waited an inordinate amount of time for the headset battery to charge, and wala!  It worked.  Lync picked it up right away, I did nothing special and the Savi W440-M was up and working.  While taking calls, the volume button worked as expected.  I “discovered” – primarily because I only read the documentation if I can’t work it out myself – that the volume button pushes in to provide muting.  Ha!  The Lync client recognizes the headset button pushes and displays status as desired.  Again, I did not play with the suggested software download.  And again – for my usage level, I did not need it – Lync recognized and used the device to my satisfaction.

Range Issues

I had what appeared to be pretty good range.  I went to the far end of my office space (my yard) and only at the far corners did the audio start to break up.  If you use the software (see above) you can change the range settings.  I was using whatever comes out of the box (see the online user guide) and should have had 300 feet of unobstructed range.  I don’t think I got quite that much before experiencing audio quality issues – after the fact I measured a 125 foot straight line to where the quality was dropping off.  Who knows what was between me and the dongle at that point, but at least one set of coated windows and insulation.

Summary

Range issues aside (and really who needs to go to the corner market while on a call?) the Savi W440 is a very nice device.  And the range issue could very well be my environment.  Usability, wearing comfort, Lync integration (Optimized for Lync), and build quality all point to this being a great choice for your next headset.

YMMV

Connecting Lync 2013 and Cisco Jabber

Many thanks to John Gizel.

Lync 2013 now has a built-in XMPP gateway.  If you look closely, there is an XMPP component running on both the Lync FE and the Lync Edge.  Very easy to setup.  Simply hit the box for XMPP Gateway in Topology Builder, and when you deploy the server roles, the XMPP will be installed along with everything else.  Sweet!

But, how do we configure this thing?  There are a variety of guides on setting up for GMail.com – Google Chat. But what if you need to federate with another entity that is running – literally – Cisco Jabber (you know that CUPC thing).  There are two methods, one for doing the internal-share-the-namespace thing on 5061, and another for using XMPP across port 5269.  The second method is for our scenario: the other entity is completely outside of your control.

To configure Lync 2013 to share a SIP namespace with Cisco Jabber – see this document. To be totally fair, Cisco would have you follow this document when transitioning Lync users to Jabber – but I have never seen that sacred event occur.  I am sure it does, and will in the future, but the usage I have seen from this document is to get intradomain SIP namespace sharing instantiated.  Microsoft has excellent documentation for getting the XMPP setup for general purposes, and prescriptive guidance for federating with Gmail.com.  For this article, I am going to gloss over some of the aspects of that guidance; no need for me to re-invent (re-write?) the wheel.  What I will show is how to configure the basics, and then we will take a look at how to help your business partner configure their Jabber setup.

Let’s take a look at what is involved with getting Lync 2013 XMPP configured to federate with an external SIP namespace hosted by another organization and is using Cisco Jabber.  We will need Topology Builder, Lync Control Panel, maybe some PowerShell (depends on your whim), some external DNS work for your namespace, some external DNS work on your federated partner’s namespace, a little firewall configuration (on both namespaces).  If this was Christmas time, we’d also want to work with the partridge in the proverbial pear tree.

Lync Setup

As hinted at above, if you do this before you deploy any servers, at this point all you need to do is complete your topology, and when you publish and deploy Lync 2013 Servers, the bootstrapper will setup the XMPP functionality.  If you have a topology already deployed, and are enabling XMPP after the fact then you will need to do a bit more work.  Perhaps now would be a good time to review your certificate requirements.  Hopefully you planned in advance and are doing this before you deploy.  This is one of the reasons I wrote the following:  http://blogs.technet.com/b/nexthop/archive/2012/12/11/ten-tips-plus-one-for-implementing-lync-server.aspx. Take a look at items 1, 2, 3, and 6.

If you have Lync servers deployed and the XMPP is going to be added in, the Lync 2013 documentation has some excellent guidance that I will not attempt to re-write.  You can read that guidance here. Be sure to follow all the links provided in the table as they lay out the requirements for enabling XMPP.

Certificate requirements on your Lync 2013 Edge pool will be simplified if you do all of this before you deploy.  This is because the certificate wizard will see that XMPP is desired, and will populate the certificate request with your domain name. If you have multiple SIP domains, make sure that all of them that need XMPP federation are listed on the certificate request.  For the curious, all that is needed for the XMPP piece of the certificate is the domain name:  tsoorad.net, domain.com, etc.

Here is my Lync 2013 Edge certificate – you can see where the SAN has an entry for just the domain name. And yes, I included AV on my certificate even though that name is not needed. You can also see that I use this certificate for my Reverse Proxy (a TMG at this point in time).

In the Lync 2013 Topology Builder, open the properties of the your site, and then select  the check box “Enable XMPP Federation.”

From there, go to your Lync 2013 Edge Pool and edit the properties. What you want is the “Enable XMPP Federation for this Edge pool (port 5269) to be checked.

 

Next, publish the topology and either deploy the servers or update the servers. The official documentation referenced above has explicit guidance for doing either action.  You did read all that, yes?

DNS Internal

For XMPP support, the internal DNS is unchanged.  Your clients will communicate with the FE servers as normal.

DNS External

Whatever you do, don’t forget to create an _xmpp-server SRV record in your external DNS. The SRV definition is this:

_xmpp-server._tcp.domain.com with a target of your access edge A record. 

In DNS-speak, this is seen as:

Name	TTL	Weight	Priority	Port	Target
_xmpp-server._tcp.domain.com	3600	0	0	5269	sip.domain.com

In my case:  _xmpp-server._tcp.tsoorad.net which points at sip.tsoorad.net.  Port requirement is 5269.

Firewall Requirements

5269 open in both directions.  Simple and sweet.  But!  Be sure to configure the firewall to pass 5269 to and from all possible Lync 2013 Access Edge IP addresses.  To whit, if you have a DNSLB Edge, then at a minimum you will have two IP addresses that will need to be bidirectional for port 5269.  If you have an HLB Edge, then the number goes to three minimum.  Failure to observe this requirement may result in random behavior.

Lync Control Panel

Once you have your server deployed, the edge server deployed, your firewall configured, and all the certificates are correct, open up your Lync Control Panel and go to the Federation and External Access tab so that we can create the settings for your Jabber federation.

First, make sure that the external access policy that applies to your users at whatever level have the “Federated User Access” selected, and that the Access Edge Configuration allows “Federated user access.”

 

Now, lets add our partner’s SIP domain in so that the Lync Edge thinks it is OK to at least attempt to communicate with the other domain.

Select the “XMPP Federated Partners” tab and click on “New.”

Fill in the blanks (literally) with the information required.  What is shown here is what I know works.

Note that the “Partner Type” here reflects the following:

• Federated   A Federated partner type represents a high level of trust between the Lync Server deployment and the XMPP partner.  This partner type is recommended for federating with XMPP servers within the same enterprise or where there is an established business relationship.  XMPP contacts in Federated partners can:
  1. Add Lync contacts and view their presence without express authorization from the Lync user.
  2. Send instant messages to Lync contacts whether or not the Lync user has added them into their contact list.
  3. See a Lync user’s status notes.
• Public verified   A Public verified partner is a public XMPP provider that is trusted to verify the identity of its users.  XMPP contacts in Public Verified networks can add Lync contacts and view their presence and send instant messages to them without express authorization from the Lync users.  XMPP contacts in public verified networks never see a Lync users’ status notes.  This setting is not recommended.
• Public unverified   A Public unverified partner is a public XMPP provider that is not trusted to verify the identity of its users.  XMPP users on Public Unverified networks cannot communicate with Lync users unless the Lync user has expressly authorized them by adding them to the contact list.  XMPP users on public unverified networks never see Lync users’ status notes.  This setting is recommended for any federation with public XMPP providers such as Google Talk.

You will want to set this to what your organization requires.  This setting is “tiered” in the setting is most open at the “Federated” level, and most restrictive at the “Public unverified” setting.  For the unverified, your users will need to add the federated contact into their Lync contact list before expecting to be able to IM with the remote Jabber user.  This is roughly equivalent to the settings for a PIC provider verification level.

PowerShell

One of the things you are most likely to want to set, especially if you have more than one Edge server in either DNSLB or HLB, is the “DialBackPassphrase.”  This is done with the Set-CsXmppGatewayConfiguration cmdlet.  One setting fits all.  There is a default setting, but I like to set it manually to make sure it is set.  The command looks like this:

Set-CsXmppGatewayConfiguration -DialbackPassphrase Tsooraddialback

With the results looking like this:

Here is the list of XMPP related cmdlets. 

Get-CsXmppAllowedPartner
Get-CsXmppGatewayConfiguration
New-CsXmppAllowedPartner
Remove-CsXmppAllowedPartner
Set-CsXmppAllowedPartner
Set-CsXmppGatewayConfiguration
Test-CsXmppIM

Note that there is a “test” cmdlet.  I recommend that you try that out before you proceed much further.  A complete description and usage for the Test-CsXmppIM cmdlet is here.

Setup XMPP Federated Partner

Now that our Lync 2013 XMPP is configured and published with Topology Builder, you deployed the servers (or modified them), changed your external DNS, modified your firewall, and changed your cert, have established your Jabber federated domain, and tested your setup, we can look at helping your Jabber friend with their setup.  The following is based on CUPC Server 8.6.1.

First, make sure that the partner has their external DNS SRV record correct.  You may want to inquire about their firewall and port 5269 at the same time.  Your bottom line is that until you can do the following from your Edge server, you have no hope of success.

Likewise, your Jabber partner must be able to do the reverse.  Here is how my lab looks to the world:

Go to the CUP Server and under Presence, Settings, check these boxes, especially the email one.

Under Presence, Inter-domain Federation, XMPP Settings, set to this: (ignore CUPC 7.0 support)  (note:  I did not configure the secret-take the default)

Then go to: Presence, Inter-domain Federation, XMPP, Policy and set as desired:

Then go to Messaging, Group Chat Server Alias Mapping and add all of the email domains your CUP server supports:

Restart all of the XCP services (but better to reboot the server if possible)

 

Down Here at the Bottom

We have looked at how to setup Lync 2013 XMPP Gateway and how to configure a Cisco CUPC 8.6.1 to Jabber to Lync across port 5269.  A few key take-aways:  DNS, certificates, firewalls, and prior planning.

YMMV

Plantronics Voyager Legend UC Device Review

Dislcaimer:  Plantronics provided this device.

I had an excellent English professor back a few decades ago. His mantra was “do not use 100 words when 10 will do.”  Decoded, that means keep it short, simple, and to the point.  Accordingly, this is the short version of my Plantronics Voyager Legend UC device review.  This is actually the third version.  The first version was long, had pictures, and rambled about with features, contents of the box, yada yada yada. My second version was about three sentences. This, then, is the third version – with some contents of the first version and the three sentences of the second version.

Background

A Bluetooth device for your cell phone (and Lync) becomes, to a large degree, how well the device fits your ear/head, and how well it integrates into your life and usage.  Face it, after you get the device setup, and connected, all of the devices on the market operate pretty much the same.

However, there are some choices that make life easier to deal with.  For instance, in-ear or on-ear – I am an “in-ear” user – I don’t like the way the “on-ear” flops around.  The Voyager Legend is an “in-ear” – and it comes with a choice of ear-thing sizes.  There are some "in-ear” devices that just plug into your ear like you are a secret agent, but they tend to flop around also.  The Voyager is not only ‘in-ear” but it also goes around the back of your ear. Very comfortable (to me). 

What comes in the Box

What I have in front of me appears to be a retail box with a label identifying the contents as “Voyager Legend UC, B235-M, NA”  Part Number 87680-1.  Apparently made in April 2013 – well, it has a date code.

Here is your single picture for this article:

Notice the THREE different chargers… wall outlet to USB, USB cradle thingy, USB Cable to magnetic doohickey that fits the earpiece and a FOURTH option – the case.  The case holds the earpiece, and the USB dongle – and it can be charged so that you have a fully charged earpiece (good for 7 hours and a boatload of standby) and the case can recharge the earpiece twice. Yowza!

For informational purposes, I deliberately drained my earpiece and used the case to recharge – never had an issue.  And while we are on that subject, I got an honest 6+ hours of talk time; I had to TRY and run the battery dead. Nice, Nice, NICE! There is software to download from Plantronics to do something with this device – but I never did anything with it, never downloaded it.  No need when I got my required functionality with the OOBE.

Lync

I wish there was room for fault, but plugging the USB dongle into my laptop resulted in Windows 8 and Lync 2013 starting to use the Voyager Legend.  It DID take about 30 seconds to work the first time through.  Apparently you cannot have the device operate Lync and my cell phone at the same time.  There!  A complaint. 

Conclusion

Did you wonder where the three sentences from the second version were?  Here they are, truncated to what was simple, and direct:  IMHO, what a great piece of gear.  I guess I am down to only seven words in one sentence being required.

YMMV

Is my HLB device a Reverse Proxy?

Ever since Microsoft announced that TMG was no longer to be sold, the Exchange and Lync implementers of the world have been somewhat at a loss.  Why?  Because the officially supported stance in the product documentation for both Exchange and Lync still says that the best practice is to abstract the environment from the nastiness in the outside world with a Reverse Proxy.  In other words, bring your outside web traffic in through your firewall, but don’t let it touch your servers.  Land that traffic on a Reverse Proxy (which one is the big question) and keep those baddies away from your internal environment. 

This raises the question of which Reverse Proxy to use.  Most of my projects have included some form of load balancer, and the load balancer product vendors will blithely state that “by definition, a load balancer is a Reverse Proxy.”  I know the fine folks over a Kemp Technologies certainly said that (guess where that quote comes from…) (to be fair, I get the same answer from Barracuda and F5 also)– and assuming that an HLB/VLB from one vendor operates pretty much the same as the next vendor, the purpose of this article is to put the concept to the test. In the immortal words of Ronald Reagan, “…trust but verify…” Let’s dive in.

Scenario

For our test, we will be using the following setup: 

• An external user on IP 10.10.10.104. 
• A firewall (TMG in this case) with an external IP of 10.10.10.58, and an internal IP of 1.1.1.2. 
• A Kemp VLB on the internal net of 1.1.1.0/24; a WAS VIP of 1.1.1.45, and two VIP member servers of 1.1.1.46 and 1.1.1.47. 
• I took the liberty of disabling the 1.1.1.47 node.  This enabled me to know exactly where the traffic would be going – making the network tracing much easier. 
• The firewall is doing a NAT from 10.10.10.58 to the VIP on 1.1.1.45. DNS is setup all the way around so that the workstation is attempting to contact https://lswaspoolext.tsoorad.net which DNS tells it is 10.10.10.58.

Here is a graphical representation:

Here is what the Kemp looks like, just in case you don’t trust me:

Workstation Traffic Analysis

From the workstation the browser saw this:

From the workstation, NetMon saw this:

From the top, the workstation on 10.10.10.104 is talking to the network printer, the domain controller, the network printer (again), (and again), www.google.com, the DNS resolution of 10.10.10.58 (our target URL of lswaspoolext.tsoorad.net), the firewall IP (again), Google (again), my network WAP (10.10.10.16), my DirectTV (10.10.10.103) and this workstation.  The IPV6 traffic is 100% between my work laptop and my Twist (which was my external workstation for this test).

Workstation Conclusion:

The workstation for this test is talking ONLY to the 10.10.10.58 address to get the data from lswaspoolext.tsoorad.net/hosting/discovery.

Firewall Traffic Analysis

Here is the Netmon trace on the Firewall:

Without proving the point again, I can identify all the traffic sources that the firewall is talking to on both interfaces.  At no time during our test did the firewall talk to 1.1.1.46 or 1.1.1.47.  The firewall did trade traffic with 1.1.1.45, the WAS VIP on the Kemp.

Office Web Apps Server Analysis

And finally, to whom was the WAS talking?  Let’s see:

It would appear (to me at least) that the server ls2013was1.tsoorad.net – which is responding to and delivering the content requested by our workstation  - has no knowledge of the workstation, or for that matter, the firewall through which the workstation is connected.  Slick!  Apparently, the techie mavens I talk to regarding using an HLB device as a Reverse Proxy might have known what they were talking about (I will never tell them – their heads are already big enough).

Conclusion

We traced the traffic all the way from the origination workstation through each step in the path.  For each hop, with our interest on who talked to who, we saw that the workstation never communicated directly to our target.  The traffic was definitely PROXIED by the Kemp VLB – to whit, traffic stopped at the HLB, the HLB retrieved the data requested, then returned that to the requestor.  To be fair, the TMG (our firewall) was doing the same thing, but I think you get my point.  Now you can tell your client with all equanimity, yes, the Kemp HLB is also a Reverse Proxy. Can we make the same assumption for other vendors?  I defer to Ronald Reagan.

YMMV

Plantronics Calisto 620-M Device Review

Disclaimer:  Plantronics provided the device.

What it is

The Plantronics Calisto is a “Blutetooth Wireless Speakerphone + Bluetooth USB Adapter” device.  Long words short, a speaker phone device.  It does make me wonder about the marketing/media-speak though.  The Calisto comes with a charging cable that is for charging only.  OK.  Got it.  But if the device REQUIRES the Bluetooth connection to operate, isn’t it reasonable to assume that a device-specific adapter would come with?  Does it operate better with the custom adapter than with my laptop’s built-in Bluetooth?  On a side note, does anyone know why this technology is labeled “Bluetooth?” 

Ok, I went and looked it up.  Provided we can trust the ubiquitous wikipedia.com -

No matter.  Let’s take a look at this Calisto and how it operates with Lync – our primary reason for living, yes?

What is in the box

Here is what comes out of the box. 

I did not include the nifty carrying bag in the photo. Also, I did not include the warranty and safety paperwork.  Which brings me to a quick question:  Safety notice?  Do we expect that folks are going to take this unit into the bathtub or use it in a flooded basement? I get it, I really do.  But this litigious society we live in slays me.  What ever happened to personal responsibility?  </Rant Off>  Adelante! 

Build Quality

From me playing with the Calisto, it feels very solid.  The USB connections are nice and tight.  The USB adapter holder thingy in the Calisto bottom panel has some rubberized feet and I don’t think the dongle will fall out of the holder without some secret agent work.  You could, of course, put the dongle in backwards – at which point  it will fall out at the worst possible moment.  The Calisto bottom panel itself has rubber booties; it did not slide around on my desk.  Nice.  The USB adapter connection to my USB port was tight.

 

Features

The list is not too long.  The Calisto is pretty simple.  Volume up/down.  Call button; Mute button, USB and wall charger, and a USB dongle.  It will also pair with your cell phone.  The instructions are in the four-language instruction sheet that comes in the box. Odd.  Why does the Calisto come with only four languages on the instruction sheet but a headset gets 15?  Is the Calisto somehow less worthy?  Out of the box, the instructions lied to me, or, my USB hub produces more power than the average laptop USB port.  The claim was 2.5 hours to fully charge from the USB port.  And that 30 minutes is needed to initially charge.  I did neither.  From plug-in to setup to fully charged took less than 20 minutes.  In fact, when the battery charge indicator went dark I was concerned that the unit had somehow failed.  Maybe the unit was partially charged coming to me in the tidy retail box?

Lync Integration

As an “Optimzed for Microsoft Lync” device, the Calisto supposedly works with Lync, understands Lync, and controls Lync to the extent that the function buttons on the Calisto will affect the corresponding function in the Lync client.

Well, yes it does.  The Lync integration was completely seamless. The instructions would have you download some software. I have no idea what the software does, I never needed it, so I never downloaded it.  Why mess with something that is already working perfectly?

The instructions cautioned against using a USB hub, but I like to live on the edge, so I plugged the dongle into my hub.  I plugged my charger cable into the same hub, and I was done.  Done as in I did nothing else and Lync 2013 was operational with the Calisto 620.  Mute muted.  Call button terminated calls.  Volume volumed.  All with pleasing dulcet tones to announce function.  The Calisto took over as my audio device.  The only thing it cannot do is dial the number for you.  But if you make a call with the Calisto plugged in and selected as your audio device, you will be pleased with the outcome.  A very minor complaint is that the Calisto became my primary and it relegated my headset (my preferred device) to secondary.  Even when turned off, the Calisto was primary and I had to manually swap the preferred and secondary devices (This could be a Lync thing and not a Plantronics thing).

Here you see the Calisto with a call in progress, with the microphone muted, and the Lync 2013 client showing the same thing.

 

Complaint Department

It could be just me but I found it difficult to tell if the button got pushed in terms of feel.  The unit responds directly with sounds and lights, but John is a button-feel person.  I think a little tactile clicky or break or something would be in order.  I also think the USB pairing lights could be a touch a lot brighter.  If you aren’t paying attention, you might think the USB connection died. Also, why not have a dial pad on this thing?  Then you could press the call button, dial (DTMF actually) and have a complete speaker phone.  Of course, I may have missed something, but I don’t want to push the call button on one device and dial from another.  I guess if you want that you need to pony up the extra $50 and look the Calisto 800 series.

General Observations

Even plugged into my USB hub, overall performance and audio quality is excellent.  Both send and receive is very clear.  The microphone picks up the human voice spectrum nicely.  The speaker has enough volume and richness for the task; it sounds very nice. Excellent, really.  I can see placing this unit into a small conference room where 4-6 people are around a small table and one person brings their laptop or perhaps there is a conference room workstation.  The Calisto 620 would shine in that role.

YMMV

Plantronics Blackwire C320-M Lync Device Review

Disclaimer:  Plantronics provided the headset.

What it is

The Plantronics Blackwire C320-M is a “Optimized for Microsoft Lync” stereo (bi-aural) USB headset.

Build Quality

This headset demonstrates the first class build quality that we have come to expect from Plantronics.  In particular, on my laptop, the USB connection is nice and tight – not all loose and nasty like some devices.The rotating boom mike stays put rather than flopping around, the foam earpieces look and feel good, and the wire leads in and out of the inline control button thingy have reinforcements that make me think that the leads won’t be breaking or pulling out anytime soon.  Overall, pretty doggone nice.

Features

The headset lead has the typical built-in buttons for call control, volume and muting – except that as a Lync-optimized device, these controls actually control Lync also.  The microphone boom has very nice feel to it.  And you can bend it to fit whatever position you want it to be in, and it stays there.  I like it.

Lync Integration

The documentation for this headset consisted of a single multiple-folded (made up that word just now!) 15 language, single piece of paper.  Of which 4 pages actually covered everything you need to know and then some.  What is more important was that on multiple systems that I checked this device on, I never needed to read anything, configure anything, or mess with anything.  I plugged it it, and it worked.  The call button takes Lync off hook as expected and terminates the call if you press it again.  The mute button makes a rising beep when it mutes, and a descending beep tone when you unmute.  And yes, the buttons controls the Lync client as well.

The buttons light up to show function.  In a call and muted:

 

The volume up/down makes louder and softer tones also – with no discernable change in the system settings (volume mixer) – but the volume goes up and down.  Nice trick, eh wot?

The Plantronics official tear sheet is here. I have used this headset for a week on four different workstations; used it for meetings, regular calls, Lync meetings, calls to cell phones and calls to other Lync users.  In each case the audio was crisp and clean.  The microphone is sensitive, but the device also seems to be very good at blocking the extraneous background (i.e.: something that is not right in front of the microphone boom).  According to the official brag material up on plantrontics.com, this headset has “…Dynamic EQ…” – whatever, it seems to work well.  When it came to Lync, both 2010 and 2013, this thing just worked, and worked well.

Complaint Department

There were two things I did not like about this unit.  One of them might be because Plantronics shipped me a bulk-order unit and not a boxed unit.  The first is that there is no clip or something to hold the headset lead to your person/clothing/otherlocation.  I tend to find the inline control module under my forearm on my desk with me accidently pushing buttons in an un-wanted fashion.  Annoying.  And such a little detail.  The second is that the wire/cable from the USB connection to the headset itself is sort of … stiff.  It might be just me, and I am wire bundle challenged – but the headset lead kept getting in my way.  Over the course of a week, it never got more flexible.  OTOH, this might indicate that it won’t break!

General Observations

Overall, I like this device.  When you consider that a quick Google-fu session prices this unit in the $35-47.50 – this headset starts to look better and better.  And comfy for my brain housing group also.  Over the week, I not once thought that I had something uncomfortable latched onto my gourd.  Combined with the overall workings and build quality, that might be what makes the decision.

YMMV.

Lync 2013 EE pool won’t start

Sub-title: We get to explore the Reset-CSPoolRegistrarState cmdlet

Life is tough.  Apparently the drunk that took out the power station the other day and caused a major power outage in my zip code is going to find that out.

What I found out was that when my lab restarted, the Lync 2013 Pool FE servers would not start any service except for the Replication Service (Lync Server Replica Replicator Agent – who names this stuff anyway?).  Wowzer.  This is not good.  I know that having only two nodes puts me living on the edge, but it is only a techie lab with no real users!  Never had this bad of a failure before.  I have been good and followed the restart instructions for a two-node EE pool.  You have read that, right? If not, here you go.  Look down at the bottom of the page – you will catch on quick. 

Issues like this is why I always recommend having Lync 2013 EE pools with at least three members.  Can’t have that quorum deficit biting you!  At the very least, I rant and rave at some length about setting up for failure and make sure the administrators of the impending doom system know what is what and the risks and the mitigation process.

In our little story, the command

Reset-CSPoolRegistrarState –ResetType QuorumLossRecovery –PoolFQDN ls2013pool.tsoorad.net

(runs on each pool FE member) did not achieve the desired pool state.  At about this time, I am really starting to exercise my military jargon skills.

When the power did come back on, there was no way to follow the recommended practice of starting the servers in reverse order they went down – they both went down at the same time!  The event viewers had enough red errors in them to allow me to open a paint store.

What to do, what to do?  Well, our intrepid hero simply dusted off the command syntax for Reset-CSPoolRegistrarState. Take a gander at this explanation of the reset types:

* ServiceReset – The RtcSrv and fabricHostSvc services are stopped and restarted. A service reset will be performed if the ResetType is not specified.

* QuorumLossRecovery – Reloads user data from the backup store for any routing groups currently in quorum loss. (A quorum loss occurs when neither a database nor its replicas are available.) Data not yet written to the database could be lost when you do this type of reset.

* FullReset – performs the same type of reset as QuorumLossRecovery but, in addition, rebuilds the local Lync Server databases. This type of reset can be potentially long and resource-intensive.

* MachineStateRemoved -- Removes the specified server from the pool. This type of reset should be used only when the server in question (or its databases) have been permanently lost.

A short period of pondering removed the “MachineStateRemoved” from being a valid fix, and the “QuorumLossRecovery” had already failed. so I ran the following (you might want to run the Lync Management Shell as Administrator, or you will find out why I always run PowerShell as Administrator): 

Reset-CSPoolRegistrarState –ResetType FullReset –PoolFQDN ls2013pool.tsoorad.net

I then did a “Shutdown /r /t 0” to get a system restart.  One at a time, mind you, but I booted both my EE nodes after running the reset-cspooregistrar cmdlet.  Success!  The sun is in my sky once again.

Now, this is a little drastic, but what the heck?  To quote Alfred E. Newman, “What, me worry?”  In my case, the lab pool was not starting anyway.  In a real life situation the data loss would be that data that had not committed to the local database prior to the failure.If you run into this, and the pool won’t start anyway, there is probably a bigger issue than losing a few contacts or a few chats.  .

YMMV.

OCS R2 client and Lync 2013 Server

Scenario

I have a coexistence issue: I need to have a boatload of R2 clients connect to a new Lync 2013 environment.  Backwards compatibility has been installed, the R2 environment has been imported with Topology Builder, and users can be moved between the R2 pool and the new 2013 pools.  We can chat back and forth, send files, use A/V and even participate in the same conferences.  External, remote, and Federation scenarios work just fine.

So what is the issue?  Today, the _sipinternaltls._tcp.domain.com SRV record points to the FQDN of the R2 pool.  Which works just fine.  When the 2013 pilot group cranked up, they found the lyncdiscoverinternal.domain.com record, hit the 2013 pool as expected, and logged in.  Perfect.  The issue in front of us today is moving the target of the _sipinternaltls._tcp.domain.com from ocspool1.domain.com to sip.domain.com  - we want to decommission the R2 pool at the end of this project.

Our plan is to simply set the SRV record TTL and the associated A record TTL to something very short, and then after waiting for that propogate, change the SRV target to sip.domain.com.  To test this, we went to an R2 client and set the manual configuration as shown. 

However, this failed with “server not available.”  We also noted that on the initial setting of “manual” the TLS option was greyed out and the initial connection attempt failed.  Checking the manual settings again revealed the TCP setting selected, but now we could change to TLS as the settings were no longer greyed out.  Odd.  Strange.  And totally consistent from machine to machine.  Can’t explain it.  After the initial failure, the TLS setting would hold, but still we had “server not available.”

The Fix

After running around the settings several times, and checking the Client Version policy at least twice, and making sure that the workstations in question could resolve sip.domain.com properly, we turned to the Client Version Policy again. It turns out that this is the default setting for the Lync 2013 Client Version Policy.  Note that it says OC 3.5.6907.233 and OLDER should be blocked. 

A cursory check of the clients tested showed versions of 3.5.6907.261 and 253.  Newer right?  Apparently not!  Setting this policy element to ALLOW fixed the issue and now the mix of R2 clients can login just fine using sip.domain.com as the “director.” which points to the new 2013 pool.  Because the SIP domain and the AD domain names match, there are no certificate issues.

YMMV.

Lync 2013 Internal and External Web Sites

Lync 2013 (and 2010 for that matter) documentation recommends using a Reverse Proxy to abstract the Lync Server Front End Web Services from the baddies on the outside world.  A cursory look at a Lync Front End Server will reveal that the Lync Server installation process does indeed create two websites.  But what is the difference?  What might be the possible reasons for having two websites?

Here is a typical Lync EE pool server IIS manager showing the Lync Web Services.

Two websites. Because the websites are both using the same IP address, different ports are needed. If you look at the binding for each you will see the External answering on ports 8080 and 4443 while the Internal is setup on 80 and 443. 

 

Because we are exposing our internal server we want the Reverse Proxy to stop traffic and play fetch for us.  Understandable, yes?  Because we have two websites that are different but on the same IP, we need different ports.  Again, understandable.  But if you look at the following eye-chart – you can also see that there are differences in the virtual directories. The Internal virtuals down below that are different from the external website (in addition to, and similar but named differently) simply have no business being exposed to non-internal users; I think the virtual directory names provide all the clues you need to agree with that assessment: CSCP (the control panel), OCSPowerShell, and RGSconfig (Response Group Configuration page) jump out at me. 

If your Lync Web Services get their authentication scheme messed up (now how would that happen?) you can also use this handy chart to return the website and virtual directories to their initial state.  How convenient is that?

So, we can see that there is a few reasons to have two websites:  two websites on the same IP but using different ports, the difference between virtual directories on the internal v external websites, and the content that is not very desirable to expose to external users who just might not be your best friend.

YMMV

Lync 2013 CU1 UCWA Errors

Just had a small issue trying to publish Lync 2013 Topology where it would appear that the Lync Server 2013 CU1 update duplicated all the 2013 FE Server MSRTCSIP-TrustedService entries for the UCWAInternal and UCWAExternal services.  Everything looked fairly good until it came time to enable-cstopology.  Here is the error we got.

“Multiple Active Directory entries were found for type “MS-RTC-TrustedService” with ID of fqdn.domain.com/UcwaExternal.

Fixing ONE of these resulted in the next item on the list being found and then erroring out.

Ouch.

I went through and renamed the service names on all 4 FE servers to update so the enable-cstopology only saw one valid entry.  This was needed on three (3) Enterprise FE nodes and on an SE FE server in the environment.

Will update this accordingly if this proves to have borked up something else.  Why this occurred is not known to me, other than running the CU1 updates into the environment.

YMMV.

Office WAC (WAS) Server Update and Lync 2013

Microsoft has an update, if you can call it that, to the Office Web Apps Server that is used (amongst others) by Lync 2013.

This “update” is 584MB of download, and will require the following procedure to update your Lync 2013 WAS (WAC) server(s).  If you have a one server pool, no problem.

Open powershell on the host server as and administrator….

Remove-OfficeWebAppsMachine

Do a Get-OfficeWebAppsFarm just to confirm the box thinks the farm is gone.  Then run the update.  It won’t take but about 10 minutes and wants a reboot.

Then recreate your Office Web Apps Farm with “new-OfficeWebAppsFarm”

If you have a pool of two or more servers, then you might think you can do one node at a time, right?!  Not so fast young Padiwan.  Remove the WebAppsFarm in its’ entirety.  As in take it completely down.  Go to each node in the farm, and run the Remove-OfficeWebsAppsMachine.  Once the last server is out of the farm, ensure the farm is really gone.  Then run the patch/update in, then reboot the entire mess. After that, recreate your Office Web Apps Farm.  You did record all those commands when you first put the farm together, right?

Enjoy taking the entire farm down for an update.

YMMV.

Lync 2013 WAS Handler Error 500.21

This whole thing started very simply.  Install a Office Web Apps Farm for a Lync 2013 deployment. 

We are using Server 2008R2 SP1, fully patched.  The Web Apps Server (WAS) installed correctly, or so it seemed.  But then the farm failed to create.  This was tracked down to MS KB 2670838 getting in the way of installing MS KB 2592525 – removing MS KB 2670838 solved that – with a weird side-note – removing 2670838 also removed IE10.  There is ample evidence on the web that 2670838 is dirty dirty dirty, bad bad bad.  Things are starting to go sideways here!

So we finally got the patches straight, MS KB2592525 goes in.  Now the farm created, but then we could not hit https://fqdn.domain.com/hosting/discovery with an error of 500.21, and a claim of “ http error 500.21 handler “discoveryservice” has a bad module managedpipelinehandler” …  El Yucko!

After some searching back and forth, it seemed that asp.net was either not installed or was not registered properly.  Looking at the installed set of programs and features on the IIS indicated that ASP.net was indeed installed….

What was needed was to reregister the ASP.

%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -i

Finally.

YMMV

Logitech USB Headset Stereo H650e (A-00057)

Wow, what a name.  Makes me think that I am back in the Army looking at the “nomenclature” for a “pin, retaining, bolt, rifle, M14” or some such.

I also have a Logitech USB Headset Mono H650e (A-00050) on hand.  Comments here will apply to that device also, with the understanding that the single-ear headset will never touch my sacred skull except for testing.  I don’t know how people do this one-ear thing.  I have a hard enough time with my cell phone Bluetooth for a short call, let alone something for all day use.

As a disclaimer, Logitech did send these units to me for evaluation purposes; however, there were no strings attached, nor any pressure to say anything good – or bad – about these units. Folks who know me are well aware that if something sucks, I will say so.

Features

The headset itself is very comfortable.  I used it all day today – essentially non-stop.  I never got any feeling that I needed to take it off – not something I can about my other headset (also a Logitech) which is several years old and much heavier.  The microphone boom on these units is adjustable for both angle-of-dangle from the earpiece as well as actually adjusting the boom itself to be where you want it.

The wire/cable leading from the headset to the USB connector is flat – supposedly to be a non-tangle feature.  Well, it works out to be true.  There is also a handy-dandy clip you can attach to the headset lead to hold the lead to your clothing and keep the control module off the desk where I typically stick my arm on it leading to unpredictable button pushes.

The control module itself has a microphone mute button, volume up/down, and an answer button.  The nicest thing about this headset (other than it having excellent audio quality) is the interface with Lync.  The mute button toggles Lync itself – Lync reflects muted and not muted. 

The call answer button will answer a Lync call and also hang up a Lync call.  Nice.

Audio Quality is excellent.  The headset earpieces are all-day comfy and the headband has a nice cushion on it to keep your head from not getting a hot-spot and causing headaches.  The volume control worked well, and the definition was much better than my current (old) Logitech unit.  My one complaint about the unit is that the microphone is so good I had to go into Lync and turn the microphone sensitivity waaaaaay down to make it appear that I was not shouting.

As a final piece of niceness, the back of the microphone boom has a red light that lights up when you are on a call.  Someone walking up behind you has a visible indication of you being busy!  This worked twice already today when someone walking in could see I was active on a call.

Conclusion

Overall quality, IMHO, is most excellent.  Audio, fit, finish, comfort and controls are all at the top of the chart.  Installation onto my laptop consisted of plugging into a USB port, waiting about 10 seconds and starting to use it.  Painless, and very typical Logitech.  Nothing else required.

The stereo unit is now my daily device.

YMMV

Lync 2013 RASK

 

Have you decided that you don’t have enough light reading in your life? 

Lync 2013 Rollout and Adoption Success Kit (RASK) Core Planning Resources

http://www.microsoft.com/en-us/download/details.aspx?id=37030

Lync 2013 Rollout and Adoption Success Kit (RASK) User Education and Training Resources

http://www.microsoft.com/en-us/download/details.aspx?id=37032

Lync 2013 Rollout and Adoption Success Kit (RASK) Resources

http://www.microsoft.com/en-us/download/details.aspx?id=37031

Enjoy!

Lync 2013 User Quick Reference

Realizing that this is old news to you seasoned professionals out there, here is a great set of Lync 2013 User Guides – Quick Reference documents.  The imbedded links pull up PowerPoint documents that you can print and distribute to your users.

http://office.microsoft.com/en-us/quick-reference-cards-about-lync-HA103433496.aspx

YMMV

Jabra Supreme UC MS

Yet another short product review.  This time a Jabra Bluetooth headset.  The box is labeled “Jabra Supreme UC MS” and there is a label that says “optimized for Microsoft Lync.”  Let’s find out.

One of the problems I had writing this article was that there was nothing negative to report.  You can find the manufacturer brag sheet here.

This is what comes out of the box:  the USB key and the headset in a nice little case (not pictured), a USB charging cable, a car adapter, extra ear cushion and wire thingy, a 110 adapter, and the ubiquitous instruction booklet. Fit and finish appear to be first rate. The wire-thingy to fit your ear is bendable/adjustable to provide a custom fit.

I pulled it out of the box, gave it a charge, and then plugged in the included USB key thingy, and it just worked. I will note that I did not even read the little instruction manual other than to see what the buttons did. This is a folding device that turns on when you open the microphone boom.

When I pushed the USB dongle into the USB port, my laptop loaded some drivers and then the Lync 2013 client discovered the headset and started using it.  Painless and worked well.  I literally did nothing special and the Jabra Supreme UC lived up to its’ name right out of the box.

Audio was clear and crisp. Noise reduction was excellent. I made several test calls and asked the other end about the audio quality. In each case the other person assumed I was on a wired headset. Nice. 

I was able to pair to the Lync client as well as my cell phone at the same time. Pairing with my cell phone worked first time through with no hassles. Several times I had calls on both – it took a few fumbles to get the correct device answered, but that is just a learning curve on how to use the new piece of gear and not a hit on the Jabra usability or functionality. After pairing with my phone, I was alerted that there was a Jabra app that would enable better experience – I declined to install this. But, even without it, this device worked as expected. What the app does I do not know.

Overall, I think this proved out to be an excellent device.

YMMV.