This one comes from the ‘Hello, Captain Obvious’ file…..

While working on a Lync 2010 to 2013 migration, I came across an issue with the Lync Dialin page not rendering/loading correctly on the 2013 side. Threat Management Gateway (TMG) was in the mix, so initially I assumed (you know what happens when you assume, right?) that it was related to my TMG publishing rule. However, testing internally yielded the same results. Can you actually yield to a result? In John’s world, yes you can.

In this case, the migration to Lync 2013 also included the addition of an additional SIP domain, and that domain was going to become the default, active SIP domain when users were migrated. This necessitated adding new Dialin and Meet URLs, natch! Do you hate “‘natch” as much as I do? In testing the Dialin page, internally and externally (and ruling out TMG as described above), it seemed as the page started to load correctly, as I saw the Microsoft Lync 2013 header, but instead of the expected Dialin page contents, I received the page below:

dialin1

Clicking the ‘Open this content in a new window’ link on the page actually loaded the correct Lync 2013 Dialin page, though the External Web Services FQDN is displayed in the browser address bar, not the Dialin URL.

NewImage

Curious no? After looking around for something obvious and searching a bit, I thought to myself, do I need to set the Phone access (Dialin) URL to the new URL before it will render properly? Bueller? Automobile? Lets test test his theory:

Open Lync Server 2013, Topology Bulder. Right Click the ‘Lync Server’ Node and choose ‘Edit Properties’

NewImage

Select ‘Simple URLs’ and highlight the correct Phone Access URL and click ‘Make Active’

NewImage

Click ‘Ok’ and publish topology. Boom! the page should load correctly now. Like I said at the beginning of the post, ‘Hello Captain Obvious’.

Hope this helps.