Survivable Branch Server Design and Configuration (Lync 2010/ 2013) with SIP Trunk

You can also use any PSTN Gateway or other SIP Trunk Provider...

General deployment of a Branch Site including QSC SIP Trunk connection and dual SIP (PSTN) Gateway Objects.
A SBS (Branch Site) can be deployed only with a Central Lync Site according your main Lync Design. It will not replace any associated Lync Pool (Std/EE) and do not hold any core Lync Database. More likely it is a SIP Registrar only, the main functionalities will still be provided from it Central Pool. There is are significant differences between Lync 2010 and Lync 2013, but in general the Voice Resiliency is still the same.
e.g. In Lync 2010 you can still use the SBS for RGS or Conferencing Dial-Ins, but all this features are temporarily out of order, if the main Lync Pool is not reachable, also the User Presence. This is different in Lync 2013, where this features set will be continuously available.

QSC SIP Trunk requirements

Within the QSC SIP Trunk requirements are several aspects we have to take care and are therefore not default settings within the Topology Builder.

Mediation Server SIP PSTN communication is set to:
- TCP Port 5068 and TLS Port 5067.

We need the SIP PSTN Gateway to be configured:
- For Signaling to QSC SBC with TCP Port 5060.
- Number handling from QSC must be E.164 format
- Media Bypass must be deactivated
- Call Admission Control must be activated
- Maximum early dialogs supported with a value of <3
- Opt. a QoS for Mediation Server to QSC SBC (DSCP Wert = 46 dez)

Other QSC requirements are:
Direct Internet connection from Mediation Server PSTN NIC to QSC SBC. Not supported are NAT or Application –Layer-Gateway. Please take care if you design a SIP Trunk Solution and carefully consider all this technical requirements.

The detailed setting and configuration of the Lync Server SIP Trunk option will be explained in a later Blog post.

Server requirements for a Survivable Branch Server SBS:

You need Silverlight only if you want to use CSCP.

Windows 2012:
• Message Queuing Server and Directory Service Integration features.
• The NET Framework: 3.5 SP1, 3.5 SP2, 4.0, or 4.0.30319, enabled using Server Manager
• Cumulative Update October 2012: Version 7577.205

Windows Server 2008 R2:• Apply the update Windows6.1-KB974372-x64.msu from:
Code Gallery (MSDN):
• Message Queuing Server and Directory Service Integration features.
• The NET Framework: 3.5 SP1, 3.5 SP2, 4.0, or 4.0.30319, enabled using Server Manager on Windows Server 2008 R2


Next Steps:

- Lync Topology Definition
- Check and define Windows Server Network
- Lync SBS installation
- Advanced Config in Lync Control Panel (SIP Trunk definition follow this LINK)
- Move User to SBS and hold Backup Registrar

Lync Topology Definition

Open Topology Build and download the actual Topology as usual.
Navigate within the Central Site, where you want to deploy the SBS and start the process as show in the next Images:


Define a Lync Site Name and a related description

Now isn’t more in detail the Location information (but this are not used in LIS)

After the Lync Site is defined, the Wizard will start defining the Lync Server and its Components:

Define the FQDN Name of your SBS

As we discussed earliest in my Blog, you need to assign the SBS to it’s Central Lync Pool, this fully depends on your Network, User and other scenarios you considered during the Lync Core Consulting.

Chose the Path for Lync Edge Server, this must not be the same as your associated Pool has, it also can be the nearest Edge Server available.

The Wizard will automatically ask you for a PSTN Gateway, which is for sure the main reason in Lync 2010 why you want a SBS.
As we need to configure here for QSC SIP Trunk, it very similar for any PSTN Gateway or SIP to any PABX.
The Gateways are here the QSC Session Border Controller (SBC) and will communicate via TCP Port 5060.
(Note, this is still secure, because it simply communicate on with MAC and IP Address registered EndPoints)
We will change the TCP Port later in this article-




Since we need redundancy in our SIP Trunk SBS config, we need a second gateway and will define this here:



This is still not all you can configure on the Mediation Server, you still have an option for dedicated IP address to be defined. In our configuration we have defined the dedicated IPs. You will have to edit the SBA Properties.



