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.

YMMV

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.

Function

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.

Comfy?

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 30i – CX 275s.

YMMV

Updated Lync Connectivity Analyzer

Announcing the Release of the Updated Lync Connectivity Analyzer.

Read all about it right here.

YMMV

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.

YMMV

W32tm Server 2012

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

Scenario

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.

YMMV

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
0	0	0000.0000
+1	3600	0000.0E10
+2	7200	0000.1C20
+3	10800	0000.2A30
+4	14400	0000.3840
+5	18000	0000.4650
+6	21600	0000.5460
+7	25200	0000.6270
+8	28800	0000.7080
+9	32400	0000.7E90
+10	36000	0000.8CA0
+11	39600	0000.9AB0
+12	43200	0000.A8CD
-1	-3600	FFFF.F1F0
-2	-7200	FFFF.E3E0
-3	-10800	FFFF.D5D0
-4	-14400	FFFF.C7CD
-5	-18000	FFFF.B9B0
-6	-21600	FFFF.ABA0
-7	-25200	FFFF.9D90
-8	-28800	FFFF.8F80
-9	-32400	FFFF.8170
-10	-36000	FFFF.7360
-11	-39600	FFFF.6550

Example

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.

YMMV