How and When to Adopt the Modern UI in SharePoint – Part 1/2


I’ve spent some time over the last few weeks doing an impact assessment of moving to the new(ish) ‘Modern UI’ in SharePoint Online. I looked at it primarily from a technical angle so that my client can decide whether to adopt it now, based on the constraints of the current technology. The conclusion I reached was that it’s not quite ready yet.

This post isn’t an attempt to bash Microsoft or poke holes in this functionality. I actually think the Modern UI is great, and completely the right direction for Microsoft to take things. But for me, it’s not quite an ‘enterprise-ready’ product yet. Hopefully this post helps other customers out there facing a similar dilemma, or at the very least frames how you can do your own assessment of whether or not to ‘go Modern’.

The post ended up getting pretty big, so I’ve split it into two parts:

  1. Part One: Introduction, assessing compatibility for existing sites, and assessing constraints for future work; and
  2. Part Two: Benefits of the Modern UI, and options/recommendations for how and when to adopt it.

What is the Modern UI?

Microsoft have begun introducing the ‘Modern UI’ for collaboration sites in SharePoint Online. This new functionality provides a better user experience, cross-device compatibility, better integration with other products in the Office 365 suite (namely, O365 Groups), and a 24 TB increase in total storage space per site.

It surfaces at three ‘levels’:

  • Modern Team Sites (AKA Group Sites);
  • Modern Lists and Libraries; and
  • Modern Pages.

Modern Page

Above: A Modern Page on a Modern Site


Modern Lib

Above: A Modern Library within a Modern Site

However, Modern UI offer some drawbacks around the customisations that can be achieved. These constraints will directly affect how, where and when the Modern UI can be adopted within many organisations’ Office 365 environments.

An important thing to note from the outset is that the Modern UI covers only collaboration sites, not Publishing sites. There are some Modern Publishing Sites coming down the pipeline, in the form of the new Communication Sites from Microsoft, but these are not yet generally available and therefore outside the scope of what I’m covering off here. I’ll probably do a post in the future going into a bit more detail about Modern Communication sites.

Process for Assessing the Impact of the Modern UI in Your Environment

When I was looking at if/when the Modern UI should be adopted and rolled out in my organisation, I undertook four steps, which I will detail in this blog post. At a high-level, these steps were:

  1. What compatibility problems (if any) are there for existing sites in SharePoint Online, and what do we need to do to address them?
  2. What compatibility problems are there that may constrain or alter the approach for future design and development work, and how might we address these problems?
  3. What requirements/use cases are there that mean moving to the Modern UI provides benefits to either the business or IT?
  4. What options do we have for if/when we roll out the Modern UI, what are the pros/cons of each, and what is our recommendation?

As mentioned above, Steps 1 and 2 will be covered in this first post; Steps 3 and 4 will follow in a second post.

Step 1 – Assess Compatibility with Existing Sites

Before moving to the Modern UI, you are going to need to look at how it plays with any existing sites you have in your Office 365 tenant. There may be bits of customisation and configuration that preclude certain sites or lists from becoming Modern, and mean that you need to do some remediation work or plan for leaving some sites/areas behind in the Classic configuration.

To help with this assessment, the PnP (Patterns and Practices) team at Microsoft have provided a really excellent tool called the ‘SharePoint Modern UI Experience Scanner’. There are some solid instructions in the GitHub repository that even a plebeian like me could understand and follow, so you shouldn’t have too many difficulties getting this up and running in your environment – provided you have an admin account to set-up an app-only principle with tenant permissions.

The UI Scanner trawls through every site on your tenant and outputs a whole raft of CSV files at the end of it. These CSVs provide information on incompatible customisations and configurations at both the site level and the list level. I created a Power BI report to make the information a bit more human-readable, but you can achieve something similar in Excel (or draw your own conclusions straight from the CSV, if you don’t need to represent an impact assessment to a broader audience).

My tips to get meaningful information out of the reports are as follows:

Site-Level Customisations

IgnoredCustomisations.csv is the high-level report that tells you sites with custom Master Pages, custom CSS, or Custom Actions. These things are currently incompatible with the Modern UI.


