Thursday, October 4, 2012

Lync Branch Site Options and Recommendations

A large-scale Lync deployment typically consists of at least one central site that contains either a Standard or Enterprise Edition pool and one or more branch sites that don't warrant having a full-blown Lync deployment, but still need local voice connectivity in case of a WAN outage.

You have 4 options when considering what to deploy at a branch site:
  1. Survivable Branch Appliance (SBA) - an all-in-one solution that consists of a PSTN gateway with the appropriate interface required for connectivity to the PSTN and a "Lync-Lite" installation that has only the Lync registrar and mediation server roles.
  2. Survivable Branch Server (SBS) - A "Lync-lite" installation containing the Lync registrar and mediation server roles.
  3. A PSTN gateway and a standalone Lync mediation server
  4. A full-blown Lync deployment (typically Standard Edition)
Microsoft doesn't give much guidance as to which option is right other than saying that an SBA is appropriate for branches up to 1000 users, an SBS or 2 SBAs is good for 2000 users, and anything beyond that should be a Standard Edition Server.

What a lot of people don't realize is that there is more to consider than simple user counts.  Let's start by looking at where an SBA is appropriate, and where it isn't.

Survivable Branch Appliance

As noted earlier, a Survivable Branch Appliance is an appliance that contains a PSTN gateway along with a small Windows Server 2008 R2 deployment with the Lync registrar and mediation server roles. SBAs are purchased from vendors such as NET, Audiocodes, Dialogic, or Ferrari, among others. An SBA is paired with a central site that has a full-blown Lync deployment and is designed to be dropped into an office that doesn't have much local IT support.

Lync clients are homed on an SBA, and will register/login directly against it. PSTN calls are routed through the mediation server role and onto the PSTN gateway component of the SBA.

While clients register against the SBA, their contact list is still homed on the central Lync deployment.  Also, all conferencing features and response group functionality is provided by the central Lync deployment.  So, if the WAN link between the central site goes down, clients will lose their personal contact list, the ability to do multiparty web/video conferencing and any response groups whose phone numbers terminate on the SBA won't work.  This is beautifully illustrated by VOIPNorm on his blog post on the topic.  What DOES work is one-to-one IMs/telephone calls, PSTN calling, searching for contacts and any other features that don't require the full Lync deployment's involvement.  Again, see the blog post by VOIPNorm for full details.

When to Use a SBA and When Not To

Use an SBA when you your site meets the following criteria:
  • Up to 1000 users (2000 if you use 2 SBAs)
  • Have a T1/E1 or analog connection to the PSTN
  • Won't miss conferencing or response group functionality during a WAN outage
  • Have limited IT staff on site
