Lync Edge Server Best Practices

Amazingly enough these topics still comes up daily in technical forums, planning discussions with customers, and when troubleshooting improper deployments.  Although most of this material is not new and can be found in various places this article is intended as summary reference for readers new to the elusive concepts of Edge and Reverse Proxy services.

Overview

Firstly the most important concept to understand when dealing with externally publishing Lync services is exactly what the Edge Server is responsible for handling as well as what it is NOT designed to do. Throughout the documentation a Reverse Proxy Server will be referred to often and it still seems like this concept is often glanced over or not clearly understood.

Edge Server

The Edge server is responsible for handling all communications and payloads in Lync Server which are made available to external and federated users with one exception: anything related to Web Services.  Note that this does not generically mean “stuff over ports 80 and 443” as TCP 443 is used throughout Lync for a variety of different communications.  More accurately it could be said that client communications to servers over HTTP and HTTPS are the types of traffic that are not handled by the Edge server.  Everything else (SIP, PSOM, ICE, etc) are all provided by the Edge server.

Reverse Proxy

The Reverse Proxy server is an optional, external component that is not a Lync Server role and is not defined in the Lync Topology.  The reason this component is considered optional is because without it deployed an external Lync client can still connect to Lync and most features will function (IM, Presence, Calls, Desktop Sharing, etc) as will federated communications.  Only the feature listed on this page will not be available to external clients, which although are important in a fully functional deployment they are not critical.  Yet best practice is always to provide for these features by publishing the internal web services. A Reverse Proxy is also required to support any external Mobility client connectivity.

Traditionally Microsoft’s Internet Security and Acceleration (ISA) 2006 Server or Forefront Threat Management Gateway (TMG) 2010 are used to publish to the Internet the various web services running on internal Lync Front End and Director servers.  But any third-party solution, be it software or a hardware appliance, which has the capacity to publish the internal IIS HTTP/HTTPS services can typically be used.  A brief search online should reveal a handful of documents on how to provide access to internal web servers for various other products.  Also simply configuring port-forwarding from the Internet to the internal servers is possible, but not recommended as a true reverse proxy solution would have the ability to provide traffic inspection and added security on inbound connections directly from the Internet.

Topologies

The questions asked most often are typically related to designing the topology (e.g. how many network interfaces are required) and just how badly some corners can be cut.  Consistently deployments will attempt to use unsupported configurations like a single network interface or not enough unique network subnets, or 4 interfaces with one external interface on an internal subnet with another external interface connected to an unsupported firewall, and so on.

For the best chance of a functional, supported, happy Lync Edge server the guidelines provided in the Assumptions section of the official Lync Edge Server Reference Architecture documentation should be followed as closely as possible.  Granted there are production deployments out there working just fine which do not match some or all of these requirements, but those can often be the exception to the rule.  Also receiving support for problematic deployments or future production failures can be difficult as although Microsoft will provide best-effort support in these cases, the further from a supported scenario the longer the resolution time can be.

For this article two different topologies will be used as examples and the the differences among them will be highlighted throughout the various sections.

Simple Topology

The simplest, fully featured deployment would consistent of a single internal Standard Edition Front End server with a single consolidated Edge server and Reverse Proxy server/appliance located in a perimeter network. This topology contains a single SIP domain and uses the least amount of hostnames possible to still provides all client functionality.

image

Complex Topology

Jumping right into the deep-end this sample topology swaps out the Standard Edition server for two separate Enterprise Edition Front End Pools and introduces the Director role. Every role is comprised of multiple-computer pools to provide fault-tolerance to every available feature. Additional SIP domains are also included, as well as the concept of wildcard certificates.

image

Best Practices

  • Always use two network interfaces on two separate subnets.  The external interface should include the default gateway and the internal interface should not.  Persistent static routes should be defined on the Edge server to address connectivity to internal subnets.

  • As stated earlier the Edge server does not handle any web services requests.  This means that without the optional Reverse Proxy then none of the features provided by web services will be available for external Lync clients and devices (e.g. address book download, location information, device updates, Lync Web App).

  • Additionally the Lync mobile client for phones and tablets will also not function without a Reverse Proxy deployment as these clients are 100% web-based and must be able to communicate to the mobility IIS web site (Mcx) running on the Lync Front End server(s).  The Edge server does not handle any communication with the mobility clients themselves as they are not SIP clients, they only leverage HTTP/HTTPS communications.  The only role the Edge server plays in terms of Mobility is that it is used for establishing Push Notification communications via Federation services.

  • A Lync Director server is not a required server, even when an Edge server is deployed.  It is an optional server which can be used to offload user authentication processing, create an additional layer of protection from external user connections, and provide a single location for internal client connections (per SIP domain) to be proxied through and redirected from.

  • A single Reverse Proxy Web Listener can often be used for all published web services (per internal pool).  The official documentation often shows creating unique listeners for every different URL but this can be costly in terms of IP addresses.  When using ISA or TMG it is possible to use the same Web Listener, IP address, ports, and certificate for multiple publishing rules by defining the specific URLs in the rule configuration.  This holds true only when all published URLs are from the same internal server, so in a single Front End server deployment then a single listener can be used.  But in a more complex deployment with multiple Front End server pools and Directors then a unique listener is required for each source server.  For example the Complex Topology depicted below would require 3 separate listeners and external IP addresses, one for each of the three pools; the same certificate can be used across all listeners though.

