About Torren

I'm a Microsoft Certified Solution Master for Communication, aka Skype for Business. As a consultant I work in all areas of SfB design, deployments, and support, with a particular focus on voice workloads, networking, and high availability.

AudioCodes Configuration for SfB

I’ve worked with a couple of organizations in the past several months that have had… inconsistent configuration on their AudioCodes gateways and SBCs for proper connectivity to multiple (or in some cases single) SfB pools. For simplicity, I’ll use the term “SBC” to mean both the SBC and Gateway, unless there’s a particular need to call out one versus the other.

In an AudioCodes SBC, you can route traffic to/from your SfB system using a variety of uncivilized methods, including specifying IP addresses. Yuck. Do yourself – and those who’ll look at your config after you’re done – a favor and use Proxy Sets. You’ll find those under “Signaling & Media”, then “Core Entities”, then “Proxy Sets”.

A Proxy Set lets you specify a number of characteristics for a system that you want your SBC to communicate with, allowing for much less clumsy and random configuration. Here’s a Proxy Set configured for one simple SfB server:

ProxySetSE

This could be a standalone mediation server, a Standard Edition server, or a solo Enterprise Edition Server. Let’s have a more detailed look at the configuration.

General

ProxySetGeneral

The General section is pretty straight forward. You need to give your Proxy Set a name. There aren’t any particular requirements here, so use something that make sense to you. The first part of your SfB pool name is a good choice “LAXSfBPool”, for example. The name of your telco provider is a good choice for connections to the PSTN. For the rest of this post, I’ll assume you’re connecting to an SfB Standard Edition server.

Next you need to specify the SIP interface that your SfB server will connect on.  A SIP interface is a network interface plus a few other characteristics, like what port and protocol the SBC will listen on. The TLS context is the group of TLS settings that you’ll use to talk to your SfB server.

Keep Alive

ProxySetKeepAlive

SfB uses SIP OPTIONS (yeah, it’s capitalized, I’m not yelling) for two purposes. One is to advertise capabilities (“options”) and the other is as a heart-beat or keep alive mechanism. For connecting an SBC to SfB, you’ll want to set the Proxy Keep-Alive to Using Options. There’s a timer for how often you want these sent – the default is every 60 seconds, and you can leave that in place.  The remainder of the variables here are for tuning the specific behavior of your connection if OPTIONS aren’t received, and what criteria need to be met for the connection to be “up” again. Generally, you can leave these alone – I’ve never had to tweak them in a couple decades of doing this stuff.

Advanced

ProxySetAdvanced

The advanced section has only two settings. Classification Input determines whether the SBC will listen to anything from the specified IP addresses (we’ll see that part later) or if the port and transport type – TCP,UDP.TLS  must match too. Go ahead and change this to include Port & Transport Type if you’re super security aware, otherwise leave it at IP address. For DNS resolve method, you can leave this blank to use the global parameter “Proxy DNS Query Type”. You can do some funky things here, but I’ll talk about FQDNs and IPs later when we specify those.

Redundancy

ProxySetRedundancy

This section is where I see the most misconfiguration. For a Standard Edition server, however, you don’t need any settings here, so leave them at their defaults (having them set won’t affect anything, but sure is confusing to look at when troubleshooting).

Proxy Address

ProxySetProxyAddress

This is the spot where you add the FQDN or IP address, port, and transport type for you SfB servers. You can use server FQDNs if you like, especially for more advanced configurations that use the various DNS Resolve Methods in the Advanced section… However, for SfB, most everyone that I know uses the IP addresses of the servers – they’re unlikely to ever change, and using IPs means you’re not dependent on DNS infrastructure. This also guards against changes or deletions of DNS records, though you have other problems if that happens! I always specify the port and transport type, to prevent any gotchas should the system defaults ever be changed.

Next post, we’ll have a  look at the changes that need to be made when you have an Enterprise Edition pool with multiple front-ends, as well as multiple pools. Just for fun, there are some differences in configuration here if you have a gateway or an SBC.

Branch Offices in Hybrid and Online Environments

In my previous two posts, I’ve covered branch office solutions including the SBA and the alternatives. No discussion on branch offices could be called complete without including hybrid environments.

