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.

• Lync Server 2010 Deployment – Part 1
• Lync Server 2010 Deployment – Part 2
• Lync Server 2010 Deployment – Part 3

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.)

Overview

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 172.16.1.0/24 was selected, so an IP address of 172.16.1.2 was assigned to the server. (The address of 172.16.1.1 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. 172.16.1.10).  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.)

• In preparation for the Edge Server deployment bind two additional IP addresses to the Isolated Network interface (e.g. 172.16.1.11, 172.16.1.12 and 172.16.1.13) 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. mslync.net).  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 sip.mslync.net, webconf.mslync.net, and av.mslync.net 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. 172.16.1.11) 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. 172.16.1.10) 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. 172.16.1.100-199), 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.

Configuration

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 sip.domain.com 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. 192.168.1.24).

• 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. 172.16.1.11).  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. 172.16.1.12, 172.16.1.13)

• 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\lyncconfig.zip

• 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:

\Setup\amd64\setup.exe

• 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 sip.mslync.net 443

telnet webconf.mslync.net 443

telnet av.mslync.net 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 sip.mslync.net 443

telnet webconf.mslync.net 443

telnet av.mslync.net 443