A Unified Communication Blog
Get Adobe Flash player

We have now come to the step where we are going to install the Access Edge Servers.

 

In our topology, we are going to have two servers, which we have defined and created in an earlier post, but you can make use of the tips that I will come with in this post even though you are only installing a single Edge Server.

The Access Edge Servers is actually one of the parts that is often causing problems in a Lync installation, not because the servers is not function or the software is broken, but simply because it’s not set up correctly, and with that I mean the servers, but also the surrounding components like the firewalls, dns etc.

 

The servers is placed in two different DMZ zones, like in the below illustration:

The servers has these IP addresses:

EDGE01

DMZ Internal IP: 10.160.65.10 (used for communication with the internal servers)

DMZ Public IP1: 89.89.89.2 (used for sip communication with the internet)

DMZ Public IP2: 89.89.89.3 (used for conference communication with the internet)

DMZ Public IP3: 89.89.89.4 (used for audio/video communication with the internet)

 

EDGE02

DMZ Internal IP: 10.160.65.11 (used for communication with the internal servers)

DMZ Public IP1: 89.89.89.5 (used for sip communication with the internet)

DMZ Public IP2: 89.89.89.6 (used for conference communication with the internet)

DMZ Public IP3: 89.89.89.7 (used for audio/video communication with the internet)

 

Note: Because I’m going to have two edge servers, you MUST give the edge servers Public IP addresses on the external interface. You cannot use NAT, and assign private ip’s on the external interface.

This can be a challenge for the firewall folks, because you will need to have a segment like a /27 or /28 which gives you 14 or 30 addresses. These ip addresses MUST be routed from the External firewall and into the DMZ public zone.

The firewall folks will still setup firewall rules or access lists on the external firewall, so that the edge servers is protected. (I’ll explain the firewall rules later).

 

In my case I want to communicate with the Skype and Google network, so to have a full HA solution I will need to use Hardware Load Balancers in the DMZ Public zone. And if I have an external HLB, I must also have HLB’s on the internal DMZ zone.

If the HA with the Skype and Google networks is not a requirement or critical in your setup you can skip the HLB, and use DNS Load Balancing instead. Federated partners which also uses Lync, can use DNS LB if you have configured that instead of HLB’s.

 

Back to my setup – I will use two HLBs in an active/passive setup from Kemp (others can also be used), I will need to assign one Public IP per HLB, and one virtual IP for the internal HA check.

So the setup will look like this:

HLB-EXT1 IP: 89.89.89.9

HLB-EXT2 IP: 89.89.89.10

HLB-EXT-VIP: 89.89.89.11 (for HA checks)

 

In the topology builder we have defined an Edge Pool, which contains our two edge servers. In there we also defined the public DNS names which in this case is:

Sip.exchangepro.dk

Webconf.exchangepro.dk

Av.exchangepro.dk

These will be the names that is going to be created in the Public DNS.

If you will DNS LB these three names must be created twice – pointing to each of the edge servers ip addresses.

 

But with HLB’s, these records must point to the HLB. So on the HLB you must have three more public IP addresses for the three services.

(I will cover the HLB setup in a later post)

So now we have three record which we can create in DNS.

 

IP Address Record Type DNS Name
89.89.89.12 A-Record Sip.exchangepro.dk
89.89.89.13 A-Record Webconf.exchangepro.dk
89.89.89.14 A-Record Av.exchangepro.dk

 

So in total we are going to use 12 public IP addresses in the DMZ public zone, and one more for the default gateway (you external firewall’s inside interface)

 

If you setup is also going to included mediation servers and a sip trunk, you might need even more.

 

Now that we have covered the DMZ Public, then let’s have a look at the DMZ Internal zone. This zone is using private IP addresses and the zone must be routable to you internal network segments (all of them, where you have Lync clients).

You cannot use NAT on the traffic to and from the internal LAN’s.

You will have an internal firewall as protection – we are in a DMZ zone with this nic. Also it’s not supported to have that nic directly on the internal network.

Because the servers is multihomed you can only have one default gateway defined on the server – you should place the default gateway on the DMZ public Nic, and not have one for the DMZ internal.

The Nic setup will look like this for the DMZ Internal

And for the DMZ Public

Click on advanced and add the two other IP adresses

 

Because the Default Gateway is placed on the DMZ public you will need you manually create the routes to the internal networks, like this:

First open the Network Connections on the server and make of note of the Device Name for the DMZ Internal nic

Now open powershell and type “route print”

Now make a note on the Interface number for the DMZ Internal Device Name

In this case the interface number is 12.