The hybrid conversation is the same as on-prem when your user is homed on-prem and not online. As soon as your user is homed online, you have two seperate considerations

  1. User connectivity to the Cloud for all functions but PSTN
  2. Cloud connectivity to Cloud Connector Edition (CCE), Direct Routing (DR), or On-Premises Call Handling (OPCH)

For the first point, local Internet is what Microsoft recommends. Recall from earlier posts that you can use your router/firewall to direct O365 traffic out locally, and send all other traffic across a WAN, if that’s what your organization requires. If this Internet connection fails, your options are to route across the WAN, a 2nd Internet connection, mobile clients with LTE, or head elsewhere to work.

For the second point, things can get a bit more complex. The routing and high-availability of CCE, OPCH, and DR varies. Other factors will be centralized PSTN breakout vs a more localized approach – you’re more likely to have a business class or redundant connection for a centralized service than if you have distributed services.

Cloud Branches

One common solution that I see a lot of, is a hybrid scenario with branch office users hosted online, and main office users hosted in the on-prem pools. This eliminates the cost and administrative overhead of running branch office solutions, while keeping some infrastructure around for financial, compliance, interoperability with other services/devices and other reasons. Cloud-homed branches are also a great stepping off point when you’re moving a larger organization to a pure online environment.

Pure Cloud Considerations

At this point it shouldn’t be surprising to you that there really aren’t any new or unique considerations for branch offices when your entire organization is cloud based. From a branch office perspective, there’s no local infrastructure different versus hybrid scenarios.

Edge Cases and Wrap-up

In the past couple of posts, I’ve covered branch office considerations for high-availability. The range from SBAs, redundant WANs, redundant Internet, full pools, and more. While comprehensive, I didn’t cover every use case. When considering the solutions that best apply to you, draw up a simplified map of your environment, get a bunch of copies of it, and have at them with a red pen to indicate failure points. Work through these outages using your most important use cases to establish what works, what’s limited or hobbled, and what’s entirely broken. If a scenario doesn’t work for your use cases, put it aside.

You’ll now have two piles – works for me, and doesn’t work for me. Next, review the scenarios that do work, and establish which one best fits your business needs, including pricing. If the mighty dollar sign knocks all of these scenarios out of contention, you now need to sort through the “doesn’t work” scenarios, and work through them to find “the best of the worst” that does the best job of fitting your business needs and budget.

Branch Office Options

In my earlier post, I covered the SBA and what I feel are some pretty significant downsides given the technology changes in the past 10 or so years. So what are the options?

Redundant WAN

The simplest option, from an SfB point of view, is to have redundant connectivity from your branch office to your main office. How you go about this can vary. You could get a 2nd line from the same carrier, but that doesn’t help you if that carrier suffers an outage. A different carrier would guard against that, though watch out for the 2nd carrier simply using the first carrier for all of part of their services. Even with two different carriers, you could wind up with fibre in the same conduit, and you may suffer the dreaded backhoe fading.

Backup VPN

A backup VPN might make more sense. An Internet connection is less expensive, and there’s a good chance that it’s not sharing much or any infrastructure with the WAN link. The first issue to watch out for with VPNs is that you may not have sufficient upstream bandwidth. The second is that you may not have sufficient bandwidth at all. If you are using a lower capacity link as a backup, you can use the DSCP markings that you applied to your SfB traffic for QoS (you did do QoS, right?) to help you out. Your firewall/VPN device can be set to prioritize voice traffic based on these markings, and potentially block video all together.

Use SfB Server Standard Edition instead of an SBA

If redundant connections aren’t feasible, using a Standard Edition server may be. This moves all of your users functionality to their location, preventing the ugliness of limited functionality mode.  However, you now have to license this server, and you’re no longer dealing with an appliance – though you’ll recall that some SBAs were just servers with PRI cards anyway.

More downsides here are that if a user homed on this server hosts a meeting with a large number of participants from outside their office, all of that traffic is going to hit the WAN. Also, if the users in this office work remotely a lot, all of that traffic transits the WAN to reach the Edge servers at the main office…. unless you deploy an edge in the branch office, and now it seems like we’re boiling the ocean and building rocket ships to guard against a branch office WAN failure.

Get Out of the Office

The last option to deal with a branch office outage would be to get out of the office, either virtually or physically.

