SharePoint Documentenset: wel of niet doen?

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.

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

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

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

docset_4Documentensets 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!

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.

bulk_1

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.

bulk_3

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.

onedrive_delete2

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.

onedrive_delete3

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!

Uitgelegd: de 5000 items limiet in SharePoint lijsten

Elke week komt het onderwerp wel een keer ter sprake: de 5.000 items limiet in SharePoint lijsten. De ‘limiet’ is inmiddels berucht en vrijwel altijd eindigt een poging tot uitleg bij gebruikers tot onbegrip en teleurstelling. Hoe kan het immers dat zo’n uitgebreid platform als Office 365, stuk gaat op meer dan 5.000 documenten in een lijst? Het is een ongemakkelijke situatie en zit de adoptie van SharePoint soms flink in de weg.

Daarom tijd om een compleet overzicht van het waar, hoe en waarom van de 5.000 item limiet in SharePoint lijsten!

Limiet? Welke limiet?

Een terechte vraag. Uit de documentatie van Microsoft over SharePoint Online staat immers:

op een lijst kunnen maximaal 30 miljoen items staan en een bibliotheek kan maximaal 30 miljoen bestanden en mappen bevatten – bron

Dit betekent dat in praktijk de limiet van lijsten vrijwel onbeperkt is. Echter, lijsten in SharePoint Online bevatten standaard een drempelwaarde van 5.000 items. In SharePoint online is deze drempelwaarde in tegenstelling tot de server versies van SharePoint, niet aan te passen door beheerders.

En wat blijkt: na wat verder zoeken, blijkt dit toch een limiet te zijn volgens de documentatie van Microsoft:

U kunt maximaal 30 miljoen items of documenten opslaan in een lijst of bibliotheek van SharePoint. Aan de hand van de volgende tips kunt u de gewenste informatie opvragen en toch binnen de limiet van 5000 items blijven, waarmee u voorkomt dat de drempelwaarde voor lijstweergave wordt overschreden. – bron

Hoe zit het nou? Is er nu wel of geen limiet? De waarheid is dat er geen 5.000 item limiet zit op de lijst, maar wel op het aantal items dat in één keer kan weergegeven worden. Hier zit de essentie van de 5.000 item limiet in.

Kan ik de limiet omzeilen?

De 5.000 items limiet is veel besproken op internet. In UserVoice (feedback aan Microsoft door gebruikers) is er veel gestemd op het oplossen van dit probleem. Echter, Microsoft heeft daar ook aangegeven dat de limiet waarschijnlijk blijft bestaan:

The 5,000 item threshold is likely here to stay. We are aware that it takes awareness on both sides to get past this limitation: list owners have to build the right fields, indices, and indexed views so that end user queries can run successfully in large lists. And then, end users have to run the correct queries – they can’t just open the root of the list, they have to use a filtered, indexed view.

Er is een aantal oplossingen om het probleem de omzeilen:

  • In geval van document bibliotheken, deel de bestanden dan op in folders of document sets. Standaard zal SharePoint alleen de inhoud van de huidige folder weergeven en daarmee minder items (als het goed is ingedeeld). Hiermee is direct de volgende optie aangestipt:
  • Gebruik filters in de (standaard) weergaven. Door een filter in te stellen op de lijst op basis van metadata, zullen het aantal items dat wordt teruggeven beperkt worden. Uiteraard moet ook hier goed gekeken worden dat het aantal de 5.000 items niet overschrijdt.
  • Maak indexen aan. Indien je werkt met veel items in een lijst, kan het handig zijn om indexen aan te leggen op een kolom. Hiermee kunnen queries op items sneller worden ingeladen en zal de gebruikerservaring verbeteren.

Microsoft geeft ook aan dat het gebruik van een Documentencentrum een mogelijke oplossing is. In dit template wordt namelijk slim gebruik gemaakt van het zoeken en bewerken van documenten, waardoor een gebruik minder snel tegen de limiet aan loopt. Echter, de ervaring leert dat in veel scenario’s dit meer een “workaround” is, dan een gedegen, goede oplossing voor het 5.000 items probleem.

