Lync 2013 – Mobility and Edge Topology: Explained

Introduction

This article is intended to serve as a supplement to any Lync 2013 Front End/Edge setup documentation. There are a lot of really great how-to’s out there and Technet has extensive documentation on the process. However, there are some things that are unclear or somewhat ambiguous and could really use the help of some explanation.

We’ll be looking at the different server roles, how each component interacts, and an explanation of the network requirements outlined by Microsoft. Having a clear understanding of the overall layout will help when trying to make sense of the topology and how to plan.

The scenario below describes a Single Consolidated Edge Topology with NAT, utilizing a single server for each the Front End and the Edge. While not completely accurate, I will be referring to the Lync Standard Edition server in my deployment as the Front End server. The reason being that the Standard Edition server plays essentially the same role as an Enterprise Front End so the concepts will apply here.

Contents

    1. Lync 2013: Ins and Outs
      1. Server Roles
        1. Lync Front End Server
        2. Lync Edge Server
        3. Reverse Proxy
    2. Network Layout
      1. Network Planning
      2. Edge IPs and URLs
        1. Edge vs “Simple” URLs
        2. Static Routes
      3. Reverse Proxy IPs and URLs
        1. IP Addresses
        2. Simple URLs
      4. Firewall and Port Requirements
        1. STUN/TURN
        2. Edge Requirements
          1. External Interface
          2. Internal Interface
        3. Reverse Proxy Requirements
        4. Port Diagram
    3. DNS Requirements
      1. External DNS
      2. Internal Public Zone DNS
    4. Certificates
      1. Required SANs
      2. Applying Certificates in Lync 2013
    5. Applying Cumulative Updates
      1. Updating Central Management Database
    6. Testing
    7. Summary

Lync 2013: Ins and Outs


To understand how Lync fits together, let’s first become familiar with the server roles.

Server Roles

The Front End, Edge, and Reverse Proxy are all very different players, and understanding how each of them works will help when trying to digest the technical requirements. There are many unique network specifications that will be outlined below and accompanied by a clear description of what’s necessary and why.

Lync Front End Server

In a non-Enterprise deployment this is known as the Standard Edition server. This guide uses the term Front End to describe either an Enterprise FE or Standard Edition server depending on the setup.

The Front End serves as the core component of Lync. Basically, anything that happens on Lync takes place in some fashion on the Front End. What’s important here is to note how the Front End server communicates with the Edge and the Reverse Proxy and how the ensuing connections are handled between peers (specifics outlined below).

This server sits on the internal network and is directly accessible by a single interface. The server resolves to clients using either the FQDN, LyncDiscoverInternal record, or SIP internal SRV record.

Front End Services Include:

      • IM/Chat
      • Address Book
      • Presence
      • Conferencing
      • Enterprise Voice

Lync Edge Server

The Edge server handles outside connections via the Federation, Web Conferencing, and A/V services. This server requires very particular network configurations that will be discussed in detail below.

Meetings joined from external locations into the corporate network are all directed through Edge after having first authenticated through the Reverse Proxy. Edge brokers features such as desktop sharing, whiteboard, and A/V meetings with external users as well as providing federation with other Lync organizations (XMPP Federation is also supported in Lync 2013).

