‘Inside look’ voor .docx bestanden

Binnenkort wordt de nieuwe feature uitgerold waarmee het inzichtelijk wordt gemaakt hoe lang je er over doet om een bestand te lezen (Time to read). Tevens wordt een aantal kernzinnen uit bestand getoond (At a glance). Het gaat hierbij in eerste instantie om .docx (MS Word) bestanden.

De feature wordt begin juni uitgerold voor Targeted Release gebruikers en wereldwijd is het eind juli beschikbaar. Je hoeft geen actie te ondernemen, maar het is wellicht handig om documentatie en trainingen te updaten.

How we did it: upgrading +1700 classic SharePoint sites to modern Office Groups

This article is translated in English. The original article in Dutch can be found here.

It is a struggle that many Office 365 administrators have to deal with: what do we do with all those classic SharePoint sites? For years we have thought that we optimally used SharePoint with sub sites, custom permission models and all sorts of linked elements.

There are not many classic SharePoint sites that have remained 100% using default configurations. Many are ‘enriched’ with embedded javascript code or image maps. Also, homepages have been modified to ensure that the branding of a site matches the house style as much as possible.

a classic SharePoint site

But then Microsoft introduced a switch to so-called ‘modern sites’, connected to Office Groups, so that the management, policy and lifecycle on sites (groups) would be improved. This did not happen immediately; for a while there has been a transition where modern sites have been of limited use due to lack of functionality, support for certain list types and, for example, document sets. However, modern sites have now developed so well that the step can be taken, with some consideration.

It’s possible for some time now to ‘groupify’ and modernize a site collection. In fact, it means that a modern homepage is created and the lists are converted to the modern layout. An Office Group is also created which is connected to the site.

But it’s not that simple: many things cannot be transferred 1-to-1, with a result that choices have to be made here, which mainly have an impact on end users:

  • The permission model is changing. When dealing with an Office Group it is wise to align with the model of Members and Owners.
  • Custom homepages can continue to exist, but the default will be a new, modern homepage.
  • You can start using Office Group functionality with the site such as Teams, Planner, etc.
  • Not all old functionality is (already) available. Think of modern documentsets (coming soon), calendar lists and, for example, content editor webparts.
  • Subsites are questionable in the modern SharePoint world. It is recommended to use a so-called ‘flat information architecture’.

In short: a challenge! Its nevertheless wise to continue the transition, since we want to take advantage of the developments that Microsoft is doing and not to get stuck in old ‘stuff’.

modern SharePoint site

We went through this process for one of my clients, but not without a struggle. I would therefore like to share the experiences and approach with you. Use it to your advantage!

The fear for end-users

The ideas (and discussions) for modernizing around 5,000 SharePoint sites (with 6,200 users, excluding many external users) date back to a year or two ago. At the time it was still difficult because of the many limitations and bugs in the modern lists. That is why we waited until a year ago with this transition. With the ability to ‘groupify’ (connecting an Office Group to a SharePoint site) we started looking seriously at the options.

With this, there are some technical challenges, but the biggest obstacle was the (fear for) end users. For them, the site changes, sometimes to a large extent. How would this fall and how much support would be requested after a site has been converted. Much of this ‘fear’ comes from the idea that users find it difficult to change. The process in which they work is going to change. And thus the continuity of the organization can be affected.

And yes, this is something that needs to be taken into account. However, this same user is the first to buy a new iPhone, exchange the newspaper for a tablet, drive electrically and switch over to Microsoft Teams without any problems! Why? Because it’s easier, because it’s faster,
because it’s good for the environment or just because it’s cool. In short, users want to change, as long as it provides benefits!

And it is precisely this that can be optimally utilized when modernizing a SharePoint site. Because let’s be honest, who still wants to work in such an old-fashioned, slow and hard-to-use classic site? Exactly, except for a small percentage, NO ONE!

Design choices

When converting classic sites, we had to make a number of design choices. These choices are not always fun, sometimes concessions have to be made and end users are sometimes limited in their current way of working. However, so the idea is, with modern sites you get so much new functionality that this should outweigh the missing of old functionality. Consider, for example, the deployment of Microsoft Teams or tools such as Flow and Planner.

Our old sites were set up globally as follows:

  • Site collections with possible subsites. Think of phases in a project or process steps.
  • Custom permission models, where there are key users (owners with limited permissions) and members (contribution permission in SharePoint).
  • The homepage is often adapted with content editor web parts (read: javascripts and css) and images with image maps.
  • Extensive use of document sets for file creation, folders were first prohibited, later allowed to use.
  • Many content types with metadata, where attempts have been made to provide a generic set of metadata to all documents (owner, labels, status, type of document, etc.).
  • ‘Open information policy’, where non-confidential sites are open to all employees.
  • Confidentiality is expressed in permissions on the site.

In collaboration with security and CIO, we wanted to position the modern Office Group sites differently. For example, access is set up based on the classification of the site (in Dutch). Settings such as external sharing and retention labels (in Dutch) are set up based on this classification. A clear shift of responsibility (in Dutch) has taken place; for example, the key users become ‘owners’ of the site and members receive editing rights instead of contributions. This way lists and views can also be adjusted.

In recent years we have received a lot of feedback on the old SharePoint implementation. For example, speed is an issue, the fact that metadata is difficult (especially if it is mandatory) and the findability is poor. The adoption of SharePoint has long been an issue, with the result that a lot of ‘shadow IT’ has been created. Modern sites must offer a solution to these problems.