My top tip for this report is to make sure you filter out any Publishing sites, i.e. stuff that is related to your publishing intranet rather than being a collaboration space. You might be able to do this via something as simple as which managed path a site resides under (/teams or /sites), but you may need some slightly more complicated logic to weed out the irrelevant stuff. Remember that the Modern UI cannot be used on Publishing sites anyway, so they’re kind of irrelevant for a compatibility report.

It’s also a good idea to find a way to call out any sites with no issues, so you have a clear way of knowing which sites you don’t need to refactor to get them working with the Modern UI.

My Power BI Report for Site-level customisations ended up looking like the below:


List-Level Customisations

The ModernListBlocked.csv file provides a whole heap of information about compatibility issues that might prevent you from switching on the Modern UI in certain lists/libraries. These issues fall into two broad buckets:

  1. Out of the Box Issues: Areas where things outside of your control mean that the Modern UI is not available for this list/library. This includes stuff like the base list template being incompatible; the view type being incompatible; or an unsupported field type (such as geo-location fields).
  2. Customisation Issues: These are areas where you, foolish developer, have caused a compatibility problem by customising something on a list or library. This includes stuff like custom list actions; JSLink; XSL; or multiple web parts added to a list view page.


I’ll discuss these limitations in much more detail in the next section, as they all need consideration, but for the purposes of assessing compatibility with your existing estate, my top tip for this report is to, again, find a way of filtering out the irrelevant publishing sites. A second tip is to find a way of categorising the type, or base template, of the list for each row. The report provides this in the format of a list base template identifier (e.g. 107, 108, 120 etc. etc.) from which you can infer the actual list type. For example, 104 is an Announcements list, 105 is Contacts, 106 is a Calendar, etc.

My Power BI Report for List-level customisations looked like the below:


How do I Upgrade?

Creating a Site as Modern Natively

Obviously, this isn’t an upgrade, but it’s worth noting here that new sites can be created as Modern natively. That said, read on to find out some of the constraints you have around provisioning Modern Sites, and other limitations you’ll experience once the site is up and running! This applies to sub-sites as well as new site collections.

Upgrading an Existing Classic Site

To upgrade an existing site in the classic configuration, you will need an admin to run a PowerShell script. This can be done against one or many sites.

Before doing this, you should – of course – have followed the guidance I outlined above around assessing the compatibility of your existing sites with the Modern UI. You might find that you need to do some remediation work before you can run any scripts.

Upgrading an Existing Classic List/Library

There are a few options as far as upgrading lists/libraries to the Modern UI goes:

  1. Administrators can set the default list experience for the whole Office 365 tenant.
  2. Site owners can switch lists and libraries to the Modern UI on a case-by-case basis.
  3. Administrators can run a PowerShell script to programmatically change the default list experience, or upgrade individual lists across a site or many sites at once.

Again, keep in mind that fact that many list types are not compatible with the Modern UI.

Upgrading an Existing Classic Page

Unfortunately, it is not possible to upgrade a Classic web page on a SharePoint site to Modern. Pages will need to be recreated as Modern Pages.

Recommendations for Remediating Existing Sites

If you’re finding lots of team sites, project sites or other collaboration spaces with custom CSS or master pages, you should consider changing these to something more generic. The general guidance extolled by Microsoft and SharePoint experts for the last couple of years has been to avoid doing these types of customisations to collaboration sites. However, in the real world, organisations usually want – at the very least – a consistent global navigation experience with the rest of their intranet/SharePoint environment. Unless you’ve kept your SharePoint environment extremely vanilla, it’s likely you’ll have some quite extensive work to do here to get these sites ready to go Modern.

As for lists, it’s unlikely that there will be any sites that don’t have at least a couple of lists with compatibility issues. This is due to the lack of Modern UI support for some very common list view types and base templates. But for lists with customisation issues, you should look at how feasible it is to tweak these, keeping in mind that support for some of the things that cause issues with Modern Lists at the moment is coming down the pipeline.

Step 2 – Assess Constraints for Future Design and Development Work

The next step I recommend is to familiarise yourself with where and how the Modern UI constrains what you want to do in the future. To help with this, I’ve looked at a variety of things an organisation might want to do with a SharePoint site, and compared the capabilities in Modern to the existing capabilities in Classic. For anything that the Modern UI does not yet support, I’ve included a bit of detail I’ve gleaned from Microsoft’s Public Roadmap (or bits I’ve inferred from supporting information around the roadmap).