Edge Services Include:

    • Access Edge: Federation
    • Web Conferencing Edge: Conferencing for External Users
    • A/V Edge: External A/V communication, Desktop Sharing

    Reverse Proxy

    The Reverse Proxy is a basic firewall that provides NAT and port translation for a single external interface to five internal Lync services. These services are Autodiscover for External Clients, Mobility (push notifications), Voice Dial-in, meeting URL access point, and certificate provisioning for outside Lync connections.

    The Reverse Proxy communicates directly with the Front End server and does not forward through the Edge.

    Reverse Proxy Services Include:

        • Dial-in for Voice conference
        • Meet URL to join meetings
        • External Autodiscover
        • Push notification for Mobile clients
        • CertProvisioningServices

    Network Layout

    Please refer to the Lync Diagram poster v6.7, Found Here, for a comprehensive view of the many routes and ports that are utilized by the different Edge services. This diagram is very useful in being able to give a full visual of all the port requirements at a glance for any given service. Keep it on hand at all times.

    Also find below a basic layout for the external services’ IP addressing scheme, firewall configuration, and certificate requirements.

    Network Planning

    Now that we have a better understanding of the services that run on each server, let’s look at where they sit and how they communicate.

    Lync Topology

    The DMZ

    In a Single Consolidated Edge Topology with NAT, it’s best to segregate the Edge and Reverse Proxy from the internal network by placing them in the DMZ. The DMZ should have a perimeter firewall on each side in order to separate the internal and external networks completely. This helps reduce the attack surface of the Edge since it is the primary point of exposure to the outside world.

    It is also recommended NOT to join the Edge to the domain for the same reason.

    Open port requirements for each firewall will be outlined in depth below.

    Edge IPs and URLs

    IP Addresses

    It is recommended that the Edge server have 3 IP addresses assigned to the external interface. These three addresses, as well as their URLs, are configured in Lync when creating an Edge Server pool in Lync Topology Builder.

    Edge IPs

    Important! Be sure to select the option The external IP address of this Edge pool is translated by NAT if your external IP addresses are translated through the firewall. Enter your A/V public IP for this field.

    External NAT

    In Windows, configure the External NIC to have three network addresses as well as a default gateway. Do not register this interface with DNS.

    Edge External NIC

    External

    The Internal interface should have just a single IP as well as an internal DNS if desired. There should be no gateway on this NIC.

    Edge Internal NIC



    Internal

    Edge vs Simple URLs

    It is very important to not use any reserved names for your Edge URLs. For instance, meet.contoso.com is reserved by Lync as the meeting URL. This cannot be changed, so if you use the Meet URL for any other Edge services they will not work.

    The downfall here is that Lync will not warn you if you do happen to use any of these names, so be cautious.

    Simple URLs

    Choose names that can be clearly identified for their associated service (ie Access, webconf, and AV are good).

    Edge URLs

    All three of these URLs, as well as meet.contoso.com and dialin.contoso.com, will need to be registered in Public DNS and a SAN is required for each on the public certificate. More details below.

    Edge Static Routes

    Because the Edge resides in the DMZ and the default gateway is configured on the external interface, static routing may be required to direct incoming traffic to the internal Front End server.

    To do this, use “route add” with the -p switch on the Edge server from an elevated command prompt. The entry should be set to route all traffic directed to the internal network (ie where FE sits) over the internal interface.

    To find the Interface value assigned to your NIC, use the route print command. Find and record the numeric value representing the internal NIC under the Interface List table from the route print output.

    Interface List - Route Print

    You may require several route add entries depending on your network layout. A basic static route entry should look something like this:

    route add -p 192.168.1.0 mask 255.255.255.0 192.168.0.254 IF 12 -p

    The above example assumes that the destination network is 192.168.1.0the destination subnet is 255.255.255.0, the gateway capable of routing to the destination is 192.168.0.254, and the interface used to route the traffic is 12. In the image above we can see that “vmxnet3 Ethernet Adapter”  is IF 12. The -P switch sets the route as persistent.

    Reverse Proxy IPs and URLs

    In regards to the Reverse Proxy and associated public DNS, I’ve written an article on deploying Mobility and tips for setting up the RP with Microsoft TMG. Be sure to check that out here.

    (Lync 2013 – Mobility Setup Tips)

    Also take a look at these great guides if setting up a TMG server for the Reverse Proxy solution.

    TMG Publishing Rules for Lync – Publishing Lync Server Simple URLs and Web Components with Forefront TMG 2010
    Reverse Proxy TMG Setup – Lync Reverse Proxy Setup

    IP Addresses

    The Reverse Proxy will have a similar network config as the Edge server with only one IP address facing the outside.

    The gateway will need to be set on the external interface and no DNS.

    As with the Edge server, the RP may require a static route for sending traffic to the FE server. Please see the steps above for configuring static routes.

    Set up the internal interface the same way as the Edge server. DNS is optional.

    URLs

    The Reverse Proxy is not only important for Mobility and Autodiscover, but it also provides access for guests to join meetings and for internal users to use the Lync Web App.

    The URLs that resolve to the Reverse Proxy externally are as follows:

        1. lyncweb.contoso.com (External FQDN)
        2. lyncdiscover.contoso.com (Lync Autodiscover URL)
        3. meet.contoso.com (Meeting Simple URL)
        4. dialin.contoso.com (Dial-in Simple URL for phone dial-in)

    The External FQDN is selected when building the Front End pool and can be updated at any time in the Topology Builder.

    External Web Services

    These URLs, in addition to the Edge URLs, will need to be included in a single public certificate.

    It is also advisable to direct internal authoritative DNS for lyncdiscoverinternal.contoso.com to the Reverse Proxy’s external interface. This helps keep mobile clients from timing out if they roam to an internal network from an outside area.

    Firewall and Port Requirements

    There are many incoming/outgoing port requirements to allow for External Lync services to function properly. It is very important to open all of the ports listed below unless otherwise stated.

    The port table is a transposition of Microsoft’s set requirements, with a little additional detail and explanation. At the end of this section there will be a link to a tool that can be used to verify all necessary ports from different originating locations.

    The Lync Front End server should be fully open on the single internal interface to avoid any issues. However, granular port configuration can be used if desired.

    Using the IP examples from above, let’s assume that our Edge services have the following IP addresses:

    Lync Services Public IP External IP Internal IP
    Access Edge 10.0.0.100 192.168.0.101 192.168.1.201
    Web Conferencing Edge 10.0.0.101 192.168.0.102 192.168.1.201
    A/V Edge 10.0.0.102 192.168.0.103 192.168.1.201
    Reverse Proxy 10.0.1.100 192.168.0.104 192.168.1.202
    Edge Internal FQDN 192.168.1.100

    Again, here is the simple external services layout using the above addressing scheme.

    Lync Topology

    STUN/TURN

    A quick mention on STUN/TURN: Microsoft explicitly states the need for STUN or TURN capabilities on the firewall. These features are designed to provide symmetric NATing and allow bi-directional communication between peers.

    We used a Cisco ASA in our deployment for the NAT, and while it did not have any specifications about STUN/TURN, the translation was confirmed as being symmetrical. If your firewall specifically defines STUN or TURN, be sure to enable it on the following port rules. If you’re having issue and see no specification for STUN or TURN, you may want to contact the manufacturer to verify symmetric NAT capabilities on the firewall.

    Port Requirements – Edge

    The following port requirements are for the Edge Server’s Internal and External interfaces.

    The Reverse Proxy port requirements are far less comprehensive and only include incoming ports 80 and 443 on the external interface and ports 8080 and 4443 opened on the internal interface. This will be discussed briefly below.

    Edge External Interface

    Role/Protocol/TCP or UDP/Port Source IP address Destination IP address Explanation

    XMPP/TCP/5269

    Any

    XMPP Proxy service (shares IP address with Access Edge service)

    XMPP Federation is for partners with 3rd party IM services such as AIM, MSN, GChat, or Jabber.


    Only necessary if federating with XMPP partners.

    Access/HTTP/TCP/80

    Edge Server Access Edge service

    Any

    Certificate revocation/CRL check and retrieval for Federated/External Partners

    Access/DNS/TCP/53

    Edge Server Access Edge service

    Any

    DNS query over TCP for resolving Federated/External Partners

    Access/DNS/UDP/53

    Edge Server Access Edge service

    Any

    DNS query over UDP for resolving Federated/External Partners

    Access/SIP(TLS)/TCP/443

    Any

    Edge Server Access Edge service

    Client-to-server SIP traffic for external user access

    Allows _sip._tls resolution for Federated/External Partners

    Access/SIP(MTLS)/TCP/5061

    Any

    Edge Server Access Edge service

    For federated and public IM connectivity using SIP

    Part of the _sip._tls resolution and communication.

    Both ways!

    Access/SIP(MTLS)/TCP/5061

    Edge Server Access Edge service

    Any

    For federated and public IM connectivity using SIP

    Part of the _sip._tls resolution and communication.

    Both ways!

    Web Conferencing/PSOM(TLS)/TCP/443

    Any

    Edge Server Web Conferencing Edge service

    Web Conferencing media

    Incoming SSL connection allows participation in conferences

    A/V/RTP/TCP/50,000-59,999

    Edge Server A/V Edge service

    Any

    THIS IS IMPORTANT!

    While Microsoft says these ports are only required for federation with Office Communications Server 2007, I have spoken directly with their support team and was told that these are REQUIRED for A/V services to work.

    Open these ports regardless of what Microsoft recommends or there will be problems with A/V services such as Desktop Sharing.

    A/V/RTP/UDP/50,000-59,999

    Edge Server A/V Edge service

    Any

    THIS IS IMPORTANT!

    While Microsoft says these ports are only required for federation with Office Communications Server 2007, I have spoken directly with their support team and was told that these are REQUIRED for A/V services to work.

    Open these ports regardless of what Microsoft recommends or there will be problems with A/V services such as Desktop Sharing.

    A/V/RTP/TCP/50,000-59,999

    Any

    Edge Server A/V Edge service

    THIS IS IMPORTANT!

    While Microsoft says these ports are only required for federation with Office Communications Server 2007, I have spoken directly with their support team and was told that these are REQUIRED for A/V services to work.

    Open these ports regardless of what Microsoft recommends or there will be problems with A/V services such as Desktop Sharing.

    A/V/RTP/UDP/50,000-59,999

    Any

    Edge Server A/V Edge service

    THIS IS IMPORTANT!

    While Microsoft says these ports are only required for federation with Office Communications Server 2007, I have spoken directly with their support team and was told that these are REQUIRED for A/V services to work.

    Open these ports regardless of what Microsoft recommends or there will be problems with A/V services such as Desktop Sharing.

    A/V/STUN,MSTURN/UDP/3478

    Edge Server A/V Edge service

    Any

    3478 outbound is used to determine the version of Edge Server that Lync Server is communicating with and also for media traffic from Edge Server-to-Edge Server.

    THESE PORTS ARE REQUIRED IN ALL CASES.

    A/V/STUN,MSTURN/UDP/3478

    Any

    Edge Server A/V Edge service

    STUN/TURN negotiation of candidates over UDP/3478

    Negotiates A/V connections with federated peers.

    Handled services include Desktop Sharing and video meetings.

    A/V/STUN,MSTURN/TCP/443

    Any

    Edge Server A/V Edge service

    STUN/TURN negotiation of candidates over TCP/443

    Negotiates A/V connections with external peers.

    Handled services include Desktop Sharing and video meetings.

    A/V/STUN,MSTURN/TCP/443

    Edge Server A/V Edge service

    Any

    STUN/TURN negotiation of candidates over TCP/443

    Negotiates A/V connections with external peers.

    Handled services include Desktop Sharing and video meetings.

    Edge Internal Interface

    Protocol/TCP or UDP/Port Source IP address Destination IP address Comments

    XMPP/MTLS/TCP/23456

    Any (can be defined as Standard Edition server IP, Standard Edition server IP address, or pool IP address running the XMPP Gateway service)

    Edge Server internal interface

    Outbound XMPP traffic from XMPP Gateway service running on Front End Server or Front End pool

    Traffic originates from internal Lync FE server.

    Only necessary if federating with XMPP partners.

    SIP/MTLS/TCP/5061

    Any (can be defined as Director, Director pool IP address, Front End Server or Front End pool IP address)

    Edge Server internal interface

    Outbound SIP traffic (from Director, Director pool IP address, Front End Server or Front End pool IP address) to Edge Server internal interface

    Traffic originates from internal Lync FE server.

    Forwards FE SIP communication to Federated/External Partners

    SIP/MTLS/TCP/5061

    Edge Server internal interface

    Any (can be defined as Director, Director pool IP address, Front End Server or Front End pool IP address)

    Inbound SIP traffic (to Director, Director pool IP address, Front End Server or Front End pool IP address) from Edge Server internal interface

    Traffic originates from external, terminates at Lync FE server.

    Forwards Federated/External SIP communication to FE

    PSOM/MTLS/TCP/8057

    Any (can be defined as Front End Server IP address, or each Front End Server IP address in a Front End pool)

    Edge Server internal interface

    Web conferencing traffic from Front End Server, or each Front End Server if in a pool, to Edge Server internal interface

    Traffic originates from internal Lync FE server.

    SIP/MTLS/TCP/5062

    Any (can be defined as Front End Server IP address, or Front End pool IP address or any Survivable Branch Appliance or Survivable Branch Server using this Edge Server)

    Edge Server internal interface

    Authentication of A/V users (A/V authentication service) from Front End Server or Front End pool IP address or any Survivable Branch Appliance or Survivable Branch Server using this Edge Server

    Authentication traffic for A/V services to Federated/External partners.

    Traffic originates from internal Lync FE server.

    STUN/MSTURN/UDP/3478

    Any

    Edge Server internal interface

    Preferred path for A/V media transfer between internal and external users, Survivable Branch Appliance or Survivable Branch Server

    A/V traffic originates from internal Lync FE server to use this preferred port.

    STUN/MSTURN/TCP/443

    Any

    Edge Server internal interface

    Fallback path for A/V media transfer between internal and external users, Survivable Branch Appliance or Survivable Branch Server if UDP communication cannot be established, TCP is used for file transfer and desktop sharing

    A/V traffic originates from internal Lync FE server to use this fallback path if UDP is unavailable.

    TCP is always used for file transfer

    HTTPS/TCP/4443

    Any (can be defined as the Front End Server IP address, or pool that holds the Central Management store)

    Edge Server internal interface

    Replication of changes from the Central Management store to the Edge Server

    Replication traffic to/from Lync FE

    MTLS/TCP/50001

    Any

    Edge Server internal interface

    Centralized Logging Service controller using Lync Server Management
    Shell and Centralized Logging Service cmdlets, ClsController command line
    (ClsController.exe) or agent (ClsAgent.exe) commands and log collection


    Centralized Logging

    MTLS/TCP/50002

    Any

    Edge Server internal interface

    Centralized Logging Service controller using Lync Server Management
    Shell and Centralized Logging Service cmdlets, ClsController command line
    (ClsController.exe) or agent (ClsAgent.exe) commands and log collection


    Centralized Logging

    MTLS/TCP/50003

    Any

    Edge Server internal interface

    Centralized Logging Service controller using Lync Server Management
    Shell and Centralized Logging Service cmdlets, ClsController command line
    (ClsController.exe) or agent (ClsAgent.exe) commands and log collection


    Centralized Logging

    Port Requirements – Reverse Proxy

    As mentioned above, the Reverse Proxy has very minimal requirements. The RP has a single external interface and address and a single internal interface for communicating traffic to the Front End.

    Please check out my Lync Mobility article for tips on setting up the reverse proxy with Microsoft TMG. Also please follow the links in the Reverse Proxy IPs and URLs section above for full steps on setting up a TMG server as the RP.

    Reverse Proxy External Interface

    Protocol/TCP or UDP/Port Source IP Address Destination IP Address Notes

    HTTP/TCP/80

    Any

    Reverse proxy listener

    (Optional) Redirection to HTTPS if user enters http://<publishedSiteFQDN>.

    Also required if using Office Web Apps for conferencing and the Autodiscover
    Service for mobile devices running Lync in situations where the organization
    does not want to modify the external web service publishing rule certificate.

    HTTPS/TCP/443

    Any

    Reverse proxy listener

    Address book downloads, Address Book Web Query service, Autodiscover, client updates, meeting content, device updates, group expansion, Office Web Apps for conferencing, dial-in conferencing, and meetings.

    Be sure to open 443 bidirectionally through the firewall.

    Reverse Proxy Internal Interface

    Protocol/TCP or UDP/Port Source IP Address Destination IP Address Notes

    HTTP/TCP/8080

    Internal reverse proxy interface

    Front End Server, Front End pool, Director, Director pool

    Required if using the Autodiscover Service for mobile devices running Lync in situations where the organization does not want to modify the external web service publishing rule certificate.

    Traffic sent to port 80 on the reverse proxy external interface is redirected to a pool on port 8080 from the reverse proxy internal interface so that the pool Web Services can distinguish it from internal web traffic.

    HTTPS/TCP/4443

    Internal reverse proxy interface

    Front End Server, Front End pool, Director, Director pool

    Traffic sent to port 443 on the reverse proxy external interface is redirected to a pool on port 4443 from the reverse proxy internal interface so that the pool web services can distinguish it from internal web traffic.

    HTTPS/TCP/443

    Internal reverse proxy interface

    Office Web Apps for conferencing

    Port Diagram

    Here is another very useful port diagram. It’s a much simpler version of the Lync Protocol Poster, but is also very helpful for reviewing your port requirements at a glance.

    Lync Perimeter Network

    DNS Requirements

    Lync relies heavily on DNS. DNS is required for almost all of the primary Lync services such as: autodiscover, federation, mobility, joining meetings, initiating conferences, initiating A/V meetings, voice dial-in, etc.

    Be sure to use A Name records rather than CNAME records when registering the Edge and Simple URL entries.

    External DNS

    Type of Record FQDN IP Description  Endpoint
    A Access.contoso.com 10.0.0.100 Access Edge Service – For Federation and External User access Edge
    A WebConf.contoso.com 10.0.0.101 Web Conferencing Edge Service – For attending internal conferences externally Edge
    A AV.contoso.com 10.0.0.102 A/V Edge Service – For initiating and relaying audio/video services Edge
    SRV _sip._tls.contoso.com access.contoso.com: 443 SRV record for resolving the SIP domain from TLS clients. The SRV should be pointed to port 443. Edge
    SRV _sipfederationtls._tcp.contoso.com access.contoso.com:5061 SRV record for resolving SIP domain for Federated partners. Edge
    A Meet.contoso.com 10.0.1.100 Access point for external users to join meetings Reverse Proxy
    A Dialin.contoso.com 10.0.1.100 Dial-in address for joining voice to a conference Reverse Proxy
    A lyncdiscover.contoso.com 10.0.1.100 Autodiscover for external and mobile clients Reverse Proxy
    A lyncweb.contoso.com 10.0.1.100 Lync External Front End Web Services URL Reverse Proxy

    Internal DNS

    The Internal DNS entries below are required if you have an internal authoritative zone for your domain’s public namespace.

    Be sure to add all of the following entries into the public zone DNS, internally.

    Type of Record FQDN IP Description  Endpoint
    A lyncdiscover.contoso.com (internal DNS, public zone) 192.168.0.104 Lync autodiscover URL Reverse Proxy
    A lyncdiscoverinternal.contoso.com (internal DNS, public zone) 192.168.0.104 Lync Internal autodiscover URL Reverse Proxy
    SRV _sipinternaltls._tcp.contoso.com (internal DNS, public zone) lyncprod.contoso.local:5061 Internal SIP SRV record for clients Internal Front End Interface
    SRV _sip._tls.contoso.com (internal DNS, public zone) lyncprod.contoso.local:5061 SRV record for resolving the SIP domain from TLS clients. The SRV should be pointed to port 443. Internal Front End Interface
    SRV _ntp._udp.contoso.com (internal DNS, public zone) Domain Controller/Time Server:123 Updated time server Domain Controller

    Public Certificates

    The final piece of the puzzle is Certificate provisioning. Because the internal certificate structure is relatively straight forward to configure we will only be focusing on the public requirements.

    Required SANs

    A single certificate is needed in this deployment for each of the servers mentioned above. A public CA cert will need to be applied to the Front End External Web Services Site, Edge Server, and the Reverse Proxy for its mobility and Simple URLs.

    Here is a complete list of required SANs to include on the public certificate.

          1. lyncweb.domain.com (External Front End FQDN) – This should be the CN
          2. access.contoso.com (Access Edge)
          3. webconf.contoso.com (Web Conferencing Edge)
          4. av.contoso.com (AV Edge)
          5. lyncdiscover.domain.com (Lync Autodiscover URL)
          6. meet.domain.com (Meeting Simple URL)
          7. dialin.domain.com (Dial-in Simple URL for phone dial-in)

    Applying Certificates in Lync

    There may be a bit of confusion on how to apply or update certificates for the Lync FE web services. I’ve read some guides that say to apply the certificate to the IIS bindings directly to the External Web Services website, but this does not work correctly.

    In order to apply or change certificates in Lync, run the Lync Server 2013 – Deployment Wizard. Select the “Request, Install or Assign Certificates” option to update the certificates for both the Front End and Edge servers.

    DeploymentWizard

    AssignEdgeExternal

    Here are step by step instructions for running the Deployment Wizard to apply certificates:

          1. Log into the Lync FE (or Lync Standard Edition) server
          2. Make sure the public cert with private key is added to the Computer’s Personal store
          3. Run the Lync Server Deployment Wizard
          4. Select Install or Update Lync Server System
          5. On Step 3 of the deployment wizard, select Run or Run Again
          6. Click the drop down next to Default certificate and uncheck all boxes except Web services external”
          7. Click Assign to select your public CA cert and click Next all the way through
          8. Verify that the friendly name for “Web services external” is the name of your public cert
          9. Click Close to finish

    Applying Cumulative Updates

    The latest Lync 2013 CU was released in January of 2014. Please see the related KB Article. It is very important to install all of the latest updates as many fixes and tweaks have been provided in this release.

    The process is very straightforward and easy to perform. Microsoft has an update tool for Lync that checks installed versions and only applies patches to modules that are out of date.

    Updating Central Management Database

    The catch here is that there’s no clear direction of how to update the Central Management Database. The instructions in the KB say to run the following command once the CU patch is complete:

    Install-CsDatabase -CentralManagementDatabase -SqlServerFqdn CMS.FQDN -SqlInstanceName DBInstanceName -Verbose


    CMDatabaseUpdate

    However, nowhere in the article does it say what the DBInstanceName will beTo answer that question, when updating the Central Management Database use the DBInstanceName of “rtc“.

    The final command should look something like this:

    Install-CsDatabase -CentralManagementDatabase -SqlServerFqdn LYNCPROD.CONTOSO.LOCAL -SqlInstanceName RTC -Verbose

    Lync should have more solid functionality and security once these updates have been applied to the services and backend databases.

    Testing

    This is a very useful tool for testing opened ports to the Edge server from Internal, External, Client and Server locations.

    Lync Edge Testing Suite

    Follow up with your Network Engineer or investigate the firewall port rules if you encounter any failures.

    Summary

    This is a very large undertaking and the components associated with the deployment can be difficult to understand at first glance. Digging a little deeper, though, we find there is a logical order to the layout.

    The toughest requirements to fulfill are the Network specifications. Remember that communication has to be symmetrical on both sides of the peer connection when communicating with users on the outside. Making sure that full bi-directional support is functional on all network interfaces and NAT translations is very important. Some network devices might refer to this as STUN or TURN, while others might not refer to it at all. Check with your firewall vendor to make sure this, or a similar setup, is available.

    Also keep in mind that some of the Port requirements given by Microsoft are listed as not needed when they are. A prime example of this is the 50,000-59,999 range of UDP/TCP ports. These ports are required for both inbound and outbound services such as Desktop Sharing to work regardless of who the partner or external user is.

    I hope this guide will help those out there who are experiencing the confusion that we faced while deploying Lync in our organization. After correctly configuring and opening the network, requesting and applying the proper certificates, and making sure DNS resolution is working from all locations, Lync should be fully functional. Any issues with Federated partners should be treated the same on both ends, and all of the areas mentioned above should be verified by both parties.

    Please leave any questions or comments below!

    Cheers!

    -ScriptdEEZ

    I also wanted to give a big shout out to everyone on my team here at OMC for helping pull this together! Many long hours have paid off!

    If you found this article helpful or interesting, please donate a tip!
    (LTC): LYs82mDXPohGDCzeRct8HkJwUCfwveGH1t
    (BTC): 19JUVeefSBNbxUZNNmbDqfcctU6im6vsNg

    Advertisements

