SharePoint – Bitspraak

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

Geplaatst op 23 april 2019 door Bitspraak

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.

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’.

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.

Communication

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!

Technology

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.

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.

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).

ClassicToModern.zip Download

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.

Conclusion

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

Geplaatst op 23 april 201923 april 2019 door Bitspraak

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.

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’.

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!

Ontwerpkeuzes

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.

Communicatie

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!

Techniek

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.

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.

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).

ClassicToModern.zip Download

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.

Conclusie

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?

Geplaatst op 12 april 201912 april 2019 door Bitspraak

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 Teams, Microsoft 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.

Eigenaren

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.

Leden

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.

Office Groups, wanneer wel en wanneer niet?

Geplaatst op 1 april 20191 april 2019 door Bitspraak

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.

groups_5 — 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.

groups_3 — 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?).

groups_4 — 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).

groups_2 — 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.

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

Governance

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.

Informatiebeheer in Office 365: Labels & Beleid (deel 3)

Geplaatst op 20 juni 2018 door Bitspraak

In deel 1 van deze serie heb ik gehad over de nieuwe manier van het toepassen van informatiebeheer binnen Office 365. In deel 2 ben ik daarbij ingegaan op het classificeren van Office Groups (en daarmee o.a. SharePoint sites en Teams). In dit deel zal ik verder ingaan op de volgende stap: het daadwerkelijk implementeren van informatiebeleid in Office 365.

Want: met het classificeren van sites en het toepassen van rechten via Site Scripts en Site Designs, gebeurt er nog weinig op het gebied van beleid. Sterker nog, de controle op content is nog niet geregeld want gebruikers kunnen in feite nog alles doen met het document, bijvoorbeeld verwijderen.

Hiervoor moeten nog twee zaken worden ingeregeld, namelijk de informatie beveiliging (zie de volgende post later) én het beleid wat van toepassing op is content.

Het Security en Compliance Center

Binnen Office 365 is voor al deze zaken een belangrijk portaal gemaakt: het security en compliance center. Op deze plek is het mogelijk om uiteenlopende zaken als toegang en beveiliging te controleren, bedreigingen van buitenaf te monitoren, rapportages en compliance rapporten te genereren, audits te doen (bijvoorbeeld in het kader van de AVG), maar ook beleid te specificeren en uit te rollen binnen Office 365. Hoewel de andere onderwerpen reuze interessant zijn en essentieel in het beheer van Office 365, blijven we in deze posting ‘hangen’ op het onderwerp Labels en Beleid.

Wat zijn Labels?

Labels zijn kenmerken (een titel en omschrijving) en bevat het beleid wat van toepassing is als een label wordt gekoppeld aan content. Content kan bijvoorbeeld een document zijn, maar net zo goed een e-mail in Outlook. En het beleid wat gekoppeld is, kan verschillende vormen bevatten. Bijvoorbeeld:

Een e-mail welke persoonsgegevens bevat, bijvoorbeeld een C.V. als bijlage, moet volgens de wet na een jaar verwijderd worden. We geven deze beleidsregels in dit geval de titel ‘Persoonsgegevens’ mee als label.
Een document met daarin een jaarverslag mag niet verwijderd worden voor een periode van 7 jaar. Na deze 7 jaar, moet een Record Manager een akkoord geven om het document te verwijderen. In dit geval geven we aan dit beleid de titel ‘Jaarverslag’ mee als label.

Deze twee voorbeelden komen vaak voor binnen organisaties en zijn daarom geschikt om als voorbeeld te dienen in deze post. De indeling van labels kan natuurlijk verschillen per organisatie; sommige organisaties draaien vooral op procesniveau en een beschrijving van het proces is in dat geval logischer. Het is ook mogelijk om een indeling op classificatie te maken.

Let wel: op content is slechts 1 label tegelijkertijd toe te passen. Een combinatie van beleid is daarom niet mogelijk!

Een label aanmaken kan via het Security & Compliance Center, te benaderen via de app in de app launcher van je Office 365 portaal, óf via https://protection.office.com. Ga daarna naar ‘Classificatie’ en labels, waar je een nieuw label kan maken.