We decided to redesign modern sites. In essence, the user can determine how the site is set up and we remain very close to the standard when it comes to permissions and functionality. New, modern sites are therefore set up as follows:

  • Flat architecture, no more breaches of rights within a site collection. Do you need other rights? Then a new site collection. Subsites are not prohibited but strongly discouraged.
  • Key users become owners. Members with ‘contribution’ rights receive ‘edit’ rights. So more responsibility to users and the team in which they work together!
  • Everything becomes modern, so also a new (empty) homepage. Users can decide for themselves how this will look like. A conscious decision was made not to transfer the ‘old’ web parts to the modern homepage. The biggest reason is that the layout and working of modern web parts differs from the old ones to such an extent that it simply cannot be done properly. In addition, the users have such different layout and layout options that it is worthwhile (possibly together with support) to redesign.
  • Existing subsites continue to exist, we take this effect for granted.
  • ALL sites must be classified according to the organization’s information classification.
  • Policy is going to be enforced on the sites (so no more exceptions). Think of external sharing, conditional access, etc.
  • Labels are used for retention and archiving.
  • All sites may link / create a Microsoft Team if desired, and use Planner. This way Office Groups are optimally used.

The plan

Of course, a plan is needed to modernize all team sites, project sites, meeting sites. We initially made a distinction between three types of solutions:

  • The default collaboration sites. These include the goal of collaborating in groups where access is determined based on the classification of the information contained in the site.
  • Publishing sites. These are SharePoint sites that are used to share (or publish) information and documents with others (often the entire organization). Think of the traditional document centers or publication portals. We have chosen not to link these types of sites to an Office Group. These sites are, however, modernized in separate processes to. For example, communication and / or hub sites.
  • Solutions for specific target groups. These are collaboration sites that are specifically designed for a target group or process. New releases of these templates (including modernization) are included in the LCM of these specific solutions.

This article is about the modernization of the first group, in this case about 1800 in total. In this process, an approach was chosen with key users who would like to participate in a ‘first release’, and users who do not want this, or who no longer actively use the site. This first release also serves as a pilot for the large bulk promotion.

We have also chosen to start the modernization announcements in an early stage, and to repeat them several times. The nature of this announcement is compelling: you MUST upgrade, whereby you can choose not to go along with the first release immediately.

Talking about the ‘MUST’: we really want to have all collaboration sites upgraded, because this offers great benefits in management with Office Groups and AAD. The policy also states that in terms of security, retention and LCM we want to join in with the possibilities that modern sites and Office Groups offer. In addition, as Office 365 admins, we also want to keep up with developments Microsoft is doing and to maintain as little legacy as possible.

Summarized, the plan is as follows:

STEP 1: Communication to all key users of a collaboration site with the announcement and the option to sign up for the first release. This is done via an e-mail which clearly explains what will happen and what consequences it will have for users.

STEP 2: Second communication moment for the first release. This e-mail is a second announcement and more detailed planning of the transition.

STEP 3: Create & test scripts for modernizing and groupifying a site collection. These scripts are discussed later in this article. The goal is to have a PowerShell script that completely takes care of modernizing the site and links the site to a new Office Group.

STEP 4: Convert first release. The first batch with first release sites are converted, about 80 in total. This concerns enthusiastic users, so that the ‘cooperation’ should be optimal.

STEP 5: Request and process feedback. After the first batch, it turned out that 79 of the 80 sites were transferred correctly. There appeared to be a problem with creating an Office Group at the one site that had failed and where the problem is not clear. It was therefore decided to park this site for a while and to pick it up later. There also appeared to be a caching problem with the use of Internet Explorer 11 after a site had become modern. Various elements were not shown. Emptying the browser cache solves the problem. However, since IE 11 is the standard browser for a few months, this is an issue that can bother many users.

STEP 6: Lessons learned, evaluation and processing results. The PowerShell script worked well, but was made more efficient. We have also written articles about the most common problems (IE cache, user questions, etc.), so that they could be addressed immediately. We have also instructed the first line service desk to be able to handle these questions. It has also been found that by far the majority of users from the first release were particularly happy with their new, modern site! In short, perhaps the fear of users’ reactions is not entirely justified.

STEP 7: Communication moment for other key users. It was decided to transfer the remaining 1700 sites in one go. This would allow us to complete the upgrade quickly, possibly provide a lot of support for a short time and prevent the process from taking (even) longer. The idea is therefore to transfer the rest in a weekend and to be fully standby the following week. This has been communicated to the other key users via e-mail.

STEP 8: Write and publish help articles. To make the process, impact and problems quickly and clearly accessible to users, articles have been written and published on a SharePoint help site. This makes it possible to quickly and easily refer to online background information in communication.

STEP 9: Inform and involve the service desk (1st line). Because possible users contact the help desk when using the modern sites, the first-line service desk is informed and involved in the process.

STEP 10: Announcements via Yammer and SharePoint. The week before the sites were modernized, it was announced again via the Yammer network and SharePoint.

STEP 11: Convert the other sites. The more than 1700 classic team sites were subsequently modernized on Friday evening and connected to an Office Group. In this process, members and owners of a site receive a standard email from Office 365, in which they are introduced to the new Office Group. The effect of this is that some users receive multiple emails. This is sometimes experienced as negative, but it also provides insight into which (old) sites a user is a member of. A trigger to clean up or archive a site!

STEP 12: Plan a week for support. The week after the modernization, a week is scheduled for resolving calls that cannot be handled by the service desk. The expectation was that we would be flooded with questions. However, the first few days this happened to a limited extent, to a few dozen. Much less than expected.


The technical conversion of a site is one thing, but communication is everything! Although users are not waiting to be overloaded with emails and messages, it is wise to announce clearly and repeatedly what awaits them.

In the time to the moment of conversion, we had several communication moments. We expect that different key users have not read the e-mails, or that they have missed the communication. It is therefore important to do this at multiple times.

In addition, we have chosen to use multiple channels: e-mail, SharePoint and Yammer to reach as large a group of users as possible. Provide clear explanations and supporting articles, so that the most frequently asked questions are answered.

The key in this communication is: be positive about what’s coming. The user gets so much more convenience and tools to support their process. Use this! Every new feature in SharePoint can be brought as a moment of success and contact with the end user. Again, make good use of this!


In addition to the process of modernization, it is also good to look at the technology. The approach we have taken is to ensure that a site can be fully and quickly converted, including connecting an Office Group.

The mechanism for doing this (in this case) consists of 5 steps:

STEP 1: Create a .csv with all sites that need to be converted. In our case, the classification of a site is also included here.

csv with sites (template)

STEP 2: Put the users in the right permission group. In our case, owners and members were set to adjusted permission levels. When a site is connected to an Office Group, the default SharePoint groups for Owners and Members are linked to the Office Group permissions for owners and members. So it was necessary to put the users in the right, default groups and to clean up the old permission levels.

STEP 3: Configure the library settings for using modern layout. In the past we have converted all lists in every classic site to use the classic layout. This is because the user would otherwise be confronted with a mixed way of modern and classic. We have therefore converted all lists, so that the settings at the tenant level are used.

classic view or modern view

STEP 4: Groupify! The script to connect the sites to an Office Group

STEP 5: With the modernization a new modern homepage is created. We have placed a modified introduction text on this to inform the user.

All supporting scripts (steps) and .csv template can be found below (with thanks / credits to Kimberly Pothuizen and Albert-Jan Spiegelenberg).

By splitting the sites into 5 batches and starting them simultaneously, we succeeded in completing the modernization in 8 hours! It should be noted that of the more than 1700 sites, around 15 were not immediately successfully completed.


We are now one week after the upgrade process, with no significant events. Some users have reported that the site was still in the process of setting up the Office Group, but in general the conversion went very well.

The process prior to modernization took quite a long time, mainly due to the impact on users. In retrospect, this appears to have been partly unnecessary. As a result, communication and awareness have been implemented over a longer period of time. The final modernization of the 1700 sites took about 8 hours, all preparations (articles, extra communication, improving scripts and inventory sites) in around 8 days.

My advice in this: take a pragmatic approach and do not limit yourself too much with requirements you cannot meet (transfer content, migrate web parts, etc.). In addition, it is wise to match the permission model to the permissions within Office Groups. In addition, indicate to the user that they play a role in the process and are ultimately responsible for the content of the site. Make it fun! Users are generally enthusiastic about the new possibilities, make full use of it!

Hoe doen we dat: +1700 klassieke SharePoint sites upgraden naar moderne Office Group sites

An English translation of this article can be found here.

Het is een worsteling waar veel Office 365 beheerders mee moeten dealen: wat doen we met al die klassieke SharePoint sites? Jaren lang hebben we gedacht dat we SharePoint optimaal gebruikten met sub sites, aangepaste permissiemodellen en allerlei aan elkaar gekoppelde elementen.

Er zijn maar weinig klassieke SharePoint sites die 100% bij de standaard gebleven zijn. Vele zijn ‘verrijkt’ met ge-embedde javascript code of image maps. Vaak is geprobeerd de branding van een site zoveel mogelijk aan te laten sluiten bij de huisstijl.

klassieke SharePoint site

Maar toen kondigde Microsoft aan dat er een omschakeling zou komen naar zogenaamde ‘modern sites’, gekoppeld aan Office Groups, zodat het beheer, beleid en lifecycle op sites (groups) een stuk verbeterd werd. Dit ging niet zonder slag op stoot; een tijd lang is er een overgang geweest waarbij de moderne sites beperkt bruikbaar zijn geweest wegens het missen van functionaliteit, ondersteuning voor bepaalde lijsttypen en bijvoorbeeld document sets. Echter, moderne sites zijn inmiddels zo goed doorontwikkeld dat de stap gezet kan worden, zij het met wat aandachtspunten.

Het is al een tijdje mogelijk om een site collectie te ‘groupify-en’ en te moderniseren. In feiten betekent dat, dat er een moderne homepage gemaakt wordt en de lijsten omgezet worden naar de moderne lay-out. Tevens wordt er een Office Group gemaakt welke gekoppeld wordt aan de site.

Maar zo simpel is dat in de praktijk niet: veel zaken zijn niet 1-op-1 over te zetten, met als gevolg dat hier keuzes gemaakt moeten worden, welke vooral impact hebben op de eindgebruikers:

  • Het rechtenmodel verandert. Bij het omgaan naar een Office Group is het verstandig aan te sluiten bij het model van Leden en Eigenaars.
  • Aangepast homepages kunnen blijven bestaan, maar de standaard wordt een nieuwe, moderne homepage.
  • Men kan Office Group functionaliteit gaan gebruiken bij de site als Teams, Planner, etc.
  • Niet alle oude functionaliteit is (al) beschikbaar. Denk hierbij aan Documentensets (komt snel), kalender lijsten en bijvoorbeeld content editor webparts.
  • Subsites zijn dubieus in de moderne SharePoint wereld. Aangeraden wordt een zogenaamde ‘platte informatiearchitectuur’ toe te passen.

Kortom: een uitdaging! Toch is het verstandig de transitie door te gaan, we willen immers meeliften op de ontwikkelingen die Microsoft doet en niet blijven hangen in oude ‘meuk’.

moderne SharePoint site

Voor een van mijn klanten zijn we dit traject doorgegaan, maar niet zonder slag of stoot. De ervaringen en aanpak wil ik daarom graag met jullie delen. doe er je voordeel mee!

De angst voor gebruikers

De ideeën (en daamee discussies) voor het moderniseren van ongeveer 5000 SharePoint sites (met 6200 gebruikers, exclusief vele externe gebruikers) stammen al van een jaar of twee geleden. Destijds was het nog lastig vanwege de vele beperkingen en bugs in de moderne lijsten. Tot een jaar geleden hebben we daarom gewacht met deze transitie. Met de mogelijkheid om te ‘groupify-en’, het koppelen van een Office Group aan een SharePoint site, zijn we serieus gaan kijken naar de opties.

Hierbij zijn wat technische uitdagingen, maar de grootste belemmering was de impact voor de eindgebruikers. Voor hen verandert de site, soms in grote mate. Hoe zou dit vallen en hoeveel support zou er gevraagd worden nadat een site is omgezet. Veel van deze ‘angst’ komt voort uit het idee dat gebruikers het lastig vinden te veranderen. Het proces waarin ze werken gaat veranderen. En daarmee de continuiteit van de organisatie aangetast kan worden.

En ja, dit is iets waar rekening mee gehouden dient te worden. Echter, deze zelfde gebruiker koopt als eerste een nieuwe iPhone, ruilt de krant in voor een tablet, gaat elektrisch rijden én stopt zonder problemen over op Microsoft Teams! Waarom? Omdat het makkelijker is, omdat het sneller is, omdat het hip is en omdat het goed is voor het milieu. Kortom, gebruikers willen graag veranderen, mits het maar voordelen oplevert!

En juist dit gegeven kan optimaal benut worden bij het moderniseren van een SharePoint site. Want laten we eerlijk zijn, wie wil er nu nog in zo’n ouderwetse, langzame en moeilijk te gebruiken klasssieke site werken? Juist, op een klein percentage na, NIEMAND!


Bij het omzetten van klassieke sites hebben we een aantal ontwerpkeuzes moeten maken. Deze keuzes zijn niet altijd leuk, soms moeten er consessies gedaan worden en worden eindgebruikers beperkt. Echter, zo is het idee, met de moderne sites krijg je zoveel nieuwe functionaliteit terug, dat dit zwaarder zou moeten wegen dan het missen van oude functionaliteit. Denk bijvoorbeeld aan het inzetten van Microsoft Teams of tools als Flow en Planner.

Voor de beeldvorming, onze oude sites waren globaal als volgt opgezet:

  • Site collecties met mogelijk subsites. Denk aan fasen in een project of processtappen.
  • Aangepast permissiemodel, waarbij er key-users zijn (eigenaren met beperkte rechten) en leden (bijdragen rechten in SharePoint).
  • Vaak is de homepage aangepast met content editor web parts (lees: javascripts en css) en plaatjes met image maps.
  • Veel gebruik van documentsets voor dossiervorming, folders werden eerst verboden, later beperkt toegestaan.
  • Veel inhoudstypen met metadata, waarbij er getracht is een generieke set van metadata aan alle documenten te geven (eigenaar, labels, status, type document, etc).
  • ‘Open, tenzij beleid’, waarbij niet vertrouwelijke sites open staan voor alle medewerkers.
  • Vertouwelijkheid uit zich in de vorm van rechten op de site.

In afstemming met security en beleid wilden we de moderne Office Group sites anders gaan positioneren. Zo wordt toegang ingericht op basis van de classificatie van de site. Zaken als extern delen en retentie labels worden ingericht op basis van deze classificatie. Hierbij heeft een duidelijke schuiving van de verantwoordelijkheid plaatsgevonden; zo worden de key-users ‘eigenaar’ van de site en leden krijgen bewerkrechten in plaats van bijdragen. Zo kunnen ook lijsten e.d. worden aangepast.

De afgelopen jaren hebben we veel feedback gekregen op de oude inrichting. Zo is snelheid een issue, het feit dat metadata lastig is (zeker als het verplicht is) en de vindbaarheid slecht. De adoptie van SharePoint is dan al tijden een issue, met als gevolg dat er veel ‘shadow IT’ is gecreeerd. Moderne sites moeten een oplossing bieden voor deze problemen.

Er is daarom gekozen om moderne sites anders in te richten. In essentie mag de gebruiker bepalen hoe de site wordt ingericht en blijven we heel dicht bij de standaard als het gaat om rechten en functionaliteit. Nieuwe, moderne sites zijn daarom alsvolgt opgezet:

  • Platte architectuur, geen doorbreking van rechten meer binnen een site collectie. Toch andere rechten nodig? Dan een nieuwe site collectie. Subsites worden niet verboden maar sterk afgeraden.
  • Key-users worden eigenaren. Leden met ‘bijdragen’ rechten krijgen ‘bewerk’ rechten. Dus meer verantwoordelijkheid naar gebruikers en het team waarin wordt samengewerkt!
  • Alles wordt modern, dus ook een nieuwe (lege) homepage. Gebruikers kunnen daarbij zelf bepalen hoe dit er uit komt te zien. Er is bewust gekozen om de ‘oude’ webparts niet over te zetten naar de moderne homepage. De grootste reden is dat de indeling en werking van moderne webparts dusdanig afwijkt van de oude, dat dit gewoonweg niet goed te doen is. Daarnaast krijgen de gebruikers dermate andere mogelijkheden qua layout en indeling, dat het de moeite waard is (eventueel samen met ondersteuning) opnieuw in te richten.
  • Bestaande subsites blijven bestaan, dit effect nemen we voor lief.
  • ALLE sites moeten worden geclassificeerd volgens de informatieclassificatie van de organisatie.
  • Beleid gaat hard (dus geen uitzonderingen meer) afgedwonen worden op de sites. Denk hierbij aan instellingen rondom extern delen, conditional access, etc.
  • Er wordt gebruik gemaakt van labels voor retentie en archivering.
  • Alles sites mogen een Microsoft Team gaan koppelen/creëren indien gewenst, en gebruik maken van Planner. Zo worden Office Groups optimaal benut.

Het plan

Voor het moderniseren van alle teamsites, projectsites, vergadersites is natuurlijk wel een plan nodig. We hebben in eerste instantie een onderscheid gemaakt in drie type oplossingen:

  • De standaard samenwerksites. Deze omvatten als doel het samenwerken in groepen waarbij de toegang wordt bepaald op basis van de classificatie van de informatie die in de site staat.
  • Publicerende sites. Dit zijn SharePoint sites die gebruikt worden om informatie en documenten te delen met anderen (vaak de hele organisatie). Denk hierbij aan de klassieke documentencentra of publicatie portalen. We hebben ervoor gekozen om deze type sites niet te koppelen aan een Office Group. Wel worden deze sites in aparte trajecten gemoderniseerd naar bijvoorbeeld communicatie en/of hub-sites.
  • Oplossingen voor specifieke doelgroepen. Dit zijn samenwerksites welke specifiek voor een doelgroep of proces zijn ingericht. Nieuwe releases van deze templates (waaronder moderniseren) worden in de LCM van deze specifieke oplossingen meegenomen.

Dit artikel gaat over de modernisering van de eerste groep, in dit geval zo’n 1800 in totaal. Er is in dit traject gekozen voor een aanpak met gebruikers (key users) die graag mee willen in een ‘first release’, en gebruikers die dit niet willen, of de site niet meer actief gebruiken. Deze first release dient tevens als pilot voor de grote bulk actie.

Tevens hebben we ervoor gekozen om de aankondigingen van modernisering ruim van de voren te starten, en dit meermalen te herhalen. De aard van deze aankondiging is dwingend: je MOET over, waarbij je kan kiezen om niet direct mee te gaan met de first release.

Het over MOETEN is wel een ding: we willen persé alle samenwerksites over hebben, omdat dit grote voordelen biedt in beheer met Office Groups en AAD. Tevens stelt het beleid ook dat we qua beveiliging, retentie en LCM mee willen met de mogelijkheden die moderne sites en Office Groups bieden. Daarnaast willen we als beheerders van Office 365 ook gewoon mee met de ontwikkelingen en zo min mogelijk ‘legacy’ in stand houden.

Samengevat ziet het plan er alsvolgt uit:

STAP 1: Communicatie naar alle key-users van een samenwerksite met de aankondiging en de mogelijkheid je aan te melden voor de first release. Dit gaat via een een e-mail waarbij duidelijk wordt uitgelegd wat er gaat gebeuren en welke consequenties het heeft voor de gebruikers.

STAP 2: Tweede communicatiemoment voor de first release. Deze e-mail is een tweede aankondiging en concretere planning van de transitie.

STAP 3: Scripts maken & testen voor het moderniseren en groupify-en van een site collectie. Deze scripts worden later in dit artikel besproken. Het doel is om een PowerShell script te hebben die het moderniseren van de site volledig uit handen neemt en de site koppelt aan een nieuwe Office Group.

STAP 4: First release omzetten. De eerste batch met first release sites worden omgezet, zo’n 80 in totaal. Het gaat hierbij om enthousiaste gebruikers, waardoor de ‘medewerking’ optimaal zou moeten zijn.

STAP 5: Feedback vragen en verwerken. Na de eerste batch bleek dat 79 van de 80 sites correct zijn overgezet. Er bleek een probleem te zijn met het maken van een Office Group bij de ene site die mislukt was waarbij niet duidelijk is wat precies het probleem is. Er is daarom gekozen om deze site even te parkeren en later op te pakken. Tevens bleek er een caching probleem op te treden met het gebruik van Internet Explorer 11 nadat een site modern was geworden. Verschillende elementen werden daarbij niet getoond. Het legen van de browser cache lost het probleem op. Echter, omdat IE 11 nog een aantal maanden de standaard browser is, is dit een issue waar veel gebruikers last van kunnen krijgen.

STAP 6: Lessons learned, evalueren en verwerken. Het PowerShell script werkte goed, maar is wat efficienter gemaakt. Tevens hebben we artikelen geschreven over de meest voorkomende problemen (IE cache, gebruikersvragen, etc.), zodat deze direct geaddresseerd konden worden. Tevens hebben we de eerste lijns service desk geïnstrueerd deze vragen te kunnen afhandelen. Ook is gebleken dat veruit de meeste gebruikers uit de first release vooral erg blij waren met hun nieuwe, moderne site! Kortom, wellicht is de angst voor de reacties van gebruikers niet geheel gegrond.

STAP 7: Communicatiemoment voor overige key-users. Er is voor gekozen om de overige 1700 sites in 1 keer over te zetten. Hiermee zouden we de actie snel kunnen afronden, we mogelijk een korte tijd veel support moeten leveren en voorkomen we dat het traject (nog) langer gaat duren. Het idee is daarom om in een weekend de rest over te zetten en de week erna volledig standby te staan. Dit is gecommuniceerd naar de overige key-users middels een e-mail.

STAP 8: Help artikelen schrijven en publiceren. Om het proces en informatie, mogelijke impact en problemen snel en duidelijk inzichtelijk te maken voor de gebruikers, zijn artikelen geschreven en gepubliceerd op een SharePoint hulp site. Hierdoor kan snel en makkelijk vanuit de communicatie verwezen worden naar online achtergrondinformatie.

STAP 9: Servicedesk (1e lijns) informeren en betrekken. Doordat mogelijk gebruikers contact opnemen met de helpdesk bij het gebruik van de moderne sites, is de eerstelijns servicedesk geïnformeerd en betrokken bij het proces.

STAP 10: Aankondigingen via Yammer en SharePoint. De week voordat de sites werden gemoderniseerd, is dit nogmaals aangekondigd via het Yammer netwerk en SharePoint.

STAP 11: Overige sites omzetten. De meer dan 1700 klassieke teamsites zijn vervolgens op vrijdagavond gemoderniseerd en gekoppeld aan een Office Group. Bij dit proces krijgen leden en eigenaren van een site een standaard e-mail van Office 365, waarin ze geïntroduceerd worden in de nieuwe Office Group. Het effect hiervan is dat sommige gebruikers meerdere e-mails ontvangen. Dat wordt soms als negatief ervaren, echter het geeft ook inzicht in van welke (oude) sites een gebruiker lid is. Een trigger om een site op te ruimen of te archiveren!

STAP 12: Week vrijmaken voor support. De week na de modernisering is een week ingepland voor het oplossen van calls die niet door de service desk kunnen worden afgehandeld. De verwachting was dat er door de actie veel vragen binnen zouden komen. Echter, de eerste dagen is dit beperkt gebeurd, tot enkele tientallen. Veel minder dan was verwacht.


Het technisch omzetten van een site is een ding; maar communicatie is alles! Hoewel gebruikers er niet op zitten te wachten overladen te worden met e-mails en berichten, is het wel verstandig duidelijk en herhaaldelijk aan te kondigen wat hen te wachten staat.

In aanloop naar het moment van omzetten, hebben we meerdere communicatiemomenten gehad. Onze verwachting is dat verschillende key-users de e-mails niet gelezen hebben, of dat ze de communicatie gemist hebben. Het is daarom belangrijk dit op meedere momenten te doen.

Daarnaast hebben we gekozen om meerdere kanalen te gebruiken: e-mail, SharePoint en Yammer om zo een groot mogelijke groep gebruikers te bereiken. Zorg daarbij voor duidelijke uitleg en ondersteunende artikelen, zodat de meest voorkomende vragen beantwoord worden.

Het sleutel in deze communciatie is: wees positief over wat er allemaal gaat komen. De gebruiker krijgt in één keer zoveel meer gemak en tools om zijn of haar proces te ondersteunen, maar hier gebruik van! Elke nieuwe feature in SharePoint kan gebracht worden als een succesmoment en contact met de eindgebruiker. Maak ook hier gretig gebruik van!


Naast het proces van moderniseren, is het ook goed te kijken naar de techniek. De aanpak die we gehanteerd hebben is ervoor te zorgen dat een site volledig en ook snel omgezet kan worden, inclusief het koppelen van een Office Group.

Het mechnisme om dit te doen (in dit geval) bestaat uit 5 stappen:

STAP 1: Stel een .csv samen met alle sites die omgezet moeten worden. In ons geval wordt hier ook de classificatie van een site meegenomen.

csv met sites (template)

STAP 2: Goedzetten van de gebruikers in de juiste groepen. In ons geval waren eigenaren en leden in aangepaste permissieniveau’s ingesteld. Als een site wordt gekoppeld aan een Office Group, worden de standaard SharePoint groepen voor Eigenaren en Leden gekoppeld aan de Office Group permissies voor eigenaren en leden. Het was dus nodig om de gebruikers in de juiste, standaard groepen te zetten en de oude permissiesniveau’s op te ruimen.

STAP 3: Instellen van de bibliotheekinstellingen voor gebruik moderne lay-out. In het verleden hebben we alle lijsten in elke klassieke site omgezet dat er gebruik gemaakt moest worden van de klassieke lay-out. Dit omdat de gebruiker anders geconfronteerd zou worden met een gemixete manier van modern en klassiek. We hebben daarom alle lijsten weer omgezet, zodat er gebruik gemaakt wordt van de instellingen op tenant niveau.

klassieke weergave of moderne weergave

STAP 4: Groupify! Het script om de sites te koppelen aan een Office Group

STAP 5: Met het moderniseren wordt een nieuwe moderne homepage aangemaakt. We hebben hier een aangepaste introductietekst op geplaatst om de gebruiker te informeren.

Alle ondersteunende scripts (stappen) en .csv template zijn hier onder te vinden (met dank/credits aan Kimberly Pothuizen en Albert-Jan Spiegelenberg).

Door de sites op te splitsen in 5 batches en deze tegelijk te starten is het gelukt om de modernisering in 8 uur af te ronden! Daarbij de kanttekening dat er van de meer dan 1700 sites, ongeveer 15 niet direct succesvol afgerond waren.


We zijn inmiddels een week verder na de actie, zonder noemenswaardige gebeurtenissen. Enkele gebruikers hebben gemeld dat de site nog bezig was met het inrichten van de Office Group, maar over het algemeen is de omzetting goed verlopen.

Het proces voorafgaand aan de modernisering heeft vrij lang geduurd, vooral vanwege de impact op gebruikers. Dit blijkt achteraf deels onnodig geweest te zijn. Wel is daardoor de communicatie en bewustwording op een rustige manier uitgevoerd. De uiteindelijke modernisering van de 1700 sites heeft 8 uur geduurd, alle voorbereidingen (artikelen, extra communicatie, verbeteren scripts en inventarisatie sites) ca. 8 dagen.

Mijn advies hierbij: ga pragmatisch te werk en wring je niet in teveel bochten (content overzetten, webparts migreren, etc.). Daarnaast is het verstandig het rechtenmodel aan te laten sluiten aan de permissies binnen Office Groups. Geef daarnaast aan de gebruiker aan dat zij een rol spelen in het proces en uiteindelijk verantwoordelijk zijn voor de inhoud van de site. Maak het daarbij vooral leuk! Gebruikers zijn over het algemeen enthousiast over de nieuwe mogelijkheden, benut dat ten volle!

Gebruikersrechten, klassieke sites en Office Groups, hoe zit het nu?

SharePoint Online is inmiddels al vele jaren in gebruik voor het online samenwerken en opslaan van documenten. De afgelopen jaren heeft Microsoft verschillende ontwikkelingen gedaan aan de interface van SharePoint Online. Tevens is de functionaliteit rondom samenwerken enorm uitgebreid. Een van deze nieuwe ontwikkelingen is het koppelen van beveiligingsgroepen (Office Groups) aan SharePoint sites. Als je werkt met zogenaamde ‘klassieke’ SharePoint sites, is er de mogelijkheid om deze te moderniseren. Hierdoor krijgt de site een nieuw fris (modern) uiterlijk en is het ook mogelijk een ‘Office Groups‘ te koppelen aan je site. 

Beter beheer

Door het koppelen van een Office Group wordt het mogelijk om het beheren en beveiligen van SharePoint sites sterk te verbeteren. Waar er voorheen allerlei zaken via instellingen op de site zelf geregeld moesten worden, kunnen we de groepen beheren op centraal niveau, met behulp van beleidsregels. Ook vanuit het informatiebeveiligingsbeleid van organisaties en wetgeving (bijvoorbeeld de AVG) is dit vaak zeer gewenst. Zo kunnen Office Groups (en dus ook de SharePoint sites) geclassificeerd worden op basis van de gevoeligheid van informatie. Met deze classificatie wordt bijvoorbeeld weer bepaald of een site extern gedeeld mag worden, of welke beveiliging van toepassing is. 

Betere gebruikerservaring

Naast deze technische reden, is het ook voor gebruikers een positieve verandering. Zo verandert te lay-out naar een snel en modernere versie. Tevens is de SharePoint site responsive, wat wil zeggen dat deze ook goed te gebruiken is op je telefoon of tablet. Ook wordt het mogelijk om andere tooling als Microsoft TeamsMicrosoft Planner, Flow, Power BI en PowerApps te gaan integreren in de SharePoint site. Door het upgraden is daarom SharePoint weer toekomst vast. 

Door het moderniseren van een SharePoint site en het koppelen van een Office Group, verandert er het een en ander qua rechten van gebruikers. Zo krijgen gebruikers van de site meer rechten om de site in te richten naar eigen inzicht. Onderstaand overzicht geeft een goed beeld van de veranderingen. 


Veel organisaties kennen wel eigenaren van een site, maar deze zijn vaak ingericht met een beperkte set van rechten. Het is immers een risico als een gebruiker, ook al is deze eigenaar, bijvoorbeeld een site weg gooit, of bijvoorbeeld site onderdelen activeert. Op de gemoderniseerde sites (met een Office Group) worden deze eigenaren ook echt de eigenaar van de groep, waarmee ze de permissies en instellingen van de groep zelf kunnen beheren. In feite krijgt de eigenaar de verantwoordelijkheid over de site en de content die erop staat. Dit heeft voordelen, omdat aanpassingen niet meer via Office 365 beheer hoeven te verlopen. Ook mogen eigenaren andere eigenaren uitnodigen op een SharePoint site. We maken hierbij een duidelijk onderscheid tussen de inhoud (content en proces) en het (beveiligings-)beleid wat moet gelden op een SharePoint site. 


Met het koppelen van een Office Group aan een SharePoint site, gaan we meeliften op het permissiemodel van deze groepen. Hierin zijn twee niveaus te onderscheiden: eigenaren (zie punt hierboven) en leden. In de oude SharePoint site, hebben leden vaak (afhankelijk van de inrichting natuurlijk) bijdragen rechten. Dit betekent dat alleen documenten en lijstitems bewerkt mogen worden, maar dat leden geen mogelijkheid hebben om de SharePoint site zo te laten werken wat voor hen prettig is. In de moderne SharePoint sites krijgen leden de mogelijkheid om de inhoud (waarmee ook de lijsten worden bedoeld), zo in te richten, dat deze aansluiten bij de manier van werken die prettig is voor de gebruiker.   

In de meeste gevallen is dit een prettige bijkomstigheid voor de gebruikers van de site, echter in sommige gevallen is het verstandig om werkafspraken te maken om zo vervuiling op de site tegen te gaan. In een samenwerkingsverband hebben alle leden van een site een gezamenlijk doel. De visie hier is dat ook dat leden de verantwoordelijkheid over de content dan ook gezamenlijk kunnen dragen.  

Afwijken van rechten

Het is mogelijk om af te wijken van het eigenaren-leden rechtenmodel. Dit kan door in de SharePoint site specifieke SharePoint permissies in te stellen. Als je een site met Office Group gebruikt, is dit echter af te raden, omdat je hiermee ook afwijkt van het model van rechten op de andere gekoppelde Office 365 tools als Planner en Teams.

Visie op samenwerken

Samengevat is het aansluiten op het rechtenmodel van Office Groups voor samenwerksites een groot voordeel (veel extra functionaliteit, modern en snel jasje en weer toekomst vast), maar moet rekening worden gehouden met de vrijheid die gebruikers krijgen op een SharePoint site. Een groep die samenwerkt op een SharePoint site welke gekoppeld is aan een Office Group, heeft zelf de verantwoordelijkheid om juist om te gaan met de informatie op de site. Hierbij wordt het onderscheid gemaakt tussen het beleid wat geldt op een site (onder regie van beheer) en de inhoud en structuur van de site (onder regie van de (eind)gebruiker).  Door de rechtengroepen ‘Eigenaren’ en ‘Leden’ te hanteren sluit je met de groep waarmee je samenwerkt aan op alle andere tooling van Office 365. 

Mocht je meer informatie over wanneer je nu wel en wanneer je niet een Office Group wilt gebruikt, lees dan ook dit artikel.

Automatische verlenging op Office 365 development tenants

Mocht je je eigen Office 365 tenant willen om dingen uit te proberen, of voor uitzoek/development werk, dan is het mogelijk om zogenaamde gratis development tenants aan te maken, inclusief 25 E3 licenties.
Sinds kort zijn deze onbeperkt te gebruiken in plaats van 1 jaar, zolang je in de tenant dingen doet. Het is dan dus niet meer nodig een nieuwe tenant aan te vragen, maar wordt de huidige automatisch verlengd. Dit proces wordt elke 90 dagen bekeken. Voorheen was dit eens per jaar.

Uitnodigen leden in Microsoft Teams verandert

Binnenkort wordt een nieuwe feature uitgerold in Microsoft Teams. Voor leden van een team wordt het makkelijk om andere gebruikers uit te nodigen. Dit zal gaan middels een uitnodiging en een aanvraag welke naar de eigenaar van het team wordt verstuurd. Als de eigenaar dit goedkeurt, wordt de gebruiker automatisch toegevoegd aan het team. Het een en ander wordt beschreven in de Microsoft Roadmap.

Office Groups, wanneer wel en wanneer niet?

Er zijn in het ‘moderne’ Office 365 landschap verschillende manieren van toegang verlenen voor gebruikers. Het inrichten van het permissiemodel is een fundamentele keuze en daarom erg belangrijk. Goed om duidelijk te hebben welke consequenties die keuze heeft. Wellicht dat dit artikel kan helpen in het uitwerken van deze keuzes.

Als je naar SharePoint kijkt, is er een tweetal type sites te onderscheiden:

  • Samenwerken binnen een groep (in de brede zin van het woord);
  • Publiceren van content, denk hierbij aan portalen of publicatie van documenten voor inzage.

Samenwerken binnen een groep

Bij het samenwerken binnen een groep, is het verstandig vast te houden aan de architectuur van Office Groups. Office Groups zijn als het ware beveiligingsgroepen in de AAD (Azure Active Directory), waarin de permissies voor die groep te beheren is. Dit heeft grote voordelen als het gaat om beheersbaarheid, maar ook de toegang, omdat het overweg kan met de functies binnen de AAD en zaken als conditional access en identity management.

Voorbeeld van een Office Group in de AAD

Je kan de groepen beschouwen als onderdeel van IDM (het mechanisme/proces waarmee je gebruikers beheert), waarmee de controle in inzichten mee kunnen liften met de AAD. Office Groups hebben één groot punt waarmee rekening gehouden moet worden, namelijk dat er twee type permissies ingesteld kunnen worden:

  • Eigenaren (welke controle hebben over de groep) en,
  • Leden (welke bewerk rechten hebben, dus niet alleen bijdragen). In de praktijk komt het dus neer dat leden bijvoorbeeld rechten hebben om in SharePoint lijsten te bewerken.

Groepslidmaatschap is beperkt tot Eigenaren en Leden

Tevens is er geen functionaliteit voor ‘bezoekers’. Binnen de SharePoint site welke gekoppeld is aan een Office Group, is het uiteraard wel mogelijk om bezoekers toe te voegen (en andere specifieke rechten). Hou er in dat geval rekening mee dat je deze niet middels de AAD kunt beheren, en deze ook geen doorwerking hebben op bijvoorbeeld Teams of Planner, welke ook gekoppeld kunnen zijn aan dezelfde Office Group.

Hoewel dit dus allemaal mogelijk is, zou dit een bewuste keuze moeten zijn, bijvoorbeeld vanuit het oogpunt van transparantie (open, tenzij). Hou er in dat geval ook rekening mee dat gebruikers die alleen leesrechten hebben, ook geconfronteerd worden met bijvoorbeeld meer resultaten uit de zoekfunctie en mogelijk andere zaken die als ‘vervuilend’ bestempeld kunnen worden door de gebruiker. Het advies hierin is dit ook beperkt toe te passen binnen Office Group gekoppelde sites, ook vanuit het security oogpunt (wat als iemand gevoelige informatie deelt binnen een groep?).

Toch ook sitebezoekers, maar dit zijn de SharePoint beveiligingsgroepen!

Binnen Office Groups is het mogelijk om verschillende ‘privacy’ niveaus aan te houden. Grofweg zijn er hierbij 3 mogelijke opties:

  • Privé. Leden moeten hierbij worden toegevoegd door de eigenaar. Dit is de meest logische keuze als je samenwerk in groepen.
  • Openbaar. Leden mogen zichzelf hierbij als lid toevoegen. Dit zou een logische keuze zijn als je bijvoorbeeld wilt samenwerken in een community of een thema, waarbij de leden ook content mogen bewerken/toevoegen.
  • Company-wide (alleen door admin in te stellen). Hierbij worden alle leden automatisch toegevoegd aan de groep, ook als er nieuwe users worden aangemaakt. Denk hierbij aan een bedrijfs-brede community (of vergelijk het met een Yammer groep, waarbij iedereen standaard lid is).

Keuze voor privacyinstellingen

Bij het instellen van het niveau, is het ook goed om de link te leggen naar de consequenties in Teams (als je deze gebruikt). Zo is het gebruik van het gekoppelde Team weer specifiek in te regelen in Teams zelf. Denk bijvoorbeeld aan het beperken van aanmaken van kanalen, of het mogen verwijderen van chats, etc.. Vaak zie ik in de praktijk dat de ‘Privé’ groepen de standaard zijn.

Publiceren van content

Voor sites met een publicerend karakter (intranet, portalen, documentpublicatie, etc.), is het verstandiger om geen Office Group te gebruiken, maar een losse SharePoint site. Vaak zijn er bij dit soort sites ook geen Planner of Team nodig en voldoet SharePoint alleen. Kies in deze gevallen om een Communicatiesite, of een moderne teamsite zonder Office Group (sinds kort mogelijk). Let daarbij ook dat de rechten dus niet meer vanuit de AAD geregeld worden, maar vanuit de permissies in SharePoint zelf, zoals ‘vroeger’ ook het geval al was. Advies hierbij is na te denken over een ‘publicatie’ team (groep content beheerders) en een bezoekers groep (standaard bezoekersgroep). Probeer niet af te wijken van de standaard permissies die SharePoint biedt, omdat dit in de praktijk altijd tot problemen gaat leiden.

Ook is het verstandig een model te hanteren met uniforme rechten binnen de site collectie. Probeer, indien het gewenst is verschillende rechten niveaus te hanteren, ervoor te kiezen dit in een nieuwe site collectie te doen, en deze site collecties middels een Hub Site te koppelen. Zo blijft de rechtenstructuur beheersbaar en transparant.

Probeer gebroken rechten te vermijden binnen een site collectie. Een hubsite zou een alternatief kunnen zijn.


Verstandig is de keuzes (wanneer gebruik je wat, en hoe dan) vast te leggen in een governance, zodat iedereen weet en kan lezen hoe jullie SharePoint en Teams inzetten en welke keuzes er hier zijn gemaakt. Denk hierbij ook na over de lifecycle van vooral Office Groups (publicaties sites zullen vaak permanent zijn). Als gebruikers zelf groepen (en Teams) mogen gaan aanmaken, kan dit leiden tot veel Office Groups, waarbij sommigen wellicht nooit gebruikt worden. Hoewel er een limiet is van 500.000 site collecties per tenant, het is het verstandig hier vanaf dag 1 rekening mee te houden. De AAD biedt hiervoor een mechanisme, maar je zou het ook in een proces kunnen vangen.

Als archivering hierbij een rol speelt, kijk dan vooral naar de retentielabels in het compliance center. Hiermee borg je op centraal niveau de bewaartermijnen en daarmee het beleid dat je wilt voeren.