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

Posted on by
1

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

Posted on by
2

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.

Is this the end of Exchange UM?

Posted on by
Reply

In a post on the MS Exchange Team blog, the Exchange team lays out alternatives to a service that is being discontinued. The service in question is using a SBC (session border controller) to connect a 3rd Party PBX (Avaya, Cisco, Mitel, anything not SfB) to Exchange UM online. The sunset date for this service is July 2018. The alternatives listed were to move to SfB, use an API, or to use a different voicemail system.

A couple of days ago, an update was provided that indicated that the 3rd option, to use an API, was no longer recommended. After some time, the wording was changed to indicate that it was only recommended as an interim solution. A little bit later, the post vanished. Throughout, there was anger and confusion expressed online over the change in guidance, and the lack of notice provided. Some people have since reported that they’d be informed that the post was an error.

What are we to make of this? First, if the post was in error, I find it challenging to believe that the content was in error, vs the timing of the post.

I say this, because Exchange UM is going away. Let’s look at the facts:

  • SfB is the #1 voice platform that uses Exchange UM. SfB Online has its own voicemail platform now, including auto-attendant functionality.
  • I went looking to see the last time a feature was added to, or updated in, Exchange UM. I went waaaay back, far enough back that I was convinced that the Exchange team would really appreciate it if someone could take UM responsibility off their hands.
  • According to https://products.office.com/en-us/exchange/microsoft-exchange-server-licensing-licensing-overview users should have an Exchange Enterprise CAL to utilize Unified Message. For organizations who only needed the license for UM, this was a tough payment to make.

The leaked/early announcement that 3rd Party PBX support via API was no longer recommended is, to me, the nail in the ExUM coffin. If the only recommended solutions from the Exchange team are “move to SfB” and “go find another voicemail platform”, then I can’t see that ExUM is sticking around.

Getting rid of Exchange UM online is a huge task. Microsoft is slowly chipping away at the number of organizations doing 3rd party integrations, to make the eventual service termination have the least impact possible. Providing this kind of guidance before service termination plans are finalized and announced is smart. It allows Microsoft to track their success in reducing the use of the services. If the use of the services is too high, they can adjust the messaging and deprecation tactics to increase the number of organizations pursuing alternatives. Dates for service termination can also be adjusted much more easily on internal roadmaps that haven’t been announced.

I expect that we’ll see more details once the specific features for SfB Server and Exchange Server 2019 are released, though online roadmaps may have a different timeline than their on-prem counterparts.

Microsoft did provide one year of notice before the planned retirement of the “SBC to Exchange UM” solution. While I expect at least a similar amount of notice before the loss of all 3rd party connectivity to Exum, I would also expect to see a block put in place on new organizations using this functionality, while those using it are encouraged to find alternate solutions.

If you are an organization with a 3rd party PBX and you are using Exchange UM online, you should be proactive and consider your possible next steps now. Don’t wait for Microsoft to re-post this announcement, you’ll only have less time to plan.

If you are an organization with a 3rd party PBX and you’re considering using Exchange UM online, you should move quickly to avoid any block that may be put into place. You must also consider this as an interim solution while you migrate to another (like SfB) lest you suffer the indignity of having to migrate off of a solution that you’ve just rolled out.

In either case, there’s no need to panic, but you do need to make sure you’ve got this on your roadmap. You can keep an eye on here for updates on this, as well as the pending 2019 release of SfB and Exchange.

 

TLS 1.2 and Skype for Business

Posted on by
Reply

By now you’re probably heard a lot of grumblings about the insecure nature of TLS 1.0 and and 1.1, and that everyone should be moving to TLS 1.2. Let’s talk about TLS 1.2, SfB, Office 365, and related things.

What’s TLS?

TLS stands for Transport Layer Security. TLS is the successor to SSL, Secure Socket Layer. You can read a nice multi-part overview of SSL/TLS here
that includes details on vulnerabilities and attacks. In a nutshell, TLS is the protocol used to encrypt your stuff.

The challenge

IT has an ongoing challenge of ensuring that related systems are at compatible levels. With TLS, the idea is to enable TLS 1.2 AND disable earlier, less secure versions. It’s plain silly to leave the less secure versions enabled, unless you’re still in transition to TLS 1.2 and need the lower levels for compatibility.

About PCI Compliance

When people say PCI, they probably really mean PCI DSS, or the Payment Card Industry Data Security Standard. These are the rules that credit card processing companies say you need to follow. They’re a good read, and probably worth following even if you don’t process payments via card. You can read more here https://www.pcisecuritystandards.org/

SfB and TLS

At present, SfB does not support TLS 1.2. Microsoft is late to this party. You can expect an up-coming update to permit SfB to run on TLS 1.2 with less secure levels disabled. A word of caution however – if you have third party software for something like a call center, user/number management, e911, or whatever, make sure that it also works in a TLS 1.2-only environment.

LPE