Hoe zit het met de OneDrive synchronisatie?

Een ander punt waar rekening mee gehouden moet worden bij het omzeilen van de 5.000 item limiet in lijsten, zijn de limieten voor het gebruik van de OneDrive offline synchronisatie applicatie. Hiermee is het mogelijk om document bibliotheken te synchroniseren. Deze synchronisatie kan met grote aantallen bestanden ook een beperking geven:

Hoewel SharePoint Online 30 miljoen documenten per bibliotheek kan opslaan, kan de synchronisatie-prestatie van OneDrive beginnen af te nemen wanneer u meer dan 100.000 bestanden in één OneDrive voor Bedrijven-site- of teamsitebibliotheek plaatst. Om deze beperking op te lossen, moet u ervoor zorgen dat bestanden in meerdere mappen/bibliotheken worden opgeslagen. Als u meer dan 100.000 bestanden in een OneDrive voor Bedrijven site hebt, moet u mogelijk langer wachten omdat OneDrive continu synchroniseert om de synchronisatie te voltooien. – bron

Kortom, heel veel documenten in één folder is ook hier geen goed idee. Uiteraard ligt deze drempel van 100.000 documenten wel een stuk hoger.

Wat zou je adviseren dan?

Door de ongemakkelijke limiet en de problemen die het op kan leveren, is het verstandig het aantal items per lijst (of folder) te beperken. Niet alleen heb je uitgebreide SharePoint kennis nodig om lijsten met veel items goed in te richten, ook kunnen er desondanks foutmeldingen optreden bij het aanmaken van indexen of beheren van rechten. Hiervan zegt Microsoft niet heel veel, maar dit is voor een gebruiker eigenlijk niet acceptabel.

Daarnaast worden in sommige gevallen niet alle items weergegeven als deze boven een bepaald aantal komt.

Samengevat zitten er een aantal haken en ogen met het werken met grote lijsten. Probeer daarom in te schatten hoeveel items er in de loop der tijd in een lijst terecht komen. In het geval van bestanden is het aan te raden documentsets of folders te gebruiken. Ook kan het handig zijn lijsten op te delen in meerdere lijsten, in plaats van één grote lijst. Probeer, indien mogelijk, onder de grens van de 5.000 items te blijven. Zo kunnen problemen en eventuele tegenvallende performance in de lijst worden voorkomen.

In een bestaande omgevingen zou het nuttig kunnen zijn om te detecteren of de 5.000 items worden overschreven, of dat dit er aan zit te komen. Dit kan met behulp van een PowerShell script, maar ook tools als Val365 kunnen dit snel en eenvoudig inzichtelijk maken. Zo kan je problemen in de toekomst tijdig voorkomen. Meer weten hierover? Laat het mij weten!

 

Nieuwe web onderdelen (WebParts) in SharePoint

Vanaf begin november komen er nieuwe web onderdelen (WebParts) beschikbaar in SharePoint sites. Het betreft hier de ‘moderne’ sites, dus niet de klassieke SharePoint sites. De aankondiging is vorige maand al gedaan, maar worden vanaf nu uitgerold door Microsoft. Eind december zou iedereen gebruik moeten kunnen maken van de nieuwe onderdelen.

Het betreft de volgende nieuwe onderdelen:

  • Een nieuwe, grote toolbox met categorisering en zoeken (naar web onderdelen).
  • Een nieuw web onderdeel voor het ontsluiten van Microsoft Forms op je pagina.
  • Paginaopmaak web onderdelen waarmee je witruimte of een lijn tussen web onderdelen kan plaatsen
  • Het documenten web onderdeel wordt hernoemd naar ‘Bestandsvoorbeeld’ en kan bestanden weergeven. Er worden inmiddels meer dan 270 bestandstypen ondersteund.
  • Het web onderdeel ‘Gemarkeerde inhoud’ ondersteunt nu bepaalde tokens als ‘Mij’, ‘Vandaag’, etc.
  • ‘Personen’ ondersteunt nu een tweede uitgebreide omschrijving.

 