It should be noted here that this blog post is correct at the time of writing (July 2017), in terms of the items on the roadmap and where the gaps are, but it will likely become out of date. I’d also say it’s highly unlikely I’ll maintain the blog post going forwards, so I’d suggest doing some of your own research around the roadmap if you’ve come across this post more than a few months after its initial published date. But

The areas I consider are as follows:

  • Provisioning: How sites can be programmatically created to enforce consistency of structure, look and feel, information architecture etc.?
  • Branding: How can a site be configured to look and feel the way a business wants it to?
  • Custom Pages: What are some of the constraints around editing custom pages on a site?
  • Site Management: What needs to be kept in mind for the management of existing sites, in terms of settings, configuration, and adding new areas to the structure?
  • Site Discovery: How is the discovery/findability of sites impacted by the Modern UI?
  • List Views: What compatibility problems are there for specific types of list view in the Modern UI (building on what I alluded to in the compatibility with existing sites section)?
  • List Customisations: What customisations can you make at the list level?

In addition to the areas I’ve considered below, there are a few extra specifics in this article from Microsoft:

Feature Gaps and Constraints


CON Provisioning

While Modern sites can be created programmatically as part of a provisioning process (including all the content types and metadata fields that are required), you have no way to make the homepage of the new site look how it needs to without human interaction. Currently, you must add a new app to a newly provisioned Modern site manually, unless you create some sort of hacky UI-based execution, which has significant risk attached to it if Microsoft make updates.


CON Brandingjpg

Options for branding Modern sites are extremely limited, though further options akin to Master Pages and custom CSS are being rolled out as I write, and should hit General Availability (GA) in the next few months. The key takeaway here is that Modern Sites/pages will not look like the rest of your SharePoint environment if you have customised it in any way, and it is currently impossible to make them fit in look and feel-wise.

Custom Pages

CON Pages

The types of Modern Page that can be created are relatively limited, though the pages themselves are much easier to use for both end users and editors. It is also worth noting that Modern Web Parts are Microsoft’s clear strategic direction, and should become the de facto way in which custom web parts are developed in your organisation. If you’re not adopting the SharePoint Framework (SPFx) wherever possible for custom web part development, you are creating a bigger and bigger backlog of legacy stuff that will eventually need to be refactored.

Site Management

CON Site Mgt

Modern Sites are currently only designed for collaboration (team/project site) scenarios, not web content management.

There are also issues with sub-sites created beneath Modern Sites, in that the homepage of the Sub-Site will be Classic, not Modern. This is a biggie for me, as it creates terrible inconsistency and is very confusing for site owners. Again, this is something that could possibly be addressed with a bit of a hack, but that’s not an ideal solution, or indeed a supported one.

Site Discovery

CON Discovery

Modern Sites/pages can be rolled up and presented in much the same way as Classic sites/pages, though some tweaking of the current configuration of your Content by Search web parts may be required. Also worth noting here is that it is not possible to capture metadata for a site in the property bag of Modern Sites. Some custom applications will have previously utilised the site property bag (rather than tags on pages or hiding properties away in some sort of site configuration list) in order to classify a site for rollup/discovery purposes when surfacing it through search. This is no longer an option, and if you’ve done this, you might have some serious remediation work on your hands.

They can also be attached/created as part of a new Group/Team to provide a more seamless interface with these other services in the Office 365 suite.

List Views

CON List Views

Some core list functionality does not work in the Modern UI, including Gantt and Calendar views which are widely used on collaboration spaces (at least in my experience). This means there will be a fragmented user experience if the site is Modern, but the list remains in classic mode. Something you must accept in the Modern UI is that there will – for the time being at least – be a degree of jumping around between Classic and Modern layouts as you move between lists. This has knock-on effects for training guidance and collateral, which must be kept in mind when you’re assessing the impact of the Modern UI (more to come on this in the next post).

Additionally, there are several field types that don’t work in Modern lists, though these are unlikely to affect the majority of sites.

List Customisations

CON List Cust

Lists with customisations generally do not work in the Modern Experience. However, Microsoft are rolling out the ability to add more customisations to the Modern Lists experience as we speak.

