Published: July 28, 2020
, Updated: July 28, 2024
How to Connect Microsoft Teams and Cisco Webex Teams While They Share the Same Domain Name
Overview
Over the past few months, an unprecedented shift has rocked the business world: remote work. Once considered an employee perk, remote working has now become an absolute must-have for business continuity.
As companies shut their offices, millions of workers are working from home. For many workers, this is their first time doing so, causing them to change and adapt their working habits.
The multitude of different team collaboration platforms, such as Microsoft Teams and Cisco Webex Teams, within employees’ own companies, as well as their business partners’ organizations, creates a unique problem for remote workers: how to navigate not only work from home (WFH) but also remote collaboration in a mixed environment.
According to a recent survey by NextPlane, 79% of IT professionals stated that their companies are operating in a mixed collaboration environment, which can include legacy UC platforms such as Microsoft Skype for Business and Cisco Jabber.
Also, almost two-thirds of IT professionals report that collaboration platforms are the de-facto tools for communicating with colleagues inside or outside the enterprise. With user-friendly features like file sharing, group conversations, powerful search, and application integration, workers are shifting the bulk of their day-to-day communications to new collaboration tools.
Also, nearly half (49%) of respondents said that the bulk of their communication with users outside their company is shifting from email to team collaboration platforms.
For mixed team collaboration environments to deliver the same seamless functionality as email, users should be able to share presence status, send messages, participate in each other’s Teams or Spaces, or share files, without leaving their preferred clients.
However, the intracompany federation in mixed team collaboration environments remains a problem. Also, it becomes even a more complicated problem when Microsoft Teams and Cisco Webex Teams need to share the same domain.
There are two reasons why the intracompany federation with domain sharing does not work. The first one is interoperability. Microsoft Teams and Cisco Webex Teams do not interoperate.
Second, Microsoft and Cisco do not allow their platforms to share the same domain names with other platforms. As a result, each platform treats the chat and presence messages sent to the other platforms users as local traffic. Thus, neither platform routes the messages to the other platform.
To avoid collaboration silos, most companies first try to put their users on both platforms. As a result, each user gets a Microsoft Teams and Cisco Webex Teams client application on their device.
This option is cost-prohibitive. It requires buying two licenses per user, one for Microsoft Teams and another for Webex Teams. Also, aside from the cost considerations, it is a productivity drain, where end-users must learn two very different systems for messaging, scheduling meetings, participating in group conversations, making voice and video calls, while dealing with the challenges of remote working.
To communicate with suppliers and customers, most companies resort to guest accounts.
Currently, 44.2% of organizations rely on guest accounts to enable external access to their own team collaboration instances or to allow their own employees to use external team collaboration apps to connect with partner organizations.
There are two critical issues with guest accounts: security and access control, and licensing consideration. For more information on guest accounts, you can read our blog post on comparing guest access policies and management of Microsoft Teams, Slack, and Webex Teams.
Increasingly IT departments realize that two client applications on their users’ devices, as well as managing guest accounts for external users, can become a daunting management task for IT.
NextPlane offers intracompany federation between the different platforms that need to share the same domain. As a result, the users of Cisco and Microsoft platforms can send messages, share their presence status & files, and participate in Teams and Spaces without leaving their respective client applications. Also, external contacts can do the same without leaving their preferred tools.
The video below shows how seamlessly two users on Microsoft Teams and Cisco Webex Teams can direct message each other without leaving the respective client applications.
Case of DynaCorp
In this case study, we will review the case of DynaCorp, a large manufacturing company with a 50,000 global workforce. DynaCorp has two primary collaboration platforms: Microsoft Teams and Cisco Webex Teams.
Given the business uncertainty, the DynaCorp executive leadership wants its employees that are working from home to communicate and collaborate seamlessly. Instead of clunky emails, employees should connect in real-time through direct messages. Instead of calling colleagues and hoping that they pick up, they can check a coworker’s presence and see if they are on a conference call or not.
DynaCorp management also wants to forge similar presence-based communications with DynaCorp’s suppliers and customers.
As a result, Microsoft Teams remote users on @dynacorp.com should be able to communicate with their colleagues on Cisco Webex Teams, who also are on @dynacorp.com, and vice versa. They should also be able to direct message and share channels with suppliers and customers that have Microsoft Skype for Business Online, Microsoft Skype for Business Server, Slack, and Cisco Jabber.
To make their executive management’s vision a reality, DynaCorp’s IT must overcome two challenges. First, Microsoft Teams and Cisco Webex Teams do not interoperate. As a result, users on their platforms are not able to share presence status, exchange direct messages, participate in each other’s Teams or Spaces, or share files.
Second, Microsoft and Cisco do not allow their platforms to share the same domain names with other platforms. As a result, each platform treats the chat and presence messages sent to the other platforms users as local traffic. Thus, neither platform routes the messages to the other platform.
Finally, dynacorp.com is a registered Microsoft Teams domain, so the federation between DynaCorp’s Cisco Webex Teams and its external partners on Microsoft Skype for Business Online would not work. Why? Because Microsoft SIP Interoperability Gateway treats that traffic as local and tries to route it to dynacorp.com‘s Microsoft Teams. As a result, the users on Cisco Webex Teams can initiate chat sessions with their colleagues on Skype for Business Online. However, the users on Skype for Business Online cannot direct message the Cisco Webex users.
To achieve the dual of objectives of fostering internal collaboration in their mixed environment and establishing a real-time relationship with customers and suppliers, DynaCorp’s IT considered the following options:
- Guest accounts—providing external users with guest accounts
- Two clients solution—putting both Microsoft Teams and Cisco Webex Teams client applications on each employee’s device
- Moving either Microsoft Teams or Cisco Webex Teams to a different domain
- Account and message syncing
- NextPlane Intracompany Federation with domain sharing services
In evaluating the above options, DynaCorp IT looked at costs (including hidden fees), security, management, and impact on end-user productivity.
Guest Accounts
The password policy for external Webex Teams accounts only requires letters and numbers and does not include Two-Factor Authentication (2FA). Also, it is nearly impossible for DynaCorp IT to control whether accounts have strong security measures such as password complexity check, password expiration, and Two-Factor Authentication (2FA).
Also, the number of guest accounts DynaCorp can extend is limited by the type of their license. Microsoft Teams only allows five guest accounts per paid Azure AD license. In the case of Cisco Webex Teams, it requires the Cisco Webex Control Hub Pro Pack edition for an additional $30.00 per user/month to manage Webex Teams’ external accounts.
This option requires buying 50,000 additional licenses from Cisco and Microsoft. Aside from being costly, DynaCorp management felt that making their end-users learn two different clients while dealing with the challenges of remote working would be too much.
Placing one of the platforms on a separate domain
IT management rejected placing either Microsoft Teams or Webex Teams on a separate domain as it would be too disruptive and require changing email addresses, etc.
Account and Message Syncing
DynaCorp IT looked at solutions that sync messages between Microsoft Teams and Cisco Webex Teams. But these solutions required DynaCorp to:
- Buy additional licenses and create users that are on Microsoft Teams on Cisco Webex Teams and vice versa. These licenses are required to bind and relay the traffic across the platforms.
- Provide and store the elevated privileged administrative access to Cisco Webex Teams and Microsoft Teams platforms.
- Store the DynaCorp’s list of users on their servers.
NextPlane Intracompany Federation with Domain Sharing
After reviewing all the other options, DynaCorp selected NextPlane for its internal and external federation.
Unlike the other options, NextPlane offers a single solution that allows DynaCorp’s Cisco and Microsoft users to share their presence status, send messages, files, and participate in Teams and Spaces without leaving their respective clients. Also, external contacts can do the same without leaving their preferred client applications.
To solve the problem of intracompany federation with domain sharing, NextPlane uses the API-based federation that acts as a secure interoperability hub between the Microsoft Teams and Cisco Webex Teams platforms.
As a result, Microsoft Teams users with username@dynacorp.com IDs can communicate with their username@dynacorp.com colleagues on Cisco Webex Teams as if they were on the same platform.
NextPlane also allows both Microsoft Teams and Cisco Webex Teams users to connect with external partners that have Microsoft Skype for Business Online, Microsoft Skype for Business Server, Slack, or Cisco Jabber.
NextPlane uses bots to act as proxies for external contacts on Microsoft Teams. NextPlane generates them in the NextPlane’s Microsoft account. The NextPlane Microsoft Teams bots act as proxies for Cisco users and provide NextPlane ConverseCloud with the ability to exchange messages through the Microsoft Teams Channel.
For Cisco Webex Teams, NextPlane creates user accounts to act as proxies for Microsoft users.
The NextPlane Apps are not executable code. They are registrations of NextPlane ConverseCloud within DynaCorp’s Microsoft Teams and Cisco Webex Teams infrastructure. These registrations provide NextPlane ConverseCloud with access tokens to call the Microsoft Teams & Cisco Webex Teams API methods and listen to events on behalf of the NextPlane bots.
DynaCorp’s Microsoft and Cisco users need to install the nextplane App to their respective client applications to be able to:
- Invite and add each other and external contacts
- View external contacts’ profiles
- Share presence
- Send direct messages with rich text, GIFs, and emoji reactions
- Share files (coming soon)
The NextPlane apps for Cisco Webex Teams and Microsoft Teams are available from https://bots.nextplane.net/:
NextPlane had zero impact on DynaCorp’s employees and contractors. They could stay on their preferred applications and add their colleagues as new contacts to share the presence status, exchange messages, participate in Teams and Spaces, and share files.
Finally, by using NextPlane, DynaCorp can also federate with external partners on Microsoft Teams, Skype for Business Server, and Slack. External contacts on Slack and Microsoft Teams need to install and use the nextplane App for their respective client applications.
The table below shows external federations for Microsoft Teams and Cisco Webex Teams.
* Using NextPlane Domain Virtualization
Sign Up for a Newsletter