SfB has excellent mobile clients. If your users are homed in a central office or a datacentre, they can use the mobile clients to connect to their pool over LTE. There may be some limits here, like not being able to be a member of a Response Group, but as a backup option this one is pretty simple, and your staff may all already have company phones or subsidized company phones.

Lastly, the users can find a different place to work. This could be home, it could be a co-working space, or a coffee shop.

What about Hybrid and Cloud?

Finally, if you’re in a hybrid or cloud deployment, I’ll provide some thoughts on how to handle branch offices in the next two posts.

 

Survivable Branch Telephony & The SBA

Skype for Business has long had a survivable branch office telephony solution product, but it’s no longer a good choice in 2018 and beyond. I’m not convinced that it was ever anything more than “the best of the worst”.

Way back in the day, Cisco had a survivable remote telephony option. If your branch office WAN was down, a line card (analog, PRI, or even SIP) in your branch router could get you access to the PSTN. Office Communication Server 2007 R2, the first release in the LCS/OCS/Lync/SfB product to be classifiable as a potential PBX replacement, didn’t have a comparable solution. With Lync 2010, Microsoft introduced the Survivable Branch Appliance (SBA).

SBA Administrative Effort

The intention was that Microsoft partners would build appliances that host the SBA software. A company could ship one of these to a branch office, have an entry level technical person rack & stack the device, and the IT techs more experience with voice would then connect to it remotely and finish the configuration. In reality, that was… challenging. Some initial firmware upgrades required a USB hub, flash drive, keyboard and VGA monitor to be hooked up, so that the “entry level” technical resource could bang their way through a really ugly CLI. Not fun.

In terms of ongoing support, the vendor is responsible for releasing updates for the SBA, including the CU. When Lync 2010 CU4 was released (it enabled the first mobile experience) it took more than 6 months for some vendors to roll out CU4 for their SBAs. Not a great experience, and a lot of my customers abandoned the SBA in order to get their users their mobile connectivity.

Hardware

Depending on the vendor, a PSTN gateway was often included as a module in the SBA. Alternatively, the  SBA was a module in the gateway. The first option offered a chance of decent performance. The second option typically offered terrible performance. It’s simply not possible to shrink Wintel server horsepower down to an itty-bitty interface card size, never mind power it. Often the specs were similar to those of entry level laptops. This really limited performance and capacity, and the higher-end modules are expensive.

If you went for the full-sized SBA with the add-on gateway, you will likely open the box and recognize the device as a rebadged 1U or 2U server from one the standard Wintel server vendors. Don’t those need 4 post racks? Yup. And this is for a branch office, and while some branches have 4 posters, a lot are lucky if they’ve got an 8U wall mount equipment rack.

Feature Loss

Other than being a difficult product to manage, the SBA has some significant drawbacks.

First, the users only use the SBA as a SIP registrar and for backup telephony. All meetings, video, whiteboard shares, response groups, contact list functionality is all in the Standard Edition or Enterprise Edition that the SBA is associated with. If that SfB pool or connection to it is lost, users are presented with a “limited functionality mode”, with no contact list, and only voice capabilities. However, voice calls have to be placed by dialing the full number. No click-to-call, no buddy list, no extension dialing. Yuck. How many users would a) remember what to do to place in call in this mode, and b) actually want to do it, versus doing other things during the outage?

Next, your PSTN connection needed to be to the gateway located onsite with the SBA. Your three options are analog lines, PRIs, or SIP trunks.

Analog lines offer terrible call quality, and don’t offer DIDs. The later is okay if you only need outbound calling and don’t need the call to have your DID as caller ID, otherwise it’s a pretty terrible experience.

PRIs offer good call quality and DID support, but they’re expensive. Fractional T1s offer just a tease of cost reduction. You can pay 20% less for 50% less capacity, if you’d like!

SIP trunks offer good call quality and DID support, and depending on your provider, offer some extra options that PRIs and analog lines can’t support, like redundancy and failover.

Remember that the SBA doesn’t have any functionality other than the SIP registrar and backup calling. It’s likely that when your wan is down, your callers can’t reach Auto Attendant, Response Groups, or voicemail. That’s not a very good scenario, though there are a couple of workarounds – with huge tradeoffs.

