As a Microsoft Gold Communications partner, we’ve had a long history of implementing Microsoft communication solutions into our clients’ business practices. Spanning back to LCS and Office Communicator, through the evolution of Lync and Skype for Business, and now to Microsoft Teams, we’ve worked with each iteration of Microsoft communication technology and have learned the nuances of implementing each new solution correctly.
As a pure Unified Communications solution, Skype for Business was fairly straight forward with architectural decisions (on-premises vs, cloud-based, high availability architecture, etc.) and functionality (IM/Presence, Web Conferencing, PSTN Conferencing and Calling). These conversations are relatively easy to have with business leaders and technology departments; there was minimal risk in providing these solutions to all departments, as they provided valuable feature sets with little security risk or day-to-day administrative requirements.
With the enhanced feature set that Microsoft Teams provides, there are many more questions that need to (or should be) answered before implementation. Based on its integration into other Microsoft and third-party applications, businesses must develop a much more involved strategy that addresses key questions before enabling users to customize their environment and potentially put the organization at risk of security incident or lack of data governance.
For organizations thinking of implementing Teams, here are a few areas that need to be addressed to ensure a successful implementation for their organization.
Teams and Channels Naming Scheme
The teams and channels within Teams are the biggest differentiator between Teams and Skype for Business. These enhanced collaboration features provide users with an organized set of the conversations and files they need to access and collaborate with.
The challenge can be creating a single, organized policy for all departments and users that allows them to collaborate without duplicating groups. For each new Team that is created, by default it also creates its own Office 365 Group, with a shared mailbox, and underlying SharePoint site for storage. These are a lot of changes to your cloud architecture that can create a lot of sprawl if users are constantly creating Teams when others that suit the same purpose already exist.
Furthermore, for organizations that have existing SharePoint Online deployments, this can create confusion for users as to where they should store documents, so building out a plan is essential for conveying the standard operating procedure.
The naming scheme itself is important to consider, and we advise organizations to build a Teams standard operating procedure users must follow, and depending on the business, a formalized process for requesting/approving/creating Teams outside of the typical departmental structure. Organizations can use Templates if their needs are simple, and may add more customization if available options don’t fit their needs.
External Collaboration (Federation, External, and Guest Access)
With Skype for Business, external communication was pretty straight forward; through federation, companies can lock it down to allow no external federation, open it up to all external federation, or allow approved organizations to federate for external communication.
With Teams, this is completely different. Teams has the External Access for when you need to let external users in other domains find, call, chat, and set meetings with your users. This also allows for communication between Teams and Skype for Business users but does not allow any external user to access your organization’s Teams or Channels. External access gives permissions to an entire domain, but Guest Access gives access permission, with additional capabilities to an individual.
If the goal is to collaborate with external users and work with them in the Teams and Channels, then Guest Access is the way to go, but this opens up more questions to consider.
- What capabilities do we want to give to guests? (calling, meeting, and messaging, etc.)
- How do we control who we give guest access to?
- Can users invite guests?
- Do we have an approval process in place for granting access to guests?
- What criteria do we want to have for guests we’re granting access to?
These can often have big implications, which make them difficult questions to answer.
For example, I have clients with internal SharePoint Online environments they don’t want anyone outside of the organization to have access to, but at the same time have contractors they want to invite to Teams for specific projects with the ability to collaborate in these spaces. This inherently causes conflicts, as Teams leverages SharePoint on the backend for collaboration, so carefully answering these questions and configuring permissions is essential to this success.
Another huge concern with Guest Access is security. Organizations typically have a security standard for internal domain-joined systems (ensuring a certain OS version is installed, patches are kept up to date, enterprise-grade Antivirus software is installed and up to date, etc.). When granting guest access to Microsoft Teams, you are opening your Office 365 tenant to individuals and systems you don’t control. How do we ensure our environment is safe in the event that that guest user knowingly or unknowingly uploads a malicious file to your tenant?
Conditional Access is the primary defense solution to ensure the environment is kept safe. As a part of Azure Active Directory Premium, you can build policies to ensure certain criteria are met before granting access to users/devices. Some examples of these conditions are approved device platforms (iOS, Windows, etc.), locations (approved IP addresses or ranges), or sign-in risk based on Microsoft’s automated risk classification. Based on these conditions being met, the organization can control that the user be granted access, denied access, or require an additional form of authentication to ensure the user is who they claim to be.
Workstation Resource Requirement
For organizations with older machines that have run the Skype for Business Online client without issue, I have seen cases of issues when Microsoft automatically upgraded these machines to Microsoft Teams. Teams is a more resource-intensive application, and especially in cases where the users were running Windows 7, this has caused significant problems when upgraded to Teams. Microsoft has published the hardware requirements for Teams on a Windows device, and I would advise anyone thinking of rolling out Teams analyze their current equipment compared to the requirements list.
Archiving and Restoring Teams
While this was not something that needed to be considered in Skype for Business Online, this does need to be planned for with Teams. Many organizations use individual teams to manage projects or events that have a start and end, so having a process in place for archiving these teams and their content is important for preserving the data that was needed during the Teams’ existence for data governance and for reducing clutter. The process of archiving and restoring teams is fairly simple and can be handled fairly straightforwardly through ongoing cleanup as Teams are no longer needed.
Which Apps, Bots, and Connectors Do We Want to Integrate with Teams?
As of the date this is being written, there are 252 app results within Microsoft AppSource that are compatible with Teams. There can be great value for an organization to integrate third-party apps with Teams–for example, using Wrike to manage all of your projects within Teams.
Bots and integrations with existing applications can greatly reduce a employees’ time spent gathering information or troubleshooting end user requests. For example, companies that leverage ServiceNow as their helpdesk software can use digital workflows so customized chatbots can build resolve common ServiceNow actions. This can save significant time by collecting data for the support team.
Because of the possibilities, the IT steering committee at your organization should take a look at existing applications being used to see if they’re able to integrate with Teams and determine if that matches the company’s goals. Additionally, once rolled out, performing some investigation on how the teams could leverage the available offerings can help further usage of Teams.
Migration Process and Interoperability Modes
Moving from Skype for Business On-Premise to Skype for Business Online? Piece of cake for end users. Moving from Skype for Business (On-Premise or Online) to Microsoft Teams? An entirely different type of flying all together (cue the Airplane! reference).
The layout of Teams is drastically different from Skype for Business, as well as little details on functionality (transferring calls to voicemail, setting notifications, tagging for status change alert, etc.) These changes can be quite challenging to users that have become accustomed to doing things a certain way for years. Most organizations do not do a hot-cut transition to Teams from Skype for Business, where one day they had the Skype for Business app and no Teams app, to the next where they had Teams with no Skype for Business.
There are various modes for coexistence and interoperability to consider, and this docs page outlines the options so you can plan the best transition for your organization. Having a pilot program is one key way many of our clients have gotten key stakeholders involved early to receive valuable feedback on their usage and habits of the tools, as well as having internal champions accelerate the adoption across their departments.
Conclusion
In no way is this discussion meant to dissuade any organization from moving to Teams. It is an incredibly powerful toolset and is a major focus area for Microsoft’s development efforts. All of the items I’ve noted can be addressed, and it simply takes a bit more planning and assistance from experienced partners to ensure you avoid costly pitfalls.
We’ve assisted many organizations successfully complete their transition from Skype for Business to Teams, so if you’d like to speak with us about your Teams initiative, please reach out to info@pei.com, and we’ll connect with you shortly.
Martin Feehan, Director of Client Relations