Certificates

Coming in a close second is the amount of clarifying questions surrounding certificate configuration for the external servers. How many certificates, which certificate authorities can or should be used, which hostnames go where; the list goes on.

For basic certificate requirements see the TechNet articles for both the Edge server and Reverse Proxy server.  Also the term ‘Common Name’ is used throughout this article. Although it is often used interchangeably with ‘Subject Name’ that is incorrect as technically the Subject Name is a complete Distinguished Name (DN) string which includes the Common Name (CN) as one of the fields. When referring to only the Fully Qualified Domain Name (FQDN) then the term ‘Common Name’ is most accurate.

Basic Guidelines

  • The Internal Edge certificate should be a standard SSL certificate and cannot contain a Subject Alternative Name field.  The Common Name field should be set to the Edge server’s defined FQDN (e.g. edge.schertz.local) in a single consolidated Edge server deployment.

image     image

  • All internally-facing certificates should be issued by an internal Windows Enterprise CA whenever possible. Although it is possible to use trusted third party certificates for the internal Edge interface (as well as other internal Lync server roles) the preferred method which is tested and supported the most is to use an internal CA with a WebServer template for the certificate request.

  • The External Edge certificate should be a UCC or SAN certificate which includes a Subject Alternative Name field.  The Common Name field should be the Access Edge FQDN (e.g. sip.mslync.net) defined in the Lync Topology.  The SAN field should contain both the Access Edge FQDN and the Web Conferencing FQDN (e.g. webconf.mslync.net) as it is a general best practice to duplicate the Common Name in the SAN field (specifically as the first SAN entry) since some foreign devices or systems have been known to (incorrectly) ignore the CN field when a SAN is present.

image     image

  • All externally-facing certificates should be issued by a public trusted certificate authority.  Although it is possible to use internal certificates on either or both the Edge and Reverse Proxy external interfaces only clients or devices which are manually configured to trust the private CA will be able to connect.  Also Edge federation with other OCS or Lync deployments would require that the remote Edge server trusts the same certificate authority.  Thus using a certificate issued by a CA which is by default already in the trusted certificate store of the client, server, or device operating system is always the best approach.

  • Although not typically recommended it is possible to use the same external certificate for both the external Edge server interface and the Reverse Proxy server interface.  This is often done for the purposes of saving money, especially when some third party CAs will require SAN certificates to be purchased in ‘tiers’ where a choice of 1, 5, 10, or more SAN entries will be provided instead of applying an extra cost to each individual SAN entry.  In this case it’s best to use use the Access Edge FQDN as the Common Name and then concatenate the list of all SAN entries from both server roles.

  • As previously explained the Mobility Autodiscover FQDN (e.g. lyncdiscover.mslync.net) does not go on any Edge certificate, it should be added to the Reverse Proxy certificate.

  • Externally-facing certificates should never include any internal hostnames, especially when using separate DNS zones internally and externally.  Broadcasting the internal namespace and server hostnames is poor practice, and is one reason not to attempt to use the same certificate across internal and external interfaces.

A/V Edge

The A/V Edge component is actually comprised of two separate services: A/V Edge and A/V Authentication.  Each has a unique function and communication flow which have been updated since OCS to provide for a simpler certificate configuration.  (The previous article Understanding Lync Edge Ports goes into further detail on these Edge services.)

  • Only the Access Edge FQDN (e.g. sip.mslync.net) and the Web Conferencing FQDN (e.g. webconf.mslync.net) are required on the external Edge Certificate.  The A/V Edge FQDN (e.g. av.mslync.net) which is defined in the Lync Topology for use with the A/V external interface is not required on any certificate.  It is not needed on the external Edge certificates as external clients or servers will not attempt a TLS connection specifically to the A/V Edge external IP address when using the A/V Edge FQDN so there is no need for that FQDN to be provided in the certificate.

  • The A/V Edge FQDN is also not used on the internal Edge certificate. Connections to the A/V Authentication service are only applicable to the internal Edge interface as these connections always come from a Front End server (which proxies all internal or external client A/V authentication requests).  The Front-End server will always use the internal Edge FQDN when connecting to any listening port on the internal Edge server regardless of which service it is connecting to.

Multiple SIP Domains