LPE is Lync Phone Edition, the software and hardware standard for the previous edition of phones. Common model numbers are the Polycom CX500, CX600 and CX3000. HP and Aastra also make some models. All LPE phones run the same software, based on a super old version of Windows CE. This version does NOT support TLS 1.2, so if you need to run only TLS 1.2 now, your LPE devices need to be replaced. There was rumour in the past that Microsoft was looking at updating the LPEs to be able to run TLS 1.2, however I’ve not seen any official word or any updates that they’re still looking at the issue.

PLEASE don’t be one of those organizations that buys a pile of cheap used LPEs. You’ll only regret it when you have to replace them, deploy a new phone management solution, and retrain your users.

O365

There is a tonne of material on Office 365 TLS 1.2 here  that you should review. While this article is relatively short, it’s chock full of links to more detailed resources.

More SfB and TLS 1.2 news here when it’s available…

Office Online Server/Office Web App Server Pool Certificates

Posted on by
Reply

I’m working on a deployment that’s using a farm of OOS servers behind a load balancer (actually, behind a high-availability pair of load balancers!) for high-availability. If you’re just using one server, this is a great guide to what you need to implement. If you’re using a farm with 2 or more servers behind a load balancer, there are a few more considerations.

To start with, the subject name on the certificate needs to be the URL that you’re defining in the SfB topology. You might use oos.example.com, for example. Now the fun part – the first SAN listed on your certificate also needs to be oos.example.com.

Everything will work at this point, but you don’t have a very good high-availability story. The load balancer will need to be configured to monitor each server in the farm to determine if the server is functional. Otherwise, a server could stop functioning and the load balancer would continue to send traffic to it – that’s no good. The load balancer will most likely monitor the servers by trying to access https://oosnode1.example.com/hosting/discovery (and the same thing for oosnode2, etc.), and watching for a 200 OK to be returned.

Most load balancers have setup wizards that will set the monitoring up for you as part of the configuration process for OOS, SfB, Exchange, SharePoint, and more. Check the vendor’s website.

In order for the HTTPS request to oosnode1.example.com to success, oosnode1.example.com needs to be a SAN on the certificate. The same holds true for the other servers in the farm.

You could cheat and monitor your OOS servers by using HTTP and thus not require a certificate. This is a bad thing to do. You should be monitoring the actual URL that will be accessed on the server for a true indication of the server status.

To summarize, your OOS certificate needs to have:

Subject Name (SN) of the URL you will use in the SfB topology, such as oos.example.com

The first Subject Alternate Name (SAN) needs to be the same as the SN.

Then, you’ll need a SAN entry for each server in the farm, such as oosnode1.example.com and oosnode2.example.com.

 

 

Teams And SfB, (oh my) but no Lions or Tigers

Posted on by
Reply

Ignite 2017 has wrapped up, and for those interested in Skype for Business and Teams, it was either exciting or frightening. Microsoft is very definitely about to unleash a bump in the net, but there’s no reason to be afraid!

Over the next couple of posts, I’ll recap what was announced in the SfB and Teams space at Ignite – and since Ignite, then I’ll cover what this means for organizations using, or thinking about using, SfB and Teams. Finally, I’ll wrap with a bit of a strategy for IT Pros who might be wondering what just hit them, and what’s next.

Teams is NOT Replacing Skype for Business. (Yet)

There was some discussion prior to Ignite, fueled by an accidentally-released banner message for some Office 365 users, that Teams was replacing Skype. For some, panic ensued. The reality is that Teams is not capable of replacing Skype for Business, and as there is no Teams server for on-premises deployments, Teams could not replace SfB on-prem.

Presentations at Ignite and in the roadmap released shortly after, made Microsoft’s intentions clear: while Teams is the future of Microsoft’s “Cloud first, Mobile First” strategy, Skype for Business is not going away.

Skype for Business Server Roadmap

The next version of on-prem SfB, Skype for Business Server 2019, was announced at Ignite. The highlights of the next version are:

  • There will only be one edition, with Standard Edition being eliminated.
  • There is no director role.
  • There is no PChat role.
  • Only Server 2016 and SQL Server 2016 will be supported.
  • No in-place upgrades.
  • Upgrades from 2013 and 2015 are supported, and as in the past, only two versions are supported in an environment.
  • The 2019 client will be C2R only, no more MSI

SfBS 2019 is based on the SfB Online code, which will allow for a significantly improved hybrid interoperability story. This is also likely behind some of the role removals outlined above.

For Teams, the roadmap announced in late October is all about driving toward feature parity with Skype for Business, including:

  • Better IM chat controls
  • Contact Groups
  • Unified Presence between SfB and Teams
  • Federated Chat
  • Tonnes of updates to the meeting experience
  • Most SfB calling features brought to Teams
  • Support for calls between Skype Consumer and Teams

You can see the full roadmap here

Up next: Guidance for organizations.

Main Number Handling – PSTN number as a Response Group IVR Destination

Posted on by
Reply

In my last post, I covered how to have a Response Group Queue overflow/timeout action send a call to a PSTN number. That means you can send a call to an analog phone (maybe a cordless one), a mobile, or any other PSTN number. That’s awesome for overflow and timeouts, but there’s still a hole in Response Group functionality: how can an IVR option deliver a call to a PSTN destination?

