Taming Office365 & SharePoint On-Line

by Martin Erasmuson

Your organisation has likely gotten caught up in the world-wide trend of migrating to Office365 and SharePoint on-line.  In doing that you have probably had conversations with various IT staff where you’ve heard words and phrases like: “Teams, Dynamic Groups, Channels, AIP, Flow, LogicApps, PowerApps, evergreen” to the point where it sounds like English, but you have no idea what they’re talking about, let alone understanding the risks and advantages. 

While I’m a seasoned Information Management Consultant and Architect, I still consider myself a simple boy from rural New Zealand and I too had to negotiate the turns and pitfalls, terms and jargon in getting my head around Microsoft’s new cloud environment.  In doing that I’ve managed to unpack it sufficiently that this simple lad can understand it.  This blog then is for non-technical, or once-technical Senior Managers who are tired, confused and/or frustrated by the mumbo jumbo and are looking to move their organisation to O-365 and SharePoint on-line, while avoiding the pitfalls along the way.  I’ve whittled it down to what I believe are the key elements, the pros and cons for each with a high-level implementation guide. 

I’ll follow it up with subsequent blogs focused on different areas and digging a bit deeper into some covered here.

Your comments and feedback are welcome.

At first glance, Windows 10 and Office365 looks much like your on-premise environment.  Yes, you will continue to use Office applications (Microsoft, much like the rest of the planet, now refer to these as ’Apps’ – Word, Excel, PowerPoint etc.), and there is a reasonably similar-looking SharePoint to save my documents in.  Great.  But there’s a whole lot more going on in the underlying mechanics (architecture) of the O-365 cloud environment, and therein lies some real advantages but also some significant risks.

In the introduction I mentioned ‘Teams’.  At first glance, Microsoft Teams looks to be ‘just another app’.  Don’t be fooled.  Teams is at the heart of Microsoft’s Modern Workplace initiative, an ‘umbrella’ for their platform and tools for collaboration, security and compliance, operating system (Windows 10), and SharePoint on-line.  Microsoft’s vision is that ‘Teams’ will become every knowledge workers’ hub of operations; users will ‘live’ in Teams for communications and collaboration.  Within that Microsoft vision, SharePoint will be relegated to a mere content store, interacting with other Microsoft architectural elements behind the scenes to enable various automated governance outcomes (information security, data loss protection, retention and disposal and loads more) but users will pretty much live in Teams. 

Back in July 2019 Microsoft announced that Teams is their fastest growing ‘app’ ever, surpassing over 13 million users (and 20 million by Nov) which would seem to support their vision of where Teams is headed. 

The upshot:  your O-365 strategy needs to include Teams at its core.

Teams in a nutshell

Microsoft Teams (Teams) is basically a front-end user interface to a bunch of previously separate tools, functions and applications; both desktop and mobile (the latter of course in the Teams mobile app for Windows, Apple or Android).  It incorporates messaging (text, voice and video - and will eventually replace Skype for Business); create and save content (documents, files); collaboration and sharing with other users. 

Most organisations with a legacy on-premise Microsoft environment had their IM Strategy centred around SharePoint.  Within their new Teams-based architecture, Microsoft relegate SharePoint to a mere content store (for various documents and content, much like the database with an application on the front-end).

Teams basically employs a Folder hierarchy where the Team (name) is at the top level, and Channels under them.   Channels are similar to sub-folders or themes of the Team e.g.

  • Team Name: “Office Christmas Party 2019”
    • Channel Name: “Catering”
    • Channel Name: “Entertainment”
    • Channel Name: “Gifts & Santa”

This Team/Channel folder structure is stored in the associated SharePoint on-line Site.  That is somewhat simplistic, but that’s the gist of it.

If you can tolerate the Microsoft ‘Kool-Aid’, I’d recommend looking at this two minute YouTube clip.  It is an adequate overview and will give you some context for the rest of this blog.


The Teams interface is ultimately designed for the busy ‘Knowledge-Worker’ allowing them to create new Teams, add Channels, save chat and emails, create and save document and interact with other users around the office or world, all within the Teams environment.  And when they’re done with a Channel or an entire Team; they can discard it.  Then rinse and repeat.  Simple right?


A key rational at the heart of Microsoft’s new strategy is the idea of self-service.  Indeed, at a certain level, self-service is Office 365, making cloud-based collaboration the most flexible, efficient and productive i.e. if a user wants something; anything, they can create, enable, share or download it by themselves.  Unsurprisingly then, out-of-the box configuration in your new 365-tenant will enable self-service to the maximum extent possible.  That is a double-edged sword.  While it supports the here-and-now approach; unchecked it will cause you longer-term pain AKA ‘Information Debt’.


