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.

Office Online Server/Office Web App Server Pool Certificates

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

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 – Putting it all Together in Large Offices, reception coverage

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

Outbound Caller ID Overrides and Anonymous Calling

A common request that we get is to mask or change the caller ID of an outbound call. This might be because the caller is a VIP and doesn’t want to be harassed, or they might be a support rep and any returned calls should go to a queue or main number. You might also be calling from a number that doesn’t belong to the carrier you’re sending the call over. There are a handful of ways to handle this scenario in SfB.

Using a number that doesn’t belong to the carrier you’re sending the call over can have some odd results. They may allow it, they may block it, or they may override it with another number, usually your billing telephone number (the “BTN”) for the trunk. The BTN is usually not taken from a customer’s block of DIDs, may not have a caller ID string or 911 address associated with it, and typically is not assigned to any endpoints, so sending the BTN as the caller ID won’t help anyone that you’re calling.

You can use the “Suppress caller ID” and “Alternate Caller ID” on a route  to set a number of your choosing. This would apply to all calls using  this route. If you want to override some users’ numbers and not others, you’ll need a of duplicate your voice policy, usage, and route, and then set the override on one route. Repeat this exercise if you have different users that need to send a different number. If you need more flexibility than this, check the other options. On the plus side, this solution doesn’t care which trunk/gateway the call is routed to.

A Trunk Translation rule gives you more flexibility than the alternate Caller ID solution. You can set a series of translation rules using regular expressions on the Trunk Configuration (you could cheat and do so globally if you’re in a small organization, but you’ll just wind up undoing and redoing all of your work if you expand).

The use of regular expressions means that you can easily handle multiple translations per trunk without needing all those extra voice policies, usages, and routes. You also get the flexibility of regular expressions to match and change only certain parts of a number and leaving the rest, like 236-551-xxxx to 236-555-xxxx.

If you have multiple trunks/gateways, you’ll need to configure appropriate rules on all of the gateways.

Trunk Translation is generally seen when performing Least Cost Routing (aka Toll Bypass), such as when a user from the UK calls a number in New York. The New York telco may not like the UK number, so you can configure translation rules so that the call appears to be from the New  York office. You lose the personal DID of the caller, but the call will go through. I’ve also used this when a different carrier is providing a backup trunk, and they won’t allow the numbers from the first carrier.

The two above options are configured by administrators, are generally deployed because of telco requirements, and aren’t very flexible. It’s possible to use some other calling features to allow your users to be in control.

Delegation, also known as Boss/Admin, allows an assistant to answer calls and place calls on behalf of their boss. This functionality can be used to allow a user to selectively mask their number with another, when they choose. I’ve typically seen this setup for VIPs, when they want the recipient to see some alternate number – maybe there assistant, or an auto attendant.

To implement this, you’ll need to setup a dummy “boss”. Delegate the dummy boss account to the real boss. Now the real boss can place calls as the dummy boss. Next, if you don’t want returned calls to simply get a busy signal or dummy boss’s voicemail, setup the dummy boss to forward all calls to the assistant, or the auto-attendant.

Don’t setup delegation between a boss and their assistant to be two-way. Weird things can happen!

The gotchas with this solution are mainly around client support. Not all clients support calling on behalf of someone else, especially mobile.

You can also use a Response Group that’s configured to have Agent Anonymity. This gives users who are agents in that Response Group to place calls on behalf of the Response Group. See my Main Number Handling posts on Response Groups for details on how to do this. This solution has even more limitations that the Boss/Admin option above. Client support is limited to the Windows client, and your users will need to be homed on the same pool that the Response Group is homed on. This is a good solution is good if the users are already agents in the Response Group (such as on a helpdesk), but otherwise I wouldn’t bother with this one.

And lastly, Ken Lasko outlines how to implement *67 in Skype for Business here.

If you’ve got any other solutions for number privacy, hit me up in the comments!