For those of you who are Kemp Technologies customers… I have the new firmware up and running with zero issues. Firmware upgrade was seamless on a vlm-200. Total process from backup to rebooted and functioning was less than 15 minutes.
The new interface is much appreciated. While the GUI does a few things I don’t like, don’t let that get in your way. Overall, this release is a home run.
This update has a raft of new features and fixes. You can read up on it here.
YMMV
I used my favorites in Win7 and Win8 because it gave me one click access to commonly used items.
Well, here comes Win10, and the Quick Access concept. Nice enough, but not the same. But it contained my migrated favorites, so I was not too unhappy. But, the other day, “something” happened, I am sure I did it, but I will be damned if I can figure out what. Bottom line was that my single-click links were no longer there.
Sadness.
Today I had a little time to dig in and figure it out. After reading a ton of blog-o-sphere stuff, and some useless Technet and equally useless forum postings, I found something that I figured couldn’t hurt to try:
Run command prompt as admin and type the following command:
del %appdata%\microsoft\windows\recent\automaticdestinations\*
Happiness. Now my stuff is back. All I need to do know is figure out what, why, when, and how.
YMMV
Reference: http://tsoorad.blogspot.com/2015/09/skype-for-business-hybrid-with-o365.html
Now see this:
This is looking better and better!
YMMV
Surface Pro 4 and Surface Book. Ooooh. Aaaaaah. Cannot choose. But I will have to. The horror of it all!
The Surface Pro 4 appears to need a separate keyboard, while the Surface Book appears to come with. I value screen size over almost everything else. And I use my 16GB RAM on a regular basis for virtuals.
Christmas is coming. Just sayin’
YMMV
Here is a view of my house; I rolled back the rock the other day and ran into a little PIN Authentication issue.
As we know, since Lync 2013 and the advent of the full-blown LyncDiscover.domain.com and LyncDiscoverInternal.domain.com concepts, the Lync 2013 (and now SfB) client does not need anything to accomplish a login other than being able to find LyncDiscover which then tells the client where to go. You can read up on this here.
I recently ran into an issue with SfB PIN Authentication while using AudioCodes 420HD handsets. The phone would login using UPN – e.g. user.name@domain.net with a password. As you know, this can be a royal PITA doing the alphabet soup thing on a 3x4 dialpad. Configuring the phone via web for login credentials worked also. But the same user could not use PIN Auth. And using the phone as a common area phone, where the UPN does not exist, did not work at all. The phone would come back and say that the account name or PIN was not correct. Futzing around with it for a goodly amount of time would sometimes give us a failure to find the Lync Server. Hmmm.
The killer is that all the desktop clients in the environment could login just fine, and to make matters worse, a Polycom VVX600 could login with PIN AUTH for real CSUser accounts as well as the common area phone that failed to login to the 420HD.
So, off we went looking for a solution.
DHCP got checked. It was perfect. Right down to the Time Zone offset. All was good. We spell checked all of the settings – not expecting to find anything (the UPN login worked), but doing our due diligence.
We then went looking at phone traces, CSLogger output on the FE pool, and finally port mirroring on the phone itself. What we saw was the phone discovering DHCP, getting an address, and generally being successful. But failing for PIN Auth. CSLogger showed wonderful results when using a UPN login, but Snooper revealed that when doing PIN Auth, the phone never contacted the pool. There was simply nothing. Ouch. Back to the phone for some port mirroring to attempt to see what was what.
OK, see all that? What the 4xxHD phone is doing is cranking through a raft of hard-coded lookups based on the DHCP information presented in the form of the domain name. Look at what is failing.
Reading the first bit of AudioCodes documentation does not mention those DNS records the phone is obviously looking for. I started with LRTR-09937, which is the latest (and supposedly greatest) administrators guide for 4xxHD phones. Section 2.1 (page 17) has this list.
Further down on page 32 I see this:
Uh oh. I think I am seeing a pattern here.
But, down on page 139, we have some troubleshooting tips, which by the way, are the exact errors we were seeing…Note that there is no mention of SRV records…
LTRT-21920, which is specifically for the phone model in question, has the exact same information in section 5.2.1
And finally, we find this little gem (LTRT 21920 page 9 if you are following along):
Off we go to check the DNS requirements per Microsoft documentation…
This one indicates that LEGACY clients require _sipinternaltls._tcp.domain.com AND the LyncDiscover.
This one reinforces that position in the “aiutomatic client sign-in” section
And this one is more of the same.
THEN I find this: https://technet.microsoft.com/en-us/library/gg412806(v=ocs.14).aspx which states:
This section describes the hardware, port, Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), and security configurations that must be in place before you deploy IP phones…
Oh yes, I remember that, and still I have to ask why does UPN work and not PIN Auth, and why does the Polycom have zero issue either way, yet the 4xxHD will only do UPN and not PIN Auth.
Why four different pages I have no idea, but there you go.
Another question is why a Polycom does not seem to need these records to operate successfully – but I don’t have an answer to that – we will assume the Polycom UC firmware/software is more updated perhaps?
OK, back to our DNS server in question and wala! no _sipinternaltls._tcp.domain.net. So we add that. Reboot the phone.
Success.
The only conclusion I can reach is that AudioCodes 4xxHD phones are still acting as a legacy client, and therefore need the legacy SRV records to function properly.
A question remains, though, as to why the exact same phone will login with a UPN without the legacy records yet fails PIN Auth. Same firmware, different result. I guess I will go back to recommending that all DNS records for legacy and Lync 2013/SfB be implemented just in case.
YMMV
