[MUSIC PLAYING] I'm Tony Redmond. I am here today to talk to you about managing Teams successfully, at least in my view. And there's no perfect recipe, there's no single recipe for managing teams. But so what I hope to do today is just give a few ideas, and then it's up to you to actually put those ideas into context for your organization.
One thing you've always got to remember about the consultant-- and I've been consulting for years, and years, and years, and years, and years-- is that a consultant, no matter how experienced they are, only has 50% of the answer to any problem. The reason why is that the other 50% comes from you-- your knowledge of the company, your knowledge of office politics, which sometimes happens inside large organizations, sometimes.
All of that kind of stuff-- the reasons why technology decisions were taken in the past, et cetera. You've got that. So anyway, we'll throw some ideas out.
So what do I do? Well, I've been around for quite a long time. I've been an a Microsoft MVP since 2004. Right now, two major things I do. I write for petri.com twice a week about Office 365 and associated technologies. And I also have this thing called the Office 365 for IT Pros ebook, which is a book that's electronic, and it's published every month-- republished every month. We publish it on a subscription basis.
And the reason why we've got to republish every month is because things change so quickly inside Office 365. And in fact, Teams is one of the apps that changes most quickly. You just have to have a look at the Office 365 Admin Center and look at the notifications that Microsoft posts there for changes. I would say, just off the top of my head, that maybe 40% of all the changes posted in Office 365 are to do with Teams right now.
This app is evolving very, very quickly. And one of the reasons why it's evolving very quickly is that it's moving quite rapidly to accommodate the needs of large enterprises, because it's large enterprises where you see all the stress points. You see all the weaknesses exposed. Microsoft is doing that quite quickly. Anyway, so that's me.
So my first and most important point. We're all IT professionals in the room here, so I imagine that there's a fair amount of cynicism. IT pros are cynic? No, never. Anyway, you may have noticed that Microsoft is marketing Teams quite heavily. Yeah? It's the new coming. Oh, whatever. It's a bit like Yammer was in 2014. Remember everybody was told that Yammer had to be the way to do things? If you didn't use Yammer, you weren't collaborating effectively.
Well, that was 2014. Let's move on. Yammer still has its place, but I think the way I would summarize it is that Yammer was a bit of a missed opportunity for Microsoft. Teams is where their head is at right now, and they're trying to force the pace. They're trying to make people believe that Teams is the way, the truth, and the light.
It's really important to them. Metrics drive behavior, and the way Microsoft people are goaled is to make people use Teams. So let's not confuse Microsoft's marketing strategy with your IT strategy. Very important point.
Some of the things I want to discuss. I'd like to talk about some of the basics of Teams to make sure that we're all on the same page. But again, because we're IT professionals, everybody knows Teams, right? Who's using Teams? Would you like to give this presentation then? Sure, come on up. OK, well, I will talk to you about my impression of teams, and then you can agree or disagree with me. By the way, if you--
If I can just talk from this, I'll take over because you just invited to talk, so--
Listen, if you want to heckle, that's good. And by the way--
[INAUDIBLE]
--heckling is good. Tweeting about me is also good, provided you're kind. If you're not kind, then I don't take it too nice. OK, [INAUDIBLE]. Anyway, so we'll talk a little bit about the basics of Teams. And then I want to talk about how you plan for success and how we measure and manage teams, and how we measure our success. And then we'll come to some conclusions. So it'll be quite quick. And I don't have a lot of slides, because I don't believe in killing people by PowerPoint.
Some points about where Teams is right now. Clearly, this is an app, as I said earlier, very fast evolution. Launched November 2016 with general availability in March 2017. So pretty new. Big announcement recently? Teams is going to take over completely from Skype for Business Online when Skype for Business Online retires in about two years' time.
According to the data released by Microsoft, Teams is used by half a million organizations. That was in April. Then they came out and they said, you know what? We've now got more active users than Slack has. So they had 13 million active users who are weekly active users, and 19 million who are active monthly. Now, the definition of what an active user is somebody who logs onto Teams and does something. They send a message. They access a file, something like that.
The interesting thing I find by looking at these numbers is that if you strip out 160 organizations that Microsoft says has more than 10,000 active users, and the big one of those which is Essentia with 170,000, you actually end up with a very low number of active users per organization. It's around 26 or 27. And what's that tell us?
Well, to me, it means that a lot of organizations are just starting with Teams. They're beginning their deployment. They're active, and Microsoft can pick up that activity because they're monitoring signals in Office 365. But relatively few people in each organization are using Teams. This is going to change, and will change because of two things.
Firstly, due to the retirement-- the elimination of Skype for Business Online. That's a forcing function. People will have to use Teams. And the second thing, of course, is that Teams is going to grow into the Office 365 installed base. Right now, the last figure we had, which is from April, it's 180 million active users. That's growing at about three to four million active users per month.
And Office 365 has grown consistently at that rate for the last three years. So it's not going to fall off anytime soon. So clearly, there's free and trial versions available. It's a replacement for StaffHub for the four tenants that used StaffHub. And there is a very strong focus within Teams on two particular sectors, which is health care and the educational sector. So that's a general thing. A lot of activity here. A lot of activity.
So basics. Teams, at its heart, is a messaging application. So it groups things together, it groups conversations together in channels. Those conversations are going to be public when they're in the channels, and you can also have private or side conversations in chats or group chats. These channels are logical divisions.
A big thing that's going to happen very soon as Microsoft is going to release private channels. And I'd love to tell you all about private channels, but I can't because it's still under NDA. What isn't under NDA is that it's coming. It's coming soon. One thing that Microsoft has revealed is that one of the primary driving factors for their design for private channels is that they're going to be very private.
In other words, you will be able to set up a subset of users within the team, I'll take them to that private channel, and that only those users will be able to see what goes on in the private channel. And that means that even a team owner will not be able to see stuff in a private channel unless they are a member of that private channel.
I expect that we're going to hear a lot more about private channels in September. Yes, sir?
So that's great and all. And I think people are relieved that's coming. But what does that do-- like SharePoint, why is that an improvement when you can just use SharePoint 7 with [INAUDIBLE]?
I would say that Teams and Office 365 Groups are actually the reason why SharePoint Online has hard a revamp of its popularity, because there's no doubt that SharePoint was in a bit of a rut.
Absolutely.
OK? And in fact, what you see with SharePoint Online today is the fact that it has become very much-- unlike its on-premises counterpart-- simply a document management provider to Office 365 apps. And what I think you're going to see-- and private channels, again, because I'm bounded by NDA, I can't say too much-- I think you'll see that Microsoft will leverage SharePoint to make private channels work.
Sure. You have to.
That's all I can say.
You have to.
That's all I can say.
OK. You answered [INAUDIBLE].
Good.
Yes.
I answered it while dancing around the pinhead, and that's really good.
Absolutely.
But you will find that-- and I think you're going to be surprised with some of the things that they do, specifically around how they ensure that the membership of private channels remains private, because that's pretty important when you think about it.
If you set up a private channel to discuss something really confidential-- let's say a staff reduction plan-- and you assign a couple of people to go and work that so they become the members of the private channel, you don't want any possibility that somebody else is going to be able to come along and maybe manipulate SharePoint permissions to suddenly get at the files that these folks are working on.
And I think-- because we're only speculating here between friends, even though I'm being videotaped at the moment, so I can't speak too much-- I think you will see something there that will make you very happy. Just speculating.
[INAUDIBLE] over. You can't have SharePoint and then--
Forget SharePoint permissions. Forget them.
Done.
Teams will drive access.
OK.
OK? And that's much, much more than I wanted to say. Anyway.
So sorry.
So clearly, there's a whole pile of different clients right now. A big issue in the clients, I guess, is tenant switching has just tended to be slow, but that doesn't affect very many people. It only affects people who have to access multiple tenants. I am impressed with the depth of the functionality that's available in the mobile client. I think they've done a very good job there.
[INAUDIBLE] limited scalability. 5,000 members of a team today. Will that go higher? Well, I think you've got to go and look at why that limit exists. Originally, it came from Office 365 Groups, and the reason why Office 365 Groups had a limit was because of multiple concurrent access to some of the Exchange components, specifically the calendar.
Over time, that's got a little bit looser because Microsoft has looked at how people use these things, and they find that you don't have so much concurrent access within a group to some of those Exchange components. And that's the reason why it's gone out to 5,000. Will it go higher? I suspect it will, but Microsoft, again, has got to be careful here because of potential performance scalability issues, and also because of the potential impact on Yammer.
Already, the fact that Teams can support up to 5,000 users in a team has impacted Yammer, because people are looking at Yammer and saying, well, why would I want to use this? And the answer is that the big thing that Yammer has over teams is total scalability-- really total scalability. If you want to go and host a discussion for 100,000 users, you're going to use Yammer.
But the vast majority of Office 365 tenants probably aren't looking for that kind of thing. And the higher up Microsoft goes with this number of users support for Teams, the less tenants are going to be interested in Yammer. So that is an issue for them.
Nature of conversations. Big thing for people moving over from email, of course, is to realize that everything is public. You say something in a team, everybody sees it. And that, again, comes from the Office 365 Groups model, which says that everybody in an Office 365 Group has the same level of access to every resource within the group.
So because conversations are part of the group resources, everybody has access to them. Now, we are going to see a change in that, too, when private channels come along. But at the moment, you can take it that within Teams, everybody has access to everything, including all of the conversations.
It's kind of interesting here, too, that when you look at the numbers and you reflect on how people use Teams versus email, Teams is a lot more efficient about dealing with conversation than a lot of the email traffic that exists today. One example I give you is that if you're having a discussion with a large group of people, in the traditional email world, if you were to send a note out to a distribution list, think about what happens.
Mail is delivered to all mailboxes. You get back a couple of auto-replies telling you people are out of the office, and then people start discussing it. You might get an email storm, et cetera, et cetera, et cetera. You have the opportunity to share in all of the stuff that people put in auto-signatures, including unwanted corporate logos that are sent internally, et cetera, et cetera, et cetera.
You end up with thousands of messages in the messaging system-- thousands. You can quite easily get-- from a single message sent out to 100 users-- you can easily end up with 10,000 messages spread across mailboxes. Teams is a lot more efficient because you get a single thread, and it stays like that. There's no forking or anything. You just see a single thread. OK?
So in that respect, Teams is a lot more efficient than email and is a better collaboration technology than email.
You can start conversations with inbound email. And the way they do this is quite interesting. A channel can have an email address. Any channel can have an email address. Once an email address is assigned to a channel, behind the scenes, the splendidly-named Office 365 Substrate sets up a private mailbox. You can't access this mailbox in any other way. It only exists to accept inbound email to the address that's allocated to the channel.
You don't get to choose what email address is allocated to the channel. It's generated automatically. The connection between this phantom email mailbox and Teams is via a connector. And what basically happens is this connector is looking for any message that arrives into the mailbox. And as soon as the message arrives in the mailbox, it's grabbed and posted to Teams, both as a conversation, so you can start off discussing the mail, and also it's posted into SharePoint into a folder called Email Messages.
So that's quite a nice way for getting people to start thinking about how to use Teams. If they get something important in email, maybe from an external partner or something like that, they can forward it on to a channel to start off a discussion. It's interesting to me that some email characteristics have started to appear in Teams. Read receipts is a thing that's going to come along very soon. Microsoft has already announced it.
You won't be able to do read receipts for channel conversations, however, you'll only be able to do them for personal conversations, personal chats. So we are seeing some characteristics arriving. I guess, also, the advent of urgent messages is another example of that.
Now, I've talked a bit about channel and group or private conversations. This is just a comparison. It's a bit of an eye test, so sorry for the guys at the back of the room. Hope you've got good glasses on. This is just kind of a comparison between it. As you can see, you've got channel conversations here. You've got personal conversations on the far side.
Interesting things-- filesharing in the channel is through SharePoint. Filesharing in a personal chat is through OneDrive.
One of the things you've got to remember about Teams is that Teams, unlike pretty well any Microsoft app I've ever seen in my life, doesn't reinvent wheels. If you strip back the Teams architecture, you see there's two big things that really come out to you. One is the fact that it uses microservices-- a whole pile of different microservices like the Azure Key Vault.
The other thing is that it pulls in services from all around Office 365 whenever possible, rather than trying to recreate this wheel. In fact, one senior Microsoft engineering manager said to me that Teams is an app that's built on the shoulders of almost every Office 365 application we have out there. OK?
So from that perspective, it's pretty interesting because you can view Teams as a collector, a point of collection, for all of the functionality that's available across Office 365. You think about it like that, and that's the way it comes up here. Of course, it adds on its own tricks, like video calling and stuff like that.
We mentioned SharePoint a little bit. I do want to mention SharePoint here because one of the strengths of Teams, I think, is that Teams puts a human face onto SharePoint. I don't know if you would agree with me, but I think that the SharePoint browser interface sucks dirty canal water and has sucked dirty canal water for many years.
It's totally unapproachable for users, whereas because Teams integrates so easily with SharePoint, sets up these folders automatically for every channel, and puts this nice files UI, which now is becoming very close to all of the power and the functionality that's available in the browser interface, we suddenly get to a point where, hey, SharePoint is usable for human beings, which is really nice.
And I think this is one of the things that's accelerated the SharePoint Online growth within Office 365. Certainly in the organizations I work, we use SharePoint this way. We don't use the browser interface. We always go through Teams. It's really, really, really, really, really good. And the point here, of course, is that you'd have OneDrive for Business, of course, which is used for sharing inside the personal chats.
So we should now all agree on what Teams is, so now we talk about creating a plan. I'm a great fan of planning because I found out that over my 40-odd years career in IT, people who don't plan tend to leave messes behind them. There are lots of evangelists who have come in for a technology and say, oh, yeah. We'll do X, Y, or Z.
And they walk out of the business six months later, after we've been doing X, Y, or Z, and you find out about X, Y, and Z doesn't really add up. It's just a mess. So I'm a great fan of planner-- planning, not planner. I like planner, as well. No pun intended. So my basic question is, why does an organization want to use Teams? Not because the Microsoft sales rep tells you it's a great thing, because they're compensated on that, so let's lose that conversation straight away.
Why does an organization want to use Teams? If you can't come up with a solid reason that can be specified in one or two sentences, then why do Teams at all? That's a basic challenge for any organization. Why do you want to do Teams? Eliminating email is the worst possible goal you can have because you will never eliminate email. I'm sorry. You won't eliminate email, no matter what people tell you.
And here's the reason. Teams is for internal communications only. There's no outbound email from Teams. There's no outbound communications from Teams. If you want to communicate outside your organization, you can invite guest users in and those guest users will have total access to all the resources of the team, but that's not the same as outbound communications.
We will need email for the foreseeable future for outbound and inbound communication into the organization, and to deal with things like very structured communication and protected communication.
I mean, one of the big things that I think that Office 365 has done really well over the last couple of years has been to make email protection so much easier, with features like the Encrypt Only feature that's in OWA and Outlook Mobile, with the ability very soon to have sensitivity labels applied directly inside Office applications, and so forth and so on.
You can protect information so much easier today inside Office 365 than you could in the past. And a lot of the times, when we want to communicate outside, we want to make sure that we're very protected in that communication, that your message is going to go to the right person, that only the right person is going to be able to receive it and interact with it, and you can do that with rights management protection.
So reducing or eliminating email isn't a good goal. Reducing email could be part of what you want to do. It could be a proof point that people are using Teams for internal communication, and that's goodness. But just starting out and saying, we want to reduce the use of email, that's not a good goal.
Encouraging better collaboration. That's a very laudable sentiment. Is it a good goal, though? Because goals have to be measured. How can you measure better collaboration? That's something that you feel. We've got better collaboration going here. It's very hard to measure it, though, isn't it? So what do you mean by it?
I think for any of the goals that you're going to put up, tell me what the measurements are. Make sure they're hard measurements. Make sure they're verifiable. They're something that you could bring to a CEO and be very happy that the CEO understands very quickly the value you are delivering to the business. Not just, hey, we're having great fun with conversations. Files make SharePoint easier to use. Not business goals. Not verifiable, right?
And I think also in your plan, you have to actually put some designated responsible individuals, people whose necks are on the line for the success of Teams, and who are going to be responsible for setting the policies for the deployment and ongoing management. Again, one of the things you have to figure out about Teams is that behind the scenes, Microsoft has actually constructed a pretty good policy-based framework for managing Teams.
They possibly have too many policies, but the fact that they have policies is a good thing because it means that you can go and assign a whole heap of different types of policies to individual user accounts to control exactly how that account will interact with Teams. So somebody's got to be responsible for setting that up, and managing it, and making sure that all happens, along with everything else. So that's the first thing.
In terms of some questions that the plan should also answer, I'll throw out training. It's an unhappy word in some organizations. I think in the 1980s and 1990s, organizations spent an awful lot more time training people about how to be successful than they do today. And there is a school of thought out there that says, if you know how to use Facebook, you can do Teams. If you know how to use Whatsapp, you can do Teams.
I will buy that in one respect. You can probably know how to use Teams conversations and chats, but Teams is much more than that. So people need training, and especially because Teams changes so quickly. There are so many new features coming out that if you just let people at it, and you never inform them, and you never let them know what's happening, they will eventually make a mess.
So we talked about policies. That's fine. Teams for voice, the phone system, replacing PBXes, all kind of stuff. That's a laudable goal, as well. That could actually be one of the business goals because you can actually measure that. You can measure the cost that you have today in terms of your voice communications, and your PBXes, and all of the stuff that goes along with it.
So replacing all that kind of old stuff with Teams and the voice system-- that could be a good thing, especially if you think about using some of these intelligent room systems and stuff like that to drive better conference calls, reduce travel, et cetera. They are definable goals. They are measurable goals. So this is a good area to investigate.
I do think you need to spend some time thinking about this before you start. Now, I remember the first time I heard about Office 365 Groups. It was at a Microsoft session in Redmond when the last 365 Groups development team were very excited, as many Microsoft development groups often are. I think it must be something in the water there or something.
Anyway, and they came in and they said, Our vision-- immediately sets a red flag when somebody starts talking about vision, because vision probably means they haven't thought the whole thing through, but they've had a vision.
[INAUDIBLE] a vision.
They had a vision. Our vision is of collaboration everywhere so people should be able to set up groups whenever they want. I want to have a group to find jam recipes. OK. I want to have a group to define the quality of toilet papers in the stalls. OK. I want to have a group to define-- I don't know-- anything I feel like. And Microsoft, this would be good.
And they brought this through into Teams. So if you start off Teams without any management, anybody can create a team for whatever purpose they want. The only result you're going to get here is a sprawl that is unmanageable and really difficult to deal with when it comes to compliance and data governance. Yes, ma'am?
Speaking of compliance, is there good context on the back end so you know who created something, if somebody read something? And then the only question we always get, the attorneys will ask, can you export [INAUDIBLE] to a platform that we can then look at?
OK. So there's a couple of questions there, which will [INAUDIBLE] data governance and compliance. The first question was about teams creation. Yes, you can track Teams creation because in the Office 365 audit log, there are many events recorded when you create a team because creating a team involves creating an Office 365 Group, creating the team, creating the SharePoint site, provisioning the site with permissions, et cetera, et cetera.
All of those activities are captured in the Office 365 Audit Log and you can find it either by going to the GUI, which is what normal human beings do, or people like me use PowerShell, and we go and search, and we find it and we format it in various reports and stuff like that. Or there are various products out there that will help you, as well.
The next question is, can I get information out of Teams for attorneys and stuff like that who need discovery? So the way things work here is that when messages are sent in Teams, Office 365 grabs copies of those messages, and it creates copies of those messages in the group mailbox for channel conversations or in the personal mailboxes of people who participate in personal chats.
Now, there are a number of issues here. Let me talk about them very briefly. The first thing, you should never believe a backup vendor who tells you that the backup Teams when they backup stuff out of Exchange. They are just backing up copies of compliance records. They are not true copies.
One of the things, which is really important for e-discovery, and really important for compliance, is that these items that are created in Exchange miss reactions. So that's things like likes, and hates, and stuff like that. And that's important from a compliance perspective because if you think of it, if somebody's thinking about doing something bad-- let's commit a fraud on the company. Sends a message. OK, that's captured.
But if somebody-- the recipient then actually likes the message, that's not captured. And that like to an investigator is very important because it means that somebody actually looked at the message and positively responded to the message. OK? So that's one problem.
Another problem from an e-discovery perspective is that each message is presented in a separate item, is captured in a separate nature. So if you want to find out a full conversation, you have to extract all the messages and then put them into order. Now, a report that Microsoft commissioned last January by a company-- I think it's called Hasset Associates. It was all to do with SEC 17a-4 compliance.
Highlighted these issues, and Microsoft responded that they would do two things. Firstly, they would capture those reactions in compliance items, and the second thing, that they would provide a form of transcript rather than individual items. So that is still to come. It's not there today. It's a commitment on the part of Microsoft. And when that happens, it'll be so much easier for everybody.
But the point is this-- everything was audited. It's all there. You just have to know where to go and get it. OK? Any other questions about data governance or stuff like that? Oh.
Can you talk about expiration based on [INAUDIBLE]?
Do I want to talk about expiration? Well, group expiration is just one of those policies that you could put in. And group expiration-- I think it's a good thing to have, because let's face it, Teams, and Groups, and stuff like that-- some of them are set up with great intentions and never followed through. And after two years or so, you'd be looking at it and saying, hey, nobody's ever used this team in the last eight months. What can I do with it?
What the group expiration policy allows you to do is it allows you to set a retention period for groups, a renewal period-- let's say two years-- and after two years, Office 365 will go and check and see has any activity occurred in this group? And if it has, it will automatically renew it. And if it hasn't, it'll delete it. So again, this is one of the policies that you have to think through before you actually go and implement.
Now, that's a very good example of another issue that comes up here because a lot of these policies, like a creation policy, a naming policy, the expiration policy, these require Azure AD Premium Licenses, which is a thing that Microsoft doesn't tend to tell you. It may or may not be an issue for you. Certainly if you're using Enterprise Mobility and Security, it's not a problem because you're covered.
But for other companies that aren't using EM and S, you will have to go and purchase Azure AD Premium Licenses to cover those features. So it's a little bit of extra cost.
Speaking about Azure AD, it comes up group or guest access. Guest access is done through this thing called Azure AD Collaboration, which is really pretty nice. It's the same thing Planner uses. SharePoint uses it extensively today. And in fact, the future for SharePoint is that all sharing links outside the company will use guest accounts to be able to set them up.
Well, basically what happens is when you add a guest user to a team, behind the scenes, Azure AD creates a guest user account inside your tenant directory and sends the recipient an invitation, sends the guest user an invitation. The invitation is basically a method to allow that user to validate their credentials.
And then when they respond to the invitation, their Azure AD account is updated to say, yep, this person-- we know them. They have validated their credentials. And they can then use that account to access resources from my tenants. It all works really well. So why have I got it up here?
The reason why I've got it up here is that because Microsoft uses Azure AD B2B Collaboration so extensively-- and as I said, will use it even more extensively within Office 365-- your tenant directory could end up with thousands of guest accounts. So this could be a management headache. For example, would you be worried if you looked at, say, your entire directory and found 4,000 guest accounts, only 300 of which are in active use? Is that a problem?
Some people say, nah, it's no problem because these accounts could be used in the future. Somebody might share another document with them. Somebody might add them to Planner. Somebody might add them to Teams. It's not a problem. But the point is that you've got to have a think about it. You've got to think through how these accounts are used and figure out, in terms of your security perspective, whether or not you want to keep guest accounts around in your directory long after they have been used, because there's no automated way to clean them out right now.
Now, you can actually write some code-- it's pretty easy to do in PowerShell-- to go and look at the audit logs to find out whether or not people are actually accessing Teams, or accessing SharePoint or whatever, and doing something, and then making the decision whether or not you're going to clean out those guest accounts if you want to.
The downside of clearing out a guest account is that once you remove a guest account from Azure AD, you remove all access for that account-- everything. So they lose all the sharing they have for SharePoint documents, for folders, for sites. They lose all access to Teams, to Groups, to Planner, et cetera. It's a pretty dramatic step to take. But it's a thing you should think about. Sir?
Yeah. I had that very thing happen. And so the level ones at work, in their infinite wisdom, decided to keep deleting and recreating [INAUDIBLE]. They had, like, seven different accounts basically that had duplicates of the same email address. It was a nightmare trying to figure out. And none of them ever had the same rights they had [INAUDIBLE].
Yeah. The important thing there is that if you go and recreate a guest account for an email address, it gets a new identifier. It gets a new GUID. OK? It's the GUID that's used to tie back to access to resources. So you could have multiple accounts for approximately the same address or approximately the same person. Different GUIDs, different access. So again, it's a thing to think about.
And then the last thing. What first and third-party apps are you going to use? Now, the first-party apps are things like the wiki, OneNote, files, stuff like that-- the Microsoft apps. A pretty simple decision about what you're going to use there. The big one that people have a difficulty with is, do we use the wiki which is stored in SharePoint, or do we use OneNote for shared notebooks and all the rest of it?
My sense is that most companies come down on the side of OneNote. I don't see a lot of enthusiasm for the Teams wiki, except from the Teams development group. But OneNote seems to be the most popular thing.
Third-party apps-- well, we now have a couple of really nice policies to help us control them. There's a setup policy that allows you to define what third-party apps are going to be presented to users in the app rail on the left-hand side of the client. And there's also a permissions policy that allows you to say, well, what third-party or first-party or custom apps am I happy for people to install in this tenant?
The setup policy has been around for a couple of months. The permissions policy is just rolling out right now. But again, it's a thing to start looking at.
OK. Some more questions. I have lots of questions. I'm sure you do, as well. Will there be any impact on your SharePoint deployment? Apart from having a whole pile of new sites created-- because remember, every team is a SharePoint site. And of course, we call them sites now. Site collections have gone out of favor. If you look at the Microsoft documentation, it's kind of interesting how they have changed everything to sites. Now we're moving away from the notion of a site collection.
Every team has a site. So will profusion of sites in your tenant cause you any problem? Probably not, except if you're thinking about things like if you're into backup or something like got, you may have issues there.
Will Teams help or hinder data governance? It's another repository, so repository needs to be controlled in the same way as other Office 365 sources like Exchange and SharePoint. It's a good thing that we've talked about the compliance records, how they're created. There are issues with them, sure, as I talked about. But you can actually do e-discovery against them.
And if necessary, you can export all those e-discovery records for a third-party investigation. So there's no real problem there, apart from it's not in a transcript.
Data loss prevention policies are supported for Teams. The way it works is that people are actually allowed to post items to Teams, and then behind the scene, as the item is processed through what they call the Aggregation Chat Service, DLP policies are applied at that point to pick up things like, hey, you're sharing some credit card information, you're sharing some social security numbers, or whatever sensitive data you should be blocked against.
And at that point, if a violation is detected, Teams will take the information and hide it from visibility. It'll make sure that users can't see it.
In terms of programming or automation, what have we got? Well, there's two things you can do. One is with PowerShell. There's a Teams PowerShell module out there. The thing about PowerShell that you've always got to remember is that PowerShell is administrative automation. So PowerShell is never going to give you access to actual content.
If you want to get to content inside a channel, for example, you're going to go to the Microsoft Graph. And I see people who have grown up with PowerShell. Maybe they came from the Exchange side. They worry about this because they say, how do I deal with this Graph stuff? Well, the interesting thing to do is to integrate both PowerShell and the graph together.
It's actually quite easy, and Microsoft has done a good job of this. And the basic concept is that you define an app inside Azure Active Directory. You give the app permissions to get to various things, like Teams channels. You then connect to the app with PowerShell, and then you start sending in web HTTP requests using the Invoke Web Request commandlet. They get processed. So it's really, really quite straightforward.
And then once you've got access through the Graph, you can get to some information that Microsoft does not expose in the Teams PowerShell module. One example of this is those email addresses. Remember we talked about them earlier? Channels can have email addresses. Channels can also have, or teams also have, renewed date-- the date that they were last renewed.
And they have expiration dates-- the date that they're due to expire. That kind of information is not exposed through PowerShell, but it's available through the Graph. You can get to that type of stuff quite easily.
But of course, introducing a new programming language or new access-- it's going to require people to skill up. It's going to require people to actually know what they're doing. And that's a thing to put into the plan.
And then the last thing here-- measurement. You've done all this planning. You've done all the deployment. How are you measuring what's happening? How are you going to measure what's happening? Now, you can say, yep, I'm going to use the standard, out-of-the-box Office 365 reports. Two things to remember. One, they're not very granular. And the second thing, they're always at least two or three days behind the curve, because there's all of this background processing that has to happen before Office 365 generates those reports.
So after all that, what is my weekly management task? What's the list that we're going to do? Well, the first thing I think any admin is going to do is kind of figure out what's happening inside Teams. What's changing? Things will change. If the admin doesn't know about what's changing, they're deficient in their duties, because something could change that will impact users, like the advent of private channels. That's a big change.
But there are lots of other small changes, like urgent messages being supported, like read receipts being supported, like Teams moderation, channel moderation. That was a big one recently, the ability to moderate who can post to a channel and to assign a group of people who can actually check stuff to allow it into a channel. OK?
So assuming that we know all about that stuff, then here's a couple of things that I think you should actually have at your fingertips. You should have this data. You should know this data. How many teams have I got? What teams are active? What are my problem children? What are the teams that might expire? What are the teams that are not being used? Why are they not being used?
Do any of the teams that are not being used contain confidential information? If I was to delete the team, would I lose, for example, some important documents in SharePoint? Do I have retention policies on to make sure that stuff can't be deleted automatically? That kind of thing.
So I want to know, what are my active, what are private, what are public, what are the largest teams, the most active teams. How many org-wide teams are in place and why are they being used? Are they being used? Are they being used effectively? Et cetera, et cetera. I'd like to know, what are the most recent set of teams that have been created? And I'd like to know a reason why.
Again, if I can't say why a team was required, why was that created? Who created it? When did they create it? Why did they create it? You should be able to tell me that. And then the type of volume of activity. Type of activity we want to know is what channels are active? How many messages are being posted to each team? How many private messages are going on? How many chats?
What type of meetings are going on? Are we using the Microsoft voice system-- the phone system? Are we talking up calls? Are we using video meetings? How effectively? That kind of stuff. I'd like to know all about that, because you think at the end of the day-- come back to where we started at. We had a plan. We had an intention. We had a reason why we were going to use Teams.
Well, if I can't measure what's happening, and I can't say in a little like 40-second conversation with the CEO in an elevator, yep, we got 292 teams. 90% of them are active. We're seeing a steady growth in messaging. We're absolutely having phenomenal success with Teams meetings. People really like it. We've had 42% growth in the number of hours of meetings, et cetera, et cetera. If you can't have those basic statistics, then you're not doing your job. You're not managing Teams.
And the last thing-- security or any problems. Where do you find that information? Because Microsoft isn't going to tell you about [INAUDIBLE]. That means that you've got to keep your eyes peeled. You've got to use informal sources, like Twitter, and blogs, and stuff like that to figure out what's really happening at the cold front with Teams.
Now, a note of caution about blogs. In the world of Office 365, a blog is like a dead fish. After three days, it goes off. And the longer the blog is in existence, the more it's likely to smell. It's just the way it is in cloud. So I guess what I'm saying here-- I'm giving you a health warning with blogs. Read them, but don't assume that everything that's said in a blog will either work or is still accurate as of today.
You've got test it against Teams. And that's depressing for those of us that write blogs. It's very, very depressing, because the thing about blogs is very, very few people actually go back and revise their blogs. Once a blog post is written, it's written. It's out there. It's in the internet. I'm happy.
OK, so really now towards the end. Where do you get success with Teams from? Well, clear goals. Absolutely. Understanding the strengths and weaknesses of Teams. Like, it's not going to replace email. Why is it not going to replace email? That's a weakness. But what it can do, it can reduce a lot of the email that is sent inside the organization and put them into conversations where everybody can see it.
Having a structured set and managed by policies. That's goodness. Having an ad-hoc structure which is not policy-driven is [INAUDIBLE]. Monitoring-- knowing what Teams is doing in the organization. If you don't know that, you're deficient.
Communication with end users-- tell them about new stuff that's happening. One of the recent changes was the advent of announcements. This is just a way of highlighting a post. It puts up a graphic at the top of the post, and they can put big letters in there to highlight that this is an important post. Now, to an administrator, announcements? That's really ugh. It's not very important, certainly not as important as private channels will be.
But to an end user, that's really important, because end users like the ability to highlight their conversations. So you should communicate with people and tell them about the changes that are happening.
And the last thing, I do really think that you need to have a sustained, and strong, and obvious executive leadership. Somebody's got to be responsible for teams within the organization, and they've got to be high enough in the organization and willing enough to stand up and say, we're doing this. We're doing Teams because X, Y, and Z.
Now, you may have to coach them a little, but executives are coachable sometimes. OK? But you do need that.
So to finish up, three things to take away. Have a plan. Know what you want to achieve with the plan. And measure it. And if you do that, you'll do OK with Teams. And I have five minutes now for questions. If anybody would like to-- yes, sir?
OK, so the question is about archiving Teams. It's pretty inevitable if you spin up teams for projects, for example-- that would be the best example-- a project is a time-limited activity, often. Some projects go on forever and ever, and ever, and ever, and ever, never complete, but a lot of projects do finish after a certain time. And the question then is, how do you archive?
And I guess there's two ways of doing it. You can take the way that Microsoft does it, which is they essentially put the team into a read-only state. It's still there. It's still obvious. It's still available. But it's read-only, so you can't go and create new conversations [INAUDIBLE].
That's OK. However, I prefer a different approach, which is once I am absolutely happy that the team is no longer needed, but I still want to keep it around, what I do is I just take away all of the membership of the team except for a single member. The member is a special account that is there for that purpose. It's to allow access to archived teams.
And then I remove any trace of it. It's not available to users, but everything is available online. What that allows me to do then is that if, for example, somebody says, I really need access to those documents, that's fine. We just add them to the team. Bang, it's online, and they're away.
[INAUDIBLE]
How do I keep this group getting deleted? Don't use an expiration policy is one way. Actually, we had that conversation this morning in Twitter. If you use a group expiration policy, how do you make sure the really important groups don't get removed, even if they're not very active?
Write a script, just read something.
You can write a script which will go and check the attributes on the group and keep on renewing it, if you want to. That's one way of doing it. Another way is to write a script which reports all of the groups that are about to be removed, and go and take action that way. There's lots of different ways of doing it. It just depends on the way your company works.
The joy of PowerShell is that all of this stuff is out there on the internet. It's just a matter of going to find it, finding the scripts and adopting them for your purpose. So that's what I would do. Any other questions? Sir?
This is a question regarding migrations [INAUDIBLE].
Migration?
Yeah.
To?
[INAUDIBLE]
So don't say it like that.
OK. Well, I have to say it like that. OK, so the big problem with tenant-to-tenant migration--
I [INAUDIBLE] know the problems, but--
What's the big problem?
Yeah. So--
What's the big problem? I asked you.
The big problem is that there are no tools that are can [INAUDIBLE] everything that's in Office 365 right now, especially--
That's not the problem.
That isn't?
No. The big problem is that Microsoft has not delivered a migration API. OK? That is the big problem. For two years, Microsoft has been talking to ISVs, for two years, and promising them an API that would allow them to move stuff from one tenant to another tenant.
[INAUDIBLE] identity [INAUDIBLE]
Oh, the identities are easy. It is really easy to go and provision Teams, move users across, all that kind of stuff. That's really easy. The problem is getting at the conversation information and moving that across in a way that's still accessible on the target tenant. And even more so, to deal with personal conversations. That's the biggest problem. All the other stuff like tabs, and connectors, and third-party apps, and all the rest of it-- that's probably going to be done manually anyway.
But the two fundamental things are, you've got to be able to move channel conversations. You can certainly move channels, no problem. You can move channel conversations in a kind of a way. If you look at what BitTitan have got, what AppPoint have got, what the other vendors that are out there-- they're all the same thing because they're limited by this API.
It's a beta API, so what they do is they read conversations out of the source tenant that goes into an HTML chunk and they post that to the target tenant. But all of the replies are concatenated, so you get this one blob of text kind of thing, and it's got different dates, et cetera, et cetera, et cetera. It's not a great solution and Microsoft has got to fix that.
Believe me, this is a source of some concern, agitation, and passion in the ISV community.
So [INAUDIBLE] is regarding migrating Teams. But this question was regarding guest access.
So a guest user is simply an Azure AD object. It's an account in Azure AD. One of the properties in an account is the mail nickname, which will give you a UPN-- a User Principal Name-- which you can match against the target tenant. So if the guest user from tenant A actually happens to be a user in tenant B, it's not an act of computer science mystery to do that check and make sure that the team membership is updated properly on the target tenant. Otherwise, it's just--
[INAUDIBLE] there's no gaps, then?
Yeah, you just go and change-- all you have to do is update the team membership because the team membership ties back to the Azure AD account. So if you've got the team membership updated, and it's pointing to the right set of members and the right set of guests on tenant B, you're golden.
[INAUDIBLE] manual remediation?
No manual-- no, no, no, no. This is easily automated. OK, we're over time. Thank you very much for attending.
[APPLAUSE]
I hope the information wasn't too boring. Oh, hold on. Before you go, look. If anybody would like a copy of Office 365 for IT Pros book, I'll give it to you for $10 off just because you lasted until the end of the presentation. OK. Listen, enjoy yourself.
[MUSIC PLAYING]
Have a great time at the rest of TEC. It's nice to see TEC back, isn't it?
Woo.
Oh, OK. One person. Best of luck and have a great day.