Microsoft’s Roadmap

Stuff That’s on the Roadmap

So this is a summary of the things that are on Microsoft’s current public roadmap, or at least alluded to as part of the collateral supporting related roadmap items.


Stuff That’s Missing from the Roadmap

This is a summary of constraints that aren’t on the roadmap to be addressed by Microsoft:


Wrapping it Up

So that’s it for Part One of this two-part series. It’s been slightly one-sided so far, but in the next post, I’ll cover off the benefits of the Modern UI, and options/recommendations for how and when to adopt it in your organisation.

Thanks for reading, and check back for part 2 in the next week or so!

Planning for the Azure CDN Capabilities in Office 365


At work the last couple of weeks, I’ve been looking at how an Azure Public CDN (Content Delivery Network) and the newly-released SharePoint Online CDN can improve performance for geographically dispersed users in Office 365. There are a few important factors to consider, but generally I think these are great options for organisations with users experiencing latency in Office 365 due to their location.

What is a CDN?

A CDN takes static web content used by web pages on SharePoint, web sites, and other custom web applications (such as images, fonts, JavaScript and Style Sheets) and stores it at strategically placed locations around the world. In an Office 365 set-up without a CDN, this content gets served to the client/user from the base location of the Office 365 tenant, be that North America, Western Europe, or wherever Office 365 was originally set-up. This results in terrible network latency for geographically dispersed users thanks to the large distances involved. But after a CDN is implemented, this content can be served to the user from their nearest data centre, as opposed to the primary tenant location. This provides much better performance and a much improved experience for users, regardless of their location.

CDN Before3

CDN After

What options are available?

Azure provides two ‘flavours’ of CDN: the Public CDN, and the Private CDN. The Private CDN (also known as the SharePoint Online CDN) can only cache assets stored in SharePoint libraries, and checks the user’s access to the original location of the asset before serving it to them from the CDN. The Public CDN allows broader access to assets cached in the CDN, meaning it can be used for all manner of web applications, and cache files hosted outside of SharePoint.

So in other words, the new SharePoint CDN can be used to serve assets from SharePoint Online to other SharePoint Online pages, while the Public CDN can be used for everything else and isn’t purely for SharePoint.

Further constraints around the types of files that can be cached by the SharePoint CDN drives how you should architect your CDN(s) for Office 365. The SharePoint CDN can only cache files of the type .gif, .ico, .jpeg, .jpg, .js, and .png, while the Public CDN can cache files of the type .css, .eot, .gif, .ico, .jpeg, .jpg, .js, .map, .png, .svg, .ttf, and .woff. The key gap for the SharePoint CDN is style sheets and fonts, which means it should be used primarily for ‘author’ content, such as images (e.g. News Article pictures in a publishing intranet scenario). The Public CDN should be used for design assets such as fonts and CSS, as well as assets originated from or served to non-SharePoint applications.

SharePoint CDN

At a high-level, the SharePoint CDN works as per the below diagram:


There are a few things worth explaining from this diagram:

Origin Libraries

These are the SharePoint Libraries set-up via PowerShell as the sources of files to serve via the SharePoint CDN. It is possible for the CDN to cache content from all libraries under a specified path by using a relative URL meaning that, for example, the Style Library within each site collection can be specified as a source, provided it exists under the same path in each site collection.

An important note about the SharePoint CDN is that it relies on a published major version of a file before that asset will be cached. Just something to keep in mind, depending on the type of version control applied to a library configured as an origin.

Referring Pages

In this context, referring pages are any pages on SharePoint Online that reference assets cached by the SharePoint CDN.

For the SharePoint CDN to work, the referring page must be a SharePoint Online page. This means that pages hosted outside of SharePoint Online (such as custom Azure Web Apps) cannot utilise the SharePoint CDN. However, provider hosted add-ins embedded on a SharePoint Online page will be able to make use of the SharePoint CDN.

URLs for SharePoint CDN content are dynamically generated and automatically rewritten so that the asset is retrieved from the nearest point of presence server location, rather than the main Office 365 tenant server location. URLs are automatically rewritten for the following elements in SharePoint Online:

  • Classic Publishing Pages will rewrite IMG and LINK URLs.
  • Content By Search web parts will rewrite display template JavaScript files and thumbnail images provided in query results.
  • Image Renditions.
  • Hyperlink fields on lists and libraries.
  • Picture Library slideshow web parts.
  • Image fields served back to the user via the SPList REST API.

So in theory, you shouldn’t have to rewrite much of your existing functionality if you opt to use the SharePoint CDN for your Office 365 environment, though of course, it would be a good idea to check.

One major gap at the time of writing is that SPFx client side web parts cannot utilise the SharePoint CDN. This is due to the way these web parts have to reference static URLs (and – as noted above – the URLs generated for cached SharePoint CDN content are not static). But this functionality is coming soon to SPFx.


When a browser requests assets stored on the SharePoint CDN, user access to these assets is considered. In other words, the user must have at least Read access to the Origin Library the asset is stored in, or the image/script will not load on the page. Though, to be fair, this is the case regardless of whether the CDN is being used to serve content to the user, so not much should change here in terms of permissions you need to grant to origin libraries.

Public CDN

The diagram below summarises the components of the Public CDN and the relationship between them:


Origin Libraries

Any location can be set as the origin for a Public CDN, including external SaaS services, Azure Web Apps, and SharePoint Server on-premises libraries (and SharePoint Online libraries).

Referring Pages

Referring pages can use the Public CDN URLs to retrieve assets from the CDN location closest to the user. These pages can be from any application, including SharePoint and an Azure Web App.


The Public CDN, by definition, allows anonymous access to cached assets and does not check a user’s authorisation against the origin library. Basically, any person out on the internet who can guess the URL of your content will see it if it is cached by the Public CDN. This has obvious security implications, though there are ways of mitigating this (see later in this blog post).

The Underlying CDN Technology

Microsoft haven’t really built a CDN themselves, and instead use third parties to deliver the capability that can be managed and configured under the Azure umbrella. Microsoft offers three alternatives for its CDN capability:

  • Akamai (Standard)
  • Verizon (Standard)
  • Verizon (Premium)

Feature Comparison

The table below compares the functionality provided by each CDN supplier. For brevity, the comparison table only includes items where the capabilities differ between suppliers. The full list of capabilities, including ones where all three provide comparable services, are available here and here.

Feature Description Standard Akamai Standard Verizon Premium Verizon
Points of Presence Number of edge locations geographically dispersed around the world. ~2200 80+ 80+
Custom domain HTTPS Enables the delivery of secure content via SSL to improve the security of data in transit.
Asset pre-loading Pre-loads assets so that there is no delay the first time they are requested by a user.
Core analytics Shows usage patterns for the CDN, including bandwidth, hits, and data transferred.
Advanced HTTP reports Generates detailed data about the CDN, including map-based geography reports on usage.
Real-time stats Provides data on bandwidth, connections, cache statuses etc. in real-time.
Real-time alerts Provides notifications about the performance of CDN end points in real-time.
Rules engine Customise how HTTP requests are handled, change the behaviour of the cache, set rules for mobile devices and implement URL redirects.
Token authentication Only requests with certain criteria in the URL will be served, e.g. only requests from certain hosts will be served.
Origin Shield Provides an extra caching layer between CDN edge servers and the origin to improve security.  
Support The support processes and models in place to handle incidents and queries. Phone and Email support, Community Forum 24/7/365 Phone and Email support 24/7/365 Phone and Email support


Price Comparison

The costs for the CDNs are based on outbound data transfers in GB per month, and differ by region. There is also a sliding scale of cost whereby data becomes less expensive the more you use.

Akamai (Standard) and Verizon (Standard) are identically priced as below:

Outbound Data Transfers NA + EMEA Asia Pac South America Australia India
First 10 TB/month £0.0649 per GB £0.1029 per GB £0.1864 per GB £0.1044 per GB £0.1268 per GB
Next 40 TB (10-50 TB)/month £0.0597 per GB £0.0969 per GB £0.1491 per GB £0.1007 per GB £0.0969 per GB
Next 100 TB (50-150 TB)/month £0.0448 per GB £0.0895 per GB £0.1342 per GB £0.0895 per GB £0.082 per GB
Next 350 TB (150-500 TB)/month £0.0299 per GB £0.0746 per GB £0.1193 per GB £0.0746 per GB £0.0746 per GB
Next 524 TB (500-1,024 TB)/month £0.0224 per GB £0.0597 per GB £0.1044 per GB £0.0709 per GB Contact MSFT
Next 4,096 TB (1,024-5,120 TB)/month £0.0187 per GB £0.0522 per GB £0.0969 per GB £0.0671 per GB Contact MSFT
Over 5,120 TB/month Contact MSFT Contact MSFT Contact MSFT Contact MSFT Contact MSFT


While the Verizon (Premium) offering is a little under twice the price of the standard services:

Outbound Data Transfers NA + EMEA Asia Pac South America Australia India
First 10 TB/month £0.1268 per GB £0.1864 per GB £0.3727 per GB £0.2087 per GB £0.2535 per GB
Next 40 TB (10-50 TB)/month £0.1118 per GB £0.164 per GB £0.3168 per GB £0.1789 per GB £0.2162 per GB
Next 100 TB (50-150 TB)/month £0.0969 per GB £0.1417 per GB £0.2684 per GB £0.1491 per GB £0.1827 per GB
Next 350 TB (150-500 TB)/month £0.082 per GB £0.1193 per GB £0.2236 per GB £0.1268 per GB £0.1566 per GB
Next 524 TB (500-1,024 TB)/month £0.0746 per GB £0.1044 per GB £0.1938 per GB £0.1081 per GB Contact MSFT
Next 4,096 TB (1,024-5,120 TB)/month £0.0671 per GB £0.0895 per GB £0.1677 per GB £0.0932 per GB Contact MSFT
Over 5,120 TB/month Contact MSFT Contact MSFT Contact MSFT Contact MSFT Contact MSFT


If you work out the costs of this based on your current trends of data use, it soon becomes clear that the SharePoint CDN costs are negligible and almost a no-brainer to implement. Similar for the Public CDN, at least in the internal/enterprise space as opposed to publically accessible web sites.


Performance between the three options is very similar, though I would suggest you conduct your own performance tests to see how it would work in your environment.


Microsoft offers a SLA-backed 99.9% uptime guarantee for the CDN (both SharePoint and Public). There are diagnostic logs and analytics to help troubleshoot CDN issues and analyse traffic and bandwidth usage. The big thing to focus on here though are the security implications:

Data Privacy and Compliance

Microsoft pretty much washes its hands of any data you choose to cache in the CDN. When you’re setting up your CDN in PowerShell it will display disclaimers similar to the following:

Both the SharePoint CDN and Public CDN are Azure features built on 3rd party applications with privacy and compliance standards that differ from the commitments outlined by Microsoft in the Office 365 Trust Centre. Data cached by the local servers for both the Public and SharePoint CDNs does not conform to Microsoft Data Processing Terms and is outside the Microsoft Office 365 Trust Centre compliance boundaries.

In other words, your data is no longer under Microsoft’s jurisdiction once it enters the CDN, as the underlying capability is provided by third parties. I haven’t managed to find any info on the web about what standards Verizon and Akamai do offer around data privacy and compliance, but will update this post if I find some.

Given the content cached in the CDN is likely just JavaScript, images, fonts, and style sheets, it is unlikely there is anything sensitive in there, but it’s still something to consider before switching on the CDN.

Anonymous Access to the Public CDN

As noted in the previous section, the Public CDN allows any referrer to access its cached content anonymously. Again, due to the nature of the content stored in the CDN, this is unlikely to be a problem (particularly given you can restrict who has access to upload assets to the origin library). However, if you need to provide an extra security wrapper around the Public CDN, you are only really left with one choice: the Verizon (Premium) offering, which supports Token Authentication.

Token Authentication can be used to check things like the referrer of specific requests (so you can, for example, limit it to just your SharePoint Online/on-prem estate), country, and a myriad of other things.


Here are a few of the constraints associated with the Azure Public CDN and SharePoint CDN technology:

Files such as aspx pages or Master Pages cannot be delivered via the Azure CDN, only the static elements and client side code that is embedded on pages. This means Master Pages must still be deployed per site collection in SharePoint Online.

The SharePoint CDN can only cache files of the type .gif, .ico, .jpeg, .jpg, .js, and .png. This covers the most common image file formats and icon files, plus JavaScript files (which are called in order to run custom client side code on some SharePoint Online pages). The most crucial file type that the SharePoint CDN cannot cache is .css, which will be used on every single page of a publishing portal and in many collaboration scenarios in SharePoint online too.

The Public CDN can cache files of the type .css (Style Sheets used to change the look and feel of a site), .eot, .woff and .ttf (fonts), .map (image maps), and .svg (scalable images/vectors) in addition to the file types outlined for the SharePoint CDN.

All files of type GIF, ICO, JPEG, JPG, JS and PNG stored in origin locations will be cached by the SharePoint CDN. If a file of this type is placed in an origin library, it cannot be excluded from the SharePoint CDN at a granular level.

Using the SharePoint CDN means that the referring site must be a SharePoint Online site, and the user must have authorisation to view the location where the static files are stored.

The SharePoint CDN can only be used for SharePoint Online, not SharePoint Server on-premises, or the on-premises elements of a hybrid implementation of SharePoint.

URLs for content served via the SharePoint CDN are dynamically generated and can change on a regular basis. They therefore cannot be hardcoded into custom scripts, applications, or SharePoint Framework Client-side Web Parts (the newly recommended way of designing and building web part functionality in SharePoint).

My Recommendations

So that’s a whistle stop tour of the Azure Public CDN and the new SharePoint CDN capabilities. Here are my recommendations if you’re thinking about enabling either of these services in your organisation:

  1. Make sure you (and your security team) are comfortable with the disclaimers Microsoft put around data privacy and compliance.
  2. Plan around using the SharePoint CDN for ‘author content’ like images (plus JavaScript), and the Public CDN for everything else. You will likely need a blend of both CDNs to deliver a holistic solution.
  3. Configure SharePoint CDN origin libraries with relative URLs so that any library located at the same place within a site collection (under a given path) can be cached. This has information architecture implications, as you do not want your asset libraries in different places within each site/site collection or you will have a massive admin overhead maintaining the CDN.
  4. Use the Verizon (Premium) offering if you want to allow anything other than completely anonymous access to Public CDN content.
  5. Keep in mind that SPFx web parts cannot – at the time of writing – utilise the SharePoint CDN.
  6. Conduct some performance baselining before implementing the CDN so you can demonstrate how much improvement has been made post-implementation.
  7. Ensure you put suitable cache expiration policies in place for CDN content.
  8. Think about consolidating content to be cached by the Public CDN into a centralised library or Azure Web App. This will help you control who has access to update these assets, and ensure that multiple versions of the same content do not proliferate across the environment.

I would state that enabling the SharePoint CDN is a bit of a no-brainer for most organisations. It’s simple to do and offers massive performance benefits to any global company using Office 365. But I would also state that some form of planning/design is also required to ensure your company is comfortable with Microsoft’s disclaimers and whether or not you’re willing to allow anonymous access to your content in the Public CDN.

Thanks for reading.







Tinfoil Hat Predictions for SharePoint and Office365 in 2021

So another year has slipped by, and the SharePoint blogosphere is alive with predictions about 2016 and what the future might hold. I thought I’d take this a step further: Time to don my trusty tinfoil hat, and make some predictions about what might be happening in the world of SharePoint in 5 years’ time! Now, it’s worth noting that most of these predictions are based on some basic research, reading, and my opinion about the way trends are heading in the broader tech landscape: I might prove to be right on some counts, I may very well be totally wrong. It will be interesting to revisit this post in 2021!

So without further ado, here are my Top 5 predictions for SharePoint in 2021:

1. SharePoint as a concept/brand will cease to exist

Microsoft barely refer to SharePoint in their marketing. This was particularly true during 2014 and the early part of 2015, when there were hardly any articles specifically about SharePoint on their Office Blogs site, one of the main channels through which Microsoft updates users about forthcoming features and changes within its enterprise technology stack. However, towards the end of last year, somebody sensible at Microsoft seemed to realise that the SharePoint brand still carries significant cachet, particularly with on-premises customers. There was more direct referral to SharePoint by Microsoft in late 2015, particularly with SharePoint Server 2016 coming out shortly.

