The Microsoft Office suite of clients offers integration with the default chat app, historically Skype for Business. This allows a user to interact with other users on that platform from within the office application, typically when co-editing, but largely throughout Outlook in features such as contact cards.

When you’re in a migration scenario, especially if you’re in Islands Mode, you’ll want to have Office pick one client over the other. You do this from within the Teams Client.

Click on your photo in the top right, then settings, then tick the box shown below:

And once you’re done this, make sure you restart Office. You may also need to wait a few minutes for the setting to take effect.

Note that if you switch to Teams-only mode, this setting is asserted for you – no need to manually configure it.

It’s not uncommon to have some combination of Skype for Business, Teams, and other PBXs in an organization, especially during migrations. One of the most challenging aspects in a scenario like this is maintaining call flow inbound from the PSTN, to the correct destination.

The magical way of doing this is to have contiguous blocks of numbers move from one platform to the next. In the real world, this almost never happens. That leaves us with the ugliness of static routing with a ton of rules to match the various number ranges and exceptions to them, or seeking some automated routing method.

One automated method is to have the SBC do a lookup in Active Directory, or some other LDAP directory. The SBC performs a lookup for the called number in a certain field, and can then look in a related field for that same user to understand the destination it should route the call to.

When a user is homed on a Skype for Business server, there phone number (lineURI) is stored in a field called msRTCSIP-LineURI. When an organization has just SfB server and another phone system, this allows for an easy “yes/no” decision. When there are multiple other phone systems, this task gets more challenging, as none of these other phone systems have a field like msRTCSIP-LineURI. This, by the way, includes Teams, which is rather ignorant of AD given that it’s a cloud platform.

There are a couple of solutions to this challenge. The first is for you to administratively populate the phone number and some sort of routing code/PBX identifier into unused fields in AD, AAD, or another LDAP platform. You can (but shouldn’t, yuck!) do this manually. Instead, populate these fields with scripting or another automated process. Now you can perform lookups and routing decisions based on the details that you’ve populated. However, you’ll need to keep these fields up-to-date with any adds/moves/changes to users and their numbers. This could mean that a user won’t receive their calls to the appropriate system until after an update completes.

A quick-and-dirty solution to this problem is to insert a series of alternate routes at the bottom of your routing table, that will try each of your phone systems in sequence, and if they receive a “404 not found”, they’ll roll to the next system:

At first glance, this table seems to duplicate things – why do we need row 5 sending to the Avaya system if row 3 sends to Avaya? We wouldn’t, if row 3 was always able to receive up-to-date, perfectly synchronized lookup data, and there were never any system errors. That’s not reality though, so placing rules 5-7 at the bottom to simply brute-force try all the systems is a nice catch-all.

The “dirty” part of this “quick-and-dirty” solution is that the SBC logs will see the 404 failure each time these rules are used. You’ll need to tune your systems to not throw alarms and freak out due to those, and you’ll need to do a bit of extra work when you’re doing any syslogs or call traces. Of course, a spike in the appearance of 404s in your logs indicates something broken, so don’t ignore them completely.

The noise of all of these 404 entries is also why I’d never recommend only using this type of logic in a production environment. Performance really doesn’t take a hit, but good luck trying to troubleshoot calls when all you can see in your traces is 404s. However, doing pure brute-force can be useful during a rapid migration where LDAP lookup results will never stay in sync. You can also shift the priority of your rules in such a scenario so that the system likely to receive the most calls is at the top of the routing list.