3

I'm building a test Lync deployment on Azure; yes, I know this is not supported, hence "test".

Lync Front-End servers expose two set of web services, one for internal users and one for external ones; they listen on different ports (443 and 4443) on the same servers; when external services are published, you need a reverse proxy or a port forwarding in order to map port 443 of a public IP address to port 4443 of the Front-End server(s). When you have multiple Front-End servers in a pool, you also need to load-balance them.

So, a typical Lync deployment looks like this:

       Internal users
             |
            443
             |
         Internal LB
        192.168.0.20
        /          \
       /            \
    443             443
     |               |
 Lync FE 1       Lync FE 2
192.168.0.21   192.168.0.22
     |               |
    4443           4443
      \             /
       \           /
        External LB
     Public IP Address
             |
            443
             |
       External Users

This should be easily replicated in Azure, as it supports both external load balancing (configuration howto) and internal load balancing (configuration howto). They are even supported together in the same cloud service, so this configuration should be easy. However, it looks like "should" is the keyword here.

After creating the external load balanced endpoint (which listens on external port 443 and forwards to port 4443 on the servers), I'm trying to create an internal load balancer and add internal endpoints to is; however, while the ILB can be created successfully, adding an internal endpoint listening on port 443 and forwarding to port 443 on the servers fails miserably, with an error stating that port 443 is already in use by another endpoint:

Update-AzureVM : BadRequest : Port 443 is already in use by one of the endpoints
in this deployment. Ensure that the port numbers are unique across endpoints
within a deployment.

For reference, my commands are:

Add-AzureInternalLoadBalancer -InternalLoadBalancerName "LyncILB" -ServiceName "LyncFrontEnd" -SubnetName "LabSubnet" -StaticVNetIPAddress 192.168.0.20

(This completes successfully)

Get-AzureVM LYNCFE1 | Add-AzureEndpoint -Name "Https-Int" -Protocol "tcp" -LocalPort 443 -PublicPort 443 -LBSetName "HttpsIntLB" -DefaultProbe -InternalLoadBalancerName "LyncILB"

(This fails)

The existing external endpoint is configured as such:

Get-AzureVM LYNCFE1 | get-azureendpoint

LBSetName                : HttpsExtLB
LocalPort                : 4443
Name                     : HTTPS-Ext
Port                     : 443
Protocol                 : tcp
Vip                      :
ProbePath                :
ProbePort                : 4443
ProbeProtocol            : tcp
ProbeIntervalInSeconds   : 15
ProbeTimeoutInSeconds    : 31
EnableDirectServerReturn : False
Acl                      : {}
InternalLoadBalancerName :
IdleTimeoutInMinutes     :
LoadBalancerDistribution :

The error doesn't even make a lot of sense; the external load balancer listens on a public IP address, while the internal load balancer listens on a private IP address in the internal network; there shouldn't be any conflict here... however it looks like there is one instead.

Why doesn't this work? Am I doing something wrong, or is Azure networking just being silly as usual again?

1

The question is now moot, as Azure now allows (and has allowed for a while) the use of both internal and public load balancers to expose the same services from the same VMs.

It's still a mystery why you need to use two completely different objects to do the exact same work, only with different front-end IP addresses. But at least, you now can.

| improve this answer | |
0

Just came across the same issue with a different deployment. The issue is that you cant have more than one LB Rule configured on the same port and protocol using the same backend IP pools.

To achieve what you are wanting you will need to add additional NIC's to the machines and use the different IP's for internal vs External balancing rules. Alternatively you could give the machines public IP's and load balance on them externally (However you expose the machines to the internet, usually undesirable).

Hope that helps!

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.