Meer weten over de moderne sites en het gebruik van Office Groups? Laat het ons weten!

Nieuw: Placeholders in OneDrive

 

Vorige week is een nieuwe update voor Windows 10 (versie 1709) uitgebracht. Deze update brengt een aantal nieuwe functionaliteiten met zich mee, waaronder verbeterde toegankelijkheid en VR/AR en 3D ondersteuning. Eén van de meest handige functionaliteiten betreft echter een update aan de OneDrive applicatie voor offline synchronisatie: ‘placeholders’, oftewel ‘bestanden on-demand’.

Wat zijn placeholders?

Placeholders zorgen ervoor dat een synchronisatie met bijvoorbeeld de persoonlijke OneDrive of een SharePoint bibliotheek gemaakt kan worden, waarmee de bestanden (als placeholder) lokaal op je PC komen te staan. Het betreft dus alleen een link, maar het gedraagt zich als het eigenlijke bestand. Bij het openen van het bestand, wordt het bestand eerst snel fysiek gedownload en dan geopend. Deze techniek zorgt ervoor dat je niet de volledige bestanden hoeft te downloaden bij een synchronisatie, maar alleen de link naar het online bestand. Dit levert zowel tijd als opslagruimte winst op! Ook heeft het een verbeterde beveiliging, omdat de meeste bestanden (zolang je ze niet gebruikt) ook niet fysiek op de harde schijf staan. Kortom, een nuttige toevoeging!

Hoe werkt het?

Na de installatie van de update, kan je de eigenschappen van OneDrive openen (via het blauwe wolkje in de taakbalk). Hierin kan de optie aangevinkt worden voor het gebruik van OneDrive met ‘Bestanden on-demand’. Zet het vinkje en je bent klaar!

onedrive_ondemand

Nadat het vinkje is aangezet, worden de bestanden anders weergegeven in de Windows Verkenner. Een wolkje betekent dat een bestand alleen online beschikbaar is. Bij wijzigingen (of bezig met synchronisatie) worden het blauwe pijltje. Indien een bestand lokaal beschikbaar is, dan is het een groen (open) vinkje.

onedrive_stages

Er zijn daarbij verschillende opties bijgekomen om de controle over de bestanden te behouden. Zo is het bij een bestand mogelijk ervoor te kiezen dat deze altijd offline beschikbaar moet zijn. Het icoontje is in dat geval een groen vinkje (dicht) geworden.

Dit laatste kan je bepalen door met de rechtermuisknop op een bestand te klikken en dan de optie ‘altijd behouden op dit apparaat’ aan te klikken.

onedrive_keep

Afwegingen

De functionaliteit is een welkome toevoeging. Het is echter belangrijk om goed te begrijpen wat de status van een bestand betekent. Er zijn immers verschillende ‘standen’ van een bestand mogelijk. Zo kan het verwarrend zijn als de bestanden in de online OneDrive anders zijn dan lokaal. Tevens moet iemand die onderweg is (en geen internet verbinding heeft) zich realiseren dat het voor kan komen dat een bestand lokaal beschikbaar lijkt te zijn, maar dat in werkelijkheid niet is. Echter, met deze weetjes in het achterhoofd is de volwassenheid van OneDrive weer een stuk verbeterd!

Lees het Microsoft artikel waarin bepaalde zaken nog wat verder worden uitgelegd. Meer weten of hulp nodig? Laat het ons weten!

 

Nieuw: kolom opmaken in SharePoint lijsten

