Migrating to Lync2013 Edge Server

3/13/2013

In a previous article, we discussed the steps to deploy a new Lync2013 Edge server into a Lync2013 FE pool that was coexisting with a legacy Lync2010 Pool with Lync2010 Edge. Users homed on the Lync2013 FE pool continued to use the legacy Edge server for remote access and federation. Although having both the legacy Edge and the 2013 Edge providing remote access is possible, such a configuration would be more difficult to manage and moreover, only one Edge can be used for federation. In this article, the steps to migrate completely to the new 2013 Edge will be discussed. Users still homed on the legacy Lync2010 FE pool as well as those homed on the new Lync2013 FE pool will use the new 2013 Edge for Remote Access and Federation. The end result should look like the diagram below:

In a production environment, changing the federation route and media traffic route requires downtime for the Lync Server 2013 and Lync Server 2010 Edge Servers. Federated access will be unavailable for the duration of the outage.

Configure the Lync2013 FE Pool to use the new 2013 Edge

In topology builder, edit the properties of the Lync2013 FE and associate the Edge pool with the new 2013 Edge:

The Edge pool (for media) should now list the new 2013 Edge as shown below:

Now edit the properties of the 2013 Edge server and verify that the next hop pool now points to the Lync2013 FE pool as shown below:

For those users still homed on the legacy Lync2010 FE pool, we also want them to use the new Lync2013 Edge for media traffic. In topology builder, edit the properties of the Lync2010 FE pool and associate the edge pool to the new 2013 Edge:

Next. since we want to migrate federation services from the legacy Edge to the 2013 Edge, we edit the properties of the Edge2013 to enable federation:

Note the warning that the topology already contains other federation-enabled Edge pools. This is because we have not yet disabled federation on the legacy Edge server, a step which will be done later. For now, we publish the topology:

After successfuly publishing the topology, click to open the to-do list to see which servers require updating of Lync components and then update by opening the Deloyment Wizard on those servers and running "Install or Update Lync Server System" and "Setup or Remove Lync Server Components".

Changing the Federation Route

We now want to migrate the federation route from the legacy Edge to the new 2013 Edge. Using topology builder, we edit the properties of the Site and select the new 2013 Edge under the "Enable SIP Federation" checkbox:

Topology will now display at the top level node "Lync Server" a "Topology validation warning" that there is more than one Federated Edge Server which is normally the case for migrations, but as stated, only one Edge would be actively used for federation and the correct external DNS SRV records, ie :sipfederationtls._tcp.domain.com needs to be pointing to the correct Edge server. In our case this should point to the new 2013 Edge.

Note that the federation is still enabled on the legacy Edge as shown below:

Edit the properties of the legacy Edge and uncheck the federation box:

Finally, we publish the topology and make sure it is successful. The "Topology validation warnings" seen earlier should dissappear now. At this stage we should verify that all the following remote access and federation scenarios work for both Lync2010 and Lync2013 users:

1. Users from at least one federated domain, an internal user on Lync Server 2013, and a user on Lync Server 2010. Test instant messaging (IM), presence, audio/video (A/V), and desktop sharing.

2. Verify that anonymous users are able to join conferences.

3. A user hosted on Lync Server 2010 using remote user access with a user on Lync Server 2013, and a user on Lync Server 2010. Test IM, presence, A/V, and desktop sharing.

4. A user hosted on Lync Server 2013 using remote user access with a user on Lync Server 2013, and a user on Lync Server 2010. Test IM, presence, A/V, and desktop sharing.

Conclusion

This article along with the preceding article desribed how to introduce the Lync2013 Edge into an existing Lync2010/2013 deployment and how to migrate to the new 2013 Edge. The steps outlines are targeted for lab environment testing scenarios. For actual production migrations it is highly recommended to follow the detailed instructions contained in the official Lync documentation.

9 Comments

Zachary

10/3/2013 01:32:17 am

Great post, but had a question, how did you test your new edge server with federation before you made the switch to your new edge pool?

Brennon

10/3/2013 04:41:05 am

There's no way to test federation with the new Edge without actually moving federation to it. Migration of the Federation Route would typically be done during scheduled downtime and if there are any problems with the new Edge, then Federation has to be switched back to legacy Edge. Not really a good answer to your question but that's how it is today.

Canada Bob link

10/18/2016 05:29:58 pm

Test federation by telnetting to 5061 on the Access Edge public IP from external. That proves the federation port is working, unless the firewall is configured to perform SIP ALG packet insprction.

Wee Lun

2/18/2014 07:34:48 pm

Most helpful post, especially with the help of the diagrams. Thanks!! One question though, any issues for users who are still homed in 2010 pool using mobility with the 2013 Edge server? Can they still use Lync 2010 Mobile client to sign in thru Lync 2013 Edge and back to their Lync 2010 pool?

Brennon link

2/20/2014 03:24:09 am

Yes the Lync2013 Edge provides backward support for Lync2010 mobility clients. The Mcx web service is still included and operational on Lync 2013 servers for backward compatibility with Lync 2010 mobile clients, but the 2013 mobility clients will only leverage the UCWA web service. As a result 2013 mobile clients cannot sign in to a Lync 2010 Edge

Michael

2/19/2014 12:24:09 am

Hello... I have a question about your article. in it you show using your internal CA to issue certificates to be used on your External interfaces. in my legacy environment I purchases certificates from digicert (which are still in use) because we did not have an internal CA. I deployed an internal CA this year and used it to issue certs to my internal FE. I was under the impression I HAD to use purchased certs from a trusted CA to use on external interfaces. is that not the case?? your article is using an internal CA

Brennon link

2/20/2014 03:29:09 am

For actual deployments then internal CA certs should only be used for the Lync Edge internal interface. The Lync Edge external interface should always use public CA certs. I'm using internal CA certs for my Edge external interface only in my lab environment which is only used for internal testing, none of the traffic actually goes out to the internet. For federating to another Lync environment internally, I actually add the internal RootCA certs to the other Lync Edge as a trusted Root and vice-versa.

Frank Carius link

3/12/2015 12:25:25 am

Are you sure, that your slide Shows a supported topology ?. From my understanding, a lync 2010 homed user cannot use a lync 2013 edge. Changing the Edge for federation is fine but the lync 2010 edge can only be removed, after the last lync 2010 users was migrated.

Brennon link

3/12/2015 12:50:44 pm

Hi Frank

Have a look at https://technet.microsoft.com/en-us/library/jj688163.aspx.

This step of the migration is when the Lync 2013 edge server has already been deployed with the federation route, and the subsequent steps to test both Lync 2010 and 2013 users are able to use this new Edge.

Your comment will be posted after it is approved.