When supporting multiple SIP domains there are a couple different considerations to take into account which can impact the planning phase related to certificate configuration and public DNS zone records.

  • The recommended approach for external client Automatic Sign-In when supporting multiple SIP domains is to include a unique Access Edge FQDN for each domain name in the SAN field.  This is no longer a requirement (it was in OCS) as it is not possible to create a DNS Service Locator Record (SRV) for each additional SIP domain yet have them all point back to the same original FQDN for the Access Edge service (e.g. sip.mslync.net).  This approach will trigger a security alert in Windows Lync clients which can be accepted by the user, but some other clients and devices are unable to connect when the Automatic Sign-In process returns a pair of SRV and Host (A) records which do not share the same domain namespace.  Thus it is still best practice to define a unique FQDN for each additional SIP domain and include that hostname in the external Edge certificate’s SAN field.

  • A unique Web Conferencing FQDN (or another other Lync FQDN) is not required for each SIP domain as once each client is able to connect the original primary FQDNs for all other services will be passed to the client in-band.  Thus a user in the SIP domain of @domain2.com would utilize the hostname sip.domain2.com to connect but would be automatically provided an FQDN of webconf.mslync.net to connect to the Web Conferencing Edge service.

  • As shown in the Complex Topology it is supported to utilize wildcard entries (e.g. *.mslync.net) for the SimpleURLs (e.g. meet, dialin) as well as the lyncdiscover FQDN.  But not all clients supports wildcard entries for all usages.  For example, even though a recent update to Lync Phone Edition introduces wildcard support there still exists the problem of how to upgrade devices on older firmware to the supported version.  Thus it is always recommended to plan for all potential client and server versions which might need to register to Lync or participate in federated communications.  The key is to avoid placing the wildcard entry in the CN itself and instead provide it as a SAN entry, making sure to still include specific entries for any and all external web service FQDNs from Front End and Director servers.  Then client’s which are still incompatible with wildcard entries can utilize the specific hostnames provided in the SAN field as well.  In the future there will probably come a time when wildcards can be used for all communications, providing simple, cheaper certificate options, especially for hosting providers which need to support a large variety of SIP domains and large deployments.

Edge Pools

When dealing with multiple Edge servers in the same pool there are some specific requirements which must be followed otherwise some or all functionality of the Edge servers can be negatively impacted.

  • As stated earlier the internal Edge certificate cannot include a SAN entry, and this holds true even in multiple server pools.  The Edge Pool FQDN (e.g. edgepool.schertz.local) must be defined as the Common Name and the individual Edge server FQDN is not included in the certificate.  The internal Lync servers, clients, and devices will connect to the pool FQDN and not any of the individual server FQDNs.  For instances when connections need to be opened directly to a specific Edge server, as in relaying a media session, these communications are not SIP-based and often times are initiated directly via an IP address, as in ICE/STUN/TURN negotiation).

    image      image

  • The exact same certificate must be used on all common interfaces across the pool, regardless of whether DNS load balancing or hardware load balancing is utilized.  This means that the original certificate request must provide the ability to export the private key as the exact same certificate and private key pair must be able to be exported from one Edge server into all other Edge servers.  This is required so that in the event of a failover any existing sessions can be moved to another server in the pool and the data can still be decrypted by the same certificate that was used to encrypt the session just prior to the failover.  Compare the serial numbers on each certificate to validate they are the same certificate and not just duplicate requests with the same configuration.  This requirement applies to the internal interfaces as well as the external interfaces, so there will be a single internal certificate shared across all internal Edge interfaces, and a second external certificate shared across all external Edge interfaces. (Do not try to use the same certificate on both internal and external interfaces.)

image image

About Jeff Schertz
Site Administrator

Comments

