ARR: how to setup and use with multiple Lync/SfB SIP domains

Hi All,
in this article I’ll show you how to setup ARR as a Reverse Proxy for Lync / Skype for Business / Office Web App / Office Online Server (and if you want for Exchange, SharePoint, ADFS…..) and, more important, how to use a very simple but useful trick to publish many lyncdiscover. with a simple 5 Domains SAN Certificate or a Wildcard certificate.



Let’s assume that you have the following public DNS A Records for your SfB deployment:

Record Type Value Note A Meet Simple URL
Only 1 for deployment A Dialin Simple URL
Only 1 for deployment A External Web Service URL
1 for each Front-End Pool A lyncdiscover.
1 for each SIP Domain A Office Web App URL
normally 1 for deployment
  • The Public IP is and there is a NAT to
  • Only HTTPS traffic is allowed.
  • On ARR we will use a SAN (5 domains) or Wildcard SSL Certificate from a Public CA (Digicert for example).

Step 1: ARR Setup
On a Windows Server 2012 R2 or 2016 server install:

  • .NET Framework 3.5
  • IIS with following components
  • Download Microsoft Web Platform Installer and install it
  • Search ARR and install Application Routing Request 3.0
  • Install in the Certificate Store the CA Chain of the internal PKI

Step 2: ARR Customization
Set the Worker Process to Always Run:

  • Launch IIS Manager
  • Select Application Pools (by default, DefaultAppPool is the corresponding application pool for the Default Web Site)
    • Right-click on DefaultAppPool in the right-hand side and then click on Advanced Settings: change the Idle Time-out (minutes) value from 20 to 0 (zero) to disable the setting and then click OK to save the changes
    • Right-click on DefaultAppPool in the right-hand side and then click on Recycling: clear the Regular time intervals (in minutes) checkbox so that it is blank
  • Under the IIS root, open Request Filtering.
    • Click Edit Feature settings on the right and change the Maximum allowed content length to 2147483648 (this is mandatory for Exchange Publishing)

Step 3: ARR Network Settings
In our example ARR NIC is configured with a DMZ IP
For improved security it is recommended to use external DNS + hosts file and to remove bindings on “File and Printer Sharing” and “Client for Microsoft Networks”