You cannot talk about Teams without talking about Groups.  Office 365 Groups (Groups), are distinct from Security Groups that your IT folk manage in Active Directory (Azure Active Directory [AAD] in the cloud environment). 

Groups are used for collaboration between users (i.e. members of Teams); so before you can create a Team you must first create a Group.  At first telling that doesn’t sound like a big deal, however, within the default self-service Microsoft environment there 20 different places (right) where any user can create a Group (and this was as at August 2019, so by now, likely more). 

Within the Microsoft default self-service environment, a user first creates a Group and from there can create or get by default a Team, SharePoint Site (Group email, Calendar, Planner and more). 

Many organisations I’ve spoken to report what I’ve termed ‘Groups-Lust’, where, via one of those 20 options, users have created hundreds of Groups, Teams and SharePoint Sites in just a few weeks.  Those same organisations report they are slowly working to unpick the mess.


In your on-premise SharePoint environment, your organisation likely created some logical structure; possibly based on your Org Structure or Functions, to make it easier for users to navigate to Sites and find content.  Typically hanging off that structure is a bunch of Folders, capability and activities including Metadata, Security measures and Retention and Disposal schedule to name a few. 

Out-of-the-box Teams ignores your structure and will save Teams generated content (including: Documents, Chat, Team Mail (distinct from personal email), External Mail, Wiki Page, Channel OneNote and Personal OneNote) to different default locations (see below)) i.e. not within any logical Site/Folder structure your organisation might have created.  So in addition to any other place you have content (File Shares, Confluence, Flowdock, GoToMeeting, Slack, WebEx, Trello, DropBox), Teams will create for you, all on its own, a bunch more.


Having created that content, the 365 default configuration also allows any member of a Team to delete a Team Channel, and with it much of the content.  While related documents will remain in the associated SharePoint Site, albeit in the Teams default location, other content including Channel conversations (chat) is (after 21 days) permanently deleted.  How does that fit with your compliance/audit obligations?


