How to fix Intermittent AOL PIC Issues within Lync
I can't chat with AOL, Lync is broken!
For all of the Lync engineers that have been burned when the decision is made to implement PIC with AOL, help is here. Usually, once provisioning is complete, your Lync end users will be able to exchange IMs with Third Party clients such as AOL, Yahoo, or MSN. Almost like magic, your Lync functionality is now opened to the world outside of Microsoft.
I've had the pleasure of being a part of such extended functionality twice and after countless hours on the phone with Microsoft or searching website after website, I discovered three possible resolutions that actually work. I've pooled together all three possible resolutions...so you don't have to search like I once did.
ACT 1 - Check your Certificates
The first is more of a confirmation that your certificates are in order. To be more specific, the external Edge certificate needs some special handling and care if you plan on chatting with AOL users via Lync 2010. Below is the link and excerpt from the TechNet article. http://technet.microsoft.com/en-us/library/gg398409.aspx
ACT2 - External SSL certificates
Next Up...an awesome article that will likely resolve your issue. Kudos to Scott Oseychik. Your discovery over 3 years ago, well before Lync Server 2010, is still alive and well. Again, this is somewhat related to the external SSL certification. Depending on the order of the SSL Cipher Suite, you could experience any of the below symptoms with Lync to AOL and/or AOL to Lync communication:
1. Presence would take up to 30 minutes to update on both clients
2. Messages in both directions would get lost 90% of the time, with some random ones getting through
3. Lots of 481 “Call Leg/Transaction does not exists” errors coming up in the SIP Stack log on the edge server
4. Tons of duplicate SYN, ACK visible during a packet trace
Below is a link to the original article, an updated Lync version, and an excerpt
ACT 3 – TCP Autotuning
If you're still having issues, this last tweak will surely resolve your issue (fingers crossed). TCP Autotuning! This feature, which became available in the Vista days and is enabled by default on Windows 7 and Windows Server 2008/2008 R2 servers, has wreaked havoc during a Lync Edge migration I performed recently for a financial institution, Company B. It returned for a second round battle when the parent company, Company A, also enabled PIC within their Lync 2010 environment. I've learned that even when Lync is configured correctly and has been in a working state for years, changing anything that touches Lync can possibly bring your deployment to its knees. I my case, I migrated servers from one data center to another. Seemed to work like a charm...Federation - check, Yahoo - check, MSN/Live - check, AOL - nogo!
Hmm, I can telnet to sip.oscar.aol.com:5061 and I see traffic between our servers and AOL's. Maybe it just takes a while! After two full days of troubleshooting with Microsoft and within our engineering team, I was at a loss. We verified the previous resolutions in this blog and searched until the end of Google for help. Nothing! The only thing I saw consistently was "dup SYN, ACK" on the Edge servers, both to and from AOL. We had users that would state that AOL was now working because they recently received an IM from a client....only to be denied on the very next send or receive attempt. AOL was down and the brokers and traders of Company B were starting to break down, the help desk queue calls went through the roof and kept on going. Managers were starting to camp out in the engineering area, mostly in my cubical. The talks of rolling back all changes were being discussed and that was not something that I wanted to do...and then -
BAM!!! It hit me as I read the words,
Random post from some guy on the technet article that I've read for the 50th time - "Hey guys, I tried all of the recommended steps on this site and other and nothing worked...but I did get it resolved"
Yes, someone in my exact situation found a solution! What could it be??
The most important post from that same guy - "I disabled TCP Autotuning and my issue disappeared immediately"
After a little research on what that feature did exactly, I pulled the trigger on both Edge servers and within 15 seconds, all was well in the world of Company B and AOL! I then researched TCP Autotuning a little more. I had to make sure I wasn't going to introduce another problem into the mix. After an hour, all was well! Not even a need to reboot the servers.
The issue with Company A wasn't as exciting or nerve wrecking...when I saw the symptoms and heard the complaints, I knew exactly what to do! Confirm certificates, check SSL Cipher Suite order, and if all else fails - disabled TCP Autotuning!
If none of the above works...Blame AOL :)