Step 4: obtain Public SSL Certificate and use it on ARR
To create CSR I always suggest to use DigiCert Certificate Utility for Windows (
Follow instructions on this page CSR Creation Instructions for Microsoft Servers

Here you can find two examples with a 5 Domains SAN and a Wildcard request.
Once you have obtained the public key, load it on the server following on of these instructions:

In this article I will use the SAN certificate

It is better to remove binding on http

Step 5: configure standard SfB and Office Web App Farms
Now that ARR is ready, we can create standard Lync / Skype for Business and Office Web App / Office Online Server Farms.

Open IIS Manager -> Server Farms -> Create Server Farm….
Start with “SfB Front-End”
arr_10b arr_11

In Server address enter the FQDN of your SfB Front-End Standard Pool.
Be careful to expand Advanced Settings and enter httpPort 8080 and httpsPort 4443 because this traffic needs to go to the External Web Service Virtual Site on the Front-End, then clicc Add

Note: the port reset after you click Add is a normal behaviour, don’t worry about that.
Click Finish.
Remember to add IP and FQDN to the hosts file.

Repeat the process for Office Web App Farm.
Note: you have to use standard ports 80 and 443.
arr_14 arr_15

At the end you will have two new Farms, like the image below.

For each Farm, select it and set the Caching and Proxy value as suggested.

SfB Front-End Farm: Disable disk cache
Office Web App Farm: Disable disk cache

SfB Front-End Farm: Time-out to 1200 and Response Buffer Threshold to 0
Office Web App Farm: Time-out to 300 and Response Buffer Threshold to 0

Step 6: configure URL Rewrite Rules
Before we can correctly setup Rewrite Rules, it is important to understand how ARR “think”. Incoming request could be described by these basic components:

So an incoming request for

correspond to:
{HTTPS} = on
{URL} = Meet

Select the ARR Server itself in the left tree -> URL Rewritearr_20

Double click on the firts rule “ARR_SfB_Front-End_loadbalance”

Match URL
Set Regular Expression and (.*) as Pattern
Note: this is not mandatory, you can leave Wildcard and * as the default settings, but I prefer to use RegEx in my rules

Add these two conditions:
{HTTPS} = on
{HTTP_HOST} = (meet|dialin|uc|lyncdiscover)

arr_23 arr_24

Set Action Scheme on https://

Now open the “ARR_Office Web App_loadbalance”
Repeat same process for Office Web App, with Conditions
{HTTPS} = on

Step 7: Reverse Proxy test

Test the Reverse Proxy, trying to open some pages on SfB and Office Web App from Internet, like

Remember to add your CA Chain to Certificate Store on ARR Server!

Evolution of the scenario: add more SIP domains

Now that everything is working with your Primary SIP domain ( in this example), your Company/Customer ask you to add other SIP domains to SfB deployment, for example,, and (many) others.

What you cannot avoid: to buy more “lines” in the SAN certificate used on EDGE server. You NEED one line sip. for each domain plus one for Webconf EDGE Service. Period.

What you CAN avoid: to buy more SAN “lines” for Reverse Proxy SSL certificate!
On your Reverse Proxy, ARR or other brand, you can use existing certificate (SAN or Wildcard) without the need to expand it, you only need a new Public IP.
Let’s see how.

As explained at the beginning of the article, for every SIP domain added to the deployment, the only mandatory Reverse Proxy related FQDN is lyncdiscover.

In this example there is a (present in certificate), and we have to manage also

These records are used by clients as primary registration lookup method.

It is important to remember these informations:

A. Protocol and search order:

1. https://lyncdiscoverinternal.SIPDomain
2. http://lyncdiscoverinternal.SIPDomain
3. https://lyncdiscover.SIPDomain
4. http://lyncdiscover.SIPDomain

B. It is possible to redirect SfB PC Client incoming HTTP traffic to a different HTTPS URL
C. It is not possible to redirect SfB Mobile Client incoming HTTP traffic (as explained here

If you merge these informations, you have the solution for our task:

  1. both clients (PC or not) of will search for, but Lyncdiscover HTTP Web Site do not listen for HTTPS traffic, so client do not get any answer but not even Certificate mismatch errors.
  2. Then both clients try to use
  3. ARR redirect HTTP traffic from SfB PC Clients to WITHOUT any alert or warning
  4. ARR proxy HTTP traffic from Mobile Clients to Front-End External Web Server on port 8080
  5. SfB Mobile Clients get an alert to authorize HTTP Redirect
  6. both clients access the SfB External Web Service via https correctly


Step 8: configure ARR for lyncdiscover redirect

  1. Assign a new DMZ IP and a new Public IP to ARR. NAT the Public IP to DMZ IP and allow http traffic only, not https (see example below)
  2. Add a new Website with these settings (ok, you can change the name if you want) 🙂arr_27
  3. Check the binding on Default Site, be sure it listen the primary IP only
  4.  You will obtain something like this
  5. ARR Root -> URL Rewrite -> Add Rule(s) -> Blank rule -> OKarr_31
  6. Configure the new rule as image below
    Take care on Conditions
    {HTTPS} = off
    {HTTP_HOST} = lyncdiscover.(||
    you have to replace these additional example SIP domains with yours 🙂arr_32
  7. Repeat point #5 and Create a new blank rule “Lyncdiscover Mobile HTTP Proxy”, this will manage incoming traffic from SfB Mobile Clients
  8. Configure the new rule as image below
    Take care on Conditions
    {HTTPS} = off
    {HTTP_HOST} = same pattern as previous rule
    (note: OC is the User Agent of SfB PC Client, so this rule works for everything that is not the SfB PC Client)
  9. adjust the priority of rules like image bolow, with Lyncdiscover Mobile HTTP Proxy above Lyncdiscover HTTP Redirect
  10. Test it and enjoy these simple but useful rules!

As always, I hope this page could help some of you.
Best Regards


12 thoughts on “ARR: how to setup and use with multiple Lync/SfB SIP domains

Add yours

  1. @Luca Vitali,

    Nice post man.

    You know a way to do the same process above to support federation with external partners, no need to issue new public certificates, examples:

    Install a server with IIS and port redirection or new VIP with port redirection or an uncertified VIP.

    Exchange has a method for this as links below:

    Liked by 1 person

    1. Hi Evandro, thank you.
      I’m sorry but I cannot understand what do you meen with “support federation with external partners no need to issue new public certificates”, could you be more clear?


      1. Luca,

        On the Lync Server Multitenant Hosting Pack v2 platform
          (SW_DVD5_Lync_Server_2013_English_Hosting_Pack_MLF_X19-04580), was supported multiple domains with the hoster domain certificate because it was a retail environment where the federation service with external domains worked for all tenants without having to issue a new certificate for each new domain.

        You can configure federation without the need for SAN certificates for AutoConfig and federation.

        In this document published at the time, there were scripts that configured the communication of each tenant of the multi-tenancy environment.

        (10.2.2 Configuring federation with other Hosting Pack deployments)



        Import-Module ActiveDirectory
        Import-Module LyncOnline
        Import-Module Lync

        $OU = “OU=$masterID,OU=Provider,OU=hosting,DC=prod,DC=domain,DC=local”
        $OUObject = Get-ADOrganizationalUnit -Identity $OU
        $GUID = $OUObject.ObjectGUID

        $all = New-CsEdgeAllowAllKnownDomains
        Set-CsTenantFederationConfiguration -Tenant $GUID -AllowedDomains $all


        11 Create Tenant DNS Records

        Several tenant-specific DNS records are required for tenant users to be able to use hosted Lync Server easily. Lync Server clients comply with SIP RFCs, which state that TLS connections must require that the server’s domain name match the SIP domain name of the client user. The client looks for a service (SRV) record with a matching domain name, which in turn must point to a server or servers with matching domain names.

        The following table shows which records need to be created for each SIP domain to be used by a given tenant.
        Tenant-specific DNS Records

        Type FQDN Target IP address/FQDN Port Maps to/comments

        SRV _sip._tls. sip. 443 Used for automatic configuration of the lync client – maps to hosters Access Edge

        SRV _sipfederationtls._tcp. sip. 5061 Used for federation with other lync deployments – maps to hosters Access Edge

        Can I express a more clear and detailed?


    1. Hi Evandro,
      yes now it’s much more clear 🙂
      First of all, I’ve never used Hosted Pack, but as expressed by the latest article, SfB Online look for a SAN certificate on the EDGE Access with every sip. listed.

      It’s not possible to avoid it with the same method of this article for two reasons:
      1. Federation traffic do not pass through ARR but via EDGE Access
      2. This method works only because clients look for https AND HTTP, and redirect works only for HTTP. Federation traffic is between servers, works only on port 5061 with SIP/MTLS, no way to avoid it.
      I’m sorry.
      Best Regards


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Blog at

Up ↑

%d bloggers like this: