I want to set up our 3 FE servers so the go through our HW load balancer. From what I have read so far, the recommended solution is to LB the SIP traffic using DNS but LB the web services through the HW LB. In order to do this, I need to override the web services URL but the problem with that is I don't have a name in my certificate available. Right now, the pool name and the web services name are the same. Lyncpool.domain.com.

If I override the web services URL, the name I choose has to be in the certificate Lync created. If I wanted to go this route, what should I do?

Or, I can just pass everything through the HW LB. Both SIP and web services traffic. Not sure what ports I would need to allow but shouldn't be too hard to figure out. Any advice would be appreciated.

Best practice is really to use HLB only for HTTP, and use DLB for the rest.

And yes, this would require you to override the internal address (give this an IP on your HLP VIP) and create a new certificate, including your new name.

You can go the other way around, and force all traffic through the HLB, but in my experience this is much harder ;) 

I agree with Lasse.  You'll either need to override those URLS (one for internal and one for external) and get them in the cert or HLB everything which is a bi

OK, so the pool itself gets load balanced by using DNS round robin and entering the pool name 3 times, one for each FE server with IP addresses pointing to the 3 FE servers.

I then need to change the Internal Web Service URL using Topology builder and then run the Certificate wizard again to add in the extra URL. I need to do this on each FE server.

Then set up a VIP mapped to the new Internal Web Service URL which points to my load balancer.

Just a few questions. Do I need to run setup again or anything like that on the FE servers?

What exactly is Internal Web Services? Are these the simple URL's like meet, dialin and admin?

Of the 3, we only use meet and that currently has a "A" record in DNS that points to our 2010 server.

• Edited by shadowtuck Wednesday, January 08, 2014 3:28 PM

"OK, so the pool itself gets load balanced by using DNS round robin and entering the pool name 3 times, one for each FE server with IP addresses pointing to the 3 FE servers."

Yes.

"I then need to change the Internal Web Service URL using Topology builder and then run the Certificate wizard again to add in the extra URL. I need to do this on each FE server."

Yes.  Or once with all three front end server FQDNs in one cert used across all three servers.

"Then set up a VIP mapped to the new Internal Web Service URL which points to my load balancer."

Yes.

"Do I need to run setup again or anything like that on the FE servers?"

Nope.  A service restart wouldn't hurt though after you make the change and get the new cert in.

"What exactly is Internal Web Services? Are these the simple URL's like meet, dialin and admin?"

Simple URLs and a handful of other services like address book, etc. 

"Of the 3, we only use meet and that currently has a "A" record in DNS that points to our 2010 server."

Dialin is really for conferencing, which you could potentially skip if you don't use it.  Admin you can skip. 

Internal web services are: Meet - you need this for meetings Dialin - you need this for pin mgmt for users, changing their meet URL and information about dtmf. I wouldn't skip it if I was you Lyncdiscoverinternal - used for location of the services for mobile and slates Internal web service URL - used for access to address book and certificate services, download of meet content and more. This IS a must Admin, can be skipped, yes All of the above should be in a single certificate + the three servers in your deployment. (I recommend this approach, as the HLB MUST have this in its certificate. You can accomplish this by enrolling on one server and adding the other server names in the additional host names dialog box. After adding the internal override URL, and publishing the topology, you should: -make sure replication status is true - Run bootstrapper on all servers - create a new cert (make sure all your host names are present), make sure it is exportable - install the new cert on the server - Restart IIS - Export this certificate with private key - import this certificate on the other two servers (restart iis after import and assignment) - Import this certificate on the HLB and use it on the http VIP Hope this helps :)

I have separate "A" records in DNS for meet, lyncdiscoverinternal, etc... so my question is if I change the internal web services URL, what is this doing for me? This is where I am getting confused because everyone explains it differently. I'll have a unique URL for internal web service but also have "A" records for meet, lyndiscoverinternal etc...I am thinking Internal Web Services are just services that are not published in DNS like address book lookups etc.... When you say Internal web services are Meet, I am getting confused.

As far as Dialin, we have absolutely no telephony integration so I don't see Dialin as important. Our LB will be doing just pass through so no need to install a certificate on it. Its much easier this way and we have a small population of users so its not an issue with performance. I will be just updating the certificate on each FE individually. I don't see any advantage to exporting and import from one server to another. Lastly, what is this bootstrapper you are referring to? Would a reboot of the FE suffice?

One item, it's not DNS Round Robin that Lync uses.  RR infers that the DNS server passes out different addresses one after another to requesters.  In Lync the DNS request will simply return multiple results and the Lync client itself is programmed to support this and how to deal with connection during normal or failed states.

If you define an Override FQDN in the topology and then rerun the certificate wizard it will automatically add the selected FQDN into the request.

For example your Pool FQDN might be "lyncpool1.domain.net" and contains three DNS Host records for that FQDN with different IP address, while your Override FQDN might be "lyncpool1web.domain.net" and only have a single DNS Host record with the IP address of the service created on the HLB to balance 443/80 traffic.

Basically, HTTPS likes to be hardware load balanced and doesn't play as nice with DNS load balancing.  This is a way of splitting that service off so you can do just that.  The A records for meet, lyncdiscoverinternal, the internal web services URL etc. would point to your HLB which would pass it off to a front end, but those URLS are just aliases that all go to the same web service. 

The bootstrapper is just step 2 of the deployment wizard that adds and removes the roles, it's different that a reboot.  You can also run this to trigger the bootstrapper:  %ProgramFiles%\Microsoft Lync Server 2013\Deployment\Bootstrapper.exe

Also, thanks Jeff for correcting the round robin statement!

Thanks. I did read up more on DNS and it's not really RR as I stated but an offering of all IP's to the client at one time. I am hoping the 2010 client supports this because most of our users have 2010 because of XP.

I suppose it would not hurt to run Step 2 (bootstrapper) again after making the change. Regarding the my question on Internal Web Services, correct me if I am wrong but this is not meet, dialin, admin etc...I think its all the web services built into the client that run in the background like Address Book etc... Reason I say this is because the other simple URL's have their own DNS entries.

To be clear, meet, dialin, lyncdiscoverinternal, and your internal web services FQDN run from the same website, but have their own alias.  So yes, this is basically adding another alias so you can use an HLB for the web services.  This will be used for the address book, conferencing, and some other items. 

The 2010 client will support everything you're doing with load balancing.