Handling SimpleURLs and Reverse Proxy during migration

I’ve thought about writing this post for a while, as the topic isn’t really covered very well in the Lync 2013 migration documentation. The issue is also only relevant when migrating from Lync 2010 to Lync 2013.

The scenario is this: You are doing a migration from Lync 2010 to Lync 2013. You are following the migration steps provided in the migration documentation, and have planned and prepared your migration, deployed a pilot pool and moved some pilot users to Lync 2013. Internally everything is working as it should,  all modalities are working and conferencing works via the meeting join page using simple urls regardless of which server the user is on.

Now, most of the deployments I do are not large enough that it is needed to use more than one FE pool and for external access one Edge pool and one reverse Proxy. Because of this, most of the conferencing going on is involving external participants. This means that modalities and meeting join needs to be working for the pilots in external scenarios as well. The next step in the migration documentation covers some of this with the deployment of the Edge server. This will handle the peer to peer modalities, but what about the simple URLs?

If you try to reuse the existing reverse proxy rules, you will end up in one of these situations:

  1. You keep the rule as it is, pointing toward the Lync 2010 pool
    If you do this, simple URLs and meeting join will continue working for meetings created by the Lync 2010 users. But if someone external tries to join a meeting created by one of the pilot Lync 2013 users, they will be met with a page saying “Sorry, something went wrong, and we can’t get you into the meeting.” and if you click on “more info” you will get en error saying “Error:Invalid Conference organizer or Conference ID” like this:
    meetingjoinerror
    The Lync 2013 pilot users will also not be able to log in via the mobile client.
  2. You change the rule, pointing it toward the new Lync 2013 pool
    If you do this, everyting will work as it should for the Lync 2013 users. But if someone tries to join a meeting created by one of the Lync 2010 users, they will be met with an ordinary IIS “404 not found” page
    404

Both of these solutions are not really wanted in a normal migration, so what do we do then? The solution is to handle it as a normal multiple pool deployment. This is as it turns out not really well documented in the TechNet library, but on the Request and Configure a Certificate for Your Reverse HTTP Proxy page there is a note saying this:

If your internal deployment consists of more than one Standard Edition server or Front End pool, you must configure web publishing rules for each external web farm FQDN and you will either need a certificate and web listener for each, or you must obtain a certificate whose subject alternative name contains the names used by all of the pools, assign it to a web listener, and share it among multiple web publishing rules.

This means that you will need to deploy a new reverse proxy publishing rule for the new Lync 2013 Pool with a different DNS name for the external services. The rule will also need to use a certificate that contains all the simple URL names in addition to the new name for the external web services and lyncdiscover. This will in most cases create a need for a new public certificate for this new rule.

By doing this Lync is able to redirect the traffic to the webservices between the reverse proxy rules as it does on the inside, and all functionality should be available for both existing Lync 2010 users and the Lync 2013 pilot users.

URI dialing domain check

I made a quick and dirty php script to check if your domain is correctly configured in DNS to support standards based URI dialling. Just input your URI domain and your target gateway, and the script will check if the SRV records are correctly configured and that the A record for the gateway exists.

I’ll add more functionality and nicer looks as time goes by 😛 feature requests in comments.

http://www.codesalot.com/dnscheck/

OCS and split brain DNS

Doug Lawty has written an excellent blogpost about OCS and split brain DNS and how to configure it:

http://blogs.technet.com/dougl/archive/2009/06/12/communicator-automatic-configuration-and-split-brain-dns.aspx

Service records and ports, VCS Express

Here are the service records needed to use the Tandberg VCS:

_h323ls._udp.company.com      srv     1 0 1719 vcs-e.company.com.
_h323cs._tcp.company.com      srv     1 0 1720 vcs-e.company.com.
_sip._udp.company.com              srv     0 0 5060 vcs-e.company.com.
_sip._tcp.company.com               srv     0 0 5060 vcs-e.company.com.
_sip._tls.company.com                 srv     0 0 5061 vcs-e.company.com.
_sips._tls.company.com               srv     0 0 5061 vcs-e.company.com.
_sips._tcp.company.com             srv     0 0 5061 vcs-e.company.com.

There should also be an a-record pointing to the vcs express. (in this example, vcs-e.company.com)

Also, should anyone ever need it, here are the ports that an endpoint needs opened outbound if it is registering directly to a VCS express:

TCP/2776 (Q931/H245 for external traversal endpoints)
UDP/2776 (RTP Media from external traversal endpoints)
UDP/2777 (RTCP Media control traffic from external traversal endpoints)
UDP/1719 (H323 RAS signaling from gatekeepers/VCSes and traversal endpoints)
TCP/1720 (Q931/H.225 call connect signaling)

UDP/5060 (SIP signaling)
TCP/5060 (SIP signaling)
TLS/5061 (Encrypted SIP signaling)

Office Communications Server 2007 Automatic login

This guy has described the autologin mechanism in a great way. It basically relies on DNS records.

Chief Architect’s Corner: Microsoft Office Communicator Auto-discovery Mechanism