Vanaf eind oktober zal een nieuwe (veel gevraagde) functionaliteit worden toegevoegd aan SharePoint Online: het opmaken van een kolom in SharePoint lijsten en bibliotheken. Door het toevoegen van deze optie, wordt de kolom anders weergegeven, afhankelijk van de waarde in een kolom. Denk bijvoorbeeld aan ‘stoplicht’ weergaven, waarbij groen goed is, oranje minder goed en rood slecht.

Een voorbeeld, de normale opmaak van kolommen in een lijst:

sp-columnformatting-none

En de kolommen na de opmaak:sp-columnformatting-all

De opmaak wordt gemaakt doormiddel van een ‘JSON’ regel, waarin de logica wordt gemaakt. Hierin wordt bijvoorbeeld gespecificeerd hoe je kleurtjes toe kan voegen en waar de drempelwaarden liggen. Wil je hier meer over weten, bekijk dan deze documentatie.

De volgende kolomtypen worden ondersteund:

  • Tekstregels
  • Getallen
  • Keuzelijst
  • Persoon of Groep
  • Ja/Nee waarden
  • Hyperlink
  • Afbeelding
  • Datum/tijd
  • Opzoek velden.

Uiteraard worden naast de lijsten ook documentbibliotheken ondersteund. Let wel, het betreft hier alleen lijsten met de moderne lay-out. De functionaliteit zal in november compleet uitgerold zijn.

Meer weten? Neem contact op!

Let op: SharePoint 2013 (mainstream) support eindigt in april 2018

Maak je gebruik van SharePoint 2013? Let dan op dat de (mainstream) support van SharePoint 2013 over 6 maanden eindigt, op 10 april 2018. De zogenaamde ‘extended support’ zal lopen tot 11 april 2023. Het gaat hier over SharePoint 2013 installaties met de laatste updates (Service Pack 1). Kortweg zal Microsoft vanaf april alleen nog maar security updates uitbrengen voor SharePoint 2013, als dat nodig is.

Traditioneel brengt Microsoft elke drie jaar een nieuwe versie uit van SharePoint. Als je gebruik maakt van SharePoint 2013, is dit de tijd om te bekijken of een upgrade naar SharePoint 2016 gewenst is, óf dat natuurlijk een overstap naar SharePoint Online (Office 365) een mogelijkheid is.

In SharePoint Online hoef je je geen zorgen meer te maken over het installeren van updates of migraties naar nieuwe versies. De software blijft in Office 365 altijd up-to-date, waarmee grote migratie projecten tot het verleden behoren. Uiteraard is de keuze om te gaan werken in de cloud afhankelijk van de situatie van je organisatie.

Wil je meer weten over de impact van deze aankondiging voor jouw omgeving, of overweeg je om over te stappen op Office 365? Laat het dan even weten. We kunnen je dan vrijblijvend adviseren.

Meer informatie over support van Microsoft op SharePoint 2013: https://support.microsoft.com/en-us/lifecycle/search?alpha=sharepoint%202013

 

Subsites of Site Collecties: wat is wijsheid?

Bij het bedenken van een handige structuur voor de indeling van een SharePoint site, komt het al snel ter sprake: hoe gaan we de sites inrichten? Zo kan het handig zijn een relatie te maken tussen verschillende sites van hetzelfde type (bijvoorbeeld projecten) met daarbij de hoofdsite als portaal of een intranet omgeving met bijvoorbeeld bedrijfsonderdelen als subsites. Vaak komt het er op neer dat een hoofdsite inhoud samengevat moet weergegeven welke op de onderliggende sites aanwezig is. Traditioneel is daarbij het hebben van subsites een logische indeling. Het is immers handig om door te klikken in de structuur en het aanmaken van subsites gaat eenvoudig en snel.

Met de introductie van de zogenaamde ‘Modern Sites’, komt het gebruik van subsites echter steeds vaker ter discussie te staan. Zo word het aanmaken van nieuwe site collecties erg eenvoudig gemaakt, worden rechten goed ingeregeld d.m.v. groepen en classificatie van de sites en zorgt de techniek ervoor dat de relatie eenvoudiger kan worden gelegd met andere site collecties. Met de aankondiging van Hub Sites wordt het zelfs nog makkelijk om content te aggregeren op een centrale site. Kortom: de noodzaak van subsites wordt steeds kleiner.

Daarnaast kleven er wat onhandigheden aan het gebruik van subsites:

  • De rechtenstructuur is niet erg inzichtelijk. Het is lastig om per site de rechten de doorgronden, wat tot mogelijke fouten kan leiden als het gaat om beveiliging.
  • Het beheer van (sub)sites wordt lastiger, zeker als je niet weer hoeveel en in hoeveel lagen er subsites aanwezig zijn.
  • Er is geen eenduidige navigatie voor de gebruiker. Het is voor de gebruiker lastig te doorgronden waar hij/zij zich bevindt in de site, zeker als de structuur meerdere lagen diep gaat.

Met de introductie van moderne sites is het daarom aan te raden kritisch te zijn op het gebruik van subsites. Microsoft zelf beweegt zich (qua interface en techniek) ook steeds meer naar een wereld met veel site collecties en zonder subsites. Zo strookt het gebruik Office Groups niet met een indeling in subsites als het gaat om rechten en bijvoorbeeld conversaties en distributielijsten. Ook nieuwe onderdelen in Office 365 als Communicatie sites, Planner en Teams, zijn gebaseerd op een platte structuur zonder sub sites.

Conclusie

Met de ontwikkeling die in Office 365 plaatsvindt, is het af te raden een SharePointstructuur te baseren op subsites. Als het even kan is het verstandig aparte site collecties te maken zodat rechten, classificaties en Office Group functionaliteit goed wordt benut. Het is niet direct nodig bestaande structuren om te gaan bouwen; SharePoint werkt prima in deze structuur. Het is echter verstandig bij een nieuwe opzet goed na te denken of een structuur met subsites gewenst is.

Wil je dat we met je meedenken over dit vraagstuk? Neem dan contact op!

 

 

SharePoint Content Type Hub: wel of geen goed idee?

Sinds geruime tijd beschikt SharePoint (Online) over de mogelijkheid om inhoudstypen centraal te beheren. Inhoudstypen zijn de definities van bestanden en lijst items. Deze kunnen worden voorzien van een naam en beschrijving, meta gegevens, en het geval van documenten ook van documentsjablonen. Daarnaast is het ook mogelijk om beleidsregels in te stellen als bijvoorbeeld bewaartermijnen en retentie.

Door deze zaken in een speciale site collectie aan te maken, de Content Type Hub, wordt het mogelijk om deze instellingen centraal te publiceren naar alle andere sites. Zo wordt het beheer ervan eenvoudig gemaakt.

CTH_pub

Er is echter veel discussie geweest over dit mechanisme. In theorie is het een mooi model. Echter, in praktijk zijn er nog wel eens wat problemen met het gebruik ervan. Daarom een overzichtje wat wel en niet handig is, als het gaat om de Content Type Hub.

1. Gebruik de Content Type Hub niet voor publiceren documentsjablonen.

Met gepubliceerde inhoudstypen kunnen ook gekoppelde document templates worden uitgerold. Het idee er achter is dat deze als opties gekoppeld kunnen worden aan documentbibliotheken (onder de knop ‘Nieuw’), zodat het juist sjabloon gekozen kan worden bij het aanmaken van een nieuw document. Echter, dit mechanisme is niet waterdicht: vaak zijn er erg veel verschillende sjablonen in een organisatie waarmee de Content Type Hub niet goed kan omgaan (zie ook punt 5). Daarnaast kan het voorkomen dat de publicatie van een nieuw sjabloon niet altijd overal goed gaat (afhankelijk wat er met een inhoudstype in een site gebeurd is). Het is dus geen waterdicht mechanisme.