14 thoughts on “Lync 2013 – Mobility and Edge Topology: Explained

  1. Pingback: Lync Server 2013 – Mobility Setup Tips | ScriptdEEZ
    • Hey Salman,

      Always happy to expand on a topic or write a new post if it’s beneficial to someone out there.

      Can you tell me what your particular concerns are?

      External or internal DNS?

      Local internal (.local), .com/.org authoritative internal, or split-brain (no local namespace, all .com/.org)?

      • Hello Dear

        I have critical situation according to lync 2013 , I need to contact you for sending the situation as it is and if you can give me any support, it is critical my future in company depend on finish this task
        external users can not login and there is error appeared related to lync can not find lync server domain , this issue related to DNS contact your support team,
        network Team did NAT fro Public IP with port 443 to first Edge IP port 4443, and do 3 rules for SIP, WC and AV, each with difference port and linked to the other 2 IPs at Edge server.
        from external when I write the sign name and press sign in, the login name and password appeared, domain.local\username and password, then press sign , late around 1-2 min and the error message which related to DNS appeared , I did test analyzer , and the only thing I can see related to chain certificate which I don’t know what is this related to the DNS error accured when login

  2. Great article.
    I’m in the process of planning lync and I had just assembled a list of caveats almost identical to your article. If only I found this sooner! The technet documentation is a deep rabbit hole, and I found I had to take a step back and work out what the requirements are per component. This article was a good sanity check.
    Cheers

  3. First of all, great article! Am I correct in assuming that I can use the same public IP for both the reverse proxy and for Access Edge? It looks like I would need port 443 opened for both access and the reverse proxy. Is this correct?

    • Hey Sean, that is correct. It all comes down to your port configuration and how you have your reverse proxy set up to handle the flow of traffic. Keep in mind that certs play a big part of this as well.

  4. it doesn’t work with me, I start to be madness,
    for certificates I have 2 kinds, 1 internal from internal CA, and run without adding any SANs on it just choose the CA server to request and assign, I do that for 2 FE servers for their 4 certificates required.
    for edge internal certificate I request offline and take the csr file to request certificate fro internal CA without adding any SAN
    for external request offline from digecert and added SANs for sip,wc,av,lyncdiscover,meet,dialin,
    the problem I don’t have TMG I did NAT from Fortigate, from 443 ext to 4443 int, and for each edge url services
    but when I connect from external the problem from my previous comment appeared, is that DNS issue or certificate issue or what? and because I can not put any pictures here if you have mail I can send you one file including everything, and you tell me where is the problem, please

  5. another thing if the external url in Lync topology called sip.domain.com, and the external certificate which I created and imported at edge server called sip.domain.com, and the edge urls were sip.domain.com,wc.domain.com,and av.domain.com, is that right or may that problem occurred,

  6. have I publish from TMG or fortigate should work also?
    I opened all ports for external to internal for test , and do the following at fortigate as test because we didn’t configure the TMG for publish we did the following
    – NAT from firewall (x.x.12.245 public IP port 443 to 192.168.100.13 SIP IP at external NIC of Edgeport 4443)
    – (x.x.12.245 public IP port 443 to 192.168.100.13 SIP IP at external NIC of Edgeport 443)
    – (x.x.12.245 public IP port 442 to 192.168.100.14 WC IP at external NIC of Edgeport 443)
    – (x.x.12.245 public IP port 441 to 192.168.100.15 VA IP at external NIC of Edgeport 443)
    – Open all ports
    Problems:
    – When tried from mobile cannot access.
    – When tried from laptop write at sign name the account mail, like X.X at public domain.ae, then credential username and password required which is local domain\x.x , after 1-2 min the error below appeared “lync couldn’t find a lync server for (ext domain) there might be an issue with DNS configuration for your domain please contact your support team”
    – When tried to open https://lyncdiscover.public domain.ae, suppose there is file will prompt to be downloaded but I get nothing
    We didn’t built any rules at TMG, just NAT from Fortigate Firewall to external edge NIC IPs, with all ports opened
    Requirements
    If you have any documents to publish the lync 2013 to be able to publish AV, WC, and SIP please send to me,
    Also need to know should I build 3 rules at TMG to publish lync for SIP, AV and WC, or it is just one rule, and if it will be one rule how transfer traffic to each edge IP
    Also will TMG need certificate? This certificate is the external edge certificate or another certificate?
    Is there is anything missing in DNS records?
    DNS:
    1- External DNS records: x.x.12.245 is the public IP
    Public DNS Record Type Linked IP
    Sip. public domain.ae A x.x.12.245
    Wc. public domain.ae A x.x.12.245
    Av. public domain.ae A x.x.12.245
    Lyncdiscover. public domain.ae A x.x.12.245
    connect. public domain.ae A x.x.12.245
    Sip SRV (tls,443) Sip. public domain.ae
    2-
    Internal DNS, have 2 forward Zones( domain.local, public domain.ae)
    – domain.local (10.0.30.37 lyncFE01.domain. local) , (10.0.30.43 is lyncFE02.domain.local)
    Internal DNS Record Type Linked IP
    lyncfe01.domain.local A 10.0.30.37
    Meet.domain.local A 10.0.30.37
    Dialin.domain.local A 10.0.30.37
    Admin.domain.local A 10.0.30.37
    _sipinternaltls SRV (_tcp, port 5061, priority 0) lyncFE01.domain.local
    Lyncdiscoverinternal.domain.local A 10.0.30.37
    lyncfe02.domain.local A 10.0.30.43
    _sipinternaltls SRV (_tcp, port 5061, priority 10) 10.0.30.43
    – public domain.ae
    DNS Record Linked IP
    Sip. public domain.ae A 10.0.30.37
    Lyncdiscover. public domain.ae A 10.0.30.37
    I Enabled remote and public access from security at lync control
    is there is anything else I should do for DNS

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s