With that said, I still think Microsoft’s preferred direction of travel is towards distinct, delineated experiences within a shared platform. SharePoint as a concept is just too big and hard to explain (as I wrote about in this article), so even though the brand name still carries some weight, I predict that Microsoft will distance themselves from it and focus on marketing ‘Groups’, ‘Delve’, ‘OneDrive’, and other individual apps within the broader platform.


2. Around 20% of content on SharePoint intranets will be created by automated writing tools

Automated composition engines are already capable of turning data and analytics into natural language writing. In my opinion, it’s a matter of when – not if – this technology makes its way onto corporate intranets and collaboration platforms. Things like market reports, shareholder reports, legal documents, and the latest quarterly financial results could all be written by machines, reviewed by a human, and then published on a SharePoint intranet as news articles.


3. Modern intranets will no longer have a homepage

This is something I’ve actually been longing to try on a project for the last couple of years, but have never found quite the right situation or client to do it with. Homepages take up a massively disproportionate amount of effort and cost on a project, usually somewhere between 10 and 20 per cent of an intranet project’s total development budget. Homepages also take up an exorbitant proportion of analysis/design time too, since stakeholders are always so wedded to the idea of having a nice-looking homepage that everybody wants to have their two pence and get it as ‘perfect’ as possible.

In my opinion, the homepage of an intranet should be nothing more than a jumping off point into distinct portals (or ‘experiences’ as Microsoft calls them) where users can get the content they need or perform the task they must do. You could already make the argument that the app launcher in O365 fulfils this purpose (particularly if it’s customised to include things like links to your News Centre, Project Sites Hub etc. etc.), so I’d be tempted to go full-Google and just have a search box and nothing more on the homepage. I still need to find a client I can sell on that concept :-).

So my bold prediction is that by 2021, modern intranets won’t really have homepages in the traditional sense, or at the very least, they will no longer be pouring disproportionate amounts of time, effort and money into one single page.


4. Team Sites will no longer exist

I’m a big fan of team sites, so this is a prediction I make with a slightly heavy heart. There are two main reasons I think this one is very likely to come into fruition: Firstly, Microsoft have created a minimum viable product in O365 called ‘Groups’ which is attempting to bridge the gap between shared mailboxes in Outlook, team sites in SharePoint, and discussion groups on Yammer. It’s a bit of a ‘worst of all worlds’ solution at the moment and I’m not aware of anywhere it’s been widely adopted, but it shows the route Microsoft are trying to go down on the collaboration side of things.

The second reason I think this prediction has a high probability of being right is that Microsoft wants to move away from power user customisation. In my experience, 90% of an organisation’s user base will only use their team sites for the basics: store some documents, maybe a team calendar, capture some contacts if you’re lucky. But the other 10% go to town, and create all sorts of power user customisations and small-scale business apps that help them get work done more efficiently and effectively. Microsoft has been burnt in the past by allowing heavy customisation of SharePoint platforms (hence the app/add-in model) since it makes things harder to support and upgrade. For SharePoint 2013, they took away the WYSIWYG visual interface from the SharePoint Designer tool to make it less non-dev friendly. And for SharePoint 2016, well… There is no more SharePoint Designer! This leaves a bit of a hole in my opinion, in terms of small-scale business applications (it remains to be seen if PowerApps can fill it effectively), but I think it’s another nail in the coffin of Team Sites in the traditional sense.

I think that by 2021, Groups will be the de facto collaboration area, and PowerApps will provide the ability for power users to customise SharePoint and create business applications.


5. ‘Intranet in a Box’ products will cease to exist

There’s been a massive trend in the last few years towards implementing pre-packaged intranet products. The market is saturated with products built on top of SharePoint Server/SharePoint Online, and there is relative parity in features and capabilities of all these platforms. I think that it’s only a matter of time before Microsoft builds something into O365/SharePoint that fills most of an organisation’s intranet requirements out of the box. Indeed, they’ve already started down this route with the forthcoming Microsites and Knowledge Management Portal features in O365. Companies that have their own intranet in a box products will have to react quickly to new functionality Microsoft provides, or they will go out of business.



So those are my predictions for the SharePoint/O365 landscape in 5 years’ time. Some slightly out there, some bold but based on solid evidence, some that it’s safe to say probably will happen at some point. It will be amusing to revisit these in a few years time and see if I’m some sort of Nostradamus, or a complete fool. Thanks for reading.