Lync 2010 Deployment Guide (adding Edge Role

- part I)
Now we will go a step further and prepare to deploy an Edge server in our lab. To me, in complexity, Edge
is no more complicated than any other role, but looks like many folks are having troubles.
Perhaps the most important (and often omitted) step is to relax, pull back for a moment and think
What is that I want to achieve and what resources I have on hand.
All right, what do we have?
I will deploy my Edge in DMZ. While I dont really have DMZ in my lab and dont have time to build one, I
will place the Edge on the same subnet where the Lync server is, but the presumption is that you will
definitely separate your internal resources from the Big, bad Internet.
I will use two different FQDNs sipint.drago.local for the machine name (SIPINT with domain suffix
applied) and sip.drago.ws for external access.
Because I have only one public IP address available, this is what I will use when configuring the
topology.
edgein.drago.local
sip.drago.ws
sip.drago.ws
sip.drago.ws

10.20.50.5
10.20.50.50 (mapped to xxx.xxx.xxx.xxx); port 5061
10.20.50.50 (mapped to xxx.xxx.xxx.xxx); port 444
10.20.50.50 (mapped to xxx.xxx.xxx.xxx); port 443

***Note that I will use the same Public IP address for all Edge Interfaces, and so, I must be sure the ports
are not overlapping.
Upon completion, I expect to have:
- External access for my users
- Federation with other domains
- IM, Video, Audio and desktop sharing with federated domain uses
Because this is a lab, I do not expect to complete PIC federation (IM and A/V session with MSN network
users).
Preparing the server to host Edge Role
My server is already named EDGEINT.

However, I MUST apply the domain suffix or later the MTLS will fail.

and restart when done. Now the Full Computer Name is FQDN.

Next I will provision the IP addresses on my server, where I will use a public DNS server and add my Lync
FE to the hosts file.

and now EDGEINT resolves our fe.drago.ws

We can now proceed with satisfying the software prerequisites as described

here:http://technet.microsoft.com/en-us/library/gg412931.aspx
Again, I will run this command:
servermanagercmd -install Net-Framework Net-Framework-Core Net-Win-CFAC Net-HTTP-Activation
NET-HTTP-Activation WAS WAS-Process-Model WAS-Net-Environment WAS-Config-ApIs

TechNet talks about this update: http://go.microsoft.com/fwlink/?LinkId=205459, but since I user Windows
2008 R2 SP1, the presumption is that the fix have been incorporated in the SP1 and I will sclip this step.
Next we will add our Edge server to the Topology.

Lync 2010 Deployment Guide (adding Edge Role

- part II)
Of course, first we must add our Edge server in Topology Builder first and publish the topology.

*** Note that is used here the internal FQDN (edgeint.drago.local)

Here we use the DMZ IP address which we will later map to Public IP address on our firewall

and now we enter the Public IP address mapped to 10.20.50.50

The next hop is out only Lync FE server in the deployment.

and mark our pool for external media traffic.

Lets recap what we have done so far, because this is VERY important and misunderstanding this
ultimately will lead to problems later!

1.

Our internal server FQDN is exdgeint.drago.local

2.

The internal IP address (typically in DMZ) is 10.20.50.5

3. The Federation is enabled, thus we MUST have _sipfederationtls._tcp.drago.ws SRV record

pointing to the A Record of sip.drago.ws (75.91.122.236) in our Public DNS

4. ***ALERT*** this is the IP address of the A/V service, where the media will flow later. This is
the major pain point of every deployment where voice problems via the edge are observed.

5.

This is the port via which the Edge will receive Configuration update

6. The next hope for this Edge server. If this server is not functional, our Edge will be pretty
much useless

7. The external FQDN used for External access (port 5061) and Federation (port 5061). This is
my first deployment with single IP address, so we will see how it goes later.

8.

The IP address we will S-NAT and D-NAT to 75.91.122.236

9.

The Edge Access Port (will be used from external Lync clients to sign-in)

10. Note that the port is different

11. and so this one

Now we will publish the Topology.

This will make all other servers (besides the Edge) aware of the change (new server added).

Lync 2010 Deployment Guide (adding Edge Role part II)

It is now time for the Big Bang the actual Edge deployment.

On the previous step, we added the new Edge to the topology and published it. The assumption is that
our Edge server is on the perimeter network and so, we must export the topology from our FE and
transfer the file to the edge somehow.

I will run export-CsConfiguration -filename C:\TopoExport.zip from Lync management shell.

...and transfer the file to the Edge

Next we run the setup.

Because our Edge is not a member of Domain (i.e. CMS cannot be read, we must point to the .zip file
moved to this server on the previous step.

Have patience SQLExpress installation takes time (good time for trip to the fridge).

Ah, certificates. A major pain point.

Edge server must have two certificates one with the CN = FQDN of the machine, assigned to the
internal interface (edgeint.drago.ws in our example), and one with the FQDN we entered earlier in
topology builder (sip.drago.ws in this case). Note that because we are building our Edge server with ONE
Public IP address only, all three roles will use sip.drago.ws and so, I need certificate for CN =
sip.drago.ws i.e. no SAN is needed.

First, I will create CSR (Certificate Signing Request) for the internal interface. Later I will use it to sign it
from my internal Domain Certificate Authority.

Here I will add sip.drago.ws (our sip domain)

Open the CSR with Notepad and copy the content.

Go to your AD Certificate Authority and request certificate signing.

Paste our request in the Saved Request field and select Web Server from Certificate Template list.

Download and save the certificate.

***Note that I have already save the Domain Root Certificate. Edge is not a member of domain and so,
the Root CA must be imported manually.

First, install the Domain Root Certificate

Proceed with the import of our certificate

***Note that because we created the CSR, the Private Key is stored locally (we just asked to be signed).

Our internal certificate is now assigned.

Perform the steps above to generate CSR, have it signed and assign it to the Public interface.

***This certificate must be signed from Public CA in order to have fully functional federation capabilities.

We are ready to start the services now.

Next step will be to verify the functionality of our Edge.

Lync 2010 Deployment Guide (Verifying Edge

functionality)
To check our Edge functionality, first we must enable at least one account for External Access and
Federation.

In Lync Control Panel, we will modify the Global External Access Policy:

***Since this is a Lab, I will not enable Communications with Public Users.

Next, I will modify the Access Edge Configuration to enable Federation and Remote
user Access.

Because I modified the Global policies, my two test users are now automatically enabled for External
access and Federation.

I will not cover the networking side this is job for the network admin. However, there are few things to
remember:

1.

We elected to use single public IP address. Because of this, our SRV records must be as follow:

a.

_sipfederationtls._tcp.drago.ws pointing sip.drago.ws on port 5061

b.

_sip._tls.drago.ws pointing to sip.drago.ws on port 5061

At this point, our external clients will now how to discover our edge and sign in and our partners how to
discover and federate.

Lets check what http://recite.microsoft.com will say:

Because this all test were successful, lets try to establish IM session with federated partner:

start desktop sharing

start an audio call from within this session...

and also add video.

All basic functions on our Edge are now verified and I have to think what would be
the next post...