Recently there has been an industry-wide push to phase out SHA-1 signed SSL certificates in favor of SHA-2.  This is a good thing from a security perspective, but presents an interesting problem for Microsoft Lync deployments that use Lync Phone Edition (Aries) phones as common area phones.  In order for Lync Phone Edition phones (henceforth, "Lync phones") to connect to Lync servers after transitioning to SHA-2, the firmware must be up-to-date.  Older firmwares did not support SHA-2 and the phone would simply not be able to log into Lync if you tried.  I had trouble finding the exact firmware version where SHA-2 support was added, but I do know that 4.0.7577.4444 and newer work.

Well, this is fine for all your phones already connected to your Lync deployment.  You simply use one of the numerous guides on the internet to push out firmware updates before you switch to a SHA-2 certificate.  But what about if you buy a phone with an older firmware after transitioning to SHA-2?  The phone has to connect to Lync to get a firmware update and it can't connect to Lync until it has the firmware update.  This is a classic chicken/egg problem.  Unfortunately, Microsoft, in their infinite wisdom, provides no means to sideload new firmware to a Lync phone.

Fortunately, there is an easy solution if your phone has a USB connector.  Connect the phone via USB to any computer with the Lync desktop application installed.  Log into your Lync account when prompted.  The Lync desktop application does all the heavy lifting here, so the phone gets all the configuration information it needs without having to connect to the pesky SHA-2 SSL web services on its own.  Now, you just have to wait for the phone (and computer too, I suppose) to be idle for a while.  I suggest doing this towards the end of the day or before a long lunch break.  It will eventually install the firmware update.  You can check that it's installed by looking at the System Information section in the phone's menu.  Now sign out of the phone.  Your phone is ready to be deployed!

I have tested this method successfully with PolyCom CX3000 phones, but the method should work on any Aries-series phone with USB connectivity.  There may be some really old firmwares (such as the phones from the MD5-era certificate devices) where this won't work.  I don't know as I haven't tested.  And, sadly, if you are trying to enroll a PolyCom CX500 or other device without a USB connection, you are still out of luck.  :-(

I've noticed increased reports of error 3334, which RD Tabs shows as an unknown disconnection code due to protocol failure.  I did some research and testing and found that it's actually due to memory pressure.  It's most noticeable on 32-bit version of RD Tabs, because you only have about 1.2GB of memory to work with before you run into .Net Framework overhead limits (actual process limit is 2GB).  Future RD Tabs versions will have a better error code description explaining what is happening.  This is not limited to RD Tabs, but all remote desktop clients.  You can read more about this error code here.

So what's going on here?

I ran some tests and when you connect to a 2012 or newer server, the per-tab memory consumption is about 150MB.  For a 2008 server, it's about 20MB.  That's a significant increase!  Even more interesting, if you let a tab stay idle for a while, the memory consumption eventually starts to decrease.  So, it seems that although when you first connect memory usage may be very high, it also may settle down with time.  If you work actively in the tab, the consumption may not go down, so it's dependent upon usage patterns.

This works out so that if you open about seven 2012+ tabs within a fairly short period using the 32-bit RD Tabs, you hit that limit and get error 3334.  I don't know about you, but for me that's not a lot of tabs!  Based on this alone, if you have a 64-bit computer, use the 64-bit version of RD Tabs.  The 32-bit version is just crippling yourself.

Messing around with the various experience settings I found that it's due to bitmap caching (see this link).  It's pretty easy to see that the graphical system of the Remote Desktop Protocol has changed a lot since 2012.  The most noticeable difference being the compression artifacts that are visible when there is a lot of on-screen animation.  My guess is that the bitmap cache feature has changed, using a lot more RAM presumably to work better over slow network connections.  The side effect is that if you open a lot of simultaneous connections, you quickly run out of RAM on your system.

It is therefore my recommendation to disable bitmap caching for all connections over a speedy LAN, and use it selectively over slow WAN links depending on your situation.  You can use Batch Favorite Editing to quickly do this in RD Tabs for all your saved connections.  :-)  Future versions of RD Tabs will have bitmap caching disabled by default.  If you are using the 32-bit version of RD Tabs, you should disable bitmap caching for all connections, regardless, unless there is a very good reason to turn it on.