Now we can create the route to the internal networks – if you have many use notepad for this:

Example of command to add the route is like this:

 

Route add 10.200.0.0 mask 255.255.255.0 10.160.65.1 if 12 –p

Explanation:

The internal segment 10.200.0.0 with subnet mask 255.255.255.0 can be reach though the gateway 10.160.65.1 (GW on the Internal Firewall) on the DMZ internal nic (if 12), and it should be a permanent route (the -p)

The route table now look like this

 

Do this for all you internal segments – The internal Lync clients must be able to access the internal Edge Server NIC to setup media traffic (audio/video) when you communicate with external users or contacts.

The routes are also used, so that the edge server can route traffic to the director and frontend servers.

Next – the servers is not member of the domain, but are in a workgroup, so you will need to define a FQDN name for the server.

Do this from System Properties (Right click this computer and choose Properties)

Click on the Change Settings

Click on Change

Click on More

Type your internal domain name

Now you have defined the FQDN name for the server

 

Next – you might notice that I used google (8.8.8.8), as my external DNS servers on the DMZ public but didn’t defined any internal DNS servers – this was on purpose.

I have before seen problems if I uses an internal DNS server instead, because the edge servers for some reason, when it communicates with other Lync partners, makes a lookup for the SRV record for the _sip.federationtls._tcp.exchangepro.dk – meaning you own federation record which you normally don’t create on the internal dns. And when it can’t look that up, the communication fails.

So, to overcome this I always uses public dns servers on my edge servers, and then uses a host file so that the edge server can look up the internal server names.

The host file is located in C:WindowsSystem32driversetc

My host file will look like this:

So now the edge server can look up the internal ip addresses for the director, frontend and mediation servers and pool names.

After a reboot of the servers then let’s have a look at the firewall rules, that must be created on the two firewalls.

Below are the rules which is related to the Edge servers:

 

EXTERNAL FIREWALL – PUBLISH RULES


 

EXTERNAL FIREWALL – ACCESS Rules for the Access Edge Servers:


 

INTERNAL FIREWALL – ACCCESS RULES



 

I also have the below access rule on the firewall that the internal client uses

 

So when you have got these rules created (more will come in a later post for the other components (Reverse Proxy)), then you should double and triple check that ALL rules, are correct.

As I started in this most of the error in Lync is related to the edge servers, and especially to the firewall rules, routing and dns lookup (or hostname lookup as we created).

It is close to impossible to find a missing port in the firewall when you look at a Lync trace – so really concentrate when you create them.

 

Now that you have been very concentrated we are ready to begin install the Edge servers.

Because the edge servers isn’t part of the internal domain, it can’t find the Central Management Store and get its configuration when you install so you will need to export the Lync configuration from the Frontend server.

So open powershell on the frontend server and type this command

Export-CsConfiguration -FileName c:tempedgeconfig.zip

 

Copy this zip file to the edge server and mount the Lync cd and begin installation (see my previous post on these steps)

In Step 1 where you install the local configuration store you browse to the zip file you created and copied to the server.

Continue the next steps.

In Step 3 you are going to use two different type of certificates.

Create a request file for the DMZ Internal Nic, copy that to the internal CA server, and get the certificate there, and import the second part of the certificate on the server.

Remember also to copy the internal CA’s root certificate to the server and install it the “Trusted Root Certification Authorities” in the local computer store.

 

The second certificate for the DMZ Public nic must be a public certificate which should contain these names:

CN=sip.exchangepro.dk

SAN: webconf.exchangepro.dk

SAN: av.exchangepro.dk

SAN: exchangepro.dk (most be there if you want to use XMPP)

 

If you have more than one sip domain, these domains should also be included as SAN names (like “sip.extradomain.dk” and “extradomain.dk”)

It can be quite expensive in certificates, especially if you have many sip domains.

Globalsign, which I normally use, has a limit of 100 SAN names. Certificates (also the internals) can be max 4096 bytes – so make a calculation if you have many have – you should count with the “length of SAN name” + 2 characters and so on.

Remember to install any updated root certificates from the public certificate provider.

When all that is done, remember to update the servers with the latest updates to Lync and windows updates. (Again see the previous posts on how to do that).

You can then start the edge services, and Lync will get its updated configuration directly from the Frontend servers though the replication service.

 

If you have not created it already by now, remember the public DNS records. Until we have the HLB up and run you can go for DNS Load Balancing by creating both servers real ip addresses.

Also make sure you remembered to create the internal DNS records for the Edge servers (see previous post), and again the edgepool should consist of the two Edge server internal ip addresses until the HLB is up an running.

 

