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.”
As always, YMMV.
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.
When using the earbuds with Lync 2013 Mobile Client, I had excellent results. ‘Nuff said.
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
Announcing the Release of the Updated Lync Connectivity Analyzer.
YMMV
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
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.
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.
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
