One of the changes I noticed with Lync Server 2010 during my earlier deployments was that you can no longer enter a URL for your External web services to download your Lync client’s address book. My former Microsoft practice lead Mark Hickson (http://markhickson.blogspot.com/) came up with this bright idea back when we were migrating from OCS 2007 R1 to R2 (I still think it was such a great idea) by reusing the FQDN we used for our R1’s:
- Address book files
- Distribution group expansion
- Meeting content
- Phone Edition upgrade files
… to also publish our R2 download WITHOUT using a new sub domain. How you ask? Simply by modifying the URL’s path and here’s what I mean:
See the field for:
File share URL for external connections
… in the screenshot below has:
https://someName.someDomain.com/Abs/Ext/Handler
What we basically did during our coexistence phase was to change that URL to:
https://someName.someDomain.com/R2/Abs/Ext/Handler
This in turn allowed us to reuse the same someName.someDomain.com and the existing certificate to publish our R2 address book and meeting content downloads through ISA.
What I noticed with Lync Server 2010 is that you are no longer allowed to modify that URL in the topology builder to have sub paths even though they still exist:
Notice how the GUI complains that: Value is not a valid FQDN?
The planning guide (Chapter 06 Planning for External User Access.doc) on page 31 also notes:
Notes:
The externalWebServicesFQDN value is used for Lync Server 2010 users. In coexistence scenarios it is likely there will already be an externalWebFarmFQDN value for existing Office Communications Server 2007 R2 or Office Communications Server 2007 pools, but the FQDN values are independent of each other.
It’s too bad we can’t use the workaround my former practice lead came up with because it would allow me to almost immediately get the web services available without having to wait for another public DNS record and certificate to be available. I’ll most likely dedicate some time to see if there’s some way of changing the path (ADSIedit perhaps?) in the following weeks and if I figure it out, I’ll update this post.
Update
5 minutes after I finished writing this post, I realized that one way of getting around it is to publish the same URL but with a different port since you are allowed to change the published ports (via the listener). After struggling for an hour trying to get the publishing rule right, I finally got it going: https://blog.terenceluk.com/2011/01/how-to-use-same-domain-url-to-publish.html.
While this may not be the best solution because some firewalls may end up blocking non standard ports, it’s probably a viable temporary solution.
