We have this offices infrastructure:

   PSTN <(1)> Central Office Central <> WAN <> Remote Office <(2)> PSTN

We need that if (1) or WAN is broken/OFF, users on Remote office can do/recieve call from PSTN (2). We need also response group funcionality...

In this case, which is the best Design

Central Site + Branch site ?? In this branch site, must I deploy only a Standard pool ?

Hello Carlosdlra,

For your first requirement an SBA (Survivable branch appliance) will do just fine. It'll provide voice resiliency for remote office users in case WAN is down.

The problem will be in RGS, as SBAs don't have this service and can't host RGS numbers.

If you host your RGS in the central office, and assuming only <(1)> is down, then remote office users can reach it via WAN. Same if WAN is down they can reach it through PSTN2 but if you're designing this for both <(1)> and WAN to be down in the same time then a std edition FE in the branch site is your best option.

Regards,

Muhammad Hazem

uchazem.wordpress.com

Hi Hazem...

Ok, I think the same...

When you have a branch site with standard Pool... Where must I add Remote Users?? Enterprise central pool or this Standard Pool ?? If I add remote users to Enterprise Central Pool and I've create RGS numbers on Standard Pool (Branch Site)...Can I add users to this Pool?

Hello Carlosdlra,

For your first requirement an SBA (Survivable branch appliance) will do just fine. It'll provide voice resiliency for remote office users in case WAN is down.

The problem will be in RGS, as SBAs don't have this service and can't host RGS numbers.

If you host your RGS in the central office, and assuming only <(1)> is down, then remote office users can reach it via WAN. Same if WAN is down they can reach it through PSTN2 but if you're designing this for both <(1)> and WAN to be down in the same time then a std edition FE in the branch site is your best option.

Regards,

Muhammad Hazem

uchazem.wordpress.com

• Proposed as answer by Eason HuangMicrosoft contingent staff, Moderator 19 hours 46 minutes ago
• Marked as answer by Eason HuangMicrosoft contingent staff, Moderator 18 hours 34 minutes ago

Hello Carlosdlra,

For your first requirement an SBA (Survivable branch appliance) will do just fine. It'll provide voice resiliency for remote office users in case WAN is down.

The problem will be in RGS, as SBAs don't have this service and can't host RGS numbers.

If you host your RGS in the central office, and assuming only <(1)> is down, then remote office users can reach it via WAN. Same if WAN is down they can reach it through PSTN2 but if you're designing this for both <(1)> and WAN to be down in the same time then a std edition FE in the branch site is your best option.

Regards,

Muhammad Hazem

uchazem.wordpress.com

• Proposed as answer by Eason HuangMicrosoft contingent staff, Moderator Tuesday, June 23, 2015 11:39 AM
• Marked as answer by Eason HuangMicrosoft contingent staff, Moderator Tuesday, June 23, 2015 12:51 PM

Hello Carlosdlra,

For your first requirement an SBA (Survivable branch appliance) will do just fine. It'll provide voice resiliency for remote office users in case WAN is down.

The problem will be in RGS, as SBAs don't have this service and can't host RGS numbers.

If you host your RGS in the central office, and assuming only <(1)> is down, then remote office users can reach it via WAN. Same if WAN is down they can reach it through PSTN2 but if you're designing this for both <(1)> and WAN to be down in the same time then a std edition FE in the branch site is your best option.

Regards,

Muhammad Hazem

uchazem.wordpress.com

• Proposed as answer by Eason HuangMicrosoft contingent staff, Moderator Tuesday, June 23, 2015 11:39 AM
• Marked as answer by Eason HuangMicrosoft contingent staff, Moderator Tuesday, June 23, 2015 12:51 PM

Hello Carlosdlra,

For your first requirement an SBA (Survivable branch appliance) will do just fine. It'll provide voice resiliency for remote office users in case WAN is down.

The problem will be in RGS, as SBAs don't have this service and can't host RGS numbers.

If you host your RGS in the central office, and assuming only <(1)> is down, then remote office users can reach it via WAN. Same if WAN is down they can reach it through PSTN2 but if you're designing this for both <(1)> and WAN to be down in the same time then a std edition FE in the branch site is your best option.

Regards,

Muhammad Hazem

uchazem.wordpress.com

• Proposed as answer by Eason HuangMicrosoft contingent staff, Moderator Tuesday, June 23, 2015 11:39 AM
• Marked as answer by Eason HuangMicrosoft contingent staff, Moderator Tuesday, June 23, 2015 12:51 PM

Hi Carlosdlra,

I think you mean you'll be creating the RGS over the STD edition pool while users are homed on the central enterprise edition pool. If that's correct then you'll have no issues. You can add these users to the RGS and call will reach them normally.

Muhammad Hazem

uchazem.wordpress.com

I know it.... but in that case we have RGS High Availability

Agree with everything Muhammad said.  But, I'd like to confirm you're running Lync 2010 vs 2013?  The other factor is pool pairing, which would be a nice addition to your design but would require 2013 and both sites to be either standard or enterprise. 

Will the inbound numbers fail over as well?  For example, if PSTN to the Central Office is down, can the incoming numbers for the Central OFfice be routed through the PSTN connected to the Remote Office?

Skype for business versin.

If is possible route calls to Remote Office when connection to Central office is down.

In that case, I'd also consider pool pairing.  Make sure both sides are enterprise or standard so this is supported.  You can have a single server enterprise pool in the remote site if needed. 

Should one pool fail, you can fail all users over to the other and route calls there.  RGS does not fail over with pool pairing, so you'd want duplicate RGS workflows with different phone numbers.  In the event of a failure, you can attempt to swap the phone numbers or redirect inbound calls to primary RGS number the other RGS number. 

I think it's not necessary duplicate RGS. You can switch manually RGS, not ??

https://technet.microsoft.com/en-us/library/gg398373%28v=ocs.15%29.aspx?f=255&MSPPError=-2147217396

Disaster recovery

Disaster recovery support for the Response Group application is enabled as part of the configuration and deployment of the paired Front End pools, which are part of the overall Lync Server 2013 disaster recovery configuration. In addition, Response Group import and export cmdlets support the failover process to the backup pool and the failback process to the primary pool or to a new pool. If an outage occurs in the primary pool, response groups can be failed over to the backup pool, and then failed back to the primary pool or to a new pool when the outage is over.