The second IP Gateway we have not jet associated with our SBS, so within the same Properties, we will add the second IP Gateway, as I have illustrated:
Optional, but not supported in our case with QSC, is the alternative IP address, as logic, if the primary IP is not available, it will try to connect to the second configure IP.

Best Practice is:
if you have dedicated PSTN/SIP Gateway, make an entry for each Gateway. Especially will Lync 2013, where we can make us of M:N relationships, we can also load balance both gateway, and have more and better options making use of the Gateway.!!! 




Not its time to publish our hard work ;)



Check and define Windows Server Network

As per requirement, we have a need of two NIC, one internal and one external NIC.
Configure your internal adapter as usual, incl. IP Default Gateway and DNS Server.
The External IP config is slightly different. We MUST NOT define a Gateway and DNS Server !!!!

Instead we configure Single IP Address Routes
ROUTE ADD –P destination_ip MASK extern_ip_gateway

Lync is really depending strongly on Networking, so make once more sure you are familiar with networking, IP and routing.


Lync SBS installation

Normally I would like to say, it’s really as usual.
Follow the installation process as documented in my Blog

We have on a SBS 3 Lync Services Running, not depending on the Lync Server 2010 or 2013.
REPLICA: The Replication Service, replicating the XDS Data from the Lync Share into the local SQL instance
RTCSRV: The Lync Server Front-End Service, it handles the Registrar
RTCMEDSRV: The Lync Server Mediation Server Component, handling the Voice Processing and Traffic

Advanced Config in Lync Control Panel

Enterprise Voice depends on several Components:

  • The Lync Client based Call handling (DialPlan, VoicePolicy, PSTN Usage)
  • The Lync Server Call handling (VoicePolicy, Route, indirectly the PSTN Usage and truly the Trunk Configuration)

I handle the Enterprise Voice setup only principally here, later this year I might write a longer Blog article about Enterprise Voice.
My advice, try to keep it as simple as possible:

  • What a User should be able to do/ call and how
  • How to normalize the call (internal/ extern)
  • Where to route the call
  • How the SIP Call as to be transformed before it’s handled by the PSTN connection (IP PBX, IP Gateways, Trunks).

(Here my advice, it’s most likely the best, if you normalize the E.164 numbers from Lync on the Gateway rather than in TRUNK configs) if you have PABX SIP Trunk, here it depends on the Vendor, not all of them accept E.164 standard numbers, e.g. Siemens.

In our case, QSC is fully conform to E.164, therefore I take care, having all transmitted numbers (calling Party, callee) in E.164, always and ever.
And all assigned users to this QSC SIP Trunk are and should be able to call to anywhere at any time.

Define your Dial Plan,

What is the user dialing and how it should be normalize into an E.164 format.

Define your Voice Policy AND PSTN Usage Record:

Define the features you want the users can make use of. In our case, I left is in default, since is good enough.
Remember, if you define Call Park Feature, you need to cover this in a separate configuration!


The PSTN Usage:
The PSTN Usage, defines in your Enterprise (Organization) the general usage of Voice Calls, here you have to define what, e.g. the CxO, HoDs, Users and other groups should be able to call.


Define your Route,

Where the normalized is Call going too.
In this described case here, we have really a lot of Gateways and Pools, but we kept it simple:
Per Region (with is a Profit Center), we have one PSTN outlet and only this group of user can make outgoing calls via this gateway and nowhere else.

We defined the Route to our location and allow ALL normalized number to this route/ gateway assigned.
The pattern therefore is default:  .*


Now I have added both QSC IP Session Border Controllers, defined earlier in the Topology Setup. The PSTN Usage is still coming from the Voice Policy defined before this step.

Add the SBC’s



Commit the changes:


User Configuration in Lync Control Panel