By default, Teams enables a user to save content directly to their personal Google Drive and/or Dropbox.  (The image below is a screenshot from within the environment of corporate site where I saved a Word document titled: ‘Very Important Document’ to my personal Google Drive (note the document contained no content, it was just for an example.  Please don’t shoot me!).  Again the reader can likely draw their own conclusions regards actual or potential issues regards that.


By default there are over 200 different ‘apps’, (both Microsoft and 3rd-party) a user can ‘add’ to their Team.  While many are really useful, others represent that classic ‘ShadowIT’ risk where a user can simply buy (with their credit card) and/or install a 3rd party app and then fill their boots creating and saving content to heavens-knows where.


In conversations with many SharePoint administrators, they reported that the default Microsoft self-service approach resulted in a bunch of intractable problems including:  a proliferation and duplication of Teams, SharePoint-Sites and associated content (in one case thousands of Sites in just a few months, and content outside their corporate structure and sitting in the various Of365 default locations);  other content subject to New Zealand’s GCSB information security classification residing in insecure third-party locations including Google and Dropbox;  difficulty for Users navigating to and finding content;  duplicated content (though to be fair, this is not new);  inappropriately deleted content; plus a change management legacy i.e. having rolled out all the functionality by default as an ‘all you can eat buffet’, users were unhappy when they had to go on a diet i.e. when functionality was managed or disabled. 

Implementation Approach

In the introduction we asked the question: ‘can we have our cake and eat it’ i.e. is there a sweet-spot that provides the maximum amount of Office 365 capability while mitigating the issues discussed above.  Here is my recommended high-level implementation plan to do that.


Disable them (they will disappear from the UI).  Yes, technically a user can still log-into and save content to Google or Dropbox anyway (though many organisations block the latter) but removing the option for the Teams UI avoids any confusion having it as an option.


Possibly the most important action.  You have more or less three options:

1.            Enable self-service group creation for all users (default setting)

2.            Limit self-service group creation to a select pool of users

3.            Disable self-service Office 365 group creation entirely

Each option has pros and cons depending on your perspective; i.e. User, Helpdesk Team, IM Team.


This is the Microsoft default setting giving you the issues described above.  Think toddlers at an all-you-can eat buffet birthday party.  What could possibly go wrong!


This is a ‘chop off your nose to spite your face’ option.  This has three major trade-offs:

  • There will be an administrative overhead with someone (Helpdesk/IM Team) forced to deal with a constant stream of requests from Users wanting Groups, Sites or Teams
  • User will use other methods and approaches to do stuff, thus contributing to “shadow IT”.
  • It stymies the value behind rolling out by Microsoft Teams in the first place


This is my recommended approach.

This approach would create a security group containing only a small/select number of specific users.  It might include your Helpdesk staff, your IM Team, some existing SharePoint Site Administrators and a small group of ‘in the business’ IM Subject Matter Experts.  Self-service group creation is disabled for everyone else.  Users wanting a new Group, Team or Site will need to go through their local, team-based SME or one of the other support channels (IM, Helpdesk etc.) with a streamlined process.

This process tips on its head the default Microsoft approach, and for good reason.


This process is undertaken by one of the people in the security group described above.

  • Encourage User to search for an existing Team they can join
    Failing that………..
  • User makes a request, with brief description/reason/purpose for (Group, Team, SharePoint Site - Develop some simple Team and Channel creation and naming criteria/guidelines that your Security Group follow (use the KISS approach!)
  • Is there an existing Group/Team? – there might already be one they can join?
  • Do they need:
    • Group only (just for email)
    • Group and SharePoint Site Only

Group, SharePoint Site and Team

  • IM/SME Security Group member:

1. Creates new Group (name it based on guidelines) and add requester as owner (Group owner/members can add other members later; or user can join a Public Group themselves)

2. Creates a new SharePoint Site (in the appropriate place within the agreed organisational structure

3. Creates a new Team off the SharePoint Site.



  • Step 2 and 3 above are key.  Rather than Teams creating a SharePoint Site in a random location, using the above process first creates the SharePoint Site in the appropriate part of your organisations SharePoint structure, and then hangs the Team off the Site (rather than the other way around)
  • Content saved from Teams automatically goes to the right place
  • Automated Governance (Metadata, Information Security, Retention & Disposal proceeds as before)
  • Team members still get their Team with all the requisite functionality

This approach gives you the sweet-spot, maximising Teams capability while still having appropriate Governance.


Above we mentioned there are over 200 Microsoft and 3rd party apps available for Teams.  While most will be benign from a security point of view, others will have tabs, connectors, bots, or any combination thereof that are or could be sending sensitive or confidential organisational information.  

I recommend a semi-permanent Working Group comprising Information Management, Security, Technical and User representation to agree criteria for enabling and/or disabling available Team Apps.

First, do a high-level pass to categorise apps in three categories, some like:

  • Yes, full your boots
  • Maybe, tell me why (with a process similar to Team/Group request)
  • Not over my dead body (apps that duplicate existing capability, or pose some other security risk)



With the release of Windows 10 software-as-a-service platform, Microsoft moved to an ‘evergreen architecture’ (PWC description right).

This is a double-edged sword.  Microsoft can and do update, change, move and remove ‘bits’ of the overall system at will.  While they might argue that such changes are in the various release notes, whoever reads those!  Yes, while this approach reduces the IT support overhead, it can compromise your existing change management approach, particularly around training and support.

By way of example, while working with a customer on their 365 migration, the ‘Protect’ tool (below) appeared one morning on the Office Apps (Word, Excel, PowerPoint) Home menu-bar.  On opening this it included the options: ‘Custom Permission’, ‘Track and Revoke’.  While one of these options did nothing and the other took you to an innocuous Microsoft website, there was no context for users.  Worse, in the several weeks it took to pull together a meeting of appropriate IM, Security and Change Management staff, discuss and agree options; a subsequent Microsoft upgrade removed the Protect Tool!

Regular evergreen rollouts by Microsoft can also impact training and comms materials where written and screen-shot information can become outdated literally overnight, without warning.

There is not much you can do about this excepting:

  • Include an explanation of the ‘evergreen’ Microsoft approach, including unexpected changes, in your training and comms, indeed encourage users to report/blog what they find
  • Use a ‘good enough is perfect’ approach to your training materials
  • Expect change and be agile and adaptive


What next?

********** CAUTION – SALE IN PROGRESS **********

Read anything here you want to discuss?  Please feel free to call or email.  The first conversation is free.

Martin Erasmuson

Mobile: 64 27 904 9191

Email: martin@stratsim.co.nz

This article originally appeared at https://www.stratsim.co.nz/new-blog/2020/1/26/taming-office365-amp-sharepoint-on-line


Sites, Libraries and Channels

Legacy data migration – issues and strategies

Workflow – harder AND simpler than you think

FTP and data sharing – a whole new world