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:
DMZ Internal IP: 10.160.65.10 (used for communication with the internal servers)
DMZ Public IP1: 18.104.22.168 (used for sip communication with the internet)
DMZ Public IP2: 22.214.171.124 (used for conference communication with the internet)
DMZ Public IP3: 126.96.36.199 (used for audio/video communication with the internet)
DMZ Internal IP: 10.160.65.11 (used for communication with the internal servers)
DMZ Public IP1: 188.8.131.52 (used for sip communication with the internet)
DMZ Public IP2: 184.108.40.206 (used for conference communication with the internet)
DMZ Public IP3: 220.127.116.11 (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: 18.104.22.168
HLB-EXT2 IP: 22.214.171.124
HLB-EXT-VIP: 126.96.36.199 (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:
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|
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
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 (188.8.131.52), 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:
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.