Making use of our configured SBS and the associated SIP Trunk.
A User is always assigned to a Lync Pool for any configured Lync features, as well the Pool is the main Registrar, where the user is authenticated. With an SBS its nor slightly different. Where normally a login go through the Lync discovery process, there is now a difference in our process.
Normally the login in go through the Directors or if not deployed, via the Homed Pool. This Homed Pool is written to an AD Attribute.
Now for this process it runs along a process like this:
If the main Pool is reachable, the user will go through the SIP discovery process and will be registered at the end on his SBS Server.
If the WAN link is broken, still the users AD Attribute is readable through AD DC, so the last discovery process it’s the users AD Attribute, which is now the SBS.
The SBS is the Backup Registrar as it’s depending Lync Pool.

So far simplified, we need to move or create users for and on the SBS, while the Users config is still store on the Main Pools SQL Server Database.

How we did it is, we search here for my Admin Account and will move it directly to the SBS, which than change the AD attribute of my Homed Pool.

DO NOT FORCE the move, since it might break Meetings



Once the user is moved, I have to change the Enterprise Voice setting and also assign a Phone Number along with the SBS.

That’s is and you successfully have a Deployment with SBS.

Regarding Lync 2013, the principals are the same only the Feature set of the SBS is a little bit more advanced.

Here what working if a WAN link fails on any configured Lync 2013 SBS (ref. Technet):

If you provide branch-site resiliency, if a branch site’s WAN connection to a central site fails or if the central site is unreachable, the following voice features should continue to be available:

  • Inbound and outbound public switched telephone network (PSTN) calls
  • Enterprise calls between users at both the same site and between two different sites
  • Basic call handling, including call hold, retrieval, and transfer
  • Two-party instant messaging
  • Call forwarding, simultaneous ringing of endpoints, call delegation, and team call services, but only if the delegator and delegate (for example, a manager and the manager’s administrator), or all team members, are configured at the same site
  • Call detail records (CDRs) (stored in MS Message Queuing Service)
  • PSTN dial-in conferencing with Conferencing Auto-Attendant (if Exchange AA is present a the Branch)
  • Voice mail capabilities, if you configure voice mail rerouting settings (same if Exchange is present at the Branch)
  • User authentication and authorization

The following features will be available only if your resiliency solution is a full-scale Lync Server (a fully deployed Lync Server) deployment at the branch site:
  • IM, web, and A/V conferencing
  • Presence and Do Not Disturb (DND)-based routing (where calls are prevented from ringing on extensions that have DND activated)
  • Updating call forwarding settings
  • Response Group application and Call Park application
  • Provisioning new phones and clients, but only if Active Directory Domain Services (AD DS) is present at the branch site.
  • Enhanced 9-1-1 (E9-1-1)

If E9-1-1 is deployed, and the SIP trunk at the central site is not available because the WAN link is down, then the Survivable Branch Appliance will route E9-1-1 calls to the local branch gateway. To enable this feature, the branch-site users’ voice policies should route calls to the local gateway in the event of WAN failure.

Registrar Assignments for Branch Users (if NO DNS is available)

Regardless of which branch-site resiliency solution you choose, you will need to assign a primary Registrar to each user. Branch site users should always register with the Registrar at the branch site, regardless of whether that Registrar resides in the Survivable Branch Appliance, Survivable Branch Server, or stand-alone Lync Server 2013 Standard or Enterprise Edition server. A domain name system (DNS) service (SRV) resource record is required so that a client can discover its Registrar pool. If the Survivable Branch Appliance becomes unavailable, this is how branch site clients will automatically discover the backup Registrar.

If a branch site does not have a DNS server, there are two alternative ways to configure discovery of the Survivable Branch Appliance or Survivable Branch Server:

  • Configure DHCP option 120 on the branch site’s Dynamic Host Configuration Protocol (DHCP) server to point to the fully qualified domain name (FQDN) of the Survivable Branch Appliance or Survivable Branch Server.
  • Configure the Survivable Branch Appliance or Survivable Branch Server to respond to DHCP 120 queries.


  1. the edge pool for the SBS cannot be the same edge pool as central site FE server?


Post a Comment

Popular posts from this blog

How to hide users from GAL if they are AD Connect synchronized

Cannot join external Lync Meeting: Lync Edge Server Single IP Address (Lync Edge Server Single IP Web Conferenceing Problem)

MFA with Guest Access and different tenants settings