Another downside is that typically a user homed on a full SfB pool has failover to a paired pool. With an SBA, this isn’t possible. The user is homed on the SBA, and can only failover to the full SfB pool associated with that SBA. If the SfB pool is lost, they’re in limited functionality mode. If an SfB pool that’s paired with another is lost users failover with that same limited functionality mode, but the administrator can quickly trigger a full failover that restore all modalities and functionality.

So what’s a organization supposed to do?

On the plus side, the SBA didn’t consume an SfB server license. That’s one small plus for SBAs, against a sizable list against. So, what are your options, in a classic on-prem only environment, but also in a hybrid, Cloud Connector Edition, Teams Direct Routing, and mixed SfB/Teams scenarios? Stay tuned!

 

 

 

Surviving the Skype for Business to Teams Transition, for the IT Pro

Okay, so you’re an IT Pro who does Skype for Business stuff, and you’re a bit freaked out by Teams and a reduction in your demand. Worry not! First have a crack at my previous posts aimed at the organization and IT department.

In the organization post, I point out that SfB on-prem isn’t quite dead yet. In fact, it won’t be for a while. Feel free to do nothing, and you should have a number of years of success with SfB on-prem skills. However, if you do that, at some point you’ll find yourself in a career cul-de-sac.  Don’t do that! (But do read Will Rowe’s book, it’s good, and I’m not getting paid to say this). As the book title suggests, you need to evolve or your career will die.

Did you see a ton of stuff in my two previous posts that you could pick up as skills, and stay on top of your game? You should have! If you’re the gal or guy who can confidently answer questions about how Teams works, what a SfB to Teams transition might look like, and how to help navigate your organization or IT department through that, you are in a great spot!

Other than focusing on learning what I’ve already covered, here are some other suggestions for you to consider.

If you’re on on-prem IT pro, get thee to the cloud! Learn the basics of Office 365 and hybrids. You can follow the learning paths for exam 70-346 Managing Office 365 Identities and 70-347 Enabling Office 365 Services. Microsoft is all about the Cloud, and you may find you need hybrid configurations for migrations, compliance, or to appease office politics.

Do you know anything about Azure? Check out this site for a great, uh, Azure overview. You can also get a free Azure account, which gives you no excuse for not expanding your knowledge. While Azure may not be directly related to SfB and Teams, it’s full of Bots/Machine Learning/AI, IoT, and other great stuff that does, will, or could (if you make it) integrate with Teams and drive value. You knowing about this stuff makes you more valuable that someone who doesn’t have a clue how the Bot Framework and what you can do with it and Teams.

Security and compliance are also big deals. GDPR is everywhere right now, and even if you’re not in Europe it can most certainly apply to your organization. Knowing how GDPR (or any other compliance regulations) applies to Teams gives you an edge and keeps you relevant.

Microsoft is Cloud first, Mobile first, which means that anything you can learn about mobile devices and clients will help you. Go find out how MFA (MultiFactor Authentication), Conditional Access, and MDM (Mobile Device Management) and impact not only mobile phones & tablets, but also laptops and boring desktop PCs. If you’re an iPhone user, get your hands on an Android and figure out how SfB, Teams, MFA, CA, and MDM work on the “other” platform. Likewise if you’re an Android user. Only knowing about half the major mobile platforms makes you LESS that half as useful as someone who knows about both.

And lastly, much my last IT department focused post was network centric. If you don’t have your CCNA, consider working towards it. Once upon a time to get your MCSE you had to write a “Network Essentials” exam. CCNA gives you that knowledge and more. You don’t have to be a network guy working on Cisco gear to derive value from the CCNA classes or certification. CCNA is full of background knowledge, and the part that’s “specific” to Cisco gear isn’t that specific since almost everyone copies Cisco’s interface, or is “influenced by an industry standard interface” as I’ve heard one vendor explain it.

The bottom line is that IT evolves, and this is just another evolution. SfB used to be Lync, which used to be LCS, which used to be OCS… Go learn something cool!

 

 

 

Surviving the Skype for Business to Teams Transition, for the IT Department

In my previous post I talked about what I feel an organization should be doing during the SfB to Teams transition. In this post, I’ll cover what an IT department should be doing to support the organization.

