This long overdue follow-up article on the Lync Server deployment series focuses on bringing what is currently in place for internal users to allowing external access and providing a channel for communications with federated and public contacts: the Edge Server.

The previous articles in this series cover the deployment and configuration of a Lync Standard Edition Server in a lab scenario but the information contained within extrapolates to best-practice enterprise deployments as well.

As there are already various Lync Edge Server deployment articles there is not much value in creating another one that walks through the same general steps, so this deployment will be somewhat unique in that it will not actually be used for an Internet-facing Edge server.  Often times in proof of concept or pilot labs organizations will deploy Edge servers to test various components and client interoperability but not actually require Internet access or public Federation capabilities. Also for the IT professional with a virtual lab at home with basic Internet access behind a single dynamic IP address it can range from complex to nearly impossible to deploy a functional Edge Server.  (Primarily though this article exists because of the need for an isolated Edge environment for a future article meant to explain the underlying traffic patterns in Edge Server media traversal.)

    This article will walk through the steps of deploying Edge services in a supported, yet compressed deployment in which ‘external’ clients can be tested from an isolated network.  This topology also allows the use of a reverse proxy solution like ISA or TMG to provide web services connectivity for the external Lync and Exchange features, but those components will not be addressed with this article.  Only basic Edge services (Access Edge, Web Conferencing, and A/V Edge) will be covered.

The following diagram depicts how the ‘external’ network interface will be connected to a physical switch to provide connectivity for the pseudo-external Lync clients.  The Edge Server will also be configured with DNS and DHCP services so that these clients can locate and connect to the Edge server automatically (Lync Phone Edition does not support static IP addressing, for example).


Understand that some of the setup will be completely backwards from what most documentation states as typically access to the Internet from the Edge Server flows in the opposite direction as to what this deployment will look like.  The goal here is to still provide Internet access to the Edge Server (for Windows Updates and other management tasks) but allow for clients on the isolated network to sign-in to the Edge Server and communicate with internal clients in the network.  (These clients will not have Internet access while connected to the isolated network, although if desired Internet access could be provided to the new network by attaching it to a secondary port in the primary router or supplying a secondary Internet connection.)


Environment Preparation

  1. Provision New Windows Server
  2. Create Isolated Network
  3. Deploy DNS Server
  4. Deploy DHCP Server
  5. Test Isolated Network

Edge Server Deployment

  1. Configure Edge Topology
  2. Complete Edge Configuration
  3. Install Edge Server Components
  4. Deploy Edge Server Certificates
  5. Validate Edge Services
  6. Test Lync Clients

Environment Preparation

Before beginning the Lync Server deployment a Windows Server must be deployed to and configured to host the Edge services as well as the essential networking services to support the new ‘external’ network which will be created.  In this scenario all Windows servers are Hyper-V guests running on the same physical server with multiple network interfaces.  The primary interface has already been defined in Hyper-V and all of the currently deployed servers (Active Directory Domain Controller, Lync Front End, Exchange, etc) are on this primary network which includes

1. Provision New Windows Server

The first step is to deploy a new Windows Server to host the Edge Server and additional networking roles, so using whatever method deemed appropriate deploy a fresh Windows Server and install al of the latest updates. For this scenario a new Windows Server 2003 R2 was deployed and configured in Hyper-V identically to the existing servers including being bound to the default network.

  • Select a new FQDN for the Edge Server and rename the virtual server (e.g. edge.schertz.local), making sure to configure the DNS suffix as well in order to define a Fully Qualified Domain Name.  The FQDN should use the same namespace as the internal AD domain, although the system will not be domain-joined. It is imperative that the server has an FQDN defined so that it will exactly match the FQDN later defined in the Lync Topology otherwise the installation of the Lync components on the Edge Server will fail due to a DNS resolution failure.  NetBIOS ‘short’ hostnames cannot be utilized for the Lync Edge Server for this reason.


  • Validate the new FQDN, leaving the server in the default WORKGROUP (do not join it to an existing Active Directory Domain) and then reboot the virtual server.


