One of the benefits of DirectAccess is that it allows an administrator the ability to define, by DNS name, whether traffic should traverse the tunnel to the internal network or simply use the regular internet.
This is very handy for Lync implementations, since DirectAccess can be set up to allow all Lync traffic to route over the internet to the Edge server.
While performing a Lync 2010 to Lync 2013 migration, I ran into a bit of difficulty with PowerPoint presentations that seemed to be related to DirectAccess.
Users in the 2013 pool, when sharing a PowerPoint file (which utilizes Office Web Apps) would get these errors:
And error ID 530 (source ID 241)
If I disabled DirectAccess (by selecting “Prefer Local DNS Names” on the DirectAccess Connectivity Assistant), PowerPoint sharing would work without issue. Clearly, a name lookup while using DirectAccess was causing a problem.
Since this was the only reported issue, and all Lync functionality had been working prior to the migration, I figured it was the Office Web Apps URL, but repeated checks (as well as a variety of DirectAccess configurations) kept coming back OK.
Eventually, I found myself scouring the client logs to try to identify where Lync was trying to reach that was failing. The culprit ended up being the Web Conferencing URL. It wasn’t defined internally, and it wasn’t in the exclusion list in DirectAccess causing the lookup to fail.
So, the moral of the story: Double and triple check your DirectAccess name exclusions to ensure all Lync services are prevented from performing internal lookups.
Shane Skriletz, PEI