Na deze omschrijving, kan aangegeven worden wat er met de content moet gebeuren nadat het geclassificeerd is met dit label. Er zijn hierbij verschillende opties:

Bewaren van de inhoud, waarbij aangegeven kan worden hoe lang en vanaf welk moment.
Ook kan worden aangegeven of de content gedurende die tijd beschouwd moet worden als een ‘record’, waardoor het niet verwijderd kan worden.
En er kan worden ingesteld wat er na deze periode moet gebeuren, bijvoorbeeld vernietiging (al dan niet met goedkeuring), of iets anders.

Na het controleren kan het label vervolgens worden aangemaakt.

Wat is beleid?

Beleid, in de context van Office 365 labels, is een set van labels welke op basis van configuratie wordt uitgerold in de Office 365 omgeving. Door beleid uit te rollen op bijvoorbeeld een site, komen de labels beschikbaar. Label kunnen uitgerold worden op:

SharePoint sites
Exchange mailboxen
OneDrive omgevingen
Office 365 Groups

In ons geval gaan we een beleid uitrollen met het persoonsgegevens label er in. Na de selectie van de labels, kunnen we de locatie specificeren waarop de labels worden uitgerold.

Ik ga het uitrollen op de demo site die ik in één van de eerdere blog postings heb aangemaakt.

Vervolgens is het mogelijk om het beleid nog een naam en omschrijving te geven, zodat duidelijk wordt om welk beleid het gaat.

Vervolgens kan het beleid gepubliceerd worden. Dit proces kan even duren, de ervaring is dat op een enkele locatie dit binnen een half uurtje geregeld is. Indien het label overal gepubliceerd worden, zou dit wat langer kunnen duren.

Nadat het label beschikbaar is, is het te gebruiken op de locatie waar het gepubliceerd is.

Zoals je kan zien is het label beschikbaar gekomen in de SharePoint site. Hierbij wordt direct een duidelijk beschrijving van het beleid gegeven, zodat gebruikers kunnen zien wat er mee gebeurt zodra een label wordt gekoppeld.

Het mooie binnen Office 365 is nu dat dit beleid ook kan worden uitgerold op bijvoorbeeld de mailboxen, zodat gebruikers ook hier de labels kunnen toepassen. Er wordt op deze manier een uniforme manier geboden die herkenbaar is voor de gebruiker. Het is dus ook een oplossing voor archiveren en vernietigen van e-mails.

Het koppelen van labels aan content in SharePoint kan op verschillende manieren:

De gebruiker selecteert het label zelf bij de eigenschappen van een document.
Er wordt een standaard label ingesteld bij de eigenschappen van een documentbibliotheek. Elk item in de bibliotheek krijgt daarmee het label toegekend.
De content wordt automatisch toegekend op basis van de analyse van het document.

Dit laatste behoeft wat meer uitleg. Binnen Office 365 is een aantal checks beschikbaar waarmee de content automatisch een label krijgt toegekend. Denk hierbij aan een document dat een BSN nummer bevat of een IP-adres. Dit soort checks zijn standaard beschikbaar binnen de E3 licentie van Office 365. Echter, het is ook mogelijk zelf een check toe toevoegen. Dit kan op basis van een patroon, maar ook op bepaalde sleutelwoorden in de content. Dit is natuurlijk enorm krachtig, want gebruikers blijven vaak de zwakke schakel in de keten. Deze functionaliteit is echter onderdeel van de E5 licentie. Je betaalt er dus wel voor.

Tevens is het automatisch classificeren van content ook risicovol: het kan zijn dat content ten onrechte een label toegekend krijgt. Let er daarom op dat bij automatisch labelen je zeker weet dat de classificatie gezet moet worden.

Conclusie

Met de inrichten van labels kan een organisatie compliant worden met het eigen gestelde beleid, maar ook de wetgeving (als bijvoorbeeld AVG). Office 365 biedt een uniforme manier aan om het beleid te laten landen in de verschillende producten als sites, e-mail of groups.