2. Configure New Isolated Network

An existing, unused secondary Network Interface Card (NIC) on the Hyper-V host server should be connected to a basic Ethernet switch to provide physically connectivity to PCs and device running Lync clients.  Then this interface can be defined as a virtual network in Hyper-V and a static IP address assigned to the new virtual network adapter created on the host.

  • From the Virtual Network Manager in Hyper-V Manager create a new virtual network and bind it to the desired physical NIC in the server.  (The name Isolated Network was used in this example but any descriptive name can be used. The existing virtual network was called Home Virtual Network.)


  • Then from the Network Connections control panel on the physical Hyper-V server edit the properties of the new virtual interface (not the physical adapter) and define a static IP address in the subnet range selected for this new network.  In this scenario the subnet was selected, so an IP address of was assigned to the server. (The address of was left reserved in the case that a router is ever added to this physical network at a later point in time, although the specific IP chosen is irrelevant.)  No default gateway or DNS servers should be specified, only the IP and subnet.


  • Shutdown the new virtual server if it is currently running and then add a second Network Adapter, selecting the newly created Isolated Network.


  • Restart the new virtual machine and validate that both NICs appear in the guest operating system.  Rename each interface to descriptively coincide with the proper networks to make it simple to identity them from each other.


  • Assign a static IP address to the primary interface, as well as the default gateway and DNS server(s) for the existing primary network.  Then assign a unique static IP address to the secondary interface (e.g.  This IP will be used for client access to the server for non Lync-related communications (e.g. DNS, DHCP). Note that this configuration is opposite of normal best practices as our ‘external’ network is a single subnet and thus the default route needs to run back towards the internal interface where the Internet actually is accessible. (Again this is only for access to the Internet for the Edge Server itself, all hosts in the isolated network will not be able to route through there.)

image  image

  • In preparation for the Edge Server deployment bind two additional IP addresses to the Isolated Network interface (e.g., and so that there will be a total of three separate IP addresses available for the ‘external’ Edge interface.


  • It is also good practice to disable the Register this connection’s addresses in DNS setting located on the DNS tab of the Advanced settings, although the server will not be able to create any dynamic DNS registrations in this configuration.


Because the Edge Server is not domain-joined, nor is it a DHCP client then the previously defined hostname will not automatically be populated in the internal DNS zone by the server, so this must be performed manually by creating a new static DNS record.

  • On the internal network’s DNS forward lookup zone (e.g. schertz.local) create a new Host (A) record for the Edge Server FQDN and the IP address defined on the internal network (e.g. Home Network).


3. Deploy DNS Server

As previously mentioned the Edge Server will need to be used to provide DNS and DHCP services to clients on the isolated network. (Alternatively another Windows Server could be deployed to handle these services, but for the sake of saving vital resources on the host server these will be collocated on the Edge Server.)  The zones deployed on this server will only be a subset of the existing zones in the internal work and will not be configured with any type of replication.  The sole purpose of this zone is to provide resolution to hosts in the isolated network for any of the external Edge FQDNs.

  • From Server Manager add the DNS Server role and when that is complete add a new Forward Lookup Zone for the Lync environment’s SIP domain (e.g.  Do not enable dynamic updates or any replication options.
  • Then create another new Forward Lookup Zone for a domain in which clients attached to the isolated network will be assigned to, either statically or via DHCP (e.g. lab.local).  Make sure to select the Allow both nonsecure and secure dynamics updates so that DHCP clients in the isolated network will be able to dynamically update their IP addresses in this lookup zone.  (Because this server is not domain-joined there is no option to provide secure updates, but since this is a physically isolated test lab then it is not an issue.)
  • Also create a new reverse lookup zone (this step is optional,but is always good practice) for the isolated network subnet.
  • Finally create three new Host (A) records for each of the Edge Server external FQDNs which will be configured in a later section.  In this scenario the three external hostnames are,, and with each FQDN being allocated to one of the three additional IP addresses which were previously bound to the Edge Server’s external (isolated) NIC.


    4. Deploy DHCP Server

  • From Server Manager add the DHCP Server role.  On the Network Connection Bindings page selecting only the server IP address which coincides with the isolated network (e.g. and deselecting the other interface.  Leaving the existing internal network selected may create competing DHCP scopes servicing the internal network.  This DHCP server is only intended to hand out leases to DHCP clients attached solely to the isolated network.


  • On the IPv4 DNS Settings page set the Parent Domain as the new forward lookup zone created only for the isolated hosts (e.g. lab.local).  The Preferred DNS server should be the primary IP address of the Edge server on the isolated network interface (e.g. and the Alternate DNS server should be left empty.  Do not assign any of the internal network’s DNS servers to these fields as the clients which are passed these values will not have any direct connectivity into the internal network to reach them.


  • Skip the WINS configuration and on the DHCP Scopes page choose a name and IP address range for the new scope (e.g., making sure to update the Subnet mask if the assumed natural mask is not used (as it is in this scenario).


  • Disable DHCPv6 Stateless mode and complete the installation.

4. Test Isolated Network

  • Connect one or more clients to the isolated network and then check the DHCP Address Leases in the activated scope to verify proper DHCP operation.  The image below shows a Windows, Mac, and CX600 all connected to the new isolated network and will be each be used to test Lync Edge connectivity.


  • Test name resolution and network connectivity to the Edge Server from the Lync Front End Server to validate the internal DNS record is working and that there are no network issues preventing communication.


These steps begin right where the previous article left off.  As the Edge Server deployment is a complicated process this article will assume a best practices network configuration of two interfaces homed on separate networks.  Lync Server has the same basic requirements that OCS did and there which has been documented already in many different articles.

1. Configure Edge Topology

Utilize the Topology Builder installed on the existing internal Lync Server to define the configuration for a single Edge server.

  • Launch the Topology Builder and then select New Edge Pool from the Site > Edge Pools section.
  • On the Define Edge Pool FQDN section enter the hostname of the new Edge server (e.g. edge.schertz.local) and select Single Computer Pool


This FQDN will be the internal name of the Edge server and is how all internal clients and servers will resolve and attempt connections to the Edge Server.  This is not the public name of any of the Edge roles.  This FQDN must be resolvable by all internal hosts and be pointed to the IP address on the internal Edge interface.  This FQDN does also not need to be in the same domain as the SIP domain(s) used.

This scenario will contain a single consolidated Edge server utilizing a multiple private IP address which will masquerade as public IP address in the pseudo-external isolated network.  Thus federation will not need to be enabled nor will NAT. (These options can be reconfigured in the topology if the isolated network is routed to the Internet at a later point.)

  • Leave all three options disabled in the Select Features window.  Federation can be selected if at some point another OCS or Lync deployment would be reachable via the isolated network (as in another internal test deployment).


  • Enter the desired external FQDNs.  For the SIP Access (a.k.a. Access Edge) it is recommended to use but any resolvable DNS Host record is allowed, but using the sip prefix allows for DNS Host (A) record fallback to be used for automatic client configuration in the absence of functional SRV records. Leave the suggested port numbers for each role as the wizard set them.


  • On the Define the Internal IP Address page enter the IP address which is (or will be) assigned to the internal interface of the new Edge server (e.g.


  • On the Define the External IP Address page enter the desired IP address on the external interface (a.k.a. isolated network) of the new Edge server (e.g.  Populate the Web Conferencing and A/V Conferencing fields as well with the two other IP address previously bound to the Edge Server (e.g.,


  • As only a single internal pool/server is deployed then the Define the Next Hop page should already show the only choice available.  If there are multiple pools deployed internally then select the desired pool which will be the ‘next hop’ target for inbound traffic from the Internet passing through the Edge server.  (If a Director server/pool was deployed then that would be the desired next hop setting.)


  • Check the box next to the desired internal Lync pool/server to enable this new Edge server as the external route for media traffic (e.g. lync.schertz.local).


  • Complete the wizard and then select the Publish Topology action to push the changes into the environment.

2. Complete Edge Configuration

After the topology has been published but prior to deploying the Edge Server components the external access settings and policies need to be configured in Lync Server.

  • Using the Lync Server Control Panel browse to the External User Access menu and select the Access Edge Configuration tab.  Enable the options as shown below on the Global policy (or define a new policy for these setting if desired) and commit the changes.


  • On the External Access Policy edit the Global policy and enable communications with remote users and commit the changes.


At this point the topology is informed of the new configuration. The Edge server is not domain-joined and thus has no access to the Lync configuration data in Active Directory and the various SQL databases, so these changes will need to be pushed to the Edge server manually. This is only a one-time process as once the Edge Server is deployed it will synchronize future changes automatically with the internal management databases via push replication initiaed by the internal Lync Front end server.

  • To prepare for the Edge server setup export the new topology data into the required ZIP file format by using the Export-CsConfiguration cmdlet in the Lync Server Management Console. For the FileName switch enter the location where the new file is to be created. (If this file already exists from a previous attempt then either delete the old file or specific a new path as the cmdlet will fail if the target file already exists.

Export-CsConfiguration -FileName c:\temp\

  • Copy the .zip file over to the Edge Server and retain this file for use during the server components installation.

Now would also be a good time to manually configure the certificate trust on the Edge Server since it’s not domain-joined.  In this scenario an Enterprise Windows CA is deployed in the internal network, so retrieving and importing the Root CA certificate into the Edge Server is required prior to requesting and installing server certificates for the Edge Server.

  • On the Lync Front End Server open the Certificates MMC Snap-in and then locate the certificate currently assigned to the Lync services.  View the properties of that certificate and from the Certification Path tab highlight the root certificate in the chain and select the View Certificate button.


  • Then change to the Details tab and select the Copy to File button to launch the Certificate Export Wizard.


  • In the export wizard select DER encoded binary X.509 (.CER) and then choose a local filename and path to save the root certificate (e.g. c:\Temp\RootCert.cer).
  • Copy this file over to the Edge Server and then open the Certificates MMC Snap-in, making sure to select the Computer account when adding the snap-in.
  • Navigate to Certificates (Local Computer) > Trusted Root Certification Authorities > Certificates and then select All Tasks > Import to launch the certificate import wizard.
  • Browse to and select the .CER file copied over to the Edge Server and then verify that the Trusted Root Certification Authorities store is chosen and then complete the wizard.


At this point the Edge Server will no trust any certificates issued to it from the internal certificate authority.

3. Install Edge Server Components

  • Launch Windows PowerShell buy selecting ‘Run As Administrator’ and enter the following cmdlets to quickly install the .NET Framework 3.5.1 package and the Telnet Client (which is not a requirement but is helpful as a troubleshooting tool).

Import-Module ServerManager

Add-WindowsFeature NET-Framework,Telnet-Client

  • From the installation media launch the setup wizard found at the following location:


  • At this point the setup will automatically ask to install the Microsoft Visual C++ 2008 Redistributable x64 package. Confirm the installation and wait for the next setup window to appear as this package is silently installed in the background.


  • Accept the default Installation Location, or enter a different path, and select Install. Then accept the End User License Agreement.
  • When the main Deployment Wizard window appears select the Install or Update Lync Server System option.


  • Click Run on Step 1: Install Local Configuration Store and then browse to the topology export file which was previously copied over to the Edge Server.  Submit the file and the Lync Bootstrapper will execute, installing the required system files on the server.


  • Click Run on Step 2: Setup or Remove Lync server Components to complete the prerequisite check and then begin installing the Lync Server components.  No databases will be installed as the Edge Server does not contain any replicas of the Lync databases (nor is SQL even installed).

      4. Deploy Edge Server Certificates

      The following steps cover the processes of issuing two separate certificates requests for the Edge Server, one for an internal facing certificate and another for the ‘external’ facing certificate.

    • Click Run on Step 3: Request, Install, or Assign Certificates, expand and select Edge internal in the wizard, and then click Request.
    • Select the options to Send the request immediately to an online certification authority and then specify the path to the CA server.  This path would be the CA server’s FQDN followed by the name of the CA itself.  The CA name can be validated by opening the previously imported root certificate and checking the Issued By name listed on the General properties of the certificate (e.g. dc.schertz.local\Schertz-RootCA).


    • Specify Active Directory domain user credentials sufficient to authenticate to the internal CA and issue certificate requests.


    • Define a descriptive Friendly Name for the new certificate (e.g. Lync Edge Internal Cert) and mark the certificate’s private key as exportable.  (Marking the certificate as exportable is not a requirement as the Edge Server itself is being used to issue the request so the private key will be created on this server and available to the Edge Server.)


    • Complete the wizard request leaving the defaults for the remaining options to finish the request and then assign the new certificate to the services immediately.
    • Back at the main wizard screen expand and highlight the External Edge certificate option and select Request.  If a public certificate will be used for this then select the offline request option, otherwise select the online request option and follow the same steps as above, using a new name for this certificate (e.g. Lync Edge External Cert).
    • Once the wizard has completed the request and assignment verify on the main window that both certificates appears as Assigned.


    5. Validate Edge Services

    In the final steps of the deployment the services will need to be started and a few tests can be run to verify proper communications between the Front End and Edge servers.

    • Click Run on Step 4: Start Services and validate that all services successfully start.


    • From the Windows Command Prompt on the Lync Front End Server test telnet connections to the internal listening ports on the Edge Server.  Each command should produce a blank telnet window (except the PSM port of 8057 will return a bunch of ASCII character).  If any tests result in a connection failure or timeout then consult the Lync Server application log on the Edge Server to identify any issues with the services.

    telnet edge.schertz.local 5061

    telnet edge.schertz.local 8057

    telnet edge.schertz.local 443

    • From  the Windows Command Prompt on the Lync Edge Server test telnet connections to the external listening ports on the server itself.  This will verify proper local DNS name resolution for the new external records created in the local DNS zones.

      (Note that upon the earlier installation of the DNS server that the secondary interface will automatically be configured to use the local DNS service as well as the internal DNS configured on the internal interface.)

    telnet 443

    telnet 443

    telnet 443

    • From a Windows PC connected to the isolated network perform the similar tests below which will validate name resolution and port connectivity to the external Edge Server services. The results for each should be identical to the tests in the previous step.

    telnet 443

    telnet 443

    telnet 443

    By Jeff Schertz

    Site Administrator

    35 thoughts on “Lync Server 2010 Deployment – Part 4”
    1. 1.In a Front End pool, the back-end database can be a single computer running SQL Server

      2.But I want Change:”two or more dedicated computers running SQL Server in a multiple-node active/passive configuration For the Front End pool”。

      3.How do you do?

      1. This series of articles only covers a basic Standard Edition deployment. For assistance deploying Enterprise Edition servers with SQL clustering I recommend reading through the official deployment guides on TechNet. You can search Microsoft download for 'Lync Deployment Guide' to find a variety of related documentation.

    2. Hi Jeff, Thanks for the article! It's great and very detailed. however I was wondering why did you have to add the av, webconf and sip to the dns ? aren't those added only to the public dns and the network segment 172.16.x.x is not part of the Lync local dns network ?

      1. That DNS zone presents the external (or 'public') zone, so that step IS adding them to the public DNS zone.

    3. Jeff,

      Thank you for an amazing blog! One quick question, is it possible to host both the Reverse Proxy (using FFTMG) and the Lync Edge Server services on 1 server? I'm trying to set up a virtual environment for training engineers so I need to conserve hard drive space if possible.

      1. No, ISA/TMG is not supported on the same host as the Edge Server. If you are using a virtual environment then one trick to save space is to use Windows 2003 with ISA 2006 SP1 as it will have a much smaller disk footprint than running TMG on Server 2008, as well as require less RAM to run.

    4. Jeff, I like the way you have written this up. I have been mystified by many of the How Tos out there. I have a question about how to apply your solution to my situation. I have a private network. It is connected to the LAN port on a Sonicwall firewall, and an internet facing router on the WAN side of the firewall. I have created a DMZ, or perimeter network off of the firewall. itn that perimeter network is my Edge server. I am getting ready to build the topology and install the Edge role. I have a few conceptual problems. What do you put as the DNS server of the Edge server? I am guess ing I use the firewall address as the Edge server's default gateway. What is necessary for the edge certificate?

      1. David, normally the DNS server that the Edge server uses is either an internal DNS server or if there is one in the DMZ (not as common). The Edge Server has two certificates (internal and external) at minimum and the internal cert contains only the internal Edge FQDN and the external cert contains the Access Edge FQDN (generally and the Web Conferencing Edge ( The A/V Conferencing Edge FQDN is not used on either certificate.

        1. I have created the first zone in step 3, which populates with the addresses, and I have added the three (av, sip, and webconf). I am unsure how to proceed with the second zone. What does it contain? Right now, the perimeter network contains two servers, but will have some more later.

          Also, I exported my root certificate to the edge server, and I imported it, but when I request the internal Edge and then try to assign it, it says "Windows does not have enough information to verify this certificate", and" the issuer of this certificate could not be found". I assume that is because of either a DNS issue or there needs to be a route or some such on the firewall. It is a three legged DMZ with a Sonicwall firewall.

    5. Regarding configuring TCP/IP settings for the Edge server: In my implementation, the internal network where the Front End Pool , DNS server, Exchange, and all clients reside is 10.1.x.x /16. The DMZ where the Edge server resides is /24. The outside network is of course a public IP range. My question is this.

      What should the default gateway of the Edge server be? My guess is the public interface on the firewall. Also, what should the DNS server setting be? My guess is the 10.1. address of the DNS server. Please correct me if I am wrong. I am having trouble converting the info in your example to my setup, which is a 3 legged DMZ configuration.

      1. David, The default gateway should only be on the external Edge interface and should be the next-hop route (router, firewall, etc) for that external DMZ network. An typically the internal interface of the Edge server would be the only interface configured with a DNS server which is often a DMZ or internal DNS server (traffic may need to be opened for this) and also make sure that if you are using NAT on the external Edge IPs that the public IP is defined for the A/V Edge external FQDN on that internal DNS Host record. Since the Edge server will resolve that name via an internal DNS zone it needs to resolve the public NATed IP and not the actual IP assigned to the interface if it's different.

    6. Hi Jeff ..

      It is written at MS documentation that for Single Edge topology the NAT is mandatory.
      I dont have any DMZ in my network, cant i use direct PUBLCI IP on external interface rather to use NAT or NAT is mandotory if i have only '1' edge server.


      1. Norman, I'm not sure what documentation you are referring to but NAT is definitely not mandatory in any Edge scenario. Either public IPs or NATed private IPs can be used on the external interface. When dealing with Hardware Load Balancers and Edge Pools then NAT is not supported.

    7. Hi! Great guide! I got a bit confused about the though.. Is the the SIP domain you specified when installing Lync?

      For me, my domain is, and my sip domain I specified is also Is this configuration ok?


      1. That is my SIP domain, which happens to be different than my AD domain name (schertz.local). You can use the same namespace for both AD and your primary SIP domain if you like instead, either configuration is allowed.

          1. Also, I want to ask; is this configuration allowed? My SIP Domain is different from what I have specified in External FQDNs.

            SIP Domain:
            External FQDN:,,

            I'm thinking it should work since it is only a DNS issue? As long as DNS is properly configured.


            1. This depends on which clients and features need to be supported. Ideally all external FQDNs should match your primary SIP domain, but if you have multiple SIP domains then you would only need to create additional Access Edge FQDNs ( A single Web Conferencing FQDN and AV FQDN can be used by all clients using any defined SIP domain in the deployment.

    8. Jeff:

      This works for me until I try to telnet from the client to the edge server in the very last step. I can only telnet to "ES" (name of the edge server) over 443, all the other telnet scenarios do not work. I have installed DNS on the Edge,DHCP was working but shut down because it cannot connect to a Active Directory Domain Controller. I am using 192.168.1.x /24 for an external network. I have installed host file entries. Internal and external SRV records resolve from the DC (_sipinteraltls._tls.(sipdomain), _sip._tls.sipdomain). Any ideas??
      Thank you!!

      1. If you can telnet to some but not all of the internal interface ports (5061, 8057) then I would assume you have a firewall configuration issue. Most likely 443 is allowed from your internal network as it's a common port, but the others are specifically blocked.

    9. Jeff:
      Here is an update: I have changed the client to use static IP addresses, DHCP is still down and will not authorize. Everything works with static addresses.

      Great article – I am researching the DHCP error. Bob

    10. Jeff,
      If I have a SIP trunk coming into my Front End Server and I publish an Edge Server, will I need to move the SIP trunk to the Edge Server?

      Thank you

    11. Excellent Blog, you are my go to guy, one question while trying to create CsDialInConferencingAccessNumber, I get the error Urn:application:Caa does not exist. Do you have to manually create this endpoint/application/pool?

    12. Jeff,
      I got a question about inviting anonymous users to meetings when federation is turned of (Access Edge Configration). What if the user you want to invite has Lync in their enterprise, with federation on their side. And you still want them to join as anonymous.

      Or even worse, you have federation turned on in the Access Edge Configuration. But some users are not allowed to communicate with federated users. How can they invite someone using Lync in their own enterprise?


    13. superp guide!!
      hello sir …
      I need to test my edge server deployment (in test environent), I have only public IP address with me, and didn't have a Public Fqdn.
      So can i provide the IP address in my client (in Advance Connection Settings >> Manual Configuration >> External Server Name : thnx n rgds….Luk

      1. Lync must use an FQDN, you cannot use IP addresses with TLS and Lync client. In the event you don't have access to an external DNS host to define the record you can simple add the required FQDNs into the 'HOSTS' fie on the Windows workstation running your Lync client for testing. Make sure to add entries for all three external FQDNs (e.g.,, &

    14. We deployed Lync 2010 but no longer have a need for our lync proxy and lync edge servers. When we turn off our lync edge server and uncheck the lync edge association pool in the topology builder, our clients receive an error message stating “Limited external calling”. Is there a way to get rid of this?

      1. If you truly will never need an Edge Server then you should remove it completely from your topology, although I do not know if that will remove the message as I’ve never removed an Edge server from an environment.

    15. HI Jeff,

      Hi Jeff,
      Need your advice, I have 3 networks communicating through jumpbox.
      N/W 1 : AD, DNS, LYNC, Front end, Bac kend etc. ….abc.local (no exchange server)
      N/W 2 : EDGE server (on workgroup with abc,local FQDN) with 2 NIC one has IP address of N/W and jumpbox
      N/W 3: XYX.local
      Requirement is to test LYNC access (only Chat) from any location in lab environment without having internet connectivity. i.e user1 will login from XYZ.local and login to LYNC with abc.local\user1 credential to chat with abc.local users.
      We have deployed EDGE and LYNC server, the LYNC server is working OK for all users on ABC.local network
      Solicit you advice for setup changes required.

    16. Hi Jeff
      I have followed all the instructions but I keep on getting the internal certificate bound to my external network interface… How can I fix this?

    Leave a Reply

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