There are several things that an IT department needs to consider when moving from Skype for Business Server to SfB Online or Teams. The biggest by far is shifting from servers – and the associated maintenance and operations – to a focus on the network. In particular, we’ve been spoiled by 1G and faster LANs with SfB on-prem. Fantastic network performance on the LAN meant we could run a bit looser, not needing to worry about bandwidth or QoS. With SfBO and Teams, that’s a different story. You should be looking at:

Internet bandwidth – is it enough? Is it symmetric, so that upstream traffic doesn’t suffer?

QoS – While it’s true that the Internet doesn’t do QoS, you can certain have your firewall prioritize traffic based on DSCP values. You should also have it classify and mark inbound traffic from the Internet, so that it’s prioritized by the rest of your network.

Subnets – Like SfB Server, SfB Online and Teams use subnets and their associated locations in a couple of spots: e911/emergency calling locations, and for Call Quality analytics and reporting. If you don’t know your exact subnets (NO SUPERNETTING!), and the areas they serve, start documenting this. If you have subnets that span locations, plan to remedy this. Spanning floors is sorta okay in a small building, but inter-building spanning is a bad thing. While e911 dynamic location isn’t turned on yet (it’s complicated, and involves life safety. And lawyers), you’ll want things ship-shape when it is.

Policies – Teams uses many other O365 services, and they include a variety of policies for things like naming, compliance, and deactivation. You need to understand what these are, and how they work, so that you can support your organization in making sound decisions. And because at the end of the day, if you don’t, you’re the ones who will have to clean up a mess of Teams with bad names and no expiration or lifecycle.

Internet Connectivity – Centralized Internet is a bad thing for Teams and SfBO. This forces traffic from branches to have to transit your WAN ($) to a central Internet breakout, then off to the Cloud. The extra distance traveled also leads to quality issues. Central Internet breakout is sorta okay in a municipal area, worse within a country, and terrible between countries. If your security department is arguing against this, you can always configure policies to allow Teams traffic locally and send Bob and Sally’s web traffic to the central breakout.

Become friends with this webpage that details the URLs and IP ranges for various O365 services.

You should fire up the bandwidth calculator often. And maybe do a Network Readiness Assessment.

How about a handy Network Assessment Tool.

And who doesn’t want Success with Teams? So get started with Skype and Teams!

 

 

 

Surviving the Skype for Business to Teams Transition, for the Organization

By now you’ve probably seen and heard all kinds of rumors, leaks, plans, guidance, announcements, and roadmaps for Skype for Business and Teams. Well, here’s one more! In this post, I’ll focus on what I think organizations should be doing over the next couple of years.

Yup. Years. One of the first things that you should do, is Keep Calm and Skype (for Business) On. There is no “end of life”, “sunset” or “get off or else” date for SfB.

If you visit the Microsoft product lifecycle pages, you can see that SfB Server 2015 is in mainstream support until October 2020, and extended support until October 2025. We know that Skype for Business Server 2019 is coming later this year, and that’ll take you a few more years out for mainstream and extended support. At Ignite last year, an attendee asked if SfB Server 2019 was the last planned version, and the response was that was “unlikely”.

If you’re looking at SfB Server 2019, be aware that there are a few changes. Alas, the list of changes keeps changing, so until the product is finalized there will continue to be some speculation. You can view the Ignite announcement from last year as a general guide to what to expect, though it has been announced that Standard Edition will be available for SfB Server 2019.

So what kind of things should an organization be thinking about then? Well, in case you’ve missed it, Microsoft recommends that you pilot Teams. I have to agree. I was iffy a year ago, but the product has seen massive feature updates since then, with many more to come. The collaboration experience of working within Teams is entirely different that other application and platform combinations from Microsoft and other parties. I find myself spending more time in Teams. If you’re not currently piloting teams, check out https://teamsdemo.office.com and then start your evaluation.

Teams features compliance, security, extensibility, collaboration and mobility stories that are unmatched by other platforms.

If you’re wondering when Teams will have all of the features that you current get in SfB Online, check out this page.

If you’re looking for guidance on how to pilot Teams, this is the spot along with this page.

And if user adoption is important to you (that’s a rhetorical statement! User experience, training and adoption are key!) follow Karuana Gatimu on twitter. Karuana is the Patterns, Practices & Adoption PM in Microsoft Teams, and is a wealth of knowledge.