Nu dit goed is ingeregeld is het tijd om na te denken over informatiebeveiliging: hoe zorgen we ervoor dat er geen data lekken ontstaan en dat informatie niet moedwillig verdwijnt? Dat wordt het onderwerp van de volgende post in deze serie!

Informatiebeheer in Office 365: Site classificatie (deel 2)

Geplaatst op 12 juni 201820 juni 2018 door Bitspraak

In deel 1 van deze serie blog postings, heb ik aangegeven dat veel inrichtingen die in SharePoint gedaan zijn, gebaseerd zijn op metadata modellen. Bij Microsoft zijn ze er inmiddels achter dat dit voor veel gebruikers als lastig wordt ervaren en in vele inrichtingen gaat dit het doel dan ook voorbij. Er is daarom besloten een aantal zaken anders aan te pakken, waardoor het voor de gebruiker een stuk eenvoudiger wordt. Dit is best een verandering; een aantal principiële uitgangspunten wordt namelijk in twijfel getrokken:

Metadata is niet heilig, gebruik het ter ondersteuning (bijvoorbeeld weergaven of workflow), maar niet voor het beveiligen of classificeren van documenten.
Folders zijn handig. In het verleden werd vaak geteld dat je metadata moet gebruiken in plaats van een folderstructuur. Heel zuiver gezien is dit zo, maar in de praktijk willen gebruikers vaak toch een vorm van (fysieke) structuur toepassen. Hoewel SharePoint beschikt over ‘Documentsets’, lijkt dit mechanisme inmiddels bestempeld te zijn als legacy.
Gebruik geen sub sites meer. Sub sites bevatten vaak een structuur, soms met aangepaste rechten. Met de verschuiving naar Office Groups, wordt deze structuur niet goed ondersteund. In plaats daarvan is het gebruik van verschillende site collecties óf het Hub Site mechanisme veel flexibeler en transparanter. Zeker op het gebied van rechten.
Beperk de inrichting op basis van SharePoint groepen met specifieke permissies. Probeer de leunen op het model van Eigenaren, Leden en Bezoekers, zoals deze ook terug komen in Office Groups.

Het grote uitgangspunt binnen Office 365 is dat het niet meer uit maakt wat voor content op welke plek staat, zolang je de content maar classificeert. Dit classificeren kan op verschillende manieren. Een van deze manieren het is het classificeren van de Office Group (met daarbij de SharePoint site). Het is standaard mogelijk om een Group een ‘classificatie label’ mee te geven, waardoor Office 365 bewust wordt van het feit dat de content in deze Group van een bepaalde gevoeligheid is.

Met de gevoeligheid van content wordt bedoeld dat duidelijk is wat het effect is van bijvoorbeeld een datalek van de content. Wat is de ‘schade’ (in kosten, in reputatie, in wetgeving) als de content gelekt wordt naar personen die het niet zouden mogen zien. Denk bijvoorbeeld aan het lekken van persoonsgegevens, e-mail uitwisseling over bedrijfsovernames of beursgang van een organisatie. De effecten daarvan kunnen enorm zijn!

Veel (grotere) organisaties hebben daarom een classificering van gegevens opgesteld. Bijvoorbeeld: openbaar, intern, vertrouwelijk en geheim. Hierbij worden regels ofwel beleid opgesteld over wat er met deze content wel en niet mag. Zo mag vertrouwelijke content bijvoorbeeld niet gedeeld worden met externen of moet geheime informatie versleuteld zijn.

Dit beleid kan worden vertaald naar een inrichting in Office 365, maar daarvoor moeten we wel eerst goed weten hoe dat beleid er uit ziet. Zo kan het bijvoorbeeld zijn dat er nog verschillende gradaties zijn in vertrouwelijke informatie. Bijvoorbeeld ‘persoonsgegevens’ mogen niet gedeeld worden met externen, maar moeten ook vernietigd worden binnen 1 jaar. Of: ‘jaarverslagen’ mogen alleen door het management ingezien worden, maar mogen 7 jaar niet verwijderd worden.

Het is daarom van belang dat deze differentiaties in kaart gebracht worden. Als voorbeeld de volgende indeling:

Openbaar
Intern (geen gevoelige informatie)
Vertrouwelijk
- Persoonsgegevens
- Financiele gegevens
Geheim
- Persoonsgegevens
- Stategisch

Let wel: dit is een voorbeeld en (waarschijnlijk) geen complete lijst. Dit is uiteraard organisatieafhankelijk, maar in ons geval voldoet het als voorbeeld.

Het is nu mogelijk om op basis van deze classificatie indeling, Office Groups te gaan classificeren. Om dit te doen kan er met behulp van een Powershell commando worden aangegeven welke classificaties er beschikbaar zijn, wat de omschrijvingen zijn van de classificaties en welke classificatie als standaard kan worden ingesteld.

 $setting= Get-AzureADDirectorySetting | ? {$_.DisplayName -eq "Group.Unified"}
 $AzureADDirectorySettingId= Get-AzureADDirectorySetting | where {$_.DisplayName -like "Group.Unified"} | Select-Object Id
 # zet classificatie opties
 $setting["ClassificationList"] = "Openbaar,Intern (geen gevoelige informatie),Vertrouwelijk (Persoonsgegevens),Vertrouwelijk (Financiële gegevens),Geheim (Persoonsgegevens),Geheim (Strategisch)"
 # Sla classificaties op
 Set-AzureADDirectorySetting -Id $AzureADDirectorySettingId.id -DirectorySetting $setting
 # bepaald de standaard waarde
 $setting["DefaultClassification"] = "Intern (geen gevoelige informatie)"
 # bepaal de omschrijvingen
 $setting["ClassificationDescriptions"] = "Openbaar: mag gedeeld worden met iedereen en bevat geen gevoelige informatie,Intern (geen gevoelige informatie): mag alleen binnen de organisatie gedeeld worden,Vertrouwelijk (Persoonsgegevens): bevat vertrouwelijke persoonsgegevens,Vertrouwelijk (Financiële gegevens): bevat financiële gegevens als jaarverslagen of contracten,Geheim (Persoonsgegevens): bevat geheime medische gegevens als bijvoorbeeld medische gegevens,Geheim (Strategisch): bevat strategische inforamtie als bijvoorbeeld overnames"
 # Sla instellingen iop
 Set-AzureADDirectorySetting -Id $AzureADDirectorySettingId.id -DirectorySetting $setting
 # Toon ingestelde waarden
 (Get-AzureADDirectorySetting -Id (Get-AzureADDirectorySetting | where -Property DisplayName -Value "Group.Unified" -EQ).id).Values

Na het uitvoeren van deze actie, wordt in het standaard scherm voor aanmaken van een nieuwe SharePoint site, de mogelijkheid geboden de classificatie van de site (of eigenlijk de Office Group) te kiezen. Dit is standaard functionaliteit.

Het prettige is dat de site die vervolgens wordt aangemaakt ook zodanig gekenmerkt is in de header van de site. Het is dus voor gebruikers direct duidelijk welk type informatie er op de site staat.

Bij het aanmaken van de site zijn ook ‘privacy instellingen’ te specificeren. Dit onderdeel behoeft wel wat uitleg, want de keuze is hierbij ‘Openbaar (public)’ of ‘Privé (private)’. In het geval van ‘Privé’ is de site alleen te benaderen door eigenaren en leden die specifiek zijn toegevoegd. In het geval van ‘Openbaar’ kan iedereen op de site komen (logisch), maar heeft iedereen ook bewerk rechten (minder logisch). Het idee hier achter is dat iedereen in het laatste geval deelneemt aan het team en daarmee bewerk rechten krijgt. Echter, deze bewerkrechten houden ook in dat er bibliotheken kunnen worden aangemaakt of verwijderd en dat pagina’s in de site kunnen worden bewerkt. Kortom, dit is vaak niet het doel van een openbare site waarbij de verwachting is dat iedereen standaard alleen leesrechten heeft.

Mocht dit laatste daarom gewenst zijn, dan is wellicht een communicatiesite een logische optie, waarbij dit wel het geval is.