69 Responses to “Lync Edge Server Best Practices”
  1. Austin Velasquez says:

    Great! Many people think in Reverse Proxy as member of Edge Servers Role

  2. Axxerix says:

    Jeff, why is so difficult to deploy Lync 2010 with just basic settings?? I've been doing this for at least 2 weeks and I'm thinkin' that I'm in the same place that I started… I dont wanna think about doing it for Lync 2013 lol

  3. Emu says:

    Once again great work by Jeff.

  4. Rick Kingslan says:

    First, excellent article as always. You have lattitude that I don't. :o )

    Jeff, for what it's worth – and it looks like it will end up being worth a lot, I'm taking on the task of writing some reverse proxy articles for 3rd party rp's and how to configure them for Lync Server 2010 – including Mobility, and for Lync Server 2013. The first one up is Apache using the SSL module and the reverse proxy modules. We will publish these on the NextHop (http://blogs.technet.com/b/nexthop/) blog site. If can get some focus, my guest writer (a tech guy from Scripps) and I should have the Apache article done and published within about 10 days, 2 weeks,.

    More to come!

    Rick (Lync Server Technical Writer – Microsoft)

  5. Yuri Olinares says:

    Jeff, I do have a question about Reverse Proxy Certs,

    When you look at the Reference Architechture for Lync from Microsoft (http://technet.microsoft.com/en-us/library/gg399001.aspx) it talks about using lsrp.domain.com for the RP cert subject name, and its only explaination for that URL is "Address Book Service, distribution group expansion and Lync IP Device publishing rules" Its not very about use of it or how it ties into lync beyond that. Is this URL really needed? I know that we don't use it in our deployment since we're using a SAN Cert with 10 entries on it and we seem to be doing just fine. If we where to break up the Cert and use one for the Edge Server and one for the RP, would you recomend using the external web services URL for our Lync Deplyoment or like microsoft recommends, the "lsrp.domain.com" address?

    • jeffschertz says:

      Yuri, funny you bring this up :) I actually pointed this out to the documentation team recently and they are working on removing that extra FQDN from the guidance in TechNet. It doesn't map to anything and shouldn't be there, so you can safely ignore it.

      • Rick Kingslan says:

        It's fixed…. My fault – missed it on the scrubs. Thanks for bringing it up.

        Rick – Lync Server Technical Writing Team

  6. Trevor says:

    You mention that a reverse proxy is technically optional and external clients can still connect without access to web services, but my understanding was that clients need to access web services during the login process to obtain client certificates, so unless the external client already has a valid client certificate, it won't be able to authenticate if it can't access web services. Is that true?

    I'm not planning on deploying Lync without a reverse proxy–I'm just curious. :)

    • jeffschertz says:

      Certificate-based authentication in Lync (TLS-DSK) is not a requirement, unless the topology has been configured to not allow NTLM (or Kerberos) which could cause other problems. So if a client is signing in for the first time on a device externally and does not have connectivity to the web services then it will still sign-in successfully using NTLM and then just fail to create a TLS-DSK client certificate. The the next time the client signs-in if the web services are available (e.g. it is on the internal network or on VPN) then it will perform the request again and be able to request and download a client certificate.

  7. Jerry says:

    Jeff, I’m reading so many mixed reviews that now I’m completely and utterly confused. If you can shed any light on this I will forever be in-debt. I’m trying to figure out the Front-end / Edge Cert requirements for a rather unique deployment.

    • jeffschertz says:

      In your scenario (because you plan to use Manual Configuration) then all you need on the Edge server external certificate is sip.domain1.com and webconf.domain1.com. All clients regardless of their SIP domain will connect to the same Access Edge FQDN, you don't even need SRV records for this.

  8. Jerry says:

    Thank you very much for your kind reply, not sure what happened to the body of my post hopefully you received it all, sorry for the length, I've been going a bit nuts but I think you just made my life a lot easier. So when on boarding a new SIP domain, we can:

    1. Completely disregard internal DNS entries as all are external
    2. Disregard SIP entries in Internal Certificates on FE
    3. Generate the External Certificate as previously discussed SN=access.lync.wehostyou.com SAN access.lync.wehostyou.com SAN=webconf.lync.wehostyou.com
    4. Then each time we want to on board a new SIP domain, simply add it to the topology and publish the topology (Where is this done the front-ends of do I need to do this on the Edge Pool when onboarding SIPS for external connectivity?)
    5. No DNS entries required for tenant, onboarded SIP domains domain1.com domain2.com domain3.com can simply connect using access.lync.wehostyou.com

    That's all? :)

  9. Tony says:

    I've found something that isn't covered here (otherwise great article, thanks). If an Edge Server Pool is configured, it appears that Lync clients and Lync Phones attempt to communicate to that pool first when making a phone call. Can you please attempt to answer why this happens?

    Even to internal phones on the same subnet. When doing a port mirror/network trace, it looks like it's checking bandwidth rules and limits, but we don't have Call Admission Control or any bandwidth rules configured.

    • jeffschertz says:

      Tony, internal clients will connect to an Edge server for all calls regardless of whether polices are enabled or if the media is able to travel peer-to-peer. This is normal behavior. For example Early Media operation in the client will attempt to connect to EVERY candidate the remote host passes, so you'll see connections go out to multiple hosts but only the first (and later, best) media candidate will used for the duration of the call.

  10. Caleb says:

    Jeff,
    This article is so helpful, thanks for posting it. I do have one question though, these two points below seem a little contradictory:

    "Although not typically recommended it is possible to use the same external certificate for both the external Edge server interface and the Reverse Proxy server interface. This is often done for the purposes of saving money, especially when some third party CAs will require SAN certificates to be purchased in ‘tiers’ where a choice of 1, 5, 10, or more SAN entries will be provided instead of applying an extra cost to each individual SAN entry. In this case it’s best to use use the Access Edge FQDN as the Common Name and then concatenate the list of all SAN entries from both server roles.

    As previously explained the Mobility Autodiscover FQDN (e.g. lyncdiscover.mslync.net) does not go on any Edge certificate, it should be added to the Reverse Proxy certificate. "

    If it is cheaper for us to purchase one SAN cert with all the entries in it, is it going to be a problem on the Edge server if it includes the Mobility AutoDiscover FQDN as a SAN entry?

    • jeffschertz says:

      The guidance is related to which server the FQDN applies to. But if you want to use a single cert for both servers then simply place ALL names in the same certificate and install it on both servers. Additional names do not pose any problems as they will just not be referred to by any client requests for the 'other' server roles.

  11. DvSMD says:

    Excellent post! I have a question, I'll start to config the reverse proxy.
    In the initial config in the FE, I have External Web Service FQND lync.domain.com (with public ip e.g. 147.16.16.53), In the pool edge (external settings) i have one FQDN & IP meet.domain.com. (with public ip e.g. 147.16.16.52). Saddly i can't get more publics ip's.
    My question is, which of this 2 ip need to be pointed to the RP and when i use the outlook to generate a Online Meeting this put a url https://meet.domain.com/user/ZBHTDF8N. The RP translate this request into https://lync.domain.com/user/ZBHTDF8N ???

    I appreciate the help kind regards.

  12. Jeff C says:

    I noticed the Edge server now allows the Certificate CN to be different than the assigned Access Role FQDN, in RTM services would not start. In a DR scenario, where you needed to restore PIC, the registered FQDN would need to be the CN from my experience. So I have dtarted applying this as the CN in the DR Edge certificate and ignore the warning. This allows for the DNS IP to be changed, I know the PIC caching would still take days, but in a long term outage, it would still be restored. Any thoughts or knowledge on this?__Thanks,_JeffCSP

  13. ChrisW says:

    "Always use two network interfaces on two separate subnets. The external interface should include the default gateway and the internal interface should not. Persistent static routes should be defined on the Edge server to address connectivity to internal subnets."

    With an EDGE server when a call is placed between an external lync client and an internal lync client, would you expect all internal traffic to use the internal interface of the EDGE server server and all external traffic to use the external interface of the EDGE server?

    In my case I see SIP traffic from the EDGE internal interface but the RTP traffic uses the external interface of the EDGE server to connect to the internal lync client. I just got lucky or unlucky that my firewall routed the traffic to the internal lync client.

    What application on the EDGE server sends the RTP traffic, because the application seems to choose to use the external interface to send RTP traffic even though the persistent route in the EDGE server says use the internal interface?

    • jeffschertz says:

      check out my newer article on STUN versus TURN to understand why this is happening. For TURN (Edge server media relay) traffic the internal Lync client will also send media to the internal Edge interface (over 3468 or 443) and any external clients will always send media to the external Edge interface. But as STUN is preferred over TURN if the internal Lync client is able to reach the external Edge IP address using it's own default route (hairpinning) then the client may be able to select this route during an internal<>internal client media session in the event that direct IP connectivity between the two clients is blocked.

  14. John says:

    In my experience, msturnping failed until I added the individual Edge server fqdn to the SAN of the internal Edge certificate. It would not accept the Edge pool fqdn. I know it is just a test tool, but it drove me nuts until I figured this out!

    • jeffschertz says:

      Interesting; I would assume that is a bug in the unsupported resource kit tool as (1) the documentation clearly states the internal Edge certificate requirements for pools and (2) I've seen and Edge pool that was incorrectly configured and there were a host of connectivity problems. Once the certificate was replaced with a standard SSL cert with only the Edge Pool FQDN as the CN the issues were resolved.

  15. Darwin Jebha says:

    Nice, thanks Jeff

  16. Fredrik says:

    Hi guys,
    If looking at the setup for the Lync 2013 Front End server, one should specify the Web Services URL (External Base URL): is that webconf.mslync.net in the example above?

    And if having contoso.local for internal DNS and contoso.com for external DNS, internal users must have a way of looking up meet.contoso.com and dialin.contoso.com as well? they should not have to send the request out to DMZ and back in again right? what about the webconf url?

    • jeffschertz says:

      The Simple URLs will always use your external names space, not the internal namespace. So although the internal web services URL would be in contoso.local the SimpleURLs would be in the contoso.com namespace. For example the internal meet.contoso.com record would point to the internal web services FQDN or IP directly on the Front End or Director server (depending on if you are using A or CNAME records) while the external meet.contoso.com record would point to the external reverse proxy FQDN or IP.

  17. Radin says:

    Hi Jeff…

    I did this parts :

    1.Create Edge Pool (machine 1)

    2.Publish Topology (machine 1)

    3.Export-CSConfiguration –FileName C:\Lync2010.zip (machine 1)

    4.After that

    In the another machine (machine2) I Installed Local Configuration Store with saved file above

    5.Install Lync Server Components on machine 2

    Unfortunately when I run Lync server 2010 deployment on machine 2 under step 3

    Request, Install, or Assign Certificate , Run button isn’t active (disable).

    Could you help me?

    Thanks.

    Radin Soufi

  18. Radin says:

    Hi Jeff…

    I have installed Lyncserver2010 on machine 2 and I have DC on machine 1 , I want to install edge server for external user. hence I installed edge server on machine 3 (this machine not member of DC). I followed this instructions :

    1.On machine 2 I created edge pool by topology builder,after that I pblish it and export zip file then copy zip file to machine 3 (C:\)

    2.I installed Local Configuration Store by zip file is copied and installed Lync Server Components.

    3.I requested Certificate by https://machine1/CertSrv and intsalled it in to machine 3

    4. After all of these,when I wnated in machine 3 ran development wizard and Request, Install, or Assign Certificate, unfortinately Button Run is disavled. :-(

    could you help me?

    Thanks in advanced.

  19. Denis Hanse says:

    Great Post, thanks a lot for this nice resume,

    We have 2 sites (1 for Europe, 1 for Brasil) and a global static route to our videoconference MCU for sip domain "video.domain.com". video.conseur.org is defined as a trusted application pool in the European site.
    There is a FE pool and an edge in every sites.
    Registrar of every VCs is local (bra-vc : bra-registrar) and SIp of every VCs is VCx@domain.com (just like every users)
    If a VC in Brasil with bra-fe registrar call xxx@video.domain.com, it goes via the edge in Brasil (even if the route is global).
    If a VC in Brasil (registrar bra-fe) call a VC in Europe (registrar europe-fe) it also go via the Edge server.

    So I'm wondering if it's normal that internal traffic between sites goes via Edge servers or do I made something wrong ?

    Thanks a lot for your reply

    Denis

  20. Andrew says:

    Which hostnames are "reserved" and which could be set as you like:
    access, sip, webconf, av, lyncdiscover, lsrp, rp, dialin, meet …
    I guess sip and lyncdiscover only (you are mixing sip and access in your guides)
    And of course all "_" SRV records.

    • jeffschertz says:

      Andrew, technically none of the Host record names used in Lync are 'reserved' (with the exception of Lyncdiscover/Lyncdiscoverinternal) as you can use any name you like. In the event that SRV records are not available in the public DNS zone then you must use either 'sip' or 'sipexternal' as the Access Edge name if you want legacy (pre-2013) client Automatic Discovery to work. The suggested sip, webconf, av names are commonly used and best practice, but are not hard-coded. Also the dialin, meet, and admin names are also common recommendations but not required. Only the autodiscover FQDNs of Lyncdiscover and Lyncdiscoverinternal must be used verbatim as the clients are hard-coded to look for those hostnames. The SRV records are not covered in this article as they are not defined in the topology, nor in any certificates; they are simply created by an administrator as per the TechNet guidance. Lastly I'm not sure what you mean by mixing up 'sip' and 'access'; some guides use the example of access.sipdomain.com versus sip.sipdomain.com but I've never used that as the 'sip' hostname can be used with A record fall-back while the 'access' name is no different then selecting anything else you like (e.g. 'foo.sipdomain.com').

  21. Radin says:

    I have some problem with Edge Server Installation :

    when I was installing edge sever , I got this error :

    MSI result: 1603 12/30/2012 10:53:50 PM

    └ Error: Error returned while installing OcsCore.msi(Feature_LocalMgmtStore), code 1603. Please consult log at C:\Users\Administrator\AppData\Local\Temp\2\Add-OcsCore.msi-Feature_LocalMgmtStore-[2012_12_30][22_53_03].log

    ▼ Details

    └ Type: MsiErrorCodeReturnedException

    └ ▼ Stack Trace

    └ at Microsoft.Rtc.Internal.Tools.Bootstrapper.BootstrapperTask.AddFeatures(String baseDir, String msiName, String[] msiFeatures, String msiParams)

    at Microsoft.Rtc.Management.Internal.Utilities.LogWriter.InvokeAndLog[T1,T2,T3,T4](Action`4 action, T1 arg1, T2 arg2, T3 arg3, T4 arg4)

    —————————————————————————-

    After one week I understood all of my problem was on SQL Server Connection to Lync server. (I have 3 machine : LyncDC,LyncFE,LyncEdge)

    I think my error is for Certificate. hence I created 2 SAN entry in my Front End Machine and my Edge Server :

    In Edge Server Machine :

    Subject=Lyncedge.lyncguy.local

    Subject Alternative Name=

    san:dns=sip.lyncguy.com&dns=lyncFE.Local.&dns=dialin.lyncguy.com&dns=meet.lyncguy.com&dns=lyncedge.lyncguy.local

    In Front End machine :

    Subject=lyncFE.lyncguy.local

    Subject Alternative Name=

    san:dns=sip.lyncguy.local&dns=lyncFE.lyncguy.local.&dns=dialin.lyncguy.local&dns=meet.lyncguy.local&dns=admin.lyncguy.local

    After that,I installed 2 cicatrices created by http://LyncDC.lyncguy.local/certsrv on both of machines.(in personal store)

    I am quite puzzled.

    Any help will be much appreciated.

    Thanks in advanced.

  22. Adam says:

    hi,
    This is confusing, MOC says that you can configure External edge pool to use Hardware load balancing and internal use DNS load balancing. But technet says otherwise. It says if you use hardware load balancing in the external side, you have to use hardware load balancing on the internal.

    • jeffschertz says:

      I'm not sure what you mean by 'MOC says' best it is best practice to use the same form of load balancing on both sides of the Edge servers. You can use different solutions between Edge pool and Front End pools, but the Edge internal and Edge external solutions should be the same (either DNS LB or HLB).

  23. jeffschertz says:

    The media path is not dependent on any of the topology configuration. The RMX will negotiate media as an ICE client in the same manner that a Lync client does, so if you media is traversing an Edge server then something in the network configuration would appear to be preventing peer-to-peer media between the RMX and Lync client internally (firewalls and/or NAT).

  24. Jirawat Rattanamet says:

    Thank you very much for such a valuable article.

  25. Mohamed Abd Elhamid says:

    thanks
    if I haven't edge server I can't make voice call?
    I give the lync server itself public ip after that I can register and login and make im chat but voice call failed all time
    what can I do to solve this problem ???

    • jeffschertz says:

      The Edge Server is required to facilitate media over the Internet and even on private networks through firewalls. You can't simply just publish the IP address of a Front End server.

  26. Stephan says:

    Hi Jeff,

    I reviewing a site where there are some call quality issues for external users. This is a simple deployment, and the edge server does have 2 NICs. Both nics are on the same subnet though, and both NICs has the default gateway set to the TMG server. Everything is working as expected, except for some call quality issues. Could you comment if this "unsupported" config could be the cause, and why it is important for the edge to have the 2 seperate subnets?

    Thank you

    • jeffschertz says:

      It is unsupported but I've seen that work in the past. The reality is that for ICE/STUN/TURN to work as designed you really can't get away with cutting any corners and expect full functionality in all possible scenarios.

  27. Muziitha says:

    hi Jeff, i have a multi sip domain infraestructure with 1 FE, 1 Edge….
    the sip domains are: e-arca.com.mx , arcacontal.com , bokados.com , e-arca.com.ar, e-arca.com.ec, but the federation only works properly with de sip domain e-arca.com.mx

    The rest of the sip domains can not see presence, except arcacontal.com wich can federate with im.migesa.com.mx.

    Lets say that the external Certificate has as Common Name: lcs.e-arca.com.mx…according to the recomendations my external certificate should have For the Edge Server the 'sip' FQDN for every domain to the SAN field. IT ONLY HAVE SIP.E-ARCA.COM.MX…Could it be the reason why i can not see presence with the rest of the domains? but if so, why arcacontal.com can federate with migesa.com.mx?

    • jeffschertz says:

      Adding additional 'sip.<sipdomain> entries in the Access Edge certificate is meant for supporting automatic discovery, but for manually configuring federation you can have all of your secondary SIP domains use the same primary Access Edge FQDN.

  28. Miles says:

    Hi Jeff, I know this post (which is GREAT by the way) is only regarding Edge servers, but I was wondering if a sip.domain.com subject was needed on the front-end servers.

    Thanks!

    • jeffschertz says:

      Only if you are not using SRV records for Automatic Client sign-in, as an internal client will use sip.<sipdomain> as one of the Host records to locate the Lync Front End server. If you have an SRV record pointing to something like lyncpool.domain.com then there is no need to add the additional sip.domain.com record.

  29. Isiah H says:

    Jeff,

    If I makereceive a WiFi call on a Lync mobile device does the media traverse the edge server? You stated that Lync mobile devices only interact with the FE via web services. Is this true even for media from mobile devices as well?

    • jeffschertz says:

      The mobile clients register through the web service, the Edge server must still be available to handle media traversal for all Lync clients.

  30. eMan says:

    I have two Lync 2013 sites that use only one sip domain. We are doing HA with paired pools. We have an edge pool in site A and and Edge pool in site B. We are using DNS load balancing. Can all four external edge servers (2 in each site) use the same external edge names (Sip,access,webconf,av) and use a single Cert spread across. Will this work and will it maintain HA? Users will be hosted on both sites.

    • jeffschertz says:

      No, each pool will need a unique FQDN for each service, you can't use the same service FQDN across different pools. You'll see this in the topology when you go to create the separate pools.

  31. lync101 says:

    Hello Jeff- very awesome post! I have 2 strange issues with our Edge Server which may be related and I hope you can help. I have a setup similiar to the Simple Topology using Lync 2013 on premises (AD and Private Domain up and running). We also have Office 365 up and running with Exchange, Lync, and Sharepoint- we plan to use the UM/Exchange function with the on-prem Lync server for voicemail. 1st issue: the Edge external certificate, which was loaded using the wizard, but not requested directly via the wizard, is not recognized (tested with https://www.digicert.com/help) unless I install and bind it in IIS to TCP port 443. When I do this, the cert is recognized but AV Audio services do no start on the Edge server. I tried changing the AV TCP port to 445 with Top Builder, export and loading to the edge server, same issue.

    • jeffschertz says:

      Normally IIS not installed on the Edge Server as it's not used, so I'm not sure what your server configuration is. Hopefully you aren't trying to use the same host as both the Edge Server and Reverse Proxy, which is unsupported and not recommended at all.

  32. lync101 says:

    2nd: on-site in and out calls (using a voip gateway) work. We completed the Office 365/on prem Lync integration steps and calls roll to O365 after 4 or 5 rings- verified with snooper. however, we get no audio and calls disconnect after a few seconds. We have tried different scenarioson O365 (ext number, etc) but no luck- same issue. I did notice that an on premise Lync user can connect from an external Internet connection and make a call but there is not audio to and from the caller. Federation is working but calls have no audio. I think the issues may be related, possibly due to the cert but I am not sure. From your experience, could this be due to a faulty cert setup?

  33. Abdul says:

    Question could someone touch on a Single NIC Edge server is this possible. I have an environment with a single subnet then a firewall which seats between the network and the Open Internet. How does one configure Edge Server is that even possible or do I have to create a DMZ

    Regards

    • jeffschertz says:

      The Edge Server must contain two separate network interfaces; this is not optional. You can connect them both to the same network but it's completely unsupported and a major headache to get working at best. I'd never recommend deviating from the Edge Server requirements as documented by Microsoft. Unless you like troubleshooting problems and making your life generally unpleasant, then go for it :)

  34. Shawn says:

    This may sound like a basic question, but when defining an Edge Pool and creating the FQDN, do I create an A record in Internal DNS or external DNS? i.e. edgepool.mydomain.com

    • jeffschertz says:

      Shawn, you need to create the internal FQDN as a DNS record in only your internal DNS zone. Because the Edge server is not domain-joined then it will not create a Dynamic DNS record in the server. You never put this FQDN in the external DNS zone as only externally facing FQDNs (e.g. sip.mydomain.com) are placed on public DNS zones.

      • Shawn says:

        Thanks for the reply, appreciate it. One follow up question, do you have any articles or documentation on why the Edge servers need the internal and external nics to be on different subnets? I know TechNet says this is required but my firewall guys are asking why? Thanks.

        • jeffschertz says:

          The Microsoft documentation covers this and there are countless other articles out there on the same topic. The only real answer you need is that "Microsoft designed the product that way" and if you want it to work in a supported topology then that is a requirement.

  35. Mitul says:

    Jeff,

    we have exchange 2013 standard and Lync 2013 standard deployment. currently we are using *.xyz wild card certificate for exchange and Lync. Now we would like to procure UC SAN certificate. Please help me to understand :

    1) Is it require to have 2 different certificate for exchange & Lync or Single with multiple SAN will work?

    2) what SAN and CN entry require for Exchange in single certificate(single certificate for Lync & Exchage)?

    3) what SAN and CN entry require for Lync in single certificate (single certificate for Lync & Exchage) ?

    4) what kind of SAN and CN entry in exchange and LYNC in separate certificate.?

    • jeffschertz says:

      You should be suing different certificates between Exchange and Lync servers. It's not clear to me if you are asking about the actual server certificates for each (which are documented ad nauseum) or if tou are asking about external certificates (Edge, Reverse Proxy). In either case it is recommended to keep them separate.

  36. GuidofromVenlo says:

    Hi Jeff,

    Very good article! I have implemented a edge server accordingly.
    I've implemented a lync-edge server like the "simple topology" with internal certificate form a internal CA ( which is trusted by the edge server) and a external certificate with cn sip.ipabo.nl and alt.subj sip.ipabo.nl and webconf.ipabo.nl. from Globalsign. Services have their own ip adresses and are natted by a router. Ive tested that all ports can be reached from the internet. But still no connection possible from external clients. The ms. connectivity analyser says: "The The certificate couldn't be validated because SSL negotiation wasn't successful". Connections from mobile clients through reverse proxy are no problem also internal clients have no issue. So i assume there's someting wrong with the certificate implementation on the Edge server, however ive tested it with the RUCT from Curtis Johnstone, and the certificate seems to be OK. Also in the Lync Server Deployment Wizard the certificates seem to be OK. In the computers personal certificate store the are only the two necessary certificates ( internal and external) also intermediate certificates are installed. Routing ( default gateway on external interface ) is working fine. So I think I'm out of options, any ideas?
    Tnx,
    Guido

    • jeffschertz says:

      Using an internal certificate on an Edge Server is more complicated than it was in the past. You may be running into an issue with the inability to access the Certificate Revocation List (CRL) hosted on the internal CA from the external clients. Many of the newer Lync clients will not connect if they cannot validate that the certificate issued to the Edge Server has not been revoked. See this article for more details: http://imaucblog.com/archive/2012/06/17/lync-onli

      • GuidofromVenlo says:

        Thanks for the reply!
        Is this also applicable when the "internal" certificate issued by the internal Ca is used only between the edge server and the frontend server?
        On the external side of the Edge I've only used the certificate(s) from a publicly trusted CA, I assumed a external client has no business with the certificates used on internal IP of the Edge server.

    • GuidofromVenlo says:

      Ok I found It:

      It was a simple setting in the Control panel, or in the management shell:
      In Set-Accessedgeconfiguration
      AllowOutsideUsers was set to False. this should be true.
      I found it by Using OCSlogging on the Edgeserver, looking at SIP.

      So I don't understand how all the certificate and server unavailable warnings make any sense.

      The next issue will be exchange integration :)

      Thanks for your help!

  37. Pravin says:

    Hi Jeff,

    If all the users are using Lync 2013 with Domain joined machine externaly and all the machine has internal root certificate on trusted root certificate authority. so for external user access does it still require Public certificate or it will work with internal enterprise certificate authority.

    Regards,

    Pravin

    • jeffschertz says:

      It should, but like I said you may need to publish (via a reverse proxy) access to the internal CRL web service if some of your clients still refuse to sign in externally with a private certificate on the external Edge services.

  38. weymansb says:

    Hi Jeff,
    "Web Conferencing FQDN (e.g. webconf.mslync.net) are required on the external Edge Certificate" .
    Is this also the case in LYNC 2013 if you select to share at single fqdn for access edge, web conferencing edge and a/v edge services?

    Thanks in advance.

    Benny

    • jeffschertz says:

      If you deploy a single IP Edge Server than there is only one FQDN defined in the Topology, so there would only be one FQDN required on the certificate. There would be not separate Web Conferencing or A/V FQDNs, the same FQDN is used for connections to all external Edge services.

Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!