A tale of two Teams features
Living at ‘cloud speed’ with Teams
One of the big advantages of the cloud is supposed to be its velocity: you get more new features, faster than you can with on-premises solutions. This sounds great, and it is – as long as what you get meets your needs. This week I had two very different experiences with two different Teams features, and the differences between them neatly illustrate the good and bad of living at cloud speed and scale.
Teams feature one: the good
Teams Live Events is a fairly new feature; it extends the feature set offered with Skype Broadcast Meetings into the Teams world. The idea behind Live Events is that you can hold slickly-produced large-scale meetings, with multiple presenters and cameras, while taking advantage of the Teams client and the Azure infrastructure to efficiently handle meetings with thousands of users. We have been piloting Live Events internally, and this week we decided to use it for our first real live event, our monthly employee town hall.
For context, we have employees in eight countries; most of them are concentrated in 5 offices (London, Bristol, Fargo, Zilina, and Namestovo), with the remainder being remote. The town hall meetings are important because they help us communicate what’s going on in the company and how we’re doing as a team at meeting our shared objectives. For this, we need a reliable platform for people to join and attend, and we need an easy way to record meetings so that people who can’t attend can watch them later.
A Teams Live Event requires a producer, and I volunteered for that; I created the Live Event in the Teams client and invited all the people I knew who would be presenting. This currently requires you to manually create a meeting invitation and then add the join URL for the Teams Live Event, but the product group assures me that they don’t like this design any better than users do, and they’ve promised something better in future. It is important to note that you can’t create Teams Live Events using the Outlook plugin for Teams meetings, nor on the mobile client.
I loaded the PowerPoint deck we were going to use (which was actually in someone else’s OneDrive for Business), made sure that all the event staff was present, and got ready to start the meeting. At some point recently, Microsoft added a counter indicating how many people had joined the event, so I knew when a critical mass of employees had joined and was able to easily start the meeting. Once the meeting was underway, everything went fairly well, certainly in line with my expectations after testing this feature on a smaller scale.
In the image below, you can see that there are 86 attendees in the meeting; as the producer, I’m mixing my own desktop sharing (sharing a PowerPoint deck directly isn’t supported yet) along with webcam video from our CEO. The items in the yellow box represent what I’ve chosen to show as the producer; the red box highlights the items that attendees see. There’s a Q&A pane displayed on the right side of the window as well.
One thing I immediately noticed is that there’s a noticeable lag between the time a presenter speaks or makes a screen change and the time that attendees see or hear the change. That’s because the meeting content has to go from the “inner meeting” (where the presenters are) to Teams, then to the Azure Media Services environment, where the incoming stream is transcoded into about a dozen unique bitrate and resolution combinations. That way each attendee’s device can get the best possible stream given its local capabilities and bandwidth—but there’s an unavoidable delay of 10 seconds or so. This becomes noticeable when you have attendees and presenters in the same room, as sometimes happens.
Another thing is that the Q&A feature (which you must choose to enable when you create the meeting) now supports anonymous Q&As. Perhaps unintentionally, the meeting producer is only shown as “Moderator” in the interface, so when the producer answers questions, attendees may not understand who is answering the question. Once one of the other presenters let on that “Moderator” was my secret identity, the feature became much more usable.
Finally, we identified a late-breaking problem with our particular meeting: our Marketing Operations Director was due to present, but she was stuck on a train and couldn’t join. I wanted to substitute in someone else from her department, but once you start the live meeting, there’s no way to change the set of presenters.
After the meeting’s over, the producer or presenters can download the meeting recording (which is automatically created when the meeting starts) or files showing the Q&A contents or a list of attendees. It would be nice to have the option to automatically post the meeting to a Microsoft Stream repository, but overall, that’s just a small quibble.
In fact, all of the issues we had were minor problems; the overall experience was quite good. I’m confident that Microsoft will continue to fix the occasional rough edges in this feature, especially given that it largely replicates (and uses many of the same components) as the Skype Broadcast Meetings service.
Teams feature two: the bad and the ugly
On the other hand, another new Teams feature I tried didn’t work well at all.
One of the ongoing issues with Teams at Quadrotech has been the need to synchronize the membership of some Teams with existing AD or Azure AD groups. We have a Team named “Quadrotech All” that we want all employees to be members of. As people join and leave the company, a Team owner has to manually edit membership—a boring and error-prone task. When I saw that Microsoft had introduced org-wide Teams, I was delighted to try the feature: I logged in using an admin account and changed the Team type to “Org-wide”, then sat back to await the promised goodness.
Instead, a few things happened. First, true to plan, every Office 365 user account in the organization was added to the Team, including service accounts and accounts for users who are in our tenant but not employees (such as our outside legal counsel and the CRM consultants we use). I expected this, so I didn’t mind too much at having to go through and remove those accounts—but they promptly came back. This was not entirely unexpected either, as the feature is intended to keep Teams membership in sync with the organizational directory, and there’s currently no way to filter out accounts you don’t want to synchronize (an obvious improvement that I’m sure Microsoft is already working on). I had hoped that the synchronization process would be smart enough not to re-add a member that I’d explicitly deleted, but no.
There was a bigger problem that I didn’t detect at first until I started getting Teams messages:
As you can see above, the issue becomes increasingly apparent: a relatively large number of employees (CEO included) were promptly kicked out of the Quadrotech-all group when we changed to the org-wide Team type. Because I’d converted the Team to org-wide mode on a Friday, I didn’t have much hope that the problem would be identified, much less fixed, over the weekend, so I switched the Team mode back to “private,” which meant I had to go back and make another membership pass. Several of the users who had been evicted were thrown out again, even after I switched the Team mode. Tony Redmond eventually figured out what the issue was, and the Teams team is fixing it.
In fact, this Teams fix may be out by the time this article is published—so why did I write about it? Remember my mention earlier of cloud velocity. In this case, that velocity both giveth and taketh away: there have been several quite useful improvements in Teams Live Events in the few weeks since the last time I used it, and org-wide Teams are a feature that users have been asking for for quite some time. However, the pressure to deliver the features (on Microsoft’s part) and to leverage them (on mine) means that end users had to contend with some speed bumps.
Thankfully, none of the problems we encountered in either feature was critical; there was no damage other than a bit of embarrassment on my part—but it reinforces the need to be aware of the changes Microsoft is continually making to the service and to test them wherever possible before putting them into widespread deployment. (I’ll leave the Windows 10 1809 debacle for other folks to write about…)