Met het instellen van de classificatie is verder niets gezegd over het beveiligingsniveau van de site of het beleid dat geldt op de site. Hiervoor moet de volgende stap worden uitgevoerd: het toevoegen van site designs en site scripts.

Site Designs en Site Scripts (templates)

De specifieke inrichting van de site, samen met de classificatie en privacy instellingen, kan ervoor zorgen dat de gewenste instellingen (grotendeels) automatisch bepaald worden. Voor elke type template kan in Office 365 een zogenaamd ‘Site Design’ worden geregistreerd. Een Site Design bevat één of meerdere Site Scripts, waarin de inrichting van een site mee wordt bepaald. Zo kunnen bijvoorbeeld branding, rechten, inhoudstypen of lijsten worden bepaald in een Site Script, welke na het aanmaken van een site worden uitgevoerd.

In dit mechanisme is het ook mogelijk om Flow triggers te definiëren, zodat ook complexere inrichting kan worden gedaan, of bijvoorbeeld het initiëren van een provisioning tool (of Powershell) actie. Site Designs komen beschikbaar bij het aanmaken van een nieuwe site. Na het aanmaken van de site, zullen de acties automatisch worden uitgevoerd en uitgerold op de SharePoint site. Een van de zaken die je hierbij niet wilt missen, is het uitrollen van labels en beleid op de site. Hierover zal de volgende blog post gaan.

Site designs komen ook weer als standaard functionaliteit terug bij het aanmaken van een nieuwe site.

Tip: Laura Kokkarinen heeft een helder en compleet overzicht uitgewerkt over Site Designs en Site Scripts. Het is het lezen waard als je hiermee aan de slag wilt gaan.

SharePoint vs. Office 365

Het valt je misschien op dat het bovenstaande vooral gaat over SharePoint sites. Dit is deels waar: bij het aanmaken van een site wordt je geconfronteerd met deze classificatie. Het mooie echter is dat de classificatie ook terug komt als je een Planner omgeving aanmaakt, een Power BI workspace of een Microsoft Teams omgeving. Hierbij wordt onder water ook een Office Group aangemaakt, waardoor de classificatie ook daar doorwerkt:

In deze gevallen geldt ook dat hieraan het juiste beleid gekoppeld kan gaat worden, wat van toepassing is op de achterliggende SharePoint site, de chat conversaties en planner taken. Kortom, binnen alle Office Group gebaseerde content kan gebruik gemaakt worden van de classificatie!

In de volgende post zal ik het samenstellen van beleid voor content verder bespreken.

Informatiebeheer in Office 365: Inleiding (deel 1)

Geplaatst op 11 juni 201820 juni 2018 door Bitspraak

Al 15 jaar lang wordt SharePoint gezien als een platform waarop het mogelijk is documenten en informatie op te slaan op een ‘gestructureerde manier’. Tussen aanhalingstekens, want gestructureerd betekent in SharePoint termen: voorzien van metadata. Door kenmerken aan een document toe te voegen, zo is het idee, wordt deze informatie makkelijk vindbaar en kunnen gebruikers makkelijk bij hetgeen komen wat ze zoeken.

Tot zover de theorie. Ik wil niet beweren dat we het 15 jaar verkeerd hebben aangepakt, maar in de praktijk blijkt een aantal aannames niet van toepassing te zijn:

Gebruikers zijn ‘lui’. Nee niet echt lui, maar wel als het gaat om invullen van kenmerken bij een document. En dit is terecht: de essentie staat in het document zelf, alles wat achteraf extra moet worden ingevuld (metadata), wordt over het algemeen al ballast gezien. Het effect:
Documenten worden onvolledig of onjuist voorzien van metadata. Hierbij is het onjuist invullen nog erger dan helemaal niet invullen.
We zoeken 1 document en vinden er 200. Zoeken is jaren lang gezien al hét middel om documenten te vinden. De zoekmachine van SharePoint is natuurlijk enorm krachtig, maar in praktijk is het vinden van het juiste document niet zo eenvoudig gebleken.
Metadata zegt wat over het document, maar doet er niets mee. Het is mogelijk documenten te voorzien van een label ‘vertrouwelijk’, of een keuzeveld ‘jaarverslag’. Het feit dat het een kenmerk bevat, betekent niet dat een document versleuteld is, of alleen beschikbaar is voor het management. Kortom, dit zal op een andere manier geregeld moeten worden. Sterker nog: de gebruiker denkt dat het goed geregeld is, zonder dat dit daadwerkelijk het geval hoeft te zijn…

Er zal daarom iets anders moeten gebeuren om de informatie huishouding in SharePoint op orde te krijgen. Niet onbelangrijk is daarbij dat in Office 365 we niet alleen te maken hebben met SharePoint, maar ook met e-mail, enquêtes, video’s, chatconversaties en nog vele andere typen media. Hoe zit het daar dan mee?

Ook Microsoft heeft dit door en is daarom sinds kort een andere koers gaan varen. Het sleutelwoord hierin is classificatie, oftewel: beschrijven hoe gevoelig de informatie is waarmee je werkt. Dit is nogal een andere invalshoek wat ook qua inrichting flink afwijkt van de traditionele SharePoint inrichtingen.

Deze serie blog postings zal daarom een overzicht geven van deze nieuwe manier. De komende weken zal ik inzoomen op de volgende onderwerpen:

Deel 2: Site classificaties, privacy instellingen en site ontwerpen
Deel 3: Labels en beleid: lifecycle management in Office 365
Informatiebeveiliging, verschijnt binnenkort
Grip op informatie (beveiliging en compliance), verschijnt binnenkort

Op elk van deze onderwerpen zal ik niet alleen op de techniek ingaan, maar ook op de organisatorische inrichting en wetgeving.

Office 365 Tip: Direct invullen van SharePoint metadata in een document

Geplaatst op 6 maart 2018 door Bitspraak

SharePoint kenmerkt zich onder andere doordat het een erg krachtig document management systeem is. In SharePoint is het eenvoudig om documenten eigenschappen (metadata) te geven en daar vervolgens voordeel mee te behalen. Zo is het mogelijk om te zoeken op eigenschappen, maar ook filters en sorteringen aan te brengen op basis van deze metadata.

Het invullen van metadata is echter een discipline op zich. De goede werking van SharePoint hangt mede af van het invullen van de juiste metadata door gebruikers. Gebeurt dit niet of verkeerd, dan kan het funest zijn voor de vindbaarheid van documenten.

Dit invullen wordt steeds eenvoudiger. Zo is er onlangs de mogelijkheid ingebouwd om in bulk metadata te bewerken. En sinds kort hebben de Office applicaties (Word, Excel, etc.) de mogelijkheid om deze metadata vanuit het bewerken direct in te vullen. In vroegere Office versies kon dit al via het Document Information Panel (DIP). Echter, dit mechanisme is in de laatste versies verwijderd. Nu is dit een ‘App’ geworden, waarmee het weer een nieuw leven is ingeblazen.

Hoe werkt het? Open een bestand vanuit SharePoint. In het menu (onder ‘Beeld’) is er een optie bijgekomen ‘Eigenschappen’.

Nadat je de knop hebt aangeklikt, worden de eigenschappen getoond van de eigenschappen in SharePoint. Deze eigenschappen zijn direct van Office in te vullen.

Ook de eigenschappen die fysiek bij het document worden opgeslagen, zijn in deze app te bewerken.

Je hoeft dus niet meer specifiek naar de SharePoint bibliotheek te navigeren om de eigenschappen in te vullen. Een erg welkome toevoeging!

Office 365 Tip: SharePoint documentversies vergelijken in Word

Geplaatst op 20 februari 2018 door Bitspraak

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!

SharePoint Documentenset: wel of niet doen?

Geplaatst op 31 januari 201831 januari 2018 door Bitspraak

Office 365 is uitermate geschikt als document management systeem (DMS); het bevat alle elementen die nodig zijn om een degelijke inrichting te doen, welke ook voldoet aan wettelijke standaarden. Zaken als documentbeveiliging, archivering, compliancy, versiebeheer en workflows, zijn standaard onderdeel van het pakket. Een van de functionaliteiten die SharePoint al jaren bevat, is het maken van dossiers.

Dossiers, in SharePoint terminologie ‘documentensets’ genoemd, zijn eigenlijk containers (of folders) waarin documenten kunnen worden opgeslagen. Een documentenset is daarna als geheel te beschouwen als het gaat om metadata of archivering. Het is als het ware een dossier, waarbij het dossier zelf de kenmerken bevat, en niet de documenten die er in zitten. Dit is direct een van de verschillen met traditionele mappen (of folders): documentensets kunnen metadata bevatten.

Documentensets kunnen worden aangezet met het activeren van een siteverzameling onderdeel.

Veel organisaties maken gebruik van deze documentsets als het gaat om dossiervorming. Echter, met de introductie van de moderne lijst lay-out, worden documentensets nog niet ondersteund. Dit gegeven is op zichzelf geen ramp, SharePoint schakelt automatisch terug naar de klassieke weergave van de lijst, zodat het documentenset alsnog getoond kan worden. Groot nadeel is dat dit voor de gebruiker heel onduidelijk is (het schakelen tussen verschillende ontwerpen binnen een lijst). Vooral beginnende gebruikers zijn hierdoor snel de weg kwijt en het is desastreus voor de acceptatie van het SharePoint platform.

Documentensets kunnen vanuit de moderne lay-out worden aangemaakt. Daarna schakelt SharePoint automatisch om naar de klassieke weergave…

Zoals met veel functionaliteit in de moderne lay-out, komt deze met de tijd. Stukje voor beetje wordt de nieuwe lay-out de standaard en bevat het oude functionaliteiten, maar ook veel nieuwe. Het is dus zeker verstandig om om te schakelen naar deze nieuwe weergave. Echter, de documentensets blijven achter. Al bijna 2 jaar.

Dit gegeven baart zorgen: wat gaat er gebeuren met documentensets? Is dit legacy, of wordt er nieuw leven geblazen in deze functionaliteit? Wellicht gaan folders een grotere rol spelen, maar ook hier is geen duidelijke richting. Wel bevatten documentensets in de nieuwe weergave de mogelijkheid om als geheel een label te koppelen (net als bij folders). Dit is relatief nieuwe functionaliteit, en daarmee zijn documentensets dus niet vergeten.

Folders en documentensets bevatten sinds kort de optie om labels toe te passen.

Navraag bij Microsoft bevestigt het gegeven dat documentensets blijven en mee gaan in de nieuwe lay-out. Echter, waarom zijn deze er na zo’n lange tijd nog niet? Het roept daarom twijfel op en ben daarom op dit moment terughoudend met het introduceren met een oplossing gebaseerd op documentensets.

Documentensets zelf zien er nog erg ouderwets uit, niet goed voor de gebruikersacceptatie.

Ook op technisch vlak is er wat onduidelijkheid. CSOM (client side object model), de bibliotheek die ontwikkelaars gebruiken om acties uit te voeren in code in Office 365, bevat methoden om documentensets aan te maken. Echter, het gedrag van deze code is niet consistent, zeker niet als er inhoudstypen worden gemaakt die overerven van een documentenset. Met wat aanpassingen is het namelijk mogelijk om een goede documentenset aan te maken. Echter, bij het gebruik van de moderne lay-out, worden deze gezien als folders (ander icoon). Wel met metadata, en dat lijkt een aanknopingspunt!

In feite zijn documentensets natuurlijk folders maar dan met metadata. Als je de OneDrive client laat synchroniseren met een SharePoint bibliotheek met documentensets, worden deze getoond als folder. Echter, folders die in de verkenner worden aangemaakt, worden geen documentensets. Hoewel het koffiedikkijken is, zit hier wat mij betreft ook wel een mogelijke (voorzichtige) voorspelling in: documentensets worden folders (met metadata).

Voor alsnog moeten we afwachten welke richting het op gaat met documentensets. Neem mijn verhaal mee in je overwegingen in de keuze om documentensets te gaan gebruiken. Graag help ik je verder op weg!