Don't use an SBA if your site meets any of these criteria:
  • Does a lot of conferencing and has a slow/expensive WAN pipe to the central site.  Conferencing services come from the central pool, so this can be a strain on WAN resources.
  • Requires high availability for conferencing features and/or Response Group services
  • Use a SIP trunk for PSTN connectivity, unless the SBA can be configured as a SIP gateway and doesn't have PSTN interfaces you don't need (they aren't cheap)

Survivable Branch Server

A Survivable Branch Server (SBS) has the same capabilities as an SBA, but without the PSTN gateway component.  It isn't something that you purchase from a vendor.  It's simply a "Lync-lite" server you define in the topology and install yourself on a regular Windows Server 2008 R2 (or Windows Server 2012 for Lync 2013) server.  Like the SBA, it only has the Lync registrar and mediation server roles.

Incidentally,  you won't see an option to define an SBS in the Lync topoology.  Your only option is an SBA.  Since the functionality of the Lync portion of the SBA is identical for an SBS, it doesn't need to be defined separately. Lync doesn't care if the PSTN gateway is part of the same chassis as in an SBA or a separate component as with an SBS.

When to Use a SBS and When Not To

Use an SBS when your site meets the following criteria:
  • Have up to 2000 users
  • Have the local infrastructure to support a full-blown Windows Server deployment (either VM or physical server)
  • Have a SIP trunk connection to a Lync-certified SIP provider, or you already have a standalone PSTN gateway
  • Won't miss conferencing or response group functionality during a WAN outage
  • Have at least some local IT staff
Don't use an SBS if your site meets any of these criteria:
  • Does a lot of conferencing and has a slow/expensive WAN pipe to your central site. Conferencing services come from the central pool, so this can be a strain on WAN resources.
  • Requires high availability for conferencing features and/or Response Group services
  • Have either a T1/E1 or analog service for PSTN access. You would still need to purchase a PSTN gateway, and would probably be better served by using an SBA (unless either of the above 2 points apply)

PSTN Gateway and Mediation Server

This option is an interesting one in that I've not seen it "in the wild".  A site with just a mediation server role is entirely dependent on the WAN link to the central site. If the WAN goes down, then so do your clients. You need the infrastructure to support a Windows installation, something many small branch sites don't have.  If you have a SIP trunk connection, you may not need a PSTN gateway at all.  Conversely, you may not require a mediation server if you use media bypass to send client audio traffic directly from the client to the PSTN gateway.

When to Use this Option and When Not To

Use a PSTN Gateway/mediation server when your site meets the following criteria:
  • You have a 100% reliable WAN connection to your central site or your users will be OK with no functionality in the event of an outage
Don't use a PSTN Gateway/mediation server if your site meets the following criteria:
  • Your WAN isn't reliable

Standard Edition Deployment 

Sometimes, you will need a full-blown Lync deployment at your branch site.  With even just a Standard Edition server, local clients will get all the functionality Lync has to offer, so WAN outages won't be a big issue.

When to Use this Option

Use a Standard Edition server when your site meets one or more of the following criteria:
  • You have more than 2000 users in a site
  • Your WAN link reliability is low
  • Your users do a lot of conferencing with each other
  • You need local Response Group functionality
Hopefully, this post will give you some better guidance as to what branch role to deploy at your sites. If you have any questions or comments, please let me know. By the way, the above is relevant for both Lync 2010 and Lync 2013.


  1. Great article Ken,
    When we say an SBS is nothing but a normal Lync installation, how different is it from a Standard edition deployment? As i understand, if we follow the normal procedure for a typical lync installation for SBS, wont a front end server get installed?
    Do we just need to deploy Lync till the "Install local configuration store" in case of SBS??

    1. Thanks Abhay,
      I think I need to clarify that sentence. An SBS isn't a normal Lync server. It has the registrar and mediation roles, but nothing else, like conferencing, response groups etc.


  2. Great post Ken! Do you know if you have to license the SBS separately?
    We recently deployed Lync at a small branch site without any Lync servers. SIP trunk to the main site and configured the response group to always dial an analog line at the remote site as the DR - it is only used in case of a WAN outage.

    1. Hey Martin,
      Thanks! No, the SBA/SBS server does not require a server license. Only front-end servers require licenses.


  3. I think the biggest factor of SBS vs SBA is whether you like the SBA vendor & their product. Personally, I prefer to separate the Lync server from the gateway, as it simplifies technical support issues. Also, if you have limited experience with VoIP gateways, you have more choices, less initial cost, and better flexibility to use a gateway + SBS.

  4. Hey Ken,

    I am facing Inbound calling issue with my Cisco ASA. I am using dedicated Mediation server with two Network cards. One facing Internal Network without Gateway & other facing my DMZ network with gateway.
    I have added required routes on mediation server for Internal network traffic.

    I do not have any issue with Outbound calling but inbound calling fails
    intermediately. I am using Static NAT on external interface.
    Do you have suggestion on the same.

    Thanks in advance.

    1. Hey Santosh,
      The first thing I would do is run a log trace against SIPStack to see if the call is actually reaching Lync. I suspect the call isn't even getting to the server.


    2. Hey Ken,

      I have run the log trace on Lync for SIPStack but no luck, as NATing is giving problem. Is public IP required for the mediation server network interface which is facing to the Direct SIP trunk? e.g. CircuitID

      Currently I am using static NAT, but inbound calling stops working after some time & start again. NO issues with outbound calling.


    3. Some SIP providers have issues with NAT on inbound calls. I know Thinktel in Canada used to until they made some network changes on their side to better support NAT. Your provider may be having similar issues. Check with them. You may either have to use a non-NATted public IP or setup a VPN between yourself and your SIP provider (if they offer that option).


  5. Great post on a subject that is not clearly defined anywhere.
    I like the idea of using the 2013 Standard Server in each of our Branch offices (currently we only have the EE in our main office).
    I have just one question, if we deploy the Standard server in the Branch offices (will be 6), how do we handle providing a backup registrar for each of the branch offices with the Standard server installed, or is that option not available.

    1. If you deploy Standard Ed servers in every site, you can pair them up with one another to provide backup registrar capabilities. It's a 1:1 pairing, though. Can't have more than 2 servers in a pairing.


    2. On the above site design, would you create a separate site for each branch location
      Just have one site and create separate pools for each branch location?

      all locations are connected by a 5mb MPLS link

    3. I like the idea of separate sites, because it makes it simpler to assign dial plans/voice policies automatically. If you're going to have different voice policies for each branch (ie. users will be calling via a local gateway), then I would create separate sites. That way, when you run the Optimizer against each branch, it will create site-specific dialplans/voice policies. When you create user accounts for those branch offices, they will automatically get the correct dialplan/voice policy.

      Putting them all into one site makes management of dialplans/voice policies easier, but most of your users will have to have a voice policy assigned to each account.


  6. Ken;

    Wondering your thoughts on this scenario, i don't have the environment to test it out. If we had a FE server in a data center which had an edge server deployed, and we also had a branch connected on a private network with a dedicated 10mb link and an SBA at the branch site.

    If the wan link went down the users are still registered against the SBA registrar and move into limited functionality mode , is there a way to force the client to connect to the edge server to get the remainder of the features ie. contacts, conferencing, response groups etc?

  7. Ken,
    Not even sure if this is doable, but could another EE pool be used as a branch site, or does a branch site need to be SE? we have several offices in Europe that need to be part of our central site but also use a European PSTN connection and be available in case the link between US and Europe fails. I'm not finding much if anything about deploying on this scale, and I'm not really concerned if the topology is supported by Microsoft.

    Bill Garner

    1. A branch site, by definition, is a site that only contains an SBA or SBS. It can't contain full Enterprise or Standard Edition servers. You are not limited in the number of central sites that you can deploy. You can even put multiple pools within a central site.

      In your case, you mentioned that your European offices have to be part of your central site (why, I'm not sure). You can install as many EE or SE pools in that central site as you require.


    2. So what I'm getting from your reply is that it would be smarter to build out another central site. That makes way more sense to me than than what I was thinking. Thanks