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.
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.
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.
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 features 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.
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.
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.
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.
- 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.
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.
- 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.
- 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.
- 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.
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.
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).
- 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.)
127 thoughts on “Lync Edge Server Best Practices”
Great! Many people think in Reverse Proxy as member of Edge Servers Role
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
Once again great work by Jeff.
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)
I just have a query for the Lync edge – Currently for our lync we have different internet lines running .
We have planned to change it to different internet connection.
What changes need to be done in internal and External DNS, please could you advise on this greatly appreciate on this.
Issue 2 : we are unable to log in to SFB app in mobile – either with internal wifi or with 4g error occurs “ cannot connect to the network” .
How to check if there is an issue with reverse proxy. ? Please let me know.
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?
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.
It's fixed…. My fault – missed it on the scrubs. Thanks for bringing it up.
Rick – Lync Server Technical Writing Team
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. 🙂
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.
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.
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.
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? 🙂
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.
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.
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?
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.
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. 184.108.40.206), In the pool edge (external settings) i have one FQDN & IP meet.domain.com. (with public ip e.g. 220.127.116.11). 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.
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
"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?
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.
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!
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.
Nice, thanks Jeff
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?
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.
I did this parts :
1.Create Edge Pool (machine 1)
2.Publish Topology (machine 1)
3.Export-CSConfiguration –FileName C:\Lync2010.zip (machine 1)
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?
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.
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 firstname.lastname@example.org, 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
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.
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').
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
└ 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 Alternative Name=
In Front End machine :
Subject Alternative Name=
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.
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.
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).
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).
Thank you very much for such a valuable article.
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 ???
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.
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?
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.
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?
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.
OCS\Lync deployment for PS…
1. PS Admin guide. See attach : “155913.pdf” 2. h…
OCS\Lync deployment for PS…
1. PS Admin guide. See attach : 155913.pdf 2. htt…
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.
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.
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?
The mobile clients register through the web service, the Edge server must still be available to handle media traversal for all Lync clients.
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.
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.
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.
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.
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?
[…] для понимания этой мути, мне куда полезнее оказалась статья Jeff Schertz, чем официальный учебник по […]
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
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 🙂
I understand the Edge server must have an internal and an external interface. Does this also apply to the reverse proxy?
We already have a Web Application Proxy installation which is being used for ADFS. However, it only has a single network interface. We are considering using it as a reverse proxy for Lync as well, but want to confirm if Lync reverse proxy is supported with only one interface.
That depends on the software or appliance you are using for the reverse proxy, as this is a security issue not anything related to specific functionality.
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
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.
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.
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.
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.?
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.
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?
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…
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.
The internal Edge certificate only needs to be trusted by the internal servers, not external clients. I always use a private certificate from a Windows CA on the Edge internal.
Ok, so the current implementation of certificates as internal/external/trust/Crl concerns seems correct as described in my first post.
I'm looking at client logfiles now, trying to figure out what's going on…
I don't expect you have any time for this but anyway :).
Ok I found It:
It was a simple setting in the Control panel, or in the management shell:
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!
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.
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.
"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.
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.
Thank you for this blog, a Lync reference.
You mention issues when you refer a pair SRV & A records which are not in the same domain. Do you have retested or viewed that is not supported on lasts link mobile versions?
You talk about "client automatic sign-in". Do you include "automatic configuration"? Here there are my test results with autoconfiguration:
You are member of the "domain.PRIV".
– If you enter login@domain.PRIV, i can't work,
– If you enter email@example.com (public domain), it does not work because your upn is login@domain.PRIV. You must enter your real login,
– If you create UPN suffix domain.com, and firstname.lastname@example.org, it works.
I don't have seen this alternative on MS documentations… but I find it very usefull.
What do you think about it?
The requirement that SRV/A record pairs are in the same domain namespace is only enforced on Lync Phone Edition and older Office Communicator clients. Lync 2010/2013 Windows desktop clients will allow mismatched records, but usually will prompt the user for guidance when this security issue is seen . Also keep in mind that Lyncdiscover and Lyncdiscoverinternal records are used first in Lync 2013 Windows clients and are the only method supported by Lync 2010/2013 mobile clients and Lync 2013 Window Modern clients, so the SRV/A record configuration is moot for those clients.
Great write-up !!!
I am stuck in a deployment
1. Have a sip domain – sip.logix.com
2. Have two FE pools and two Edge pools
3. Got two public ip's – one for each edge pool
4. Two regions south and north
5. Requirement is that both edge should be active – active and users for south should login to south FE via south edge pool and north login to north FE via north edge pool
6. we don't have GTM
Can you please suggest how can we achieve this.
That cannot be done without different DNS servers for each region with unique zone records. All clients in the same SIP domain will register to the same Edge. Media will flow through their local Edge pool.
[…] Lync Edge Server Best Practices: […]
How would I be able to setup federation across a shared MPLS network? All I want is to be federated for IM/Presence with a partner over the same MPLS. No A/V or web services needed.
Hi, i have successfully configured lync with edge but when i m going to sign in from externally i m getting error , can’t sign into lync we’re having trouble connecting to the server, any suggestion,
Thank you so much for your great posts!
I have a doubt. I you just want to enable Federation (no external users, remote users or mobility), do you need a Reverse Proxy?
As they say in TechNet and you are stating:
“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 features listed on this page will not be available to external clients, which although are important in a fully functional deployment they are not critical.”
“Enabling external users to download meeting content for your meetings”
It’s said “to download meeting content” not to join meetings or conferences. I think that, without RP, a federated user cannot join an Outlook scheduled meeting as it should have to connect to a Meet Simple URL and there is not RP. But, if that federated user is invited to a peer to peer IM or A/V conversation, does it need a RP to connect or all the connections are made between Edges?
I don’t know if I’m explaining well which my doubt is.
In addition, regarding the Lync 2013 Workloads poster, Federation doesn’t have any flux connecting to RP, so I doubt if a federated user need a RP to connect to an invitation to join a conversation/conference (more than two people) or he doesn’t. He won’t be able to download content but, will he be able to connect?
Thank you in advance.
P.S.: I haven’t found information about just Federation and nothing else.
I mean, not only peer to peer. If there is an existing peer to peer conversation/call and you invite another federated user, becoming a conference… does the federated user need to connect through RP somehow? Or is the whole connection through Edges servers, not needing a RP? (but for downloading content and those other features).
It doesn’t matter if the Lync client is external or federated the reverse proxy provides access to the same components. In reality the Reverse Proxy is not optional as you’ll have an incomplete deployment with broken Lync features. As more features are added to the web services components of the Lync Front End servers this places even more importance on the RP for any external usage.
Thank you for your reply, Jeff.
You’re right it would be an incomplete deployment with broken Lync features, But, assuming there would be some features unusablewithout Reverse Proxy, would it be possible to create an audio/video conference for three or more people (not using Outlook Meeting, of course, just by inviting them)? And sharing?
Yes, the Edge Server can provide the needed A/V connectivity.
Thank you for your help, Jeff.
I have done video calls in a federated scenario without a reverse proxy. It works.
BUT, we are putting a reverse proxy in now.
All media payloads are handled entirely by the Edge Server (audio, video, content sharing).
I need your help i have front end server and edge server al ready configured internally every thing it’s OK but when connect from external i have trouble problems cause i don’t have SRV records becouse my DNS hoasting does not support SRV record .i need to know what should I do about internal server (FQDN) and external server (FQDN)
in manual configuration (internal ——->point to front end and external ——>point to access edge ??? is it right
Just define you external Edge FQDN as sip.domain.com and you don’t need SRV records as all the Lync clients are configured to look for sip.
records after the SRV look fails.
The technet reference architecture for Lync 2013 consolidated edge with load balancer (http://technet.microsoft.com/en-us/library/gg398478.aspx), appears to indicate that even when using an load balancer with snat on the external edge, that a public IP address is still required for the access edge external interface.
The rationale for this does not make sense to me. If the VIP on the load balancer is public, and it is performing all of the source and destination IP translation between the external client and Lync access edge external interface, why is the public IP still required on the access edge interface?
The nature of what the HLB does obfuscates the access edge IP anyway from the external client, so if the access edge is not being accessed directly by the external client (i.e. bypassing the HLB), why is the public IP required.
Curious if you have any insight or experiences for why this is the Microsoft recommendation and if it is truly required?
Jerry, unfortunately the TechNet documentation is not 100% accurate in that section. The VIP does NOT handle all communications, especially media from external clients. The external clients are passed the public IP of a single Edge server after the initial connection to external VIP to send their media to for a given call. Honestly, it is best practice to no longer use HLBs on your Edge Pools and just utilize DNS LB on both sides, which simplifies the deployment greatly.
I am having a situation where there is a Lync 2010 environment and Lync 2013 Standard is implemented. I have a new 2013 Edge server in which I would like to use for the Lync 2013 users even though I have a shared simple URL. Is this possible?
The Simple URL has no impact on the Edge Server, that points to your reverse proxy. Just follow the migration documentation in TechNet which covers moving from 2010 to 2013.
[…] Or better yet, from here: http://blog.schertz.name/2012/07/lync-edge-server-best-practices/ […]
I have an odd problem where our cert expired for external edge access and upon being replaced our mobility is broken. It is very strange actually… the cert is updated in the Lync deployment wizard, desktop clients connect without a problem now but mobile clients are unable to connect. I ran the connectivity test from Microsoft and it looks like the server is trying to hand out the old expired cert to mobile clients instead of the new one in spite of the certificate having been recreated and executed in the deployment wizard. Any thoughts on this?? I am at a loss.
So I have since realized that when we deployed Lync 3 years ago, we used IIS as the reverse proxy server and that is what seems to be handing out the bogus cert to mobile clients… I realized this because of one of your articles outlining edge cert requirements. We actually had Dell set this up, and they are no longer providing us with support so I am in a jam now because I don’t know what they did and where to reassign the cert being used by the reverse proxy in IIS. Can you clarify this part of the process please?
Always perform a server reboot after changing any certificates in Lync/SfB. I’ve seen the old cert handed out in various scenarios if the server has not be rebooted.
We’re having an issue with external clients signing in. Currently, our external DNS records for autodiscover, meet, and dialin all point to the External Web Services FQDN (we do not have a reverse proxy) configured on the front-end server. However, one of my colleagues put an entry in his host file pointing lyncdiscover to the external IP address of our Edge Server. So, my question is, if we do not have a reverse proxy, what should we be pointing our external DNS records to, specifically for autodiscover?
That will not work as the Edge Server cannot handle requests directed towards the lyncdiscover web service. A reverse proxy of some fashion must be used.
can i transfer my FXO gatewau trafic to Edge server??
I Know we can set in as a pstngateway on mediation server but i in my environment i want to know that is it possible or not
No, the Mediation server must talk to any media gateways directly.
This website became a staple while we were deploying Lync 2010 to our environment. Now I come back with a problem with the Edge server.
We have multiple sites, but the same SIP domain. Site 1 has a Enterprise Ed server and a director, site 2 has just the Enterprise Ed server and site 3 has a Standard Ed server, and each has SimpleURLs set to allow for their own conference rooms. They all support the same SIP domains, mostly for IM&P with some desktop/application sharing only. Now they want to put a single Edge server out to allow for anonymous access to meetings (desktop sharing). In looking at the current config, I see only 1 “external setting” on the Edge server for the incoming A/V, WebConf and Access. Is it possible to support our current internal configuration with this Edge server?
Thank you for your time and for all the great articles you have written on this subject. It has helped us a lot!
Mike, a single Edge server can support multiple pools like you have in your topology. You’ll first need to deploy at least one Reverse Proxy solution to actually allow external anonymous meeting participants to even join, but the Edge Server is also needed to support desktop sharing (the A/V Edge role handles that).
Jeff – In the Lync Topology builder for the edge server, it always appears to want to put the edge, web, and a/v ip addresses through a NAT. If I provide three publically available IP addresses for those services, do I have to put them through a NAT? I’m not doing any load balancing or HA, just a rather simple configuration.
NAT is not a requirement on the Edge server for the external IPs, you can put the true public IPs right on the server and in the Topology.
I have been trying to find an answer to my question but have been unsuccessful and I am hoping you can explain it to me please.
The other day our open federation broke. We could receive IMs but we could not send back to the federated company. I did an IIS reset on both of our front end servers and this resolved the issue. Why would an IISreset fix this? is Federation tied to IIS. Sorry if this is a dumb question.
Thanks in advance,
I have a lync single server with 1 edge server followed your guides (thanks btw) but for some reason no devices can connect like android and iphones both will not connect with Lync For Business app – and the microsoft connectivity analyzer is all green saying it can connect, laptops running windows can also connect external and internal – it is literally just cell phones that will not connect.Any ideas?
Donald, you must also setup a reverse proxy to support any mobile clients: http://blog.schertz.name/2013/07/understanding-lync-2013-mobility
It’s a bit late but I’m posting on this thread because I’m a bit stumped. According to this post, I can have two front end pools, one edge pool and a reverse proxy and allow mobility and external access to work no matter which pool you are homed on. At least that appears to be the case. I can’t get it to work. Each pool needs an external WEB services FQDN and they can’t be the same, so what do you put in the reverse proxy certificate and external DNS? Basically everything works in my setup as long as you are on the right pool. Microsoft documentation is worthless as usual, so maybe you have some suggestions assuming this is even possible. Many thanks in advance.
Every pool must be published via a reverse proxy, but not all services. A single pool is selected as the ‘home’ for the Simple URLs, but every pool has its own, unique external web service FQDN. When external clients connect they are given the correct external FQDN for their home pool.
Thank you Jeff!
A doubt related to Edge Internal Certificate.
I’m migrating to Skype for Business. Lync 2013 was running perfect. I have now a Lync 2013 FE (to be decomised once migration is finished) and a S4B FE. Edge is still Lync 2013. CMS has been moved to S4B FE.
When replicating, Edge is failing. After modifying a number of thing, I see that S4B FE is trying to connect to the Edge server itself (4443) instead of to the Edge Pool. The certificate was issued for the pool and Lync 2013 was working, but replication from the S4B FE, when trying to connect to the server itselft, realizes there is not a certificate for it.
What am I doing wrong? Even in this situation is it not possible to add a SAN?
I don’t know what could be causing that. All TLS requests to the internal Edge server should use the pool name, not the server name.
We are adding looking at adding a new SIP sub domain, does the information you provided still apply are you were referring to a completely different domain?
Primary SIP Domain: test.com
Secondary SIP Domain: subdomain.test.com
Yes, although there can be some special considerations when dealing with child domains related to split-domain configurations. Otherwise it’s the same guidance though.
When trying to request a new CRS for my edge external certificate, I get a subject name of sip.domaim.com when I believe it should be the FQDN of my edge server ie WEB-LYNC-EDGE-1.
I am current getting many TLS errors and the Outlook UM is not working for mailbox users
Any Advice from the master would be helpful
The internal Edge certificate uses the server FQDN or pool FQDN in Edge Pools. The external certificate should never include the server or pool FQDN. It only includes the Public Access Edge and Web Conferencing Edge FQDNs (e.g. sip.domain.com).
Just curios about the edge internal certificates. What sort of negative things have you seen if you include a SAN in the certificate besides just having the edge pool name?
Other than being unsupported, here’s one example: http://blog.schertz.name/2014/10/msturnping-bug/
Please share your thoughts on the below :
I have now made the configuration within the reverse proxy for the below urls to point to the reverse proxy Public IP
• webext.domain.com (A record)
• dialin.domain.com (A record)
• meet.domain.com (A record)
• lyncdiscover.domain.com (A record)
• officewebapps.domain.com (A record)
I had to also have an public CName entry for FE lync01.domain.com as meet.domain.com for the URL to work.
Now what I see is that I can browse to the https://meet.domain.com but upon downloading the plugin it redirects the page to https://lync01.domain which is the internal FE server.
You should never need to create a public DNS record for any internal FQDNs. Something is wrong with your environment configuration which is causing the incorrect name redirection (probably your reverse proxy setup).
[…] good place to continue after this would be http://blog.schertz.name/2012/07/lync-edge-server-best-practices/. It’s a very nice all-around document about Edge and Reverse proxy. Pay close attention to the […]
Have an issue whereby we have a cert name mismatch
sip.kornferry.com has a cname for sipdir.online.lync.com.
When a site that check for insecure issues scans the site, it says that there is a mismatch.
sip.kornferry.com does not match sipdir.online.lync.com.
sipdir.online.lync.com. is hosted by Microsoft and we cannot add our cert here.
What to do.
I’m not sure what the context is here but you cannot issue your own certificates using Microsoft’s own domain names. Only your own domain names would go on certificates applied to your Edge server.