Every once in a while, you need to get creative in your solutions to meet end-user requirements. The solution here is tricky to figure out, but simple to configure once you know what to do.

To review, a Response Group IVR is when someone calls a workflow number, hears options, and presses a corresponding key. The native workflow options are to deliver the call to a Queue, or to ask another series of questions. There is no option to deliver a call to a PSTN number.

If we look deeper at the Queue configuration, the only place to specify a PSTN number is in the overflow and timeout options. If we could set the workflow to deliver a call to a Queue, and set the Queue to overflow immediately to a telephone number, we’d be set. We can do that by setting the Maximum number of calls in the Queue configuration to zero:

Queueoverflow0

And if you try the call, it will not work. As it turns out, a Queue will error out if there is no Group assigned to the Queue. The fix is simple: create a user in AD, enable them for SfB and enable Enterprise Voice, create a new Response Group group and assign the new user as an Agent. Assign that Group to the Queue:

Group in Queue

And things will work – a call to the IVR, where the caller selects the option for the mobile number, will be forwarded to that mobile phone immediately. The Queue process throws an error when it see there isn’t a Group with at least one Agent assigned, it never gets far enough in the process to look at the overflow options.

I don’t recommend that you use a real user’s SfB account for this. Create a fake account, and make sure you add comments or notes to indicate the purpose of the account, so that it’s not deleted or changed.

If you’re going to use this solution for a number of different workflows, you can use a more generic name for the User and Group, and use the same User and Group for all the Queues, as the destination is configured in the Queue.

 

 

Main Number Handling – Putting it all Together, Response Group Calls to a non-SfB number

Posted on by
Reply

A few years ago, I worked with a two different organizations who had the same scenario.  They had a main number for the security department. This number was for a Response Group Workflow, which would ring the security staff and a couple of additional phones in the security area, such as the break room.

That worked well when there was someone in the security office to answer the call, but it meant that calls would go to voicemail if there were no security staff in office. This happened often, especially in the one organization that was closed at night and the security staff member had to do patrols.

The solution for both was to setup the Response Group Queue timeout and overflow actions to “forward to telephone number”:

call action PSTN

Note the formation for the telephone number – you need to enter it as if it’s a SIP address, with your SIP domain after the @.

Yes, all of my lab environment domain names are colors! I set the desktop background of all the servers to be the domain name color, which helps me stay straight on which environment I’m connected to.

Okay, that’s cool, we can forward calls to a mobile or analog or any other phone as a timeout action on a queue. Tune in next blog post, where I show you how to send a call to any PSTN destination from a Response Group IVR.

Main Number Handling – Putting it all Together in Large Offices, reception coverage

Posted on by
Reply

In the previous post, I covered how to have a receptionist have first kick at answering a call, then for the call to be handled by an Auto Attendant if they weren’t available. You might want to have a backup for the receptionist if they’re not able to answer the phone. The easy solution is to also add this person to the Response Group group as an Agent. The trick here is to specify the two agents, and set the Routing Method to Serial in the Group configuration:

Serial Agents

Wit this setup, calls will always first ring “AApple”, then after the Alert Time has expired, the call will go to “BBlueberry”, and finally to the overflow destination. Be sure to watch your Queue and Group timers as discussed here to make sure your call doesn’t bounce around between the users.

This solution works well if you only need a main person and one backup. If you need a main group and a backup group, you would configure two groups, and then create an ordered list in the Queue settings:

Reception Queue

Make sure that the sum of the Group timeout values equals the Queue timeout value, otherwise your call with ring “Reception_Main”, then “Reception_Backup”, and then “Reception_Main” again. For example, I might set the Reception_Main group to 10 seconds, the Reception_Backup group to 15 seconds, and the Queue timeout to 25 seconds.

You can include the users in the “Reception_Main” group as agents in “Reception_Backup” if you want the users in the main group to be able to answer the call if it’s ringing the backup group.

I’ve seen this approach used for a shipping/receiving door buzzer. The driver pushed the door buzzer, which automatically dialed the Response Group (this behaviour was configured in an AudioCodes MediaPack). The Response Group had the shipper/receiver as the main group, and then some other nearby staff who could act as their backup.

Up next: Sending a call from a Response Group to a PSTN or other PBX phone

Main Number Handling – Putting it all Together in Larger Offices

Posted on by
Reply

I previously covered some simple solutions for main number handling for smaller offices. Now let’s have a look at larger offices.

I’ve worked with several organizations that prefer a human voice answer the phone wherever possible, and when that can’t happen they would allow the call to handled by an Auto Attendant.

The simplest way to configure this is to have the main number be a response group workflow. The receptionist is added as an agent. In the Queue, set the timeout (and optionally the max calls) overflow destination to the SIP address of your Auto Attendant. Callers now ring the agents when they first call, and then get the Auto Attendant if no agent can take their call.

Up next, some scenarios where you might want to add a second group of agents.