Home » Microsoft Teams » Microsoft Teams 10 Points to Consider before Deploying

Microsoft Teams 10 Points to Consider before Deploying

We all want to use Microsoft Teams, but don’t rush it out to your business. Instead take a breath and consider your options. Here is my 10 tips to mull over before sliding that license button.

1. Why What When How?

As with every new technology introduction, start with why? Why are you looking at Microsoft Teams? What do you hope Microsoft Teams will bring to your organization? What are your objectives? What do you need to achieve your goals? When do you think you really require it? How do you expect your employees to use it?

Until you can answer these basic questions then you are not ready. It is all too easy in cloud commoditised to just slide the license to active and throw it out and hope for viral take up. But with Microsoft Teams, as good as it is, if you do this then you’re setting yourself up for a world of pain down the line. Compliance and information security, I can think of off the top of my head as the most important consideration when allowing your employees to collaborate. Not only with external users, but also internally as well. Should your production line workers be able to join a Team that discusses their redundancies, or be able to access a shared file link that shows the director’s bonuses for the financial year? Probably not, and without proper consideration and planning from the outset it is going to be difficult for you to control when these situations arise, least not the embarrassment of IT having not considered this in their deployment of course.

2. Don’t Assume

Don’t assume that just because you’ve enabled Microsoft Teams that your users will use it. Prising their hands away from their shadow IT or your legacy system is going to be the most difficult challenge you will face. Remember, techies love tech, so they will be enthusiastic about the move and uptake will be easier. However, normal users are more sceptical and negative towards change because as they see it, what they are using currently is muscle memory and they have learnt to work with it and around it. Have a plan to tackle user adoption early on. Do not leave it as an afterthought or Microsoft Teams will struggle to get off the ground.

When I speak to companies about adoption, the most common go to method of communication with users is e-mail. Personally, I find e-mail the least attractive proposition in an adoption strategy. If I receive an email that is loaded with information and looks daunting, it’s lost my concentration before my eyes have moved off the subject line. The best media for adoption awareness is without doubt video! Creating corporate videos talking and showing the benefits of Microsoft Teams is far more interesting and engaging than reading a boring email. Videos should be short, to the point and easy to follow, free of jargon. Spending the money on professional videos is money well spent.

Then it’s about the distribution method. You could email out a short “Take a look at What is Coming” mail with the video embedded, or the most effective distribution method is a post on your corporate social channel from the CEO. You’ll find that more employees will engage in that form of distribution than any other medium you choose.

However, it is not just about awareness, it’s also about training. Don’t assume that everyone will get Teams. Remember, they are used to performing tasks in a specific way and used to the way features are worded. These change and there is confusion. Make sure your training program includes how to videos, drop in sessions, virtual surgeries that users can jump in to ask questions etc.

3. Don’t Expect Teams to Solve All Your Problems

Remember, Microsoft Teams is a fledgling product. It has a long way to go still and as a result some features you may expect to be there, may not be. Should you wait for that one specific feature to come out before rolling out Teams? I would suggest not. There is far more value in having Teams in your organization without this feature than with it. Your awaited feature completes Teams for you, it does not define it.

You should take time in getting to know what Teams can do for your organization, work out its pro’s and cons for your situation and then decide on how you are going to augment Teams into your workforce and business processes. Use it as an early adopter technique to build a robust and reliable collaboration and communication tool that has long term benefits to your business. Remember, it is not a race. Rushed projects always fail. This may mean that you will have Teams alongside other similar systems for a period of time. This is not always a negative. This allows your workforce to transition at a manageable pace without real impacting and disruptive change. It also gives you time to focus on key scenarios more closely and without masses of expense. If you’re trying to transform your entire organization over a 6 to 12 month period, then you’re going to need a lot of people to help you. Whereas, concentrating on deploying a good base product that provides instant benefit on top of current systems to users, and then working with each department to transition reduces your body count and increases quality and of course adoption long term.

Teams will not automatically fix your broken processes, or poor communication or whatever challenges you currently face. Technology alone cannot do this and circling back to the previous paragraph this can only be done with focus and direction. Putting Teams alongside other systems allows your users to continue BAU while you help them fix their problems showing how Teams when used effectively can assist in achieving those fixes. It’s about promoting possibilities.

4. Coexistence is Critical

