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.

Is this the end of Exchange UM?

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

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 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.


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

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 – PSTN number as a Response Group IVR Destination

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:


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

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

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