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


28 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


  2. Hi Luca,

    I’m using IIS ARR :
    * for 3 applications (Exchange, office Web App and Skype for business)
    * with 2 NIC, 1st to inside the network, secondary for internet with 3 ip for each application

    Should I have to use one certificate for all (sfb, exch and owapp) or one certificate per application ?
    Can I use the existing certificate of all application ?
    Where I have to install application certificate, on internal nic ou external nic ?

    Thank you for your answer

    Liked by 1 person

    1. Hi Tien,
      first of all I suggest to never user 2NIC on ARR, only one in DMZ. It’s more simple and it works like a charm! I’ve never found any reason to use 2 NICs on ARR.
      Second: yes, you can publish Exchange, SfB and Office Web App with 1 single Public IP and 1 single Certificate! That’s one of the reason to use a Reverse Proxy, lower costs and simplify deployment.
      In that case you have to use a single certificate that contain every fqdn name used by your applications, maybe a Wildcard cert like *
      Obviously if you need to use the redirect described in this article, you need to have 2 Public IPs on ARR, one for http/https (with a single common certificate) and one with only http to use the redirect.
      Let me know.


      1. Hi Luca,

        Could you give more details about irp setting to allow mobile phone connexion to sfb server ?

        Thank you for your reply I will change my setting.


  3. Hi Luca,

    I apologize, I understood that you didn’t want to change the existing certificate on you IRP so you configured:
    • sfb -> https for the domain
    • sfb -> http redirect for the domain -> https for the domain

    If I have only one domain, and I already configured https for sfb on pc.
    For sfb on mobile phone using the same domain, I would like to know if I must configure “lyncdiscover http redirect” or if “lyncdiscover Mobile HTTP Proxy rule” is enough?

    Thank you very much


    1. Hi Tien,
      if you have only one SIP Domain you do not have to use the http redirect “trick”, you only have to setup the first part of the ARR publishing rule described in this article (from step 1 to step 7).


  4. Hello Luca,

    Thank you for the article.

    I am currently learning Skype for business and planning to setup a test lab for Skype,exchange and only have one public IP. I want to check if you can guide me here on setting up enterprise voice as well as publishing the resources to outside network for testing etc?

    As i have only one public IP can you please let me know the steps need to be followed for a successful deployment?

    Appreciate your help here.

    Many thanks



    1. Hi Pavan, if you need to correctly publish Exchange and SfB, you need at least TWO Public IPs, one for ARR and one for SfB EDGE in the Single Public IP with NAT configuration. You can use the same Public IP of ARR to route also SMTP traffic to Exchange with a port forward on your firewall. On your Public DNS you will create the Exchange, SfB and OOS records. On ARR you will need to create 3 Farm (Exchange 2016, SfB 2016, Office Online Server 2016), and 3 simple Rule, one for Exchange, one for SfB and one for OOS to match the differents host names and route the traffic to the correct farm.
      Regards. Luca


      1. Thank you very much Luca on coming back to me on this.Much appreciate it! So when i create farm for exchange on ARR i need to include ports 25 and 443 similar to 80&443/8080/4443 for other services and then port forward port 25,80&443 on the firewall? Also i was researching about the federation services which edge service provides and seems needs a microsoft agreement number to make it work. As i am doing a home lab is there anyway to by pass this so that test things etc?

        I believe Skype for business 2019 would be the last on perm as ppl were talking that teams might take over things going forward?

        Hope to hear from you soon on this.

        Liked by 1 person

      2. Hi Pavan, glad to help you.
        First question (firewall): correct
        Second question (federation): the only number you need is the Enterprise Agreement to establish Federation with Skype Consumer via this site , maybe you can avoid it 🙂
        Federation between SfB servers is “free”, but it works only if you use Trusted Public SSL Certs. You can use Let’s Encrypt Certs for free.
        SfB 2019 is not updated at this moment, I suggest to use the old but frequently updated SfB 2015.
        Agree, SfB is reaching the End, start to use Teams as soon as possible.


  5. Hello Luca,

    Good article!! but i have a problem ;(
    I have 3 Sip, one prinpipal sip domain (domain1) and two secondary sip domain (domain2 and domain3)
    When you use the tool Microsoft remote connectivity Analyzer with domain2 or domain3 show the error the port is not open (443), but i dont understand why the tool only search and dont search, so the redirect not working, but if you test the url internaly redirect correctly to
    Can you help me?



    1. Hi Koke, I’ve not understand if only the Remote Connectivity Analyzer give you an error or if you cannot connect with domain2 and 3 at all. In the first case, simply do not care. In the second case, there is something in your configuration that do not work correctly, check it again please.
      Best. Luca


  6. Hello, thanks for your fast answer.
    i cannot connect with domain2 and 3 at all, i´m going to explain the scenario:
    i have 3 server for sfb 2015:
    – 1 Edge server
    – 1 Front server
    – 1 ARR server (server configure with this great article)
    I have 3 server with Exchange 2013 with DAG

    When one user connect to Skype or exchange with domain1 work correctly internal and External (for the moment i havent changed the public DNS to redirect to ARR Server, now redirect to as this: => redirect Front end server of sfb 2015 =>redirect edge server of sfb 2015 =>redirect edge server of sfb 2015 =>redirect edge server of sfb 2015 =>redirect edge server of sfb 2015 =>redirect edge server of sfb 2015

    I want sure that ARR Server work correctly with domain2 and 3 before to change domain1 in the public DNS.

    When one user connect to Skype with domain1 but with domain2 in Exchange, the Exchange work correctly and the Skype connect correctly but dont see the list of last calls, etc because the domain of Skype and Exchange arent same, for those i want to use your great article to connect skype with domain2 and Exchange with domain2 in the same servers of sfb and Exchange to domain1

    Do you understand me?
    Sorry for my english



    1. I Koke, I see many errors in your current configuration. If I can give a hint, try to achieve a perfectly running SfB Deployment with only one SIP Domain, then add the others using my article.
      Try to use one of the many articles to correctly configure and publish SfB, your config is not correct at all (sorry). Best. Luca


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.

Create a free website or blog at

Up ↑

%d bloggers like this: