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.

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.

Office 365 Tip: SharePoint documentversies vergelijken in Word

SharePoint biedt de mogelijkheid om te werken met versies. Hierbij wordt onderscheid gemaakt tussen zogenaamde major (1.0, 2.0, etc.) en minor (0.1, 0.2, etc.) versies. Het bijhouden van versies is een instelling op bibliotheek niveau en heeft als voordeel dat het inzichtelijk wordt wie, wat en wanneer er wat met het document gedaan is.


Soms is het nodig te zien welke wijzigingen er hebben plaatsgevonden sinds een bepaalde versie. Het is dan mogelijk om in SharePoint een oudere versie in te zien. Je kan de huidige versie dan vergelijken met een vorige versie.


Dit laatste kan echter ook heel simpel vanuit Word. Open hiervoor het document uit SharePoint in Word.


Kies vervolgens voor het ‘Vergelijken‘ menu en kies ‘Bepaalde versie…‘.


Selecteer vervolgens de versie die je wilt vergelijken met het origineel.


En het is vervolgens mogelijk de wijzigingen te vergelijken, direct vanuit Word!

Bouw je eigen Bot in Microsoft Teams & Skype (stap voor stap)

Eind vorig jaar schreef ik een blog met daarin een voorspelling over Bots in Microsoft Teams. Hierin benoemde ik de mogelijk om zelf aan de slag te gaan met het maken van een eigen Bot. In het (verre) verleden (2004) heb ik ooit een bot gemaakt die je SharePoint kon laten doorzoeken met behulp van Live Communication Server (LCS), de verre voorloper van Skype voor Bedrijven.


Met de mogelijkheid om Bots te bouwen in Microsoft Teams, is het een stuk eenvoudiger geworden om hiermee aan de slag te gaan. In een uurtje tijd lukte het me om een eigen bot te maken, deze in Azure uit te rollen, en deze vervolgens in Microsoft Teams, Skype en Skype voor bedrijven te gebruiken! Een korte samenvatting:

Bouwen van je Bot
Een goed startpunt is de Bot Builder SDK for .Net te gebruiken. Hier heb je de mogelijkheid om drie zip bestanden te downloaden die een Bot template beschikbaar maken in Visual Studio 2017.bitspraakbot5Tevens wordt er een link gelegd naar de Bot emulator, waarmee je je eigen Bot offline kan testen. Als je alles binnen hebt, kan je een nieuw project starten. Ik kan in dit artikel niet te veel in op de logica van een Bot, maar je kan heel eenvoudig je eerste logica toevoegen. bitspraakbot6

Testen van je Bot
Je kan de Bot testen door de emulator te gebruiken. Debug je project en voer het Bot ‘endpoint’ in, in de emulator. Het endpoint is van belang; via dit kanaal communiceert je Bot straks met Teams of Skype. Het endpoint bevindt zich op: https://[url]/api/messages

Registratie van je Bot
Bij het verbinden met je Bot, werk je met een application ID en een wachtwoord. Deze kan je zelf genereren en aanpassen in de web.config van het project, maar omdat je Bot straks ook online geregistreerd wordt, is het handig deze registratie eerst uit te voeren. Ga hiervoor naar, en maak een nieuwe Bot aan. Je geeft tijdens deze registratie aan wat je Bot is en doet, de afbeeldingen van je Bot, en je endpoint. Tevens genereer je een ID en wachtwoord. Deze heb je op verschillende plekken nodig.

Uitrollen van je Bot
Nadat je registratie van je Bot klaar is, je het ID en wachtwoord in de web.config hebt geregistreerd hebt, en je de Bot werkend gezien hebt in de emulator, kan je de Bot uitrollen naar bijvoorbeeld Azure. Dit gaat eenvoudig via de publicatie optie in Visual Studio. Let er wel op dat je Bot communiceert over een beveiligde verbinding (https). Uiteraard is dit standaard binnen een Azure Web app.

Kanalen configureren
Je bot is gepubliceerd in Azure, en je kan nu beginnen met het configureren van de kanalen waar je Bot over mag communiceren. In mijn geval stel ik de Bot beschikbaar in Microsoft Teams, Skype en Skype voor Bedrijven. Het is een kwestie van aanzetten in je Bot configuratie online.


Je Bot gebruiken in Microsoft Teams
Het is mogelijk om je Bot nu te gebruiken in Teams. Hiervoor is het handig om de Teams App Studio te downloaden. Met deze tool maak je eenvoudig een package (.zip) zodat je deze kan toevoegen in Teams.


Ook hier gebruik je weer de ID en gegevens van je Bot. Uiteindelijk package je de Bot en wordt een .zip bestand gegenereerd welke gebruikers kunnen gebruiken om je Bot toe te voegen. Omdat het een test betreft, is dit de makkelijkste manier om je Bot te gebruiken. Uiteraard kan je de Bot, indien deze voldoet aan bepaalde eisen, ook publiceren in de Store van Microsoft.

Gebruikers kunnen nu de .zip gebruiken om de Bot toe te voegen. Selecteer hiervoor in de Store de optie ‘Een aangepaste app uploaden’ (linksonder in het menu).


Je Bot is vervolgens beschikbaar in je Chat scherm, of in het Team waaraan je de Bot toevoegt.


Je Bot gebruiken in Skype
Het is eenvoudig je Bot te gebruiken in Skype (voor consumenten). Bij het activeren van het kanaal online, krijg je een URL. Door deze URL aan te klikken wordt de Bot toegevoegd aan je contacten in Skype. Je kan de Bot daarna direct gebruiken