This is all for now, in the next post we will be looking at the reverse proxy servers.

 

Lync 2013 High Availability

Part 1: http://exchangepro.dk/2013/08/28/install-a-sql-2012-mirroring-cluster-for-use-with-lync-2013-part-1/

Part 2: http://exchangepro.dk/2013/08/29/install-a-sql-2012-witness-server-for-use-with-lync-2013-part-2/

Part 3: http://exchangepro.dk/2013/09/01/configure-a-sql-2012-mirroring-cluster-for-use-with-lync-2013-part-3/

Part 4: http://exchangepro.dk/2013/09/14/deploy-a-lync-2013-file-store-part-4/

Part 5: http://exchangepro.dk/2013/09/19/prepare-your-servers-for-lync-server-2013-ha-part-5/

Part 6: http://exchangepro.dk/2013/09/21/creating-the-lync-server-2013-ha-topology-part-6/

Part 7: http://exchangepro.dk/2013/09/30/install-the-first-frontend-server-part-7/

Part 8: http://exchangepro.dk/2013/10/06/update-the-frontend-server-part-8/

Part 9: http://exchangepro.dk/2013/10/13/install-the-office-web-servers-part-9/

Part 10: http://exchangepro.dk/2013/10/21/deploy-the-director-servers-in-lync-2013-ha/

Part 12: http://exchangepro.dk/2013/11/05/deploy-reverse-proxy-using-kemp-hardware-load-balancer-part-12/

Part 13: http://exchangepro.dk/2013/11/14/adding-additional-frontend-servers-to-lync-ha-part-13/

Part 14: http://exchangepro.dk/2013/11/26/setup-load-balancers-for-the-internal-lync-servers-part-14/

Part 15: http://exchangepro.dk/2013/11/26/load-balance-the-office-web-apps-server-part-15/

Part 16: http://exchangepro.dk/2013/11/26/load-balance-the-lync-frontend-web-services-part-16/

Part 17: http://exchangepro.dk/2013/11/28/load-balance-the-lync-frontend-services-part-17/

Part 18: http://exchangepro.dk/2013/12/15/load-balance-the-lync-director-servers-part-18/

Part 19: http://exchangepro.dk/2013/12/15/load-balance-lync-access-edge-internal-nic-part-19/

Part 20: http://exchangepro.dk/2013/12/29/load-balance-lync-access-edge-external-nic-part-20/

6 Responses to Install the Access Edge HA Servers – Part 11

  • Hi,

    Technet does not show the extra firewall rules you have in place. For example, from internal client to internet rule. Is that necessary ? The Lync 2013 protocol poster does not show this as being necessary either. Thanks.

    • Hi John

      No, it’s true the rule are not on any official list, but I always have the rule, so that I’m sure that I can use my Lync from other customers/installations at a customer site!!!!
      In my installations, I often uses serveral different accounts (from other customers and my own) so I can test a customers installation, and therefor I need that rule.
      So you don’t need that rule in “normal” Lync installations.

      /Joachim

      • Thank you for your response Joachim. I followed your guides to the tee and it helped me quickly setup a high availability architecture. Your efforts are much appreciated. I had one question if you have time to answer. I currently don’t have the firewall rule from internal edge to internal clients and vice versa for the media traffic ports (49,152-65,535). I didn’t think I needed that because I was expecting a peer to peer desktop sharing session for most of our users. However, I noticed that in few of our sites, direct UDP connection was not possible and so it was using the TURN method to relay through our Edge servers. Desktop sharing is currently failing with “we couldn’t connect to the presentation because of network issues”. I’m assuming this firewall rule should fix the problem. Am I on the right path ? Still learning about ICE/STUN/TURN. Thanks again.

        • Hi John

          Sorry for the late response – I missed it.
          Yes I would look at the firewall rules. The lync client will try to setup a connection to the edge servers, although it’s only internal sharing.
          And also if the client can’t make an UDP connection (3478/udp) from client to client it will try https, and the high ports (both udp and TCP) are used when the traffic runs between the clients.

  • Thanks for the reply. Will give that a try.

  • Hi Joachim!

    Can you explain, why this: Note: “Because I’m going to have two edge servers, you MUST give the edge servers Public IP addresses on the external interface. You cannot use NAT, and assign private ip’s on the external interface.”
    I created lync edge pool with two servers with DNS Load Balancing with private IP addresses using NAT. But I can’t do conference call. I receive message “You’ve left the call”.
    Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Search

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 72 other subscribers

Follow me on Twitter