Unless you are a sub 50 seat company, switching overnight to Teams from your old system is not going to be possible. Of course, big bang is the easiest way of switching platforms for the target system but it is often not well received by users and causes 100% disruption immediately. In order for a successful deployment of Teams, you need a coexistence strategy, and this doesn’t just extend to the UC element of Teams, but also Collaboration as well. All of a sudden, you’ll have almost limitless document stores across multiple Teams that your business hasn’t fully understood how to maintain source authority or consistency. For instance, imagine a design document being stored in a file share. A user moves it to Teams, then copies it to their One Drive then copies it to another Team and then shares that with another user who copies it to their One Drive. How do you maintain control? Through proper education and eDiscovery searches for duplicated documents etc. but that needs to be planned. UC is perhaps the most critical, you’re rarely going to be able to move everyone over to Teams in one go, especially if they have voice capabilities. How migrated users and legacy users interact is a critical element to get right. Coexistence only really exists between Skype for Business and Teams where in certain modes and certain conditions it is possible for conversations to pass between the two systems natively.

However, for most who use other UC platforms coexistence doesn’t exist in the technology. This means that users, even the ones using Teams will still need access to the old system for legacy communication. This creates a confusion with the users, especially if legacy users are licensed for Skype for Business Online as part of E3 for example, they turn up in address book searches, messages get missed and it becomes largely a nightmare.

For these customers and scenarios, it is easier to deploy Teams with Chat Only capability so that everyone can use Teams to communicate. It is better, in my opinion at least, that in these situations you role out Teams with the minimum functionality needed to support the only critical workload at that moment in Teams, chat. A single chat space is a must. If you try and deliver Teams with full features including voice etc in one hit to people, then you’re going to drive longer projects and as a result longer duration that users have to put up with having to use Teams to chat to Jane, but Google Hangouts to chat to Jack etc.

5. Changing Things Take Time

One particular frustration of mine and something I wasn’t prepared for when I first looked at Teams in anger was the delay between and admin changing a user’s account and not only the affected user seeing that change, but the rest of the users within the organization too. In SfB we are used to inband changes being made within 15 to 20 minutes. In Teams this can be as long as 3 days! This makes execution, especially in deployment a nightmare, and even more so when a user is being moved from SfB online to Teams.

Let me give you an example of what I mean. Jane is using Skype for Business Online. She is in SfBOnly mode and must now move to Teams. I change her interop mode to UpgradeToTeams and grant her Teams meeting, calling and chat policies.

The SfB client realises the user has been moved to Teams within 30 minutes. Jane signs into Teams for the first time. She realises her calling button for telephone calls has not appeared. Calls IT and they say, yes this is normal, it may take 24 hours. So now Jane is without calling capability for 24 hours. No ideal, it’s an outage. Ok this does not happen all the time, but I have seen it happen more times than I feel comfortable with.

But the real issue is this. Jane has been chatting with Jack while she was using Skype. But Jack was using Teams. Jack sees Jane in the Teams client as a Skype contact and that’s where the conversation history and thread is. Jane has now moved to Teams. But Jack’s client hasn’t realised this and is still trying to send a message to Jane’s Skype account and this fails. Jack has to search for Jane again in hope that Teams realises that she has migrated and start a new conversation. This can take 3 days to work as Jack’s client uses cached data and the cache doesn’t refresh as often as you need it to.

Now consider a greenfield deployment of user Emily. Emily uses Google Hangouts. Emily is scheduled to become a Teams user tomorrow. When you license Emily it can take up to 24 hours for all systems to become license aware and provision Emily’s account. So that means, post license you’ll not be able to change Emily’s interop mode to Teams Only is the tenant default is SfB Only until SfB Online has finished enabling her account. After that, Emily is still subject to the risk of the calling button appearing late, especially if she is going to be using direct routing.

In the experience I have the only way I have been able to have some sort of consistency and control is to start the deployment of Emily 3 days before she is scheduled to use it. The penalty for this is that she becomes searchable to others in the GAL ahead of time.

6. Forget SCCM for Deploying Teams

If you use a desktop software deployment solution like SCCM, you’ll be thinking that you can use this to control the deployment of the Teams client. Whilst this is true, you can deploy Teams by MSI or EXE via SCCM, you cannot stop a user from downloading the client and installing it themselves even with restricting local admin rights. This is because the Teams client is installed directly into the users app data folder which runs under the user context.