Je Bot gebruiken in Skype voor Bedrijven
Je Bot beschikbaar stellen in Skype voor Bedrijven binnen je organisatie kan je centraal regelen. Dit kan vooralsnog alleen via PowerShell. De handleiding hiervoor staat hier beschreven: In feite registreer je de Bot in Skype onder een eigen account (bijvoorbeeld:  Het kan tot 8 uur duren voordat de Bot bij alle gebruikers beschikbaar is.


Het maken van een Bot is relatief eenvoudig, als je tenminste de logica van je Bot buiten beschouwing laat. Hoewel je een bewerkelijk aantal stappen moet zetten om je Bot werkend te krijgen, zijn de stappen niet heel lastig. De uitdaging ligt vooral bij het ‘intelligent’ maken van je Bot.

De toepassingen van een Bot zijn natuurlijk legio: informatie opvragen, simpele taken uitvoeren, etc. Doordat je Bot in Teams of Skype aanwezig is, kan je makkelijk ook onderweg via je telefoon je Bot benaderen.

Op dit moment bevat mijn Bot nog niet veel handigheidjes. De komende tijd zal ik daarom af en toe een update geven van de vorderingen van de Bitspraak Bot. Mocht je intussen vragen hebben, laat het mij dan weten!

Office 365 Tip: Bulksgewijs metadata bewerken

Met het toekennen van metadata in SharePoint lijsten, kunnen gebruikers de kracht van SharePoint optimaal benutten. Het wordt op deze manier namelijk makkelijk overzichten te creëren en zoekopdrachten uit te voeren op content, ongeacht op welke plek deze content is opgeslagen. Van oudsher is dit een van de speerpunten van SharePoint.

Het toekennen en updaten van metadata is in de loop der tijd veranderd. Zeker met de introductie van de ‘modern layout’ in SharePoint, is dit een fluitje van een cent geworden. Echter, het in één keer updaten van een metadata veld van meerdere items in een lijst, is altijd bewerkelijk geweest: in de klassieke SharePoint sites was er de optie ‘Weergeven in Excel weergave’, waarmee gebruikers een mogelijkheid kregen om metadata ‘snel’ te bewerken. Echter, in praktijk blijkt dit niet altijd even betrouwbaar. In de moderne lay-out is deze optie zelfs helemaal verdwenen.

Maar hiervoor is nu een oplossing geïntroduceerd: Bulksgewijs bewerken van metadata. Het was al mogelijk om een item in een lijst te selecteren en de metadata direct aan te passen onder het ‘i’-tje, rechtsboven in de lijst. De wijziging wordt daarmee direct opgeslagen. Snel en handig.


Nu is het echter ook mogelijk geworden om meerdere items tegelijk te selecteren en daarvan de metadata te bewerken! Dit gaat op dezelfde wijze: selecteer de documenten en klik op het ‘i’-tje. De optie ‘Bulksgewijs bewerken’ word daarna getoond. In dit scherm komen alleen de kolommen terug die ondersteund worden om bulksgewijs te updaten.


Nadat de juiste waarde is geselecteerd en je op ‘Opslaan’ hebt geklikt, is de metadata direct opgeslagen voor alle geselecteerde items. Een (zeer) welkome toevoeging in SharePoint!

Wil je meer informatie, lees dan het artikel hierover van Microsoft of neem contact met me op.

Security issue? Het verwijderen van bestanden met OneDrive Synchronisatie is niet altijd wat je denkt!

Met de OneDrive synchronisatie applicatie is het mogelijk om OneDrive omgeving en SharePoint bibliotheken te synchroniseren met de lokale werkstation. Dit is een heel mooi en krachtig mechanisme waarmee de adoptie van online werken sterk wordt bevorderd. Het wordt hiermee namelijk erg makkelijk om te werken met bestanden in SharePoint of OneDrive.

Zo is het mogelijk dat meerdere gebruikers dezelfde bibliotheken synchroniseren. Erg handig dus, want wijzigingen van anderen worden direct verwerkt op je eigen lokale omgeving.

Echter, hier zitten ook wat nadelen aan. Waar een van mijn klanten mee te maken kreeg is het volgende scenario:

  • Meerdere mensen hebben dezelfde SharePoint bibliotheek gesynchroniseerd.
  • Een van de gebruikers plaatst, per ongeluk, een vertrouwelijk document in de bibliotheek.
  • Deze wordt snel weer verwijderd uit SharePoint, en dus ook weer van de lokale machines van andere gebruikers.

Maar wat is er daadwerkelijk gebeurd? Ten eerste heeft elke gebruiker het bestand lokaal op zijn machine gekregen. De verwijderactie in SharePoint heeft ervoor gezorgd dat het bestand ook bij elke gebruiker wordt verwijderd. Echter, deze bestanden worden lokaal bij iedereen in de Windows Prullenbak geplaatst. Fysiek niet verdwenen dus.

N.a.v. dit gedrag werden de volgende acties uitgevoerd:

  • De gebruiker heeft de prullenbak in SharePoint (waar het document nog in stond) geleegd. Ook de site collectie prullenbak werd geleegd. Hiermee is het bestand daadwerkelijk uit de SharePoint site verwijderd, tenzij DLP beleid anders is geconfigureerd. Dit is in dit scenario niet het geval.
  • Tevens heeft de gebruiker zijn eigen prullenbak in Windows geleegd.


In de beleving van de gebruiker is het document nu écht weg en verwijderd. Echter, het verwijderde document is nog niet verwijderd uit de lokale prullenbakken op de werkplekken van de andere gebruikers. Gebruikers kunnen de documenten vanuit de Windows prullenbak weer terugzetten in hun lokale OneDrive folder, waarmee het document ook weer in SharePoint terecht komt.


Kortom, een mogelijk security gat, waarbij gebruikers niet altijd inzichtelijk krijgen wat er met een bestand gedaan wordt. Omdat het Office 365 Compliance & Security center ook niet fysiek op de computer van gebruikers controleert, is ook lastig te achterhalen wat er met het bestand gebeurt.

Hoe hiermee om te gaan? Vooralsnog is er een aantal mogelijkheden om grip te krijgen op dit verschijnsel.

  • De prullenbak bij alle gebruikers die synchroniseren legen. Dit is natuurlijk bewerkelijk en zal lastiger worden naarmate er meer gebruiker bij betrokken zijn.
  • (AIP) Azure Information Protection / IRM (Information Rights Management) implementeren voor dergelijk vertrouwelijke documenten. Hiermee kan centraal geregeld worden wat er met een bestand gedaan mag worden. Onder andere kunnen dan bijvoorbeeld op centraal niveau de rechten van gebruikers worden ingetrokken. Het document wordt dan onbruikbaar. Deze methode is waterdicht, maar behoeft wel enige kennis en energie om te implementeren.
  • Als derde optie, een work-around, het bestand in eerste plaats niet weg gooien (want dan belandt het in de prullenbak), maar de inhoud van het document verwijderen en vervolgens het document verwijderen. Let er bij deze methode wel op dat oude versies ook niet bewaard worden in SharePoint.

Samengevat is het een probleem als er fouten worden gemaakt met het plaatsen van bepaalde (vertrouwelijke) documenten op de verkeerde plek, in combinatie met synchronisatie van OneDrive. Ik ben daarom ook erg benieuwd naar jullie ervaringen en ideeën over dit probleem. Laat het me weten!