When deploying a Director server or pool in Lync Server 2010 it is important to understand how this change in the internal topology will impact the externally published web services solution. Because the Director is still essentially a trimmed-down Front End server it also contains a complete set of internal and external web services. It is difficult to understand from the TechNet documentation the requirements for this scenario and as it may seem logical that the Director’s external web site might be published in place of the Front End server, but in reality it should be published in addition to it.
The clearest direction for this is stated in the Set Up Reverse Proxy Servers page of the Lync documentation:
We recommend that you configure your HTTP reverse proxy to publish all Web Services in all pools. Publishing https:// ExternalFQDN/* publishes all IIS virtual directories for a pool. You need one publishing rule for each Standard Edition server, Front End pool, or Director or Director pool in your organization.
In addition, you need to publish the simple URLs. If the organization has a Director or Director pool, proxy requests to these URLs to the external Web Services virtual directory on the Director.
But this does not explain why both the Front End and Director roles should be published externally.
- Firstly the Simple URLs (meet.contoso.com, dialin.contoso.com) can be directed to either server but when a Director is deployed then it is the recommend location to land these requests. This allows the Director to be a single-point-of-entry and then it can either respond or redirect traffic based on the specific requests.
- The Front End server still needs to be published as when an external client is authenticated via the Director it will be passed in-band the remaining Lync configuration settings, including the DG External URL and URL External From Server values. These URLs will point to the external web services FQDN of the Front End server of the pool where the Lync account is assigned. The Director’s external web services FQDN is not passed to the clients at all.
- Because the authentication is handled on the Director during an initial client sign-in the web ticket is generated on the Director. During this process the client is passed the Director’s external web services FQDN, thus without also publishing the Director’s external web site the external clients would not be able to complete the web ticket request process.
In summary, the Front End web services must be published so that external clients can access services handled directly by the Front End like distribution group expansion and address book download/query, while the Director must also be published to allow external clients to access the certificate services. And the Simple URLs can be pointed to either system but the Director is the preferred target.
The diagram below shows the traffic flow through a reverse proxy utilizing separate web listeners on dedicated IP addresses.
The first listener handles requests for the Simple URLs (meet.contoso.com, dialin.contoso.com) and the Director’s external web services FQDN (dirweb.contoso.com).
The second listener’s IP address is only resolved by the Front End’s external web services FQDN(feweb.contoso.com).
A quick look at the IIS logs on the Director will confirm this behavior.
- To identify the proper IIS log directory open Internet Information Services (IIS) Manager and select the the Lync Server External Web Site object under Sites. Select Manage Web Site > Advanced Settings…
- Under the General section note the the ID value of 34578. (On each Lync Server with web components installed the internal web site will be 34577 and the external web site is 34578.)
- Browse to the default IIS log directory at %SystemDrive%inetpublogsLogFiles and open the W3SVC34578 directory as that folder name matches the ID of the specific web site. Open the most recent log file to look for POST entries to the /WebTicket and /CertProv applications as well as GET entries for the Simple URLs.
- Then look at the IIS log on the Front End server’s External Web Site to see the requests from external clients through the reverse proxy for DL expansion, post-authentication webtickets, and Address Book file requests.
To further highlight the overall process here are both the Director and Front-End Server IIS logs for their respective external web sites during the sign-in in a Lync Client via Edge. The Director’s IP address is 10.1.1.22 and the Front End server is on 10.1.1.21. The source IP address of 172.16.5.13 recorded for all log entries is the reverse proxy TMG server . Although there are two different listeners with dedicated public IP addresses the IIS logs will only show the traffic as coming from the TMG server’s internal interface.
- The Director’s IIS log shows the external client requesting access to the /CertProv and /WebTicket applications first, based on the timestamp of the POST entries.
2011-03-25 13:18:07 10.1.1.22 POST /CertProv/CertProvisioningService.svc/mex – 4443 – 172.16.5.13 OC/4.0.7577.108+(Microsoft+Lync+2010) 200 0 0 6
2011-03-25 13:18:08 10.1.1.22 POST /WebTicket/WebTicketService.svc/mex – 4443 – 172.16.5.13 OC/4.0.7577.108+(Microsoft+Lync+2010) 200 0 0 6
2011-03-25 13:18:08 10.1.1.22 POST /WebTicket/WebTicketService.svc – 4443 – 172.16.5.13 OC/4.0.7577.108+(Microsoft+Lync+2010) 401 0 0 1
2011-03-25 13:18:08 10.1.1.22 POST /WebTicket/WebTicketService.svc – 4443 – 172.16.5.13 OC/4.0.7577.108+(Microsoft+Lync+2010) 401 1 2148074254 1
2011-03-25 13:18:08 10.1.1.22 POST /WebTicket/WebTicketService.svc – 4443 – 172.16.5.13 OC/4.0.7577.108+(Microsoft+Lync+2010) 401 1 2148074252 2
2011-03-25 13:18:15 10.1.1.22 POST /WebTicket/WebTicketService.svc – 4443 – 172.16.5.13 OC/4.0.7577.108+(Microsoft+Lync+2010) 401 0 0 1
2011-03-25 13:18:15 10.1.1.22 POST /WebTicket/WebTicketService.svc – 4443 – 172.16.5.13 OC/4.0.7577.108+(Microsoft+Lync+2010) 401 1 2148074254 1
2011-03-25 13:18:15 10.1.1.22 POST /WebTicket/WebTicketService.svc – 4443 sip:test1@mslync.net 172.16.5.13 OC/4.0.7577.108+(Microsoft+Lync+2010) 200 0 0 221
2011-03-25 13:18:15 10.1.1.22 POST /CertProv/CertProvisioningService.svc/WebTicket_Proof_SHA1 – 4443 MSLYNCtest 172.16.5.13 OC/4.0.7577.108+(Microsoft+Lync+2010) 200 0 0 521
- While immediately afterward the Front End’s external web site IIS log shows the remaining web service requests from the same client (test1@mslync.net).
2011-03-25 13:18:22 10.1.1.21 POST /RgsClients/AgentService.svc/mex – 4443 – 172.16.5.13 OC/4.0.7577.108+(Microsoft+Lync+2010) 200 0 0 6
2011-03-25 13:18:22 10.1.1.21 POST /WebTicket/WebTicketService.svc/mex – 4443 – 172.16.5.13 OC/4.0.7577.108+(Microsoft+Lync+2010) 200 0 0 3
2011-03-25 13:18:23 10.1.1.21 POST /WebTicket/WebTicketService.svc/cert – 4443 – 172.16.5.13 OC/4.0.7577.108+(Microsoft+Lync+2010) 200 0 0 596
2011-03-25 13:18:23 10.1.1.21 POST /RgsClients/AgentService.svc/webticket_bearer – 4443 – 172.16.5.13 OC/4.0.7577.108+(Microsoft+Lync+2010) 200 0 0 416
2011-03-25 13:18:25 10.1.1.21 POST /groupexpansion/service.svc/mex – 4443 – 172.16.5.13 OC/4.0.7577.108+(Microsoft+Lync+2010) 200 0 0 4
2011-03-25 13:18:25 10.1.1.21 POST /groupexpansion/service.svc/WebTicket_Bearer – 4443 – 172.16.5.13 OC/4.0.7577.108+(Microsoft+Lync+2010) 200 0 0 646
2011-03-25 13:18:30 10.1.1.21 POST /groupexpansion/service.svc/WebTicket_Bearer – 4443 – 172.16.5.13 OC/4.0.7577.108+(Microsoft+Lync+2010) 200 0 0 216
2011-03-25 13:18:30 10.1.1.21 POST /groupexpansion/service.svc/WebTicket_Bearer – 4443 – 172.16.5.13 OC/4.0.7577.108+(Microsoft+Lync+2010) 200 0 0 418
2011-03-25 13:18:50 10.1.1.21 GET /abs/handler/C-0e8e-0e97.lsabs – 4443 sip:test1@mslync.net 172.16.5.13 OC/4.0.7577.108+(Microsoft+Lync+2010) 200 0 0 204
[…] Technical – Deploying Lync director web services correctly – here […]
[…] Publishing Lync Director Web Services « Jeff Schertz’s Blog Posted on March 22, 2011 by johnacook http://blog.schertz.name/2011/03/publishing-lync-director-web-services/ […]
How does the client know that it has to hit the External web service url defined on the director rather than on the external web service url defined on the FE pool?
I dont see it anywhere in the client log where it comes to know about director external web service url
By the time you get to the client log the client has already authenticated and has been passed in-band the external URL for their pool server (Front End). The Director's web services are contacted during the authentication process (prior to sign-in) for access to the Certificate provisioning and Web Ticket applications. Take a look at the IIS log file screenshots I've added to the end of this article for more details.
I saw the IIS logs you posted. My question is still unanswered
We are publising Director's external web service url on TMG server, how the lync client come to know about this url. I could not find it anywhere in the etl log or uccp log.
If it is web ticket then client will get it at the time of authentication… in that case the request will go from edge to director which will anyway authenticate the client.
I don't know if the Director external FQDN is recorded in either of those client logs but the traffic history definitely shows the requests coming through the reverse proxy to the Director's external IIS site, and not from the Edge server. If you run wireshark during the authentication process you'll see the traffic from the client to the Director's external web services FQDN. I've also clarified this behavior with the Lync product team.
Hi Jeff
Do i need to publish the External Web services URL, Office web apps URL and the simple URL's in RP.
Do we have a process document on how to achieve it.
Yes, without publishing the web services publicly you'll have a very poor external Lync users experience as may features will not be functional. The process is covered in TechNet for some solutions like TMG or IIS ARR, but for other third-party solutions they often have their own documentation for this.
Hello,
I have installed Lync 2010 all-in-one with one IP. I don't have a reverse proxy and host is going to the Internet via NAT.
Internal and External users can make calls to each other, but external users cannot connect to the meetings.
Could you give me some advice with this problem, please?
You don't need the reverse proxy just to join meetings so it appears something is incorrectly configured with the Web Conferencing Edge component. Make sure that none of the listening ports overlap on the single external IP.
Is it possible to use 1 external IP address for both the external Director and external FE FQDN's, then create the certificate with both names in it (plus the simple url's)? So that way they both go through the same interface on ISA (my reverse proxy). I would still have 2 separate publishing rules, but they would use the same certificate. Would this configuration work?
Tim, I have not tested this yet in Lync but technically it is possible to point multiple FQDNs to the same ISA/TMG listener and then use separate rule configurations to match against only specific URLs (this is how Exchange Web Publishing is traditionally setup). I'm unsure as to if the Lync server will like that setup (although the reverse proxy should mask that behavior from the Lync internal server anyways). This may also not be a Microsoft-supported scenario even if it does work. Let me know if you try and it what happens.
So just to make sure I've got this right your director and front end pools should have seperate fqdns for web services but both can have meet and dialin be the same? or do the meet and dialin need to be different fqdns on each?
You could place the Simple URLS (meet, dialin) on either or both servers, but only one server would be routed the traffic due to using a single external DNS record for each FQDN. You cannot use Robin-Robin DNS to create multiple IP for these services, load balancing would need to be performed with a Hardware Load Balancer for web service traffic.
Good writeup Jeff, much appreciated.
Doesn’t this potentially leave a domain connected server (FE) accessible and exploitable from the internet (albeit from connections forwarded by the Reverse Proxy and through firewalls) as essentially the conference web page will be loaded from the FE Server directly? Do you know if you can separate the external IIS Website off so that any potential exploits against the site would be on a work group server (like an Edge in the same network segment as the RP) with limited data access?
Peter, the Web Services cannot be located on an Edge server, nor can they be installed on a server which is not a domain member. Publishing these using a reverse proxy is no different than publishing Exchange Web Services or a SharePoint web site.
Ah I see, have you ever had to put an authentication page infront of the RP before requests are forwarded to the FE or have you any advice how this would be best done? Very helpful article by the way!
Great Document!
I am a little confused – if my TMG rule is set to bridge external connections from 443 to 4443 on to my director pool. I understand there are some web requests/responses with the director, if it then it determines the correct destination is pool01 for example, does the HTTP/S requests to pool01 go THROUGH the director, in other words the external client still communicates to the same URL, through the same IP or is somehow a redirection request send back to the external client. If it is a re-direct do I need to setup an external URL / TMG rule through to each director pool and front-end pool?
You need to publish all pools individually as the Lync client will need to connect to both the Director and the Front End server at different times for different purposes. There is no classic redirection going on, but basically the client will connect to the Director web services FQDN it was passed during sign-in but then after the client is then connected to it's home Front End pool it will receive another web services FQDN. So the client is aware of both FQDNs and will need to connect to both. This is only for the external web services FQDNs, the SimpleURLs only need to be published in one location and all external client connections will always go to that one location.
Hi,
Will it be possible to use a single public IP (Listener) for both the director and the FE Web Services? I understand that it will need two publishing rules, but I'm interested to find out if I need more than one public IP.
This is possible if you define all the public FQDNs on the same certificate and then use the same Web Listener (hence the same listening IP/port). The individual rules will then use unique Public Names to match the correct FQDN for the different internal servers. This is not best practice and I'm not sure if it's supported by Microsoft but it theoretically does work.
Hi Jeff,
Great article. The only peace I dont understand is how the client gets aware of both FQDNs? Is there any Lync internal mechanism who publishes this information to the client?
Cheers
The Lync client receives in-band a bunch of configuration information from the Lync Server. If you are curious to peek at some of the many URLs then simply hold-down the CTRL key and right-click the Lync icon in your Windows systems tray to show the hidden "Configuration Information" menu.
Hi Jeff,
Fantastic article, it was an informative read. Any advice you can give with regards to a network having a single Public IP address with an Exchange Edge loaded on the TMG with an existing listener setup for port 443 to resolve webmail, activesync and autodiscover? I have thought of perhaps issuing a new certificate which includes ALL names for Lync and Exchange or generating a wildcard certificate. Any suggestions which would be the best and advise on if it would work, and if it may work, at what capacity?… i.e. would certain services not be available if I did it this way? Appreciate your input in advance Jeff, I know for a fact this would not be supported by Microsoft in a million years, but I am limited to what resources I have at the moment with only 1 x Public IP Address. Oh I also have LDAP and RADIUS running, I don’t think this is an issue or concern though…
Cheers!
You can use a single certificate for both the Exchange and Lync reverse proxy rules, but do not use a wildcard certificate. Simply populate all of the required FQDNs in the SAN (e.g. mail, autodiscover, lyncweb, dialin, meet, etc). Normally I recommended separate certificates but I have deployed non-production systems in this fashion and it works fine. And technically you can use a single Web Listener across multiple TMG rules with different destinations and Public Names. But Exchange and Lync require slightly different authentication settings as well as a few other tweaks to the Web Listeners, preventing you from using the same Web Listener on both Lync and Exchange publishing rules. If you mess with the settings enough you may find a common configuration that will work for both systems but it will probably be unsupported and definitely will not be best practice. I highly recommend acquiring at least one additional public IP address.
[…] In this scenario the Lync Autodiscover service is published in the same manner that the SimpleURLs are published. There are currently two separate web publishing rules, one for the Front end Server and one […]
Nice Article Jeff!
What about the External Lync mobility url, is that suppose to be terminated to the Director pool as well or the Front-End Pool? If director than would the mobile devices still go to FE pool for addressbook etc?
That guidance is explained in this article. In short the autodiscover service is treated like a SimpleURL; it is only published for the Director. After the mobile client connects to the Director's autodiscover service it will be redirected to the Mcx service using the external web services FQDN of it's own pool which should already be published anyways.
Jeff is great )
What goes into the Internal Public site name on the TMG firewall policies? Microsoft states
"7.On the Internal Publishing Details page, type the fully qualified domain name (FQDN) of the internal web farm that hosts your meeting content and Address Book content in the Internal Site name box."
We have a split DNS LB and HLB deployemnt and have seperated the internal and external Webservices url for each of the director and frontend pools. So by internal web farm, is this referrering to the internal web services VIP listening on 443 and not the external webserrvices VIP listening on 4443. Thanks.
The exact FQDN you select for that option may vary depending on your actual DNS configuration, but the goal is to point the TMG rule to the External Web Services on the Internal servers, meaning you need to point to the 8080/4443 services. You should never redirect external clients to the Internal web services (80/443).
It is important to understand the impact of change in topology in externally published web services solution. It is difficult to understand from the documentation process but in reality it should be published. This article highlight the do’s and don’ts .It is explained in a step-by-step process so that users will not get confused. Thank you for the great post.
We currently have a single datacenter with front end and director pools. For DR I'm adding another FE pool in another DC. The DCs are connected by a high bandwidth, low latency pipe. Each FE pool will host 50% of my users in an active/active backup scenario. My plans are to leave the Director pool in one DC, and in the event of a disaster in the DC where the Directors reside, simply point meet, dialin and lyncdiscover to the FE pool in the other DC and fail over to that pool. Will this scenario work, or would external clients continue to look for the now-down Director servers for authentication and fail?