Personally, I don’t see an issue with this, but some organizations are concerned about unmanaged software distribution that they cannot control.

In my opinion you would want users to download and install the client themselves. You’re not preventing anything by trying to restrict it because they can login to Teams via their browser and get pretty much parity functionality (minus a few UC features). So, if they want the desktop client, then let them. It makes IT’s life easier and encourages users to use the platform.

7. Consider Your Groups

At the core, Teams Team structure is built on top of Office 365 Groups. Therefore, the settings you apply to Office 365 Groups at admin level effect Microsoft Teams. Similarly, if you want a group to behave in a certain way for Teams, for instance, you may want a naming convention, then remember this applies to all Office 365 Groups in your tenant and that means these changes are effective across the entire suite, Exchange, Yammer etc.

Another common restriction on not so much groups but more Azure AD guest invitations is administrators tend not to permit Azure AD guest invites coming from Azure AD members. This means that Group / Team owners and members of that Team will not be able to invite guest users to their Team. In Azure AD there is a guest inviter role, and you can add privileged users to that role. This allows them in Azure AD to generate a guest invitation to an external user, but Teams is not aware of this role, so they are unable to use the Teams client to invite a guest member.

The recommended approach is to allow Azure AD members to create guest invites. However, if you use SharePoint, then use the SharePoint site controls to restrict guest access to these SharePoint sites outside of Teams, thus protecting your data. The same goes with Yammer.

8. Guest Domain Approval & Federated Domains

Out of the Azure AD box any user can invite any external user to a guest AD account in their tenant. This is used for guest access in Teams. You may want to consider restricting this privilege to certain approved external domains so that people cannot add in users from unauthorised sources. In Azure AD there is a white/black list where you can specify domains you want to allow or block. You have to choose your schema, are you going to whitelist, which means everyone is blocked by default unless the domain is in the list, or blacklist, which means everyone is allowed by default unless the domain is in the list.

Most organizations go for the whitelist option as it offers the most protection.

Adding a domain to this list is separate to federated domains. Federated domains are controlled within the Teams Admin Console and works completely independently to the Azure AD whitelist.

Federation is for 1:1 conversations in Teams with an external user from another domain. You cannot use federated domains as a control for guest access in Teams. Guest access is completely different in terms of use case, so do not get these mixed up.

9. Be Prepared for Stuff You Don’t know

Teams offers a lot of app integration with 3rd party providers through the app store, as well as with other Office 365 apps such as planner. Suddenly you will have gone from a UC engineer to having to help and support users who have added apps into their Team that they thought they needed but don’t know how to use it. As it is in Teams, naturally users will think it’s down to you to help them.

Now there is no way to control 3rd party app integration. In my opinion it is needed even if it is a short-term measure to ease businesses over the Teams line and encourage them into the ecosystem.

Most organizations are worried about what data is stored in these 3rd party apps, where they are stored and how the business can control it.

10. Do Your Devices Work with Teams?

If you want the full Teams experience, then you’re going to need to buy Teams devices. The chances are you’re invested in Skype for Business devices and are going to be wondering how they perform with Teams.

Headsets currently have a few troubles with Teams, but they are getting there. This is more about control by the user than them simply not working. For instance, a headset may have its own mute button, but when pressed Teams does not understand that the headset has muted so the mute button is still inactive. Mute still works in this scenario, but users can get confused as to why they are talking but no one can hear them if they’ve muted a while ago via headset but the client still showing them as not. It’s more of an experience thing.

If you’ve invested in 3PIP handsets (Polycom VVX for example) then you are going to be able to use these with Teams through native interop from the Office 365 cloud. At the moment the experience is quite good, and you can do most of what you need to do on a phone without too much trouble. However, they will not work with device management within the Teams Admin Console, for that, you need Teams native devices. Furthermore, it is likely that additional functionality will come to native Teams handsets and 3PIP will become the new LPE and eventually be retired.

Meeting Room devices, if you have SRS version 2 or Surface Hub devices then after an update these systems can be used in Teams meetings as VC endpoints. Anything older then you are going to need interop services. Currently, there are 3 providers, Pexip, Polycom and Blue Jeans. All three have SaaS offerings with their cloud hosted video interop (CVI), but Pexip offers on-premises interop together with distributed interop that can benefit customers with large foot prints of VC rooms more options than cloud based offerings.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: