Adding the SharePoint Starter Kit

If you have a look at all the web parts you have available to you in your current SharePoint environment,


versus what I have available,


You will see that I have quite a few more! The good news is that it is easy to add all these plus a range of additional features using the SharePoint Online provisioning service.

The easiest way to add all these features to simply visit the SharePoint Starter Kit option


and use the option in the top right of the page to Sign in as a Global Administrator for your tenant and then select the Add to your tenant button on the right as shown above.

However, before you do that you’ll need to ensure you have completed a few pre-requisites. Firstly, that your tenant is on Targeted Release.


You’ll find the setting for that in the Office 365 Admin Center, under Settings and Organizational profile as shown above.


You can use the Edit button to make changes to the setting.

If you do change the setting, it may take up to 24 hours for that change to be fully applied to the tenant. Making this change may also affect other areas of your tenant, so I suggest you review the following documentation:

Set up the Standard or Targeted release options in Office 365

Next, you need to ensure your tenant has an App Catalog. To see whether it does, locate the SharePoint Admin console.


If you are taken to a newer version of the SharePoint Admin console, as shown above, select the Classic SharePoint admin console option on the left.


At the “Classic” SharePoint Admin console select apps on the left.


Then select App catalog at the top, on the right as shown above.


If you don’t already have an App Catalog you need to select the option – Create a new app catalog site and then select OK.


It is recommended that you use the following settings here:

Title = Apps

URL suffix = apps

Administrator = Global or SharePoint administrator

Once you have completed these details select OK to create the site.


In a short while you should find that you have a new SharePoint Site Collection, as shown above, with the details you just entered.


If you already have an App Catalog or you just created one, when you visit that URL you should see a site like that seen above.

The final pre-requisite that you need to configure is some permissions on the SharePoint Term Store.


Once again, from the “Classic” SharePoint Admin center, select term store on the left. Then scroll down on the right and locate the Term Store Administrators option and enter you Global or SharePoint administrator in there again.

Scroll down to the bottom of the page on the right and Save the changes.

Now that all these pre-requisites have been configured, return to the SharePoint Starter Kit option:


and select the Add to your tenant button on the right.


You may see a message about providing permissions, which you should accept. You’ll also see a summary of what will be provisioned as shown above. You’ll basically get all the new features plus three new site collections.

Select Confirm to continue.


In a short while you’ll get a number of new SharePoint sites like that shown above that you can explore. Importantly, you also get additional features and web parts across your whole tenant.


If you return to the App Catalog site and select the Apps for SharePoint option on the left, you will that the SharePoint Starter Kit solution appears as shown. This is the item that delivers all the new features to your environment.

The above sequence is the easiest way to deploy these add on features but what happens if you wish to do this manually and not get the additional demo Site Collections the above deploys?

You’ll still need to ensure the pre-requisites from above are completed (enable Targeted Release, have an App Catalog and modify the permissions on your SharePoint Term Store). Once these are complete you need to visit the sp-starter-kit GitHub repo:

and download the file sharepoint.starter-kit.sppkg here:


You then need to return to the Apps for SharePoint location in the App Catalog


and upload the file sharepoint.starter-kit.sppkg here.


The file is about 7MB so you’ll need to wait while the file uploads into the library. You’ll the progress as shown above.


Once the package has been uploaded, you’ll see the above dialog boxing asking you to Deploy it. Before you deploy, ensure the option to Make this solution available to all sites in the organization is selected.

You may need to wait a little while for the package to roll out to all areas in your tenant. In most cases, this won’t usually be more than a few minutes.


You should now see all these new web parts available to you in your modern pages within all sites in your tenant.

Remember that the SharePoint Starter Kit is available in GitHub and will continue to be updated over time. As it is, simply upload the new package into your App Catalog to gain access to the new features.

Using the SharePoint Starter Kit should give now you lots more options when working with SharePoint and all for free!

Your collaboration structure should be wide not deep

In previous articles I’ve provided:

A framework for file migrations to Microsoft 365


Processes for file migrations to Microsoft 365

In this article, I’m going to focus on the next level down and how you should be thinking wide not deep when it comes to transforming your data into Microsoft 365.

In essence, structure is not as important as it once used to be. Having layers and layers of directories and sub-directories in a file share was really the only way to catalogue and organise your information in the world of on premises. However, structure becomes far less important in a world where everything is available via search. Think about it, how do you find stuff on the Internet? You search for it. Why then should internal data work any differently?


Search is built into Microsoft 365 and now appears at the top of most pages as you see above.


For example, if I do a search for “bitcoin” then I’m returned results from that location, in this case a list.


Not only do I have search, but thanks to the Microsoft Graph and some “AI” magic I can get a feed of my most relevant documents in Delve. I can also see documents others are working on that are also relevant to me and that I have permission to, again all in Delve.

So, the concept of structure is less important than it used to be, especially the deeper you go. It more becomes a case of get it into some major buckets and we can filter and sort from there.

Let’s say that there is an existing on premises folder structure like so:




and so on. How do you ‘transform’ this into the new world of Microsoft 365? Best practices is to start at the top and work down. Thus:


is going to be the initial bucket. This means that you should either create a Microsoft Team or a SharePoint Site called “Finance”.

Once you have a Microsoft Team called “Finance” then you would probably create a Channel called “Customers”. If it was a SharePoint site then you’d have a Document Library called “Customers”.

Inside the Microsoft Team called “Finance” and the Channel called “Customers” you have a folder in the Files area called “ABC” and so on for each customer.

At this point we have now reached “Robert’s rule of three” maximum structure depth. That means we have a Microsoft Team, a Channel and a folder. We don’t really want to create anything deeper if we can avoid it. This is where “metadata” comes to the rescue. Perhaps, instead of a a single Channel or Document Library for customers, maybe you have a unique library for each? The choice is yours.

If we look at the structure of the source data, we see that is broken out be year. However, we can create a custom column in SharePoint that contains the values of “Year” and use that to ‘tag’ our data. Thus, you create an additional column in the Document Library where the data lives. You specify that the only values allowed in the column are numerical years. You then set that field to the appropriate value for each file.


In the above example, you’ll see that I have created an additional column called “Customer” and used that to tag both files and folders.

Thus, metadata allows me to collapse my structure by using tags, which in many ways is what people used folders for on premises. Once I have tagged my data I can easily sort and filter it like so:


Here it is “grouped by Customer”


Thus, with metadata you can create a much flatter structure because you don’t need all those sub folders. The benefits of a flatter structure is that it is easy to see more of the data quickly and then using the inbuilt filtering tools to get to what you want. Typically, you’ll only be using this filtering technique if you haven’t searched for the data or had it presented to you via Delve. However, for those that still like to navigate a formal structure, it is still possible as you can see.

My best practice is that every time you are considering going more than three levels deep, you should break the data into another Channel or Document Library. Remember, you can create as many Document Libraries as you want in SharePoint and then also link them back into Microsoft Teams if you want. You should be looking to use lots of Document Libraries and keeping them no deeper than a single folder as a rule of thumb.

The other benefits of using additional Document Libraries is that you can have a different set of metadata to describe your information. You can also have a different set of permissions as well as a different look and feel thanks to SharePoint Views. A wide structure in general makes more things visible to people when they go looking, rather than it being buried deep within a folder structure and lost.

Thus, most of your top level folders from on premises file servers will become independent Teams or SharePoint sites. Subfolders below these will become Teams Channels or unique Document Libraries in SharePoint. It is also always better to break deep structures into different Document Libraries and link them back into Microsoft Teams if required.

Remember, moving to Microsoft 365 is about “transforming” data and restructuring it in a ways that users will benefit most. This means keeping it as shallow as possible and using inbuilt tools like filter, sort and search to get to your information rather than constantly navigating up and down deep structures. Services like Delve will also present to you the information you need most times and so you won’t even have to go searching for it. Simply ‘dumping’ data from an on premises file share into a single Document Library is not providing any value or transforming that in any way. If you aren’t going to do that why are you even bothering to move it?

As I have said previously, transformation requires effort, it doesn’t magically happen. However, the point of migration is the opportunity to transform data so that it can take advantage of all the tool Microsoft 365 provides. Also don’t forget that you don’t have to do all of this transformation in one hit. Create the Microsoft Teams, Channels as a starting point at least, then add metadata across the data down the track. Likewise, if you want to make a change down the track you can. That’s the whole idea with Microsoft 365, it is something that will evolve over time as the business does. It is never a once off migration process without future change. Never!

Microsoft 365 gives you the resources and tools to go wide not deep with your structure. Start my replacing some of your sub folders with metadata fields as illustrated above. Doing so will enable your business to be far more productive than it ever was with deep on premises file shares. Remember, moving to Microsoft 365 is about transforming not merely migrating.

Cloud App Discovery/Security

Microsoft has a range of security options available, delivered in a variety of ways from the cloud. I’m going to focus on three items that tend to get lumped together and with which I see much confusion. These services are:

1. Azure AD Cloud App Discovery

2. Office 365 Cloud App Security

3. Microsoft Cloud App Security

Here’s a summary of the differences between the products:


1. Azure AD Cloud App Discovery

This is the most basic of the three services and is only available when you purchase and license Azure AD P1, there is no stand alone version of just Azure AD Cloud App Discovery. This is a description of the product:

Azure Active Directory Premium P1 includes Azure Active Directory Cloud App Discovery at no additional cost. This feature is based on the Microsoft Cloud App Security Cloud Discovery capabilities that provide deeper visibility into cloud app usage in your organizations. Upgrade to Microsoft Cloud App Security to receive the full suite of Cloud App Security Broker (CASB) capabilities offered by Microsoft Cloud App Security.

Thus you receive Azure AD Cloud App Discovery when you purchase the following:

– Azure AD Premium P1 (stand alone)

– Azure AD premium p2 (stand alone)

– Microsoft 365 E3 (which includes Azure AD P1)

– Enterprise and Mobility Suite (EMS) E3 (which includes Azure AD P1)

When you visit the portal you will see:


Firstly, note that the banner reads Cloud App Security like so:


2. Office 365 Cloud App Security

This is available as a stand alone purchase for existing Office 365 / Microsoft 365 tenants.


You can also get Office 365 Cloud App Security as part of:

– Office 365 E5

You’ll see Office 365 Cloud App Security in the top left of the portal like so:


The biggest advantage I believe of Office 365 Cloud App Security over Azure AD Cloud App Discovery is the Activity policies like so:


These activities includes built in anomaly detection for things like Impossible travel like so:


You also get a number of default activity policies like Logon from a risky IP address:


as well as the ability to create your own unique activity policies and alerting.

3. Microsoft Cloud App Security

This again, is available as a stand alone add-on to any Office 365 / Microsoft 365 tenant, being a tad more expensive that office 365 Cloud App Security:


It is also available when you purchase:

– Microsoft 365 E5

– Microsoft 365 E5 Security

– Enterprise and Mobility Suite (EMS) E5

As you can see from the table at the top of this article, Microsoft Cloud App Security includes everything (plus more) that is in Azure AD Cloud App Discover and Office 365 Cloud App Security. Thus, think of Microsoft Cloud App Security as Azure AD Cloud App Discovery + Office 365 Cloud App Security.

This is what you see when login to Dashboard:


You’ll see it look very different even though the top left says “Cloud App Security” again. You get far more options that with either of the other two including more options under Investigate like so:



Not everything is quite as simple as I have outlined here. Deeper detail about the licensing can be found here:

or on:

Microsoft Cloud App Security

In my opinion Azure AD P1 is a must have for all tenants to get features like conditional access and trusted IP’s. That will give you Azure AD Cloud App Discovery. However, I’d also recommend also adding Office 365 Cloud App Security as a minimum to get access to the Activity alerts. if you want even more power then add Microsoft Cloud App Security instead.

The final question I get is whether you require a license for all users in your tenant? For that I will leave you with the official word from Microsoft on that topic which is:

“Each user must be licensed for Microsoft Cloud App Security to use or benefit from it. For customers who license a subset of users, services enforced at the tenant level are not licensed for the other users. They are not entitled to use or benefit from the service, regardless of whether the service is technically accessible.”

A framework for file migrations to Microsoft 365

One of the major points of confusion and poor execution I still see today is the approach that many take to migrating files to Microsoft 365 and Office 365.

Many years ago I wrote a number of articles about this:

The classic SharePoint migration mistake

SharePoint Online – Pilers and Filers

SharePoint Online migration – Start up is key

and all of that is still valid and I recommend you read it, however the technology has moved on somewhat and it is now perhaps time for an update.

What I’ll cover here is a framework for migrating on premises data, typically on file servers in network shares, into the collaboration tools in Microsoft 365. And that’s the first point. You need to look at this across all the services Microsoft 365 provides you today. Not just SharePoint. Not just OneDrive. And not just Teams. Microsoft provides a range of services that you should consider in this file migration process.

Now many claim that because of all these options it is too complex and therefore you should just dump your data in one place. I can’t tell you how many times I’ve see exactly this, everything from a file server F: drive dumped into a single Document Library in SharePoint. Oh the pain.


The secret of success is to have a “system” and not do things randomly without thought. Thus, my framework is shown above. Now let me break down the pieces for you.


You firstly start with the source (on the left i.e. a file server drive) and the destinations (on the right, i.e. collaboration services in Microsoft 365).


The first step is to filter the source information and remove (yes I said DELETE) stuff that doesn’t make sense to move. Old and duplicate files are example but I have highlighted this in more depth in a previous article:

Data discovery done right

Thus, you should now have less data to move because you have thrown some away. If you haven’t then you are not being serious about this. You should also have a better idea about what data to archive, what is user data, what is common data and so on.


With the remaining good data you move (yes, I said move NOT copy) users personal data to their OneDrive. You actually get them to do that so firstly they get familiar with the new environment, they move only what they want to keep and you crowd source this task reducing the workload. We all know that some people will never ‘get around’ to moving their data, so after a suitable time period has elapsed you move it for them. The typically data that is moved in this process is anything on the desktop, home drive or in user profiles.


Next, is to identify the common data by function or location and move it to a Microsoft Team. In a typical on premises file server the existing shares you will find data stored in folders like F:\Finance and F:\Administration and so on. These top level shares are most likely going to be the name of the Team and the next level down folders to be the channels inside that Team. In many cases, users may also wish to ‘clean up’ the existing or ‘start fresh’, which is also fine. However, it is relatively easy to find the data that should go into a Microsoft Team and move it there.


The next data to move is common data that makes sense living in it’s own dedicated SharePoint Team site. Data that goes into stand alone SharePoint is data that does not require chat and conversations around it, Teams is where that data would live.

The best example here is probably Archive data. This is data the business want to keep ‘just in case’ but won’t be updated by users. Thus, you move the archive data as is, into it’s own designated SharePoint Team site, mark it as read only for everyone so they can use it as a starting point if they need to. The major advantage of moving the archive data to SharePoint is that it is now searchable using the tools in Microsoft 365.

Another good example of a stand alone SharePoint Team site would be an Extranet from which you want external parties to come and download data. Having a stand alone SharePoint Team site makes managing securities much easier.


The data that is now left is typically company wide data like policies, procedures, manuals, etc. This is then moved into the traditional ‘Intranet’ using a nice pretty SharePoint Communications Site. This Intranet is available to all and typically used to consume data i.e. get something, read something. New data for this Intranet comes from the output of the individual Microsoft Teams created earlier. For example, imagine the Finance team produces an annual budget. They do this creation inside their own Team and publish the finished result into the Intranet for everyone in the business to consume. I’ve covered this concept in greater detail in a previous article:

The layers of Office 365 collaboration


Now you have data all over the place inside Microsoft 365 as many will point out correctly. What’s missing is a consistent method of navigation between all these sources to make it easy for users to navigate. This is where SharePoint Hub Sites come in. You uses this to provide a consistent navigation over the top of all your data. To users this makes it all appear very logical and structured (even perhaps like their old file server) and yet provides the flexibility to be reconfigured at any stage and have those changes automatically applied across the whole structure thanks to SharePoint Hub sites.


The final layer is Yammer. This is for company wide communications such as water cooler chat (birthdays, sports, holidays), information on how to better use Microsoft 365, questions about the business, messages from CEO, suggestion boxes, what’s happening with the business or competition, sales, wins and so on.

Like the Intranet, Yammer is designed for corporate wide chat that doesn’t fit into any specific Team (which are arranged by function or location). I have detailed the importance of Yammer in a previous article:

Why Yammer is still relevant


Now that you have a linear framework that builds on top of itself, hopefully you have a better picture of where you can put data from a file server into Microsoft 365. Having a framework is great but more importantly is how to get users to also adapt to working in this way. My approach is to start with Yammer and OneDrive first as I have detailed previously:

Focus on the ‘Me’ services first

In short, if users get used to working with just files using OneDrive and then with just chat in Yammer, they will find it much easier to then move to Teams which is effectively files and chat combined. This thinking stems from:

The rule of three

I advocate to not over load people. This is because you need to:

Stop making your users feel stupid

You can have the greatest technology in the world but if no one uses it then it is pretty much wasted. that’s what I see with Microsoft 365. Not enough through and time is devoted to adoption and transformation. Most migrations are done as fast as possible to ‘close the ticket’ and move onto the next. The fallacy of that rushed approach is evident in failed adoption and user frustration.

So there you have it, a framework for migration of file data into the world of Microsoft 365. You can use this framework in whatever way makes sense to you. You can use all of it, none of it or as a basis for your own approach. However, the key message is to HAVE a process rather than something random. Remember, moving to a world of collaboration from a world of storage requires transformation not just migration!

Once you have the top level framework or process, you can then start developing individual frameworks and adoption processes for each piece. That is, one for OneDrive, one for Teams, One for Yammer and so on. Once you have these processes, next you can start automating them to improve reliability and allow you to scale. Without a system you can’t automate. Without automation your effectiveness and profitability continue to fall, so investing the time in a collaborate system is definitely worthwhile. It makes users happier and it makes IT more profitable! A win – win. That is what a move to Microsoft 365 should be all about!

Microsoft Cloud URLs


I’ve started to put together a list of unique URL’s from Microsoft Cloud services such as Azure and Microsoft 365. Typically you navigate to individual services inside the main portal. However, this file I am maintaining on my Office 365 GitHub repository:

has a direct link to the services so you can navigate there directly.

I’ll keep adding to these over time, so ensure you check back regularly. if you know any URL’s you reckon should be included, let me know and I’ll add them.

Need to Know podcast–Episode 206

A short sharp episode focusing on the latest news and updates from Microsoft Build. Brenton and I cover off all the Microsoft Cloud news, good and bad as there is unfortunately some bad news to report in recent experiences with Azure. However, there is also lots of good news about updates to your favourite services. Tune in and give us your feedback.

This episode was recorded using Microsoft Teams

Take a listen and let us know what you think –

You can listen directly to this episode at:

Subscribe via iTunes at:

The podcast is also available on Stitcher at:

Don’t forget to give the show a rating as well as send us any feedback or suggestions you may have for the show.




CIAOPS Patron program

Azure cheat sheet

Azure global outage

What’s new in Microsoft 365 user management

New people centered experiences in Microsoft 365

Microsoft Edge – All the news from Build

Minimize distractions and stay focused with AI powered updates in Microsoft 365

The insecurity of shared mailboxes

Shared mailboxes are a really handy component of Microsoft 365 in that they allow multiple users to access a single mailbox. This works really well for generic accounts like info@, accounts@, etc. However, there are some security issues with these that I don’t think many people are aware of.

The first point to note is that shared mailboxes in Microsoft 365 actually have a login and password. Thus, they can be accessed directly using these details. Don’t believe me? Well check out the following documentation:

which says:

“Every shared mailbox has a corresponding user account. Notice how you weren’t asked to provide a password when you created the shared mailbox? The account has a password, but it’s system-generated (unknown). You aren’t supposed to use the account to log in to the shared mailbox”

So, by default, when you create a shared mailbox you are actually creating an account with a system password in your environment. No so bad you think right? Well, the problem is that, by default, IMAP and POP3 are enabled on all mailboxes, including shared ones.


Some actually use this IMAP ability to be able to open shared mailboxes on mobile devices, however doing this comes with a huge risk in my books.

Why? Well, if IMAP is enabled, that means basic authentication is enabled and that is bad as I have said previously:

Disable basic auth to improve Office 365 security

You may feel an unknown system or complex password on a shared mailbox is good enough but to remote bad actors running automated cracking programs against accounts on your tenant, it is only a matter of time until they generate a matching password for that shared mailbox. Once they have that, boom, they’re into that mailbox. From that foothold, they can then launch all types of attacks, but the most likely being phishing your users. It’s all down hill from there!

If you use shared mailboxes on mobile devices, this means you have to know the password for the shared mailbox prior to configuration on the mobile device. Because the shared mailbox has an account, it can have it’s password changed. That means, if you want to use shared mailboxes on mobile devices, you reset the password for the shared mailbox so you know it. You then give that to users so they can configure access on their phones. Anyone else see a problem here? You are providing multiple people access to a single resource with a shared password. What is a shared password? It ain’t a secret for sure now is it? So, what happens when a user leaves the business? I’ll bet most businesses don’t go and reset the password on all the shared mailboxes that user had access to. This means you now have someone outside your business who has a login (shared mailbox email address) and password to a resource in your tenant.

Here’s a scenario where that came back to bite the business. A disgruntled user was terminated and their individual login account was disabled. After the user has fired, they connected back into a shared mailbox directly using IMAP and started sending all sorts of nasty emails to all staff from this mailbox. Now if they had been smart, they would have done this from an anonymous IP address, not one assigned to them from their ISP so we could track them down. However, the damage was done. Why? All because access to the shared mailbox was permitted by insecure protocols and shared passwords.

Edit sign-in status flyout in the M365 admin center

As with most things security, it is pretty easy to protect yourself from this BUT it requires changing the defaults. The easiest way is to:

Block sign-in for the shared mailbox account

along with disabling IMAP, POP and basic auth. Yes, I fully appreciate that may have productivity ramifications, so you need to balance up the risk. However, given how easily this can be exploited, and the damage it could to the business, I’d rather be in the safe and secure camp than the ‘it’ll never happen to us’ blind faith camp personally. Anything that allows anonymous external users the ability to access accounts externally and allows them to keep guessing passwords as you can with IMAP spray attacks is very, very bad in my books. If you read this article:

make sure you note the very last paragraph which says:

Update, March 21, 2019: This post has been updated to reflect specific cases in which IMAP-based password-spraying attacks were successful, particularly as threat actors targeted shared service accounts, (e.g., hr@company[.]com or helpdesk@company[.]com) or exploited weaknesses in MFA implementations and third-party email client logins.” 

So please, secure your shared mailboxes NOW! If you really, really need shared mailbox access on mobile devices I would suggest you use Office 365 groups instead until Microsoft enables shared mailboxes natively on mobile devices (which is on the roadmap).

Access the Microsoft Graph with a script

In a recent article I showed how to connect to the Microsoft Graph in a web browser:

Using the Microsoft Graph Explorer

I also showed how you could do the same:

Using Interactive PowerShell

This article is going to focus on how you can do the same thing but directly via a script that won’t prompt you for credentials.

Before running this script you’ll need to follow the Using Interactive PowerShell article and set up an app in your Azure AD.



During that process you’ll need to record three things that will be used here:

1. Application ID

2. Tenant ID

3. Client secret

I borrowed the connection piece of this script from:

which I found really handy in helping me understand all this. You can download my script from my GitHub repository here:

You’ll need to enter your own Application ID, Tenant ID and Client secret in the variables section. After that, all you need to do is run the script. The results for the query of /security/alerts will end up in a variable called $query which you can view. The actual content of the alerts you’ll find in $query.content.


This Graph connection script should now allow you to connect to the Microsoft Graph for a tenant and start running queries and returning values for entries in there. At the moment it only queries security alerts, but you can modify it to query anything in the Graph for your tenant.