Probeer in plaats hiervan documentsjablonen beschikbaar te stellen via het mechanisme van sjablonen in Office zelf via policies, netwerkschijven of via de OneDrive synchronisatie van een centrale bibliotheek uit SharePoint.

2. Hanteer een minimale set van meta gegevens in de inhoudstypen.

SharePoint is sterk in metadata. Het invullen ervan is echter een taak voor een gebruiker, waarbij de gebruiker vaak steken laat vallen, zeker als het nut van een metadata veld niet duidelijk is. Tevens kan het de gebruiker moeilijk worden gemaakt als er veel of onduidelijke keuzes aangeboden worden in een veld. Erger dan documenten zonder metadata, zijn documenten met onvolledige of foutieve metadata. Wees dus voorzichtig met het aantal velden.

3. Voorkom het gebruik van verplichte velden.

Verplichte velden vergen veel aandacht van de gebruiker. Bij het maken of uploaden van een document is dit nog te overzien. Echter, bij het uploaden van veel bestanden (bijvoorbeeld via drag and drop, of via OneDrive synchronisatie), is het zeer bewerkelijk voor een gebruiker om alle velden goed in te vullen. Tevens veroorzaken verplichte velden issues als het gaat om synchronisatie, uitgecheckte documenten (welke nog niet zijn ingecheckt) en het updaten van metadata velden.

4. Maak alleen inhoudstypen in de hub die vanuit beleid noodzakelijk zijn.

Op deze manier worden gebruikers niet lastiggevallen met extra ballast. Alleen de uiterst noodzakelijke inhoudstypen en metadata worden op deze manier aangeboden. Bij verdere uitwerking is het aan te raden binnen de site collectie de inhoudstypen over te erven en aan te vullen met metadata.

5. Beperk het aantal eigen inhoudstypen tot onder de 30 stuks.

Het is een vage limiet, welke (nog) niet goed beschreven is. Het gebruik van vele inhoudstypen in de hub, zorgt ervoor dat de creatie van (klassieke) site collecties langer duurt. Elk inhoudstype moet immers in een site aangemaakt worden bij het aanmaken van de site. Als dit er veel zijn, dan kan het maken van een nieuwe site collectie exponentieel toenemen in tijd. Gevallen van meer dan een uur zijn hierbij geen uitzondering. Dit is onwenselijk.

Alternatieven

De Content Type Hub bestaat al geruime tijd. Echter, de ontwikkeling er aan staat ook al een tijdje stil. Het lijkt er op dit in de toekomst zo blijft, ook omdat er inmiddels alternatieven beschikbaar zijn voor het toekennen van beleid:

  • Labels en Classificatie van documenten (in heel Office 365) en e-mail (Exchange Online).
  • Data Loss Prevention (DLP) op tenant niveau.
  • Classificatie van sites (Office Groups in Azure AD).
  • Life Cycle Management van Office Groups (in Azure AD).

Met deze alternatieven hoeft een gebruiker zich minder bezig te houden met het invullen van meta data en de locatie van opslag, maar kan de controle bepaald worden op een hoger niveau. In feite zijn inhoudstypen minder relevant geworden.

Conclusie

De Content Type Hub is binnen SharePoint Online een mechanisme om centraal inhoudstypen en beleid te definiëren. Echter, door de groei van het platform en de uitbreiding van de beschikbare applicaties, is de wens er om dit beleid breder toepasbaar te maken. Hiervoor zijn krachtigere alternatieven beschikbaar. Kort door de bocht (maar zeker met een kern van waarheid) kan de Content Type Hub daarmee beschouwd worden als ‘legacy’, een mechanisme dat in stand wordt gehouden vanuit keuzes in het verleden. Het advies is daarom: probeer dit mechanisme indien mogelijk te vermijden bij nieuwe inrichtingen.

Ook ‘last’ van de Content Type Hub, of heb je vragen over je huidige inrichting? Laat ons je adviseren!