Content publiceren binnen of buiten een Site Collectie: wat kan en wat kan niet?

Of je content vanuit de ene site in een andere kunt publiceren is eigenlijk afhankelijk of beide sites binnen dezelfde Site Collectie liggen of niet.

Publiceren binnen dezelfde Site Collectie

Als dat het geval is kun je gegevens van de ene site met de andere site delen door b.v. het Content Query Webpart te gebruiken. Liggen de plaatsen waar de content moet worden gepubliceert binnen dezelfde site (b.v. verschillende webpagina's binnen dezelfde site), dan zijn hiervoor (per Lijst of Bibiotheek) standaard Webparts in de Gallery beschikbaar.

Publiceren buiten een Site Collectie

Als de sites in verschillende Site Collecties liggen dan zou dit met de zoekfunctie kunnen (zoekpagina’s kunnen informatie over verschillende Site Collecties heen verzamelen). Nadeel van gebruik van de zoekmachine is dat er een tijd zit tussen het publiceren van content en het daadwerkelijk zien ervan in een andere Site Collectie, omdat de zoekmachine de content eerst moet indexeren voordat deze beschikbaar is voor publicatie. Deze vertraging is dan afhankelijk van de frequentie waarin de content wordt geïndexeerd (meerdere keren per dag is gebruikelijk).

Andere mogelijkheden

Alternatieven zijn:

• Gebruik maken van RSS (op een lijst of bibliotheek kan een RSS feed worden aangezet en deze feed kan in een andere site of Site Collectie worden gebruikt in een RSS Webpart). Wel moet dat zijn toegestaan middels een instelling door systeembeheer in de SharePoint omgeving).
• Zelf een Webpart ontwikkelen waarin een CAML Query wordt gebruikt om content te verzamelen over sites of Site Collecties.
• Gebruik maken van al aanwezige (third party) Webparts die daarvoor speciaal zijn ontwikkeld en die al beschikbaar zijn in de Webpart Gallery. Anders kan een oplossing worden aangekocht die door een third party is ontwikkeld (zoals een Webpart dat over meerdere Site Collecties kan worden gebruikt, als http://www.lightningtools.com/pages/lightning-conductor-web-part.aspx).

Content Types en kolommen in Site Collecties en Subsites: hoe werkt het, en valkuilen, tips en truuks

Waarom dit artikel?
In de praktijk zie ik regelmatig problemen (die je als projectmanager natuurlijk "uitdagingen" zou noemen) met metadata (kolommen) en metadata sets (Content Types) in SharePoint omgevingen. Regelmatig worden  wijzigingen doorgevoerd waarna onverwachte en vervelende situaties ontstaan. Veel van die situaties zijn te herleiden tot te weinig begrip metadata(sets) binnen SharePoint en de wijze waarop SharePoint hiermee omgaat. Daarom in dit artikel een praktische inleiding hierop, aangevuld met praktische tips en valkuilen. Dit artikel zal ik de komende tijd verder uitbreiden, reden om regelmatig terug te keren.

Metadatering in SharePoint
Dat metadatering belangrijk is, daar ga ik in dit artikel niet op in, dat is te lezen in Metadata: belang, inleiding en hoe ermee om te gaan. Laat ik beginnen met uit te leggen hoe metadatering in het algemeen en binnen SharePoint is geïmplementeerd...

Metadata in lijsten en bibliotheken
Lijsten en bibliotheken kunnen voorzien worden van kolommen. Wanneer een item aan een lijst, of een document aan een bibliotheek wordt toegevoegd, kunnen deze kolommen worden gebruikt om het betreffende lijstitem of document te beschrijven. De kolommen zijn dan kenmerken van de items resp. de documenten. Veelgebruikte kolommen zijn bijvoorbeeld: auteur, datum van opslag en titel.

Op deze manier wordt ieder item in een lijst en ieder document in een bibliotheek voorzien van dezelfde kenmerken, dezelfde "metadata set", namelijk de kolommen die voor de lijst resp. de bibliotheek zijn gedefinieerd.

Wanneer je echter verschillende typen documenten hebt, en je wilt voor ieder type document of item een andere verzameling kenmerken (metadata set) wilt gebruiken, dan volstaat de bovenstaande aanpak niet. Ook als je metadata sets wilt hergebruiken voor meerdere lijsten of bibliotheken is er meer nodig dan alleen kolommen in een lijst of bibliotheek. En als metadata sets elkaar overlappen en je wilt deze metadata sets doelmatig onderhouden, dan is er meer nodig dan alleen kolommen.

Wat hierbij helpt zijn Content Types, herbruikbare metadata sets.

Herbruikbare metadata sets: Content Types
Alle content; documenten (web pagina's, Office documenten, plaatjes, PDF's en alle andere typen bestanden), maar ook lijstitems kunnen worden beschreven door er kenmerken (b.v. titel, auteur, datum aanmaak) aan te koppelen. Deze kenmerken, kolommen, worden ondergebracht in verzamelingen, metadata sets. Deze metadatasets worden binnen SharePoint "Content Types" genoemd. Aan documenten en lijstitems kunnen binnen SharePoint dus Content Types worden gekoppeld die deze documenten of lijstitems beschrijven. Deze Content Types worden opgenomen in zogenaamde "Site Content Type Galleries" (bibliotheken met Content Types). Iedere site kent een Site Content Type Gallery.

Binnen een bibliotheek of lijst kunnen documenten en items worden opgenomen. Aan een bibliotheek of lijst kunnen zowel losse kolommen (zoals in een spreadsheet) als Content Types worden toegevoegd. Door Content Types te koppelen aan de kenmerken (properties) van document templates (b.v. Word, PDF, Excel) worden alle kenmerken van documenten als kolommen in de bibliotheek of lijst opgenomen wanneer deze documenten in de bibliotheek of lijst worden opslagen.

Overlappende Content Types
Wanneer je meerdere Content Types hebt gedefinieerd die erg op elkaar lijken, bijvoorbeeld als bepaalde kolommen in ieder van deze Content Types voorkomen, kun je ervoor kiezen om deze Content Types in een hiërarchie onder te brengen. Hierin kunnen "gedeelde" kolommen in een "parent" Content Type worden ondergebracht waarbij de kolommen in het "parent" Content Type automatisch worden opgenomen in de "child" Content Types. Zodoende kunnen wijzigingen in Content Types met minder moeite worden doorgevoerd. Hier zitten echter wel wat haken en ogen aan, maar meer daarover later in dit artikel.

Standaard biedt SharePoint al een aantal Content Types die als basis kunnen worden gebruikt voor zelfgedefinieerde Content Types. Deze Content Types zijn ondergebracht in een hierarchie waarvan het parent Content Type van het type "Item" is. Daaruit zijn andere standaard Content Types als "Document", "Event" en "Task" afgeleid, welke bekend zullen voorkomen omdat deze standaard in bepaalde voorgedefinieerde bibliotheken met dezelfde naam worden gebruikt.

Standaard kolommen: Site Columns
Naast Content Types kunnen ook standaard kolommen (Site Columns) binnen SharePoint worden gedefinieerd. Deze standaard kolommen kunnen vervolgens in Content Types, lijsten en bibliotheken worden gebruikt. Dit is handig omdat je op die manier slechts een maal een kolom definitie, bijvoorbeeld een keuzelijst met standaard status waarden (draft, concept, final), hoeft te definiëren. Deze Site Columns worden opgenomen in zogenaamde "Site Column Galleries" (bibliotheken met Site Columns). Iedere site kent een Site Column Gallery.

Standaard biedt SharePoint al een aantal Site Columns die gebruikt kunnen worden voor lijsten, bibliotheken en Content Types.

Metadatering op verschillende niveaus: SharePoint Farm, Site (Collection) en lijst/bibliotheek niveau
Zowel Columns als Content Types kunnen op verschillende niveau's in een SharePoint Farm worden gedefinieerd en (her)gebruikt:

• Op Farm niveau; te gebruiken binnen een heel SharePoint farm;
• Op Site niveau: te gebruiken binnen sites en subsites;
• Op bibliotheek / lijst niveau: te gebruiken binnen lijsten en bibliotheken.

Meta datering op Farm niveau
Sinds SharePoint 2010 kunnen Content Types op Farm niveau worden gedefinieerd en op deze manier worden (her)gebruikt (gepubliceerd) binnen meerdere Site Collecties. Daarnaast kunnen sinds SharePoint 2010 ook taxonomieën (Managed Metadata, zie Managed metadata overview (SharePoint Server 2010) en Plan terms and term sets (SharePoint Server 2010)) op Farm niveau worden gedefinieerd en in het gehele Farm worden (her)gebruikt.

Meta datering op Site Collectie, Site en Subsite niveau
Vanaf SharePoint 2007 kunnen Content Types en Site Columns op ieder niveau binnen een Site Collectie worden gedefinieerd en worden gebruikt in de sites eronder. Definieer je een Site Column of Content Type in een bepaalde Site, dan verschijnt deze ook in de Site Column Gallery resp. Site Content Type Gallery in alle Subsites van de betreffende Site.

Meta datering op lijst - en bibliotheek niveau
Op het niveau van lijsten en bibliotheken kunnen kolommen en Site Columns (die gedefinieerd zijn in de site waarin de lijst of bibliotheek zich bevindt of een van de parent sites erboven) worden toegevoegd. Van een geselecteerde Site Column wordt een onafhankelijke kopie gemaakt die, als List Column, wordt gebruikt binnen de betreffende lijst of bibliotheek.
Ook kunnen Content Types worden toegevoegd die gedefinieerd zijn in de site waarin de lijst of bibliotheek zich bevindt en Content Types die in de sites erboven zijn gedefinieerd. Van het geselecteerde Content Type wordt dan een onafhankelijke kopie gemaakt die, als List Content Type, wordt gebruikt binnen de betreffende lijst of bibliotheek.

Beginnen met Content Types gebruiken in lijsten en bibliotheken
Om Content Types in lijsten en bibliotheken te kunnen gebruiken moet eerst in de instellingen van de betreffende lijst of bibliotheek ingesteld worden dat er gebruik wordt gemaakt van Content Types. Dit gaat via het menu: List settings > Advanced Settings > Allow management of content types.
Wanneer dit ingesteld is kunnen Site Content Types en Content Types van de bovenliggende sites worden toegevoegd

Wijzigingen doorvoeren in Columns en Content Types
Wanneer je een wijziging wilt doorvoeren in Content Types is het belangrijk een aantal zaken goed in de gaten te hebben en te houden:

• Op welk niveau de wijziging wordt doorgevoerd en welke consequenties dat heeft voor de onderliggende niveaus. De betrokken menu schermen zien er namelijk verradelijk eender uit;
• Welke consequenties de verschillende mogelijkheden die SharePoint biedt om additionele wijzigingen door te voeren hebben voor andere Content Types, lijsten en bibliotheken op hetzelfde niveau of andere niveaus.

Het niet goed in de gaten hebben van de bovenstaande zaken is in veel gevallen de reden dat het doorvoeren van wijzigingen niet de gewenste gevolgen hebben.

Wat meer in detail...

Wijzigen in meta data structuren
Op de verschillende genoemde niveaus kunnen lijst/bibliotheek kolommen, Site Columns en Content Types gewijzigd worden.  Deze wijzigingen kunnen vaak, naar believen ook op onderliggende niveaus worden doorgevoerd. Vantevoren nadenken over wijzigingen is aan te raden, omdat wijzigingen nadelige gevolgen kunnen hebben. Daarom hieronder uitleg over wat mogelijk is en wat hierbij de overwegingen kunnen zijn.

Toevoegen van Site Columns aan lijsten en bibliotheken
Wanneer een Site Column wordt toegevoegd aan lijsten of bibliotheken kan ervoor gekozen worden dat deze ook toegevoegd wordt aan alle Content Types die aan de betreffende lijst of bibliotheek zijn toegevoegd.

Toevoegen van Site Columns aan Site Content Types
Wanneer een Site Column wordt toegevoegd aan een Site Content Type kan ervoor gekozen worden dat  deze ook toegevoegd wordt  aan alle Content Types die afgeleid zijn van dit Content Type, zowel List – als Site Content Types. SharePoint vraagt dan: “Update all content types inheriting from this type?”

Toevoegen van Site Columns aan List Content Types
SharePoint biedt hier niet de mogelijkheid om alle Content Types met de toegevoegde Site Column bij te werken (Update all content types inheriting from this type?). Dat is logisch, want een List Content Type kent geen verdere afgeleide Content Types; het is immers een zelfstandige kopie van een bestaand Site Content Type.

Wijzigen van Site Columns
Een Site Column kan op het (site) niveau waarin het is aangemaakt, worden gewijzigd. Hierbij kan gekozen worden de wijziging door te voeren in alle Content Types, zowel List – als Site Content Types en in alle lijsten en bibliotheken (op alle niveau’s) die gebruik maken van de betreffende Site Column.

Wijzigen van List Columns
Een List Column (ook wanneer deze is afgeleid van een Site Column) kan direct in een lijst of bibliotheek worden gewijzigd. Wanneer een List Column deel uitmaakt van een List Content Type dan verandert dat niet doordat de betreffende List Column wordt gewijzigd. In de lijst/bibliotheek settings wordt achter de betreffende kolom nog steeds weergegeven dat  de List Column uitmaakt van de oorspronkelijke List Content Type bij de betreffende kolom .

Wijzigen van het type van een (List) Column
Wanneer het type van een List Column (b.v. van een tekst naar een numerieke waarde) wordt gewijzigd geeft SharePoint een waarschuwing: “Changing the type of this column may result in loss of data. Are you sure that you want to change this column from <Type> to <Other Type>?”. De wijziging kan worden doorgevoerd, maar de afhankelijk van de Site Column waar de betreffende kolom van is afgeleid gaat deels verloren. Bestaande waarden worden omgezet in waarden van het nieuwe kolom type. Hierbij kan informatie verloren gaan. Hoe waarden worden omgezet is een nieuwe blogpost waard :).

Verwijderen van Site Columns
Site Columns kunnen niet verwijderd worden als ze nog in gebruik zijn in Site - en List Content Types Wanneer dit toch geprobeerd wordt, geeft SharePoint de volgende foutmelding: “Site Columns which are included in content types cannot be deleted. Remove all references to this prior to deleting it.”.

Wanneer een Site Column als losse kolom aan een lijst of bibliotheek is toegevoegd en de betreffende Site Column wordt verwijderd geeft SharePoint een waarschuwing (“This site column will be removed and list columns which were created from it will be permanently orphaned. Are you sure you want to delete this site column?”). Wanneer de betreffende Site Column toch wordt verwijderd, dan blijven de kopies die gemaakt zijn in de lijsten of bibliotheken bestaan, onder dezelfde naam, maar kunnen niet meer in een slag worden gewijzigd. Wijzigingen zullen dan in iedere lijst of bibliotheek apart moeten worden doorgevoerd.

Toevoegen van Content Types aan lijsten en bibliotheken
Wanneer een Site Content Type wordt toegevoegd aan een lijst of bibliotheek worden alle kolommen hierin opgenomen als kolommen in de betreffende lijst of bibliotheek. In de lijst/bibliotheek settings wordt dan achter de betreffende kolom weergegeven in welk List Content Type de betreffende kolom voorkomt.

Wijzigen van Site Content Types
Een Site Content Type kan op het (site) niveau waarin het is aangemaakt, worden gewijzigd. Hierbij kan gekozen worden de wijziging door te voeren in alle Content Types, zowel List – als Site Content Types (op alle niveau’s) die afgeleid zijn van het betreffende Content Type.

Wijzigen van List Content Types
Een List Content Type kan direct worden gewijzigd. Hierbij kan niet gekozen worden de wijziging door te voeren in afgeleide Content Types. Immers: een List Content kent geen afgeleide Content Types.

Verwijderen van Site Content Types
Wanneer Site Content Type in gebruik is binnen een lijst of bibliotheek, kan deze niet worden verwijderd. Wordt dit toch geprobeerd dan geeft SharePoint een foutmelding: “The content type is in use. Troubleshoot issues with Windows SharePoint Services. ”.

Verwijderen van List Content Types
Wanneer een List Content Type wordt verwijderd, worden de kolommen in dit List Content Type niet uit de lijst verwijderd, maar blijven bestaan als onafhankelijke List Columns.

Let op: als vervolgens een nieuw (List Content Type) wordt toegevoegd aan de lijst met een of meer kolomnamen die al in de lijst voorkomen, dan zullen in de betreffende lijst dubbele kolomnamen lijken voor te komen. In werkelijkheid geeft SharePoint aan deze nieuw toegevoegde kolommen nieuwe (interne) namen, gebaseerd op de kolomnaam waaraan een volgnummer is toegekend (b.v. MijnKolom0). Deze namen zijn zichtbaar in de URL van het edit formulier waarin de betreffende kolom details kunnen worden bekeken (FldEdit.aspx).

Valkuilen, voetangels en klemmen
In de bovenstaande wijzigingen heb ik al gehint naar risico’s. Voordat wijzigingen worden doorgevoerd zullen deze risico’s goed afgewogen moeten worden tegen de voordelen ervan.

Onderstaand een (niet compleet) lijstje van veel tegengekomen situaties…

Wijzigen van kolom typen kan verlies van data veroorzaken.

Preventie: weten wat de invulling is van de betreffende kolommen en weten welke gevolgen omzetten naar een ander kolom type heeft.

Doorvoeren van “uitzonderingen” op lagere niveaus verlaagt de beheerbaarheid van de informatie architectuur.

Hoe meer uitzonderingen, hoe groter de moeite die gedaan moet worden de uitzonderingen te beheren en hoe groter de kans dat uitzonderingen (maatwerk) worden overschreven door andere wijzigingen die ook doorgevoerd worden op lagere niveaus. Vooral de uitrol van Solutions waarbij de bestaande informatie architectuur “globaal” wordt gewijzigd (gestandaardiseerd) kan zorgen voor onverwachte wijzigingen.

Preventie:

1. Beperken van uitzonderingen, documenteren ervan;
2. Read-only maken van Site – en List Content types;
3. Bepalen en implementeren van duidelijke regels voor het wijzigen van Content Types

In de “Advanced settings” van een Site – en List Content Type kan gekozen worden voor het read-only maken ervan (“Choose whether the content type is modifiable. This setting can be changed later from this page by anyone with permissions to edit this type. “).

Van een Site Content Type kan (in de advanced settings) gekozen worden voor het automatisch bijwerken van afgeleide Site – en List Content Types (“Specify whether all child site and list content types using this type should be updated with the settings on this page. This operation can take a long time, and any customizations made to the child site and list content types will be lost.  Update all content types inheriting from this type? “).

Gelijktrekken van Site - en List Content Types
Wanneer Site Content Types en List Content Types niet meer gelijk zijn, dan kun je, door wijzigingen in het Site Content Type aan te brengen en deze wijzigingen in de onderliggende List Content Types door te laten voeren, de Site - en Lijst Content Types weer gelijk maken.

Voorbeeld:
Worden in een Site Content Type kolommen verwijderd en staan deze nog in de afgeleide List Content Types, dan kunnen deze verwijderde kolommen niet meer allemaal in een keer worden gewijzigd (b.v. Required / Optional gemaakt worden). De kolommen bevinden zich immers niet meer in het Site Content Type.
Wanneer de ontbrekende kolommen weer aan het Site Content Type worden toegevoegd kunnen wijzigingen hierop weer automatisch in de onderliggende List Content Types (waarin de kolommen dezelfde naam / type hebben) worden doorgevoerd. Soms is het nodig om daarbij kolom eigenschappen een extra keer te wijzigen om alle kolom eigenschappen weer gelijk te krijgen (b.v. Required / Optional maken).


Wees voorzichtig met het verwijderen van Site Columns
Wanneer een Site Column als losse kolom aan een lijst of bibliotheek is toegevoegd en de betreffende Site Column wordt verwijderd, dan blijven de kopies die gemaakt zijn in de lijsten of bibliotheken bestaan, onder dezelfde naam. Helaas kunnen deze kolommen niet meer in een slag worden gewijzigd. Wijzigingen zullen dan in iedere lijst of bibliotheek apart moeten worden doorgevoerd. Needless to say dat dit niet bevorderlijk is voor de beheersbaarheid.

Content Types met dezelfde naam kunnen op verschillende site niveaus worden aangemaakt.

Dit wekt natuurlijk verwarring en zal voorkomen moeten worden.

Preventie: gebruik unieke namen voor alle Content Types.

Verander standaard SharePoint Content Types niet

SharePoint kent een aantal standaard Content Types. Verander deze liever niet omdat ze de basis vormen van SharePoint en veel standaard (out of the box) lijsten en bibliotheken hierop zijn gebaseerd.

Content Type en Column Menus lijken veel op elkaar: verwar ze niet met elkaar

Door niet goed in de gaten te hebben op welk niveau een menu wordt gebruikt, kunnen onbedoeld wijzigingen worden doorgevoerd.

Remedie: goed letten op het niveau waarin de het menu zich evindt en de titel van het menu, b.v. “List Content Type” of “Site Content Type”.


Let op in welke groep je een kolom toevoegt

Als je een kolom per ongeluk aan een verkeerde groep hebt toegevoegd en je hebt ervoor gekozen deze wijziging door te voeren op de onderliggende niveaus, dan wordt de betreffende kolom ook op de onderliggende niveaus in de verkeerde groep ondergebracht.

Remedie: goed opletten.

Let bij het wijzigen van Columns op het gebruik ervan in custom Page Layouts

Weleens gehoord van de SharePoint “Unknown error”? Een van de oorzaken hiervan kan zijn dat in een custom (aangepast) Page Layout wordt verwezen naar een Column die is gewijzigd.

Remedie:  aanpassen van de betreffende Page Layout.

SharePoint 2013 (Office 15): praktisch aan de slag

Hij is er: de SharePoint Server 2013 Preview!

Wat is er vernieuwd en verbeterd?

In het kort is SharePoint verbeterd op de onderstaande hoofdpunten:

Delen en samenwerken
Nieuwe "social" functionaliteit. Verbeterde ondersteuning voor mobiel telefoon en tablets.

Organiseren
Verbeterde ondersteuning van projecten (b.v. zichtbaar maken van taken en deliverables via o.a. SharePoint en Outlook) en project team sites. Opslag en synchronisatie van online (SkyDrive Pro, zie ook: Introducing SkyDrive pro) en offline (desktop) documenten.

Zoeken en vinden
Zoeken van personen op basis van interesses, projecten en publicaties van documenten.
Verbeterde zoekresultaten (relevantie) door verder kunnen filteren (narrow down) van zoekresultaten, en rekening kunnen houden met aanbevelingen van personen en documenten.

Applicatie bouw
Bouwen van Apps en publiceren ervan in de eigen SharePoint App Store op basis van technieken als AJAX en het nieuwe Microsoft Cloud App Model voor SharePoint (zie ook Apps for SharePoint overview en Build Apps for Office and SharePoint (met voorbeelden)).

Een korte intro video hieronder.



Meer informatie voor bouwers is te vinden in het SharePoint 2013 Dev Center. Interessant overzicht hierin is: SharePoint 2013 development overview.

Beheer en management
Delen van online diensten door gebruik te maken van Office 365 (SharePoint in de cloud).
Verbeterde en nieuwe ondersteuning van Risk Management: b.v. archiveren, eDiscovery en case management.
Meer info voor beheerders is te vinden in o.a. de SharePoint 2013 IT pro site (installatie, architectuur, configuratie, etc.) en SharePoint 2013: presentation: IT pro training (trainingsmateriaal voor SharePoint beheerders).

Daarnaast zijn natuurlijk verdere verbeteringen doorgevoerd op de gebieden van schaalbaarheid, security en flexibiliteit.

Meer informatie hierover is te vinden in SharePoint 2013 benefits. En een goede vergelijking met SharePoint 2010 is hier te vinden.

Wat biedt de preview versie?

De preview is een versie met alle beschikbare features die voor een beperkte tijd bruikbaar is. Je kunt ermee aan de slag in de volgende stappen:

1. Review de Microsoft SharePoint Server 2013 system requirements. In het kort: een minimale (single server) installatie vergt 8 Gb RAM, 64-bit Windows OS, 4 cores processor en 80 Gb vrije harddisk ruimte. Meer info voor beheerders vind je in de SharePoint 2013 IT pro site (installatie, architectuur, configuratie, etc.).
2. Registreer jezelf
3. Download en installeer de trial versie.
   
   Voor een gedetailleerde walkthrough van de installatie, zie de serie "Install SharePoint 2013 Public Beta on Windows Server 2012 RC" (op de Microsoft Playground website, http://msftplayground.com/):
   Part I – Installation of Windows Server 2012 RC
   Part II – Installation of Active Directory and DNS Services on Windows Server 2012 RC
   Part III – Installation of SQL Server 2012
   Part IV – Installation of the Prerequisites
   Part V – Installation of SharePoint 2013
   Part VI – Configuring SharePoint 2013 (zal nog verschijnen op de Microsoft Playground website, http://msftplayground.com/)
   
   Ook handig: Install SharePoint 2013 in a Virtual Machine
4. Daarna ontvang je 2 emails met aanvullende informatie over documentatie en de volgende release
5. Daarna kun je de forums en blogs gebruiken om kennis en ervaring te delen. Zie hiervoor ook de Community.

Meteen aan de slag?

Meteen aan de slag met een Virtual Image (waarmee je SharePoint kunt (proef)draaien op je eigen computer):
http://gauravmahajan.net/2012/07/22/sharepoint-2013-virtual-machine/

Meer weten?

Microsoft SharePoint Server 2013 Preview Evaluation Resources
Download Microsoft SharePoint Server 2013 Preview

Betere SharePoint foutmeldingen... hoe regel ik dat?

Bij een van mijn vorige werkgevers hadden we een melding bedacht voor foutsituaties waarmee we niets konden: "Er is iets vreselijks gebeurd, bel systeembeheer.". Wij technici konder de humor wel inzien, voor eindgebruikers moet deze melding angstaanjagend geweest zijn. Ik voel me schuldig, maar da's achteraf. Maar ik heb nu ook aan den lijve ondervonden wat eindgebruikers doorgemaakt moeten hebben. En dat allemaal dankzij de "An unexpected error has occurred" melding die SharePoint (2007) standaard geeft wanneer er "iets vreselijks" mis gaat. Gelukkig is er een eenvoudige oplossing die met een welwillende houding van systeembeheer snel kan worden gerealiseerd.

De oplossing in het kort

Oplossing moet worden geimplementeerd op de webservers in het SharePoint farm in kwestie. Tip: maak hier een script voor.

Voor iedere web server:

1. Login op de web en ga naar de locatie van de betreffende web site (collectie), waarschijnlijk te vinden in een lokatie als: C:\Inetpub\wwwroot\wss\VirtualDirectories.
2. Open de “web.config” file met een tekst editor
3. Wijzig de volgende regels in de configuratie file:
4. Op de eerste regel code waar het woord “CallStack” voorkomt, verander de instellingen CallStack en AllowPageLevelTrace in “true”.
5. Zoek verder naar het woord “Errors”, en verander de instelling mode in “Off”.
6. Bewaar de configuratie file en sluit de editor.
7. De web server IIS moet hierna reset worden (IISRESET). Dat betekent dat de SharePoint webservers eventjes niet beschikbaar zijn. 

Aandachtspunten

Bovenstaande oplossing is snel te realiseren, maar en zijn ook een paar aandachtspuntjes. In het kort:

• Voor websites die door de boze buitenwereld kunnen worden bekeken (internet, extranet) biedt bovenstaande oplossing extra informatie aan potentiele inbrekers. Dit is natuurlijk niet gewenst.
• Een melding die met bovenstaande oplossing aan de eindgebruiker wordt gegeven biedt welliswaar meer informatie, maar dit moet wel door de eindgebruiker aan de helpdesk doorgegeven (kunnen) worden. En als dat niet gebeurt (b.v. omdat de foutmeldingen technisch van aard zijn en niet begrepen worden of misschien gewoon weggeklikt worden), dan schiet de oplossing haar doel voorbij.

Een eigen error page maken

Een betere oplossing is het maken van een eigen error page waarin zelf geselecteerde informatie kan worden aangeboden. Naast specifieke informatie over de fout kan ook informatie worden opgenomen over de manier waarop er melding van gedaan kan worden. Denk hierbij ook aan een link naar een email adres waarop geklikt kan worden en waarbij de mailapplicatie wordt opgestart en een nieuw mailtje wordt aangemaakt met alvast de meest relevante informatie daarin.

Een mooie start hiervoor is te vinden in deze site.

SharePoint, IIS, Windows server en SQL-server logfiles

Natuurlijk zijn bovenstaande logfiles eveneens zeer waardevol voor het kunnen analyseren van fouten. Echter, ze moeten wel toegankelijk gemaakt worden. Wellicht kan hiervoor een online dienst gemaakt worden.

SharePoint 2010

SharePoint 2010 biedt betere mogelijkheden om fouten te analyeren. De "An unexpected error has occurred" melding is gebleven maar gaat vergezeld van een zogenaamde correlation code. Dit is een alfa-numerieke code (een GUID, een Globaly Unique IDentifier) waarmee systeembeheer relatief eenvoudig relevante informatie over de gebeurtenis aan de hand van deze code in de verschillende logfiles kan terugvinden.

Een praktisch vraagje aan jullie: welke praktische onderwerpen zouden in deze blog aan de orde moeten komen?

Ik ben inmiddels een tijdje bezig met het schrijven van artikelen voor mijn blog. En regelmatig kijk ik hierbij ook naar de bezoekstatistieken. Het bezoek valt niet tegen, moet ik zeggen, en het neemt toe. Maar statistieken zeggen relatief weinig. Vandaar ook dat ik maar beter een heel directe vraag aan jullie kan stellen:

Waar hebben jullie behoefte aan?

...en iets concreter: welke onderwerpen / vraagstukken zou ik aan de orde moeten laten komen?

Alle ideeen zijn welkom... deze graag sturen aan hansrontheweb@live.com

Alvast dank!

Site definities en Site Templates: wat is het verschil en hoe ga je ermee om?

Een veelgestelde vraag is wat de verschillen zijn tussen Site definitions en Site templates. Beide mogelijkheden worden nogal eens door elkaar gehaald en het blijkt telkens weer lastig te zijn om beslissingen te nemen hoe beide technieken in te zetten.

Vandaar ook een korte intro en wat praktische tips in dit blog artikel.

Een Site definition en een Site template zijn sterk gerelateerd aan elkaar; ze liggen in elkaars verlengde. Een Site template is gebaseerd op een Site definition en bestaat uit wijzigingen die op een bepaalde Site definitie worden toegepast.

Maar laten we eerst eens ingaan op de basis: Site definitions

Een Site definition omschrijft de look en feel van een site, de inhoud ervan (lijsten, bibliotheken, content types, column types, et cetera), navigatie, et cetera. Deze omschrijving wordt gemaakt in aspx en CAML (een XML taal, zie ook: Introduction — What Is CAML?). Site definitions worden opgeslagen in het filesystem van SharePoint webservers, worden gecached door de webserver en zijn daarmee snel beschikbaar voor gebruik. Het detailniveau waarop websites te definieren zijn is groot, groter dan bij het gebruik van Site templates. Aanpassen van menu's (b.v. Edit menu) is bijvoorbeeld goed mogelijk. Let wel: aanpassingen aan Site definities hebben gevolgen voor de de sites die op basis hiervan zijn gemaakt.

Site templates zijn wijzigingen gebaseerd op Site definitions.

Ze worden in Content Databases opgeslagen. Een Site template kan in de vorm van een CAB bestand (Zip bestand met een mappenstructuur met daarin definitie - en content bestanden) worden opgeslagen en worden uploaded in een Site template gallery van een Site collection. Van bestaande Sites kunnen met een simpele klik Site templates worden gemaakt. Site templates kunnen gewijzigd worden zonder dat de sites die op basis hiervan zijn gemaakt, worden aangetast.

De verschillen en afhankelijkheden zijn dus duidelijk. Maar wanneer zet je welke techniek in? En waarmee moet je dan rekening houden?

Best practices: waarmee rekening houden bij de keuze tussen Site definitions en Site temlates?

Hierin zijn de volgende overwegingen van belang:

De mate van detail waarin een site beschreven moet worden.
Wanneer een Site kan worden beschreven door een bestaande Site definitie te gebruiken, heeft dat meestal de voorkeur. Pas wanneer gebruik van een Site definitie noodzakelijk is (b.v. voor het definieren van menu's, nieuwe document typen, ) kan daarop worden overgegaan.

De afhankelijkheden tussen Site definitions en Site templates.
Allereerst: de Site definitie waarop een Site template gebaseerd is, moet op de betreffende webserver aanwezig zijn.
Daarnaast moet rekening gehouden worden met de mate van verandering waaraan site onderhevig zijn en wat de gevolgen zijn voor de Site definities en de afhankelijke Site templates. Zaken die gemakkelijk zijn te veranderen of zaken die aan geen of heel weinig verandering onderhevig zijn, kunnen worden opgenomen in Site definitions. Andere zaken kunnen het beste in Site templates worden opgenomen.

De voorhanden expertise, tools en rechten
Site templates kunnen relatief simpel worden aangemaakt en gebruikt door (bevoegde) eindgebruikers. Site definities, daarentegen, worden gemaakt met speciale tooling, moeten met de juiste expertise worden opgebouwd, en worden opgeslagen in het File system van een webserver, hetgeen de juiste rechten vereist.

Andere situaties...

Daarnaast kunnen andere zaken in bepaalde situaties van belang zijn, bijvoorbeeld performance. Site definities zijn in het algemeen sneller door de webserver aan te bieden dan Site templates.

Conclusies

Bovenstaande geeft aan dat het zaak is om verstandig om te gaan met Site definities: pas je ze naderhand aan dan loop je het risico dat de Site templates die erop gebaseerd zijn beschadigd raken en web sites die hierop gebaseerd zijn niet meer naar behoren functioneren. Eerst nadenken over de gevolgen van wijzigingen en verstandig ontwerpen is daarom een aanrader.

Ondersteuning van Microsoft: wanneer eindigt het?

Microsoft ondersteunt haar producten niet tot in het oneindige. Wanneer ondersteuning wordt afgebouwd en wanneer deze stopt kan worden opgezocht in de Support lifecycle database. Per land kan ondersteuning verschillen. Selecteer dus eerst het land waarvoor je de gegevens wilt opzoeken.

Voor de Support Lifecycle database, zie: http://support.microsoft.com/lifecycle.

Voor de ondersteuning van SharePoint 2007, bijvoorbeeld, zie: http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=SharePoint+Server+2007&Filter=FilterMS&msdate=0

SharePoint Commandline tools: een korte introductie

SharePoint kan met de good old commandline worden beheerd. In het onderstaand artikel een kort overzicht met beschrijvingen, wat voorbeelden en verwijzingen naar documentatie.

Setup.exe (voor SharePoint 2007 en 2010)

setup.exe Wordt gebruikt voor en klein aantal operaties zoals configuraties, installeren volgens een standaard, aanpassen van de configuratie, reparatie van de installatie en deinstallatie.
Documentatie is te vinden in:
SharePoint 2007: http://technet.microsoft.com/en-us/library/cc262897(v=office.12)
SharePoint 2010: http://technet.microsoft.com/en-us/library/cc262897(v=office.12

psconfig.exe (voor SharePoint 2007 en 2010)

Voor het configureren van een SharePoint omgeving. Deze tool wordt vaak gebruikt in een batch script (.bat) om een omgeving op te zetten en te configureren.

Let op: inloggen met een account dat lid is van de Administrators groep.

Documentatie is te vinden in:
SharePoint 2007: http://technet.microsoft.com/en-us/library/cc263093(v=office.12).aspx
SharePoint 2010: http://technet.microsoft.com/en-us/library/cc263093.aspx

Voorbeelden:
psconfig.exe -cmd configdb <parameters>
-cmd helpcollections <parameters>
-cmd secureresources <parameters>
-cmd services <parameters>
-cmd installfeatures <parameters>
-cmd adminvs <parameters>
-cmd evalprovision <parameters>
-cmd applicationcontent <parameters>

stsadm.exe (voor SharePoint 2007 en 2010)

stsadm wordt gebruikt voor configuratie en beheer van SharePoint platforms. het kan op de commandline en in batchfiles gebruikt worden. stsadm Biedt meer mogelijkheden dan de Central Administration site.

Let op: inloggen met een account dat lid is van de Administrators groep.
Let op:  stsadm bevindt zich op de volgende lokatie: %COMMONPROGRAMFILES%\microsoft shared\web server extensions\12\bin. Gewoon stsadm intikken op de commandline werk meestal niet meteen omdat het commando op die specifieke locatie staat en dus daarvanuit opgestart moet worden of aan de PATH varialele moet worden toegevoegd.

Voorbeelden:
stsadm -o activatefeature {-filename <relative path to Feature.xml> | -name <feature folder> | -id <feature Id>} [-url <url>] [-force]
stsadm -o addsolution -filename <Solution filename> [-lcid <language>]

Documentatie is te vinden in:
SharePoint 2003: http://technet.microsoft.com/en-us/library/cc287902(v=office.12).aspx
SharePoint 2007: http://blogs.technet.com/b/josebda/archive/2007/03/22/complete-reference-of-all-stsadm-commands-with-options-in-moss-2007.aspx
SharePoint 2007: Stsadm Technical Reference for SharePoint Server 2007 (Quick Reference Card):
http://technet.microsoft.com/en-us/office/sharepointserver/cc948709
SharePoint 2010: http://technet.microsoft.com/en-us/library/cc261956(v=office.12).aspx

PowerShell command scripts (voor SharePoint 2007 en 2010)

PowerShell is de nieuwe (en nu standaard) tool voor beheer van SharePoint omgevingen. Het is uitgebreider dan stsadm en verdient de voorkeur boven stsadm. Versie 1.0 is verouderd en biedt minder mogelijkheden dan versie 2.0 (en volgende versies). PowerShell wordt gebruikt voor meer dan SharePoint alleen; voor SharePoint is een commando bibliotheek (snapin) beschikbaar die kan worden uitgebreid (zie ook de CodePlex community voor voorbeelden hiervan, b.v. http://sharepointpsscripts.codeplex.com/releases/view/53114). De commando's heten cmdlets. Het SharePoint object model van een SharePoint installatie kan middels deze cmdlets worden benaderd en gemanipuleerd.

Voorbeeld:
$spWeb = Get-SPWeb -Identity http://SPServer
$listTemplate = [Microsoft.SharePoint.SPListTemplateType]::DocumentLibrary
$spWeb.Lists.Add("My Documents","My Doc Library",$listTemplate)

Documentatie is te vinden in:
SharePoint 2007/2010: http://blog.falchionconsulting.com/index.php/stsadmpowershell-commands

stsadm of PowerShell?

stsadm Is verouderd ten opzichte van PowerShell. PowerShell verdient daarom de voorkeur. Voor een overzicht van PowerShell commando's en hun equivalenten in stsadm, zie: Stsadm to Windows PowerShell mapping (SharePoint Server 2010):
http://technet.microsoft.com/en-us/library/ff621084.aspx

GacUtil.exe

De Global Assembly Cache (GAC) tool biedt de mogelijkheid om de inoud van de Global Assembly Cache in te zien en te bewerken. Handig wanneer je wilt zien welke versies van DLL's aanwezig zijn om eventuele conflicten te analyseren en te verhelpen.

Documentatie is te vinden in:
http://msdn.microsoft.com/en-us/library/ex0ss12c(VS.80).aspx

makecab.exe

Verpakt bestanden die nodig zijn voor een SharePoint solution in een cabinet (.cab) bestand. Dergelijke bestanden zijn te vergelijken met zip-files en ook zo te openen.

Documentatie is te vinden in:
Makecab reference

cabarc.exe

Met Cabarc kunnen .cab bestanden gemaakt, uitgepakt en bekeken worden. Cabarc ondersteunt wildcards en recursieve directory zoekopdrachten.

Documentatie is te vinden in:
Microsoft Cabarc User's Guide

Alle tools onder handbereik

Wanneer je een command window opent is het handig om hierin direct de commando's te kunnen gebruiken die je nodig hebt. Hiervoor kun je de paden naar deze commando's instellen zodat ze direct kunnen worden aangeroepen. Onder de properties van "My Computer" vindt je de advanced tab waarin je de environment variabelen kunt instellen.Voeg het pad naar het te gebruiken commando toe en bewaar de instellingen.

Documentatie is te vinden in:
http://technet.microsoft.com/en-us/library/cc736637(v=ws.10).aspx

Kosten rekenen voor het gebruik van SharePoint

Een door mij veelgehoorde vraag van klanten is hoe het gebruik van SharePoint kan worden doorberekend aan klanten. Veelal zijn dat interne klanten, afdelingen, maar de vraag wordt ook gesteld voor externe klanten.

De oplossing lijkt simpel; per gebruiker of per “gebruik”. Maar er is meer mogelijk en er is meer om rekening mee te houden.

Een korte uitleg in dit artikel…

Modellen voor doorberekening van kosten

De meest gangbare modellen om kosten door te kunnen berekenen zijn gebaseerd op:

·         Betaling per gebruiker

·         Betaling per website

·         Betaling per hoeveelheid opslagruimte

·         Betaling per dienst

SharePoint biedt goede mogelijkheden op dergelijke modellen te gebruiken, zoals een gebruikersadministratie, een site administratie, vaststellen hoeveel opslagruimte per site mag worden gebruikt (quota) en een toegangsadministratie voor diensten die middels SharePoint worden ontsloten.

Wat betreft diensten kunnen natuurlijk ook kosten worden gerekend voor diensten als backup/restore, helpdesk ondersteuning, uitvoering en onderhoud van maatwerk, et cetera.

Welk model (of combinatie van modellen) het beste gebruikt kan worden,hangt echter af van de situatie.

Welk model kan ik het beste gebruiken?

Het doorberekenen van kosten is natuurlijk een manier om de kosten te kunnen terugverdienen of winst te maken, maar kan ook gezien worden als een manier om gedragsverandering te bereiken. Daarom is het van belang om eerst de volgende vragen te stellen:

·         Voor welke doelen moet SharePoint in de organisatie ingezet worden?

·         Hoe wordt SharePoint nu in de organisatie gebruikt?

Daarna kan bepaald worden welk model of combinatie ervan voor kostendoorberekening doeltreffend en doelmatig gebruikt kan worden om de doelen te bereiken en hoe dit model of combinatie van modellen het beste kan worden ingezet.

Allereerst is het dus van belang te weten wat met SharePoint binnen de organisatie bereikt moet worden, en in het verlengde hiervan: welke SharePoint toepassingen hiervoor gebruikt moeten worden. Daarnaast is het van belang te bepalen wat de waarde voor de organisatie is van deze toepassingen. Immers: de waarde van een toepassing bepaalt in grote mate in hoeverre een organisatie in de SharePoint  toepassing wil investeren, en daarmee in hoeverre kosten doorberekening voor deze toepasingen geaccepteerd wordt.

Daarnaast is het van belang wat te weten van de uitgangssituatie, te weten in hoeverre SharePoint binnen de organisatie is “ingeburgerd”; hoe en in hoeverre SharePoint toepassingen op het gegeven moment wordt gebruikt. De mate waarin SharePoint geaccepteerd als “het platform” voor de toepassing waarvoor het wordt gebruikt is eveneens van invloed op de acceptatie van kostendoorberekening.

Laten we eerst eens kijken naar de mate van “inburgering” van SharePoint in een organisatie.

SharePoint gebruik: van onvolwassen verkenning tot een volwassen beheerst platform

Om een beeld te krijgen van de mate waarin SharePoint in een organisatie is “ingeburgerd”, kan gebruik worden gemaakt van het Capability Maturity Model (CMM) model. Dit model wordt vaak gebruikt om te bepalen hoe volwassen software ontwikkeling is, maar kan ook voor het gebruik van platform als SharePoint worden ingezet. In het model wordt onderscheid gemaakt tussen 5 niveaus van volwassenheid waarbij een hoger niveau inhoudt dat de organisatie tot een grotere beheersbaarheid in staat is.

De verschillende niveaus worden in de onderstaande tekst omschreven, waarbij per niveau ingegaan wordt op kenmerken van SharePoint gebruik. De opsomming van kenmerken is niet volledig, maar geeft een goed beeld op basis waarvan het niveau van SharePoint gebruik in een organisatie kan worden herkend.

1.       Initial: chaotisch en ad hoc. Hierbij worden problemen worden pas opgelost als ze zich voordoen.

In SharePoint termen: beheer houdt zich relatief afzijdig; eindgebruikers kunnen relatief veel of juist weinig binnen SharePoint. Er heerst wildgroei of SharePoint wordt juist weinig gebruikt. Er worden geen vaste templates gebruikt, SharePoint wordt veelal out-of-the-box gebruikt, aangevuld met ad hoc en onbeheerst maatwerk van relatief onervaren gebruikers. 

Wanneer SharePoint in een organisatie wordt geïntroduceerd gebeurt dit vaak door de ICT afdeling die SharePoint installeert en ermee gaat experimenteren. Andere groepen en afdelingen volgen hierin. Alternatieve systemen zijn hierbij vaak gelijktijdig met SharePoint in gebruik waardoor de gebruiker de keuze heeft SharePoint of andere systemen (b.v. fileservers voor de opslag van documenten) te gebruiken.

2.       Repeatable: het niveau waarbij de organisatie zover volwassen is dat gebruik wordt gemaakt van de kennis die eerder is opgedaan. Beslissingen worden genomen op basis van opgedane ervaring.

In SharePoint termen: Gebruik van projectsites (op basis van site templates die gebaseerd zijn van zelfgemaakte project web sites), vaste plekken (bibliotheken en lijsten) waar de gebruiker informatie kan vinden, een geaccepteerde site structuur, simpele business applicaties. Op eigen initiatief worden site/bibliotheek/lijst templates (her)gebruikt.

Verdere ondersteuning wordt steeds belangrijker omdat steeds meer medewerkers gebruik maken van SharePoint. Het snel kunnen beantwoorden van praktische vragen is hiervan een goed voorbeeld.

3.       Defined:  is het niveau waarbij de belangrijkste processen zijn gestandaardiseerd.

In SharePoint termen: Vergevorderd gebruik van site-, bibliotheek- en lijst templates, opgelegd door de organisatie. Verplicht gebruik van een metadata set om documenten te metadateren, voor bepaalde toepassingen worden workflows gebruikt, voor sites worden beheerders aangewezen.

SharePoint wordt steeds meer “the place to be” voor ondersteuning van projecten en samenwerkingsverbanden. Verwezen wordt naar SharePoint als “de” bron van de informatie en vanuit SharePoint wordt verwezen naar andere systemen, b.v. SAP, Siebel, et cetera.

Bruikbaarheid en gebruiksvriendelijkheid krijgen meer aandacht, hetgeen zich uit in aandacht voor onder anderen layout/vormgeving en het gebruik van een style guide bij aanpassingen en nieuwe implementaties. Content beheer en verspreiding wordt geformaliseerd en rechten worden beter bepaald en bijgehouden.

Verdere ondersteuning wordt steeds belangrijker omdat de waarde van SharePoint in de organisatie doordringt. Het snel kunnen herstellen op basis van backups is hiervan een goed voorbeeld. Ook worden hogere eisen gesteld aan SharePoint beheer en applicatie ontwikkeling, onder anderen door de introductie van een OTAP omgeving (aparte omgevingen voor Ontwikkeling, Test, Acceptatie en Productie, met formele processen  hier mee om te gaan).

In organisaties waarin gebruikers relatief veel vrijheid hebben om zelf te bepalen hoe met documenten wordt omgegaan (b.v. fileservers, lokale schijven, geen versie management) zal deze standaardisatie als bureaucratisch ervaren kunnen worden. Wanneer, naast SharePoint, concurrerende systemen (fileservers) vrij beschikbaar zijn loert het gevaar dat gebruikers “om SharePoint heen” gaan werken.

4.       Managed: Het niveau waarbij de kwaliteit van het ontwikkelproces wordt gemeten zodat dit kan worden bijgestuurd.

In SharePoint termen: Gebruik van quota voor onder anderen gegevensopslag en het gebruik van resources, recyclebin management, rapportage over het gebruik van SharePoint (gebruiksstatistieken, zoekstatistieken) worden geanalyseerd en gebruikt om de structuur en inhoud (content) van het SharePoint platform te verbeteren.

Er wordt gebruik gemaakt van Sandboxed solutions om toepassingen in quarantaine te ontwikkelen en te testen.

Migratie trajecten worden voorbereid; van te voren wordt ingeschat wat nodig is voor een migratie naar bijvoorbeeld een nieuwe versie van SharePoint.

5.       Optimizing: Het niveau waarbij het ontwikkelproces als een geoliede machine loopt en er alleen maar sprake is van fijnafstemming (de puntjes op de i).

In SharePoint termen: kan op niveau geanticipeerd worden op aanpassingen, nieuwe SharePoint toepassingen, toename of aanname van gebruik, migratie, consolidatie en splitsing van SharePoint omgevingen.

Er is sprake van doeltreffend Document lifecycle management. Duidelijk is voor elk type content wat het belang hiervan is voor de organisatie, welke regels hiervoor gelden en welke ondersteuning hiervoor noodzakelijk is. Hoe lang en onder welke omstandigheden moet informatie beschikbaar zijn, wat is de waarde ervan voor de organisatie, hoe en voor wie is de informatie beschikbaar zijn, zijn vragen die hierbij naar voren komen. Aanvullende SharePoint rollen worden aan medewerkers toegewezen en medewerkers worden hierop getraind.

De onderliggende (virtuele en fysieke) infrastructuur wordt continu aangepast aan de behoeften die gebruik van het SharePoint platform stelt.

Ook wordt op dit niveau steeds meer gekeken naar SharePoint als onderdeel van het Information Workplace concept, dus in combinatie met andere tools en toepassingen, en niet als op zichzelf staand web platform. De organisatie gebruikt hierbij, naast de SharePoint web sites, ook toepassingen als Office (Word, Excel, Access, Outlook, et cetera) om taken uit te voeren. Hierbij wordt ook aandacht besteed aan mobiel gebruik (mobiele toepassingen, b.v. op SmartPhones).

One size fits all of differentiëren?

Bovenstaande volwassenheidsniveaus gelden vaak niet voor de hele organisatie. SharePoint wordt in de praktijk immers vaak niet organisatie breed uitgerold en toegepast. Veelal begint de ICT afdeling van een organisatie met het toepassen ervan (experimenteren) en volgen andere afdelingen en groepen. Afhankelijk van, onder anderen, het succes dat met SharePoint wordt behaald, wordt het gebruik ervan voor de ene afdeling sneller volwasssen dan voor de andere afdeling.

En daar blijft het niet bij; organisaties veranderen voortdurend. Onder anderen mergers en splitsingen zorgen ervoor dat het volwassenheidsniveau van het gebruik van SharePoint niet altijd op hetzelfde niveau blijft.

Dit heeft, zoals afgeleid kan worden uit de onderstaande tekst, gevolgen voor de doeltreffendheid waarmee kostenmodellen kunnen “werken” voor de afzonderlijke afdelingen of groepen. Wanneer we ingaan op de doeltreffendheid en doelmatigheid van de verschillende kostenmodellen moeten we dit dus bekijken per afdeling of groep, als deze verschillende volwassenheidsniveau’s kennen.

Doeltreffendheid en doelmatigheid van kostenmodellen

Nu we weten hoe SharePoint in een bepaalde afdeling of groep wordt gebruikt en we weten waarvoor en hoe SharePoint voor deze afdeling of groep moet worden wordt gebruikt, kan bepaald worden wat met kostendoorberekening bereikt moet worden en hoe dat het beste gedaan kan worden.

Laten we daarvoor kijken naar de voor – en nadelen van de verschillende kostenmodellen. Ik ga er hierbij vanuit dat alle kosten (licentiekosten, opslagkosten, beheerskosten, et cetera) als basis voor de doorberekeningen worden meegenomen, maar hier wordt niet verder op ingegaan.

Algemene voor- en nadelen van kostenmodellen

Voor ieder kostenmodel kunnen alvast algemene voor – en nadelen bedacht worden die gelden voor ieder volwassenheidsniveau. Deze worden in de onderstaande tabel weergegeven.

Betaling per gebruiker
Voordelen:	Nadelen:
Simpel te implementeren en bij te houden.	Zware gebruikers en lichte gebruikers worden even zwaar belast, hetgeen als oneerlijk kan worden ervaren.
Betaling per website
Voordelen:	Nadelen:
Simpel te implementeren en bij te houden.	Om kosten te besparen worden Web sites worden samengevoegd, hetgeen ten koste kan gaan van de beheersbaarheid.
Betaling per hoeveelheid opslagruimte
Voordelen:	Nadelen:
Simpel te implementeren en bij te houden, gebruik makend van site quota en alert mails bij overschrijding.	In sommige omstandigheden,wanneer het (tijdelijk) nodig is om grote hoeveelheden opslagruimte te gebruiken, relatief duur en onaantrekkelijk.
Betaling per dienst
Voordelen:	Nadelen:
Als aanvulling op andere kostenmodellen een goede manier om kosten beter te differentiëren.	Minder eenvoudig te implementeren en bij te houden.

Natuurlijk kan ervoor gekozen worden om geen kosten door te berekenen. Maar dit heeft ook zijn nadelen (naast de voordelen):

Voordelen zijn:

·         Simpel te realiseren, we doen immers “niets”.

·         Niet rekenen van kosten verlaagt de drempel voor het gebruik van SharePoint.

Maar (nadelen) zijn:

·         De verantwoordelijk voor de Sharepoint omgeving wordt hiermee onduidelijk. Hierdoor ontstaat wildgroei die later lastig is terug te brengen.

·         Verminderde mogelijkheden voor investering in verdere ondersteuning. Kosten doorberekenen geeft de mogelijheid voor het doen van investeringen in diensten die nodig zijn voor het volwassen maken van het SharePoint platformen en de ondersteuning van diensten waarmee de de ambities van de organisatie waargemaakt kunnen worden.

Het doorberekenen van kosten heeft dus duidelijke voordelen ten opzichte van het niet doorberekenen ervan.

In de onderstaande tekst wordt ingegaan op in het oog springende voor-en nadelen van de verschillende kostenmodellen bij de verschillende volwassenheidsniveau’s. Vantevoren moet wel gezegd worden dat iedere situatie waarin kosten moeten worden doorberekend natuurlijk uniek is, en dat de voor- en nadelen daarom ook in meer of mindere mate kunnen worden gevoeld.

Gebruik van kostenmodellen op de verschillende volwassenheidsniveau’s

Op de niveau’s 1 en 2 (Inital en Repeatable), is acceptatie van SharePoint in een organisatie erg belangrijk. Er moet ruim de tijd en gelegenheid zijn voor experimenteren. Wanneer voor het gebruik van SharePoint meteen alle kosten voor iedereen in rekening worden gebracht kan dit de drempel om SharePoint te gaan gebruiken (en als standaard te gaan zien) verhogen en kan dit ten koste gaan van de acceptatiegraad van SharePoint.
Aan de andere kant kan het in rekening brengen van kosten de wildgroei, wat een reël gevaar is wanneer SharePoint voor het eerst wordt gebruikt, in toom houden. Wildgroei ontstaat wanneer, zonder beleid, grote hoeveelheden gebruikers, content, web sites en functies aan het SharePoint platform worden toegevoegd. Dit komt vaak voor bij groepen die zich op de toepassing van SharePoint veel sneller en sterker ontwikkelen dan andere groepen. Dit gedrag moet enerzijds in toom worden gehouden, maar anderzijds worden aangemoedigd; immers: dergelijke groepen leren snel, kunnen andere groepen inspireren en daarmee de acceptatiegraad verhogen.

Over de kostenmodellen kan het volgende worden gezegd:

·         Betaling per gebruiker: lage acceptatie wanneer gebruik van SharePoint sterk verdeeld is of sterk wisselt binnen een organisatie.

·         Betaling per website: redelijk geaccepteerd, maar werkt samenvoegen van web sites in de hand waardoor de beheersbaarheid afneemt.

·         Betaling per hoeveelheid opslagruimte: redelijk geaccepteerd, maar werkt gebruik van alternatieve systemen in de hand waardoor de standaardisatie op basis van SharePoint wordt benadeeld.

·         Betaling per dienst: geaccepteerd voor diensten waar relatief weinig gebruikers gebruik van maken of van relatief dure diensten.

Wanneer toch kosten gerekend moeten worden kan overwogen worden een basispakket (aantal websites, per web site een bepaalde hoeveelheid opslagruimte, vaste nuttige diensten) “gratis“ of tegen een  aantrekkelijk prijs aan te bieden. Wat betreft de basisdiensten kan gedacht worden aan een helpdesk, backup/restore, faciliteren van een gebruikerscommunity et cetera. Deze diensten komen de acceptatiegraad en standaardisatie ten goede.

Voor aanvullende diensten, extra web sites, meer opslagruimte et cetera, kunnen aanvullende kosten worden berekend.

Wanneer het SharePoint platform tot standaard wordt verheven, op niveau 3 (Defined) is de acceptatiegraad, net zoals bij niveau 1 en 2, van groot belang, maar moet anders bekeken worden. Het is nu niet meer zozeer het doel om medewerkers te motiveren om met SharePoint te gaan experimenteren, nu is het zaak om iedereen volgens een standaard te laten werken met Sharepoint. En dat kan eveneens voor wildgroei zorgen.

We hebben het hier over migratietrajecten waarin de organisatie (en de gebruikers), veelal naast hun dagelijks werk en onder hoge druk, grote hoeveelheden bestanden naar hun nieuwe werkomgeving (SharePoint) moeten verplaatsen. En deze nieuwe werkomgeving moet daarnaast ook nog eens (deels) worden aangepast. In dergelijke trajecten is de kans dat, zonder beleid en met haast, veel SharePoint web sites worden aangemaakt waarin grote hoeveelheiden bestanden worden “gedumpt”. Dit komt de onbeheersbaarheid niet ten goede. En is dit nueenmaal gebeurd, dan is dit lastig terug te draaien.
Daarnaast loert op dit niveau des te meer het gevaar dat concurrerende platformen gebruikt worden, wanneer deze gemakkelijk beschikbaar zijn en migratie naar SharePoint voor de gebruikers te veel “moeite” kost of de kosten voor het gevoel te hoog liggen. Denk hierbij aan de ouderwetse fileservers waarop gebruikers gewend zijn hun documenten op te slaan en waar ze een relatief grote vrijheid hebben. Gebruikers hebben dan de neiging om “om SharePoint heen te werken”.

Over de kostenmodellen kan het volgende worden gezegd:

·         Betaling per gebruiker: redelijke acceptatie omdat SharePoint als standaard is geaccepteerd en iedereen hiervan gebruik maakt.

·         Betaling per website: redelijk geaccepteerd, maar als onder druk van b.v. een migratie traject veel web sites worden aangemaakt kunnen deze kosten als te hoog worden gezien. Hierdoor gaan gebruikers  web sites samenvoegen waardoor de beheersbaarheid afneemt.

·         Betaling per hoeveelheid opslagruimte: redelijk geaccepteerd, maar kan gebruik van alternatieve systemen in de hand werken wanneer de kosten als te hoog worden gezien (b.v. bij migratie).

·         Betaling per dienst: geaccepteerd voor diensten waar relatief weinig gebruikers gebruik van maken of van relatief dure diensten.

Het is op dit volwassenheidsniveau, meer nog dan op de niveau’s 1 en 2, van belang dat enerzijds wildgroei in toom wordt gehouden en anderzijds SharePoint faciliteiten voldoende laagdrempelig (kosten) worden aangeboden.

Wanneer toch kosten gerekend moeten worden kan overwogen worden een basispakket (aantal websites, per web site een bepaalde hoeveelheid opslagruimte, vaste nuttige diensten) “gratis“ of tegen een  aantrekkelijk prijs worden aangeboden. Het is hierbij van belang dat redelijke quota’s worden gehanteerd; bij migraties moet niet meteen tegen grenzen worden aangelopen. Verder zijn basisdiensten als een helpdesk, backup/restore, Virus Filtering, faciliteren en een gebruikerscommunity (diensten die migratie ondersteunen) van groot belang. Deze diensten komen de acceptatiegraad en standaardisatie ten goede en zullen als basis tegen aantrekkelijke prijzen aangeboden moeten worden.

Voor aanvullende diensten, extra web sites, meer opslagruimte et cetera, kunnen aanvullende kosten worden berekend.

Applicatie ontwikkeling(somgeving) als dienstEen speciale vorm van dienstverlening is het uitvoeren van platform aanpassingen en uitbreidingen. Wanneer SharePoint dit volwassenheidsniveau bereikt zullen ook de processen rond platform aanpassingen en uitbreidingen gestandaardiseerd moeten zijn. Het gaat hier met name om maatwerk dat significante invloed heeft op de werking van het SharePoint platform en waarvan de implementatie risico’s met zich meebrengt.

Het beschikbaar hebben van aparte omgevingen voor applicatie ontwikkeling, test, acceptatie en productie (OTAP) is , met bijbehorende procedures en verdere ondersteuning, als dienst onmisbaar.  Deze omgevingen kunnen zowel fysiek, virtueel of als combinatie hiervan uitgevoerd worden. Verder kan gebruik worden gemaakt van zogenaamde Sandboxed Solutions om toepassingen in quarantaine (met beperkt en gemonitord gebruik van resources) te ontwikkelen en te testen.

Wat hier ook belangrijk is, en vaak vergeten wordt, zijn ondersteunende diensten voor het snel beschikbaar maken van deze omgevingen. Wanneer na een test, een omgeving vervuild is, zal een verse omgeving beschikbaar moeten zijn. Verder zullen alle omgevingen up to date gehouden moeten worden met software updates. In de praktijk zijn hiervoor dus opslagruimte (voor b.v. virtuele images, testdata) en mankracht beschikbaar moeten zijn. Tijdig beschikbaar stellen is in projecten van groot belang omdat, wanneer een omgeving niet beschikbaar is, een deel van het projectteam aan het wachten is. Dit kan voor een project duur uitvallen en deadlines in gevaar brengen.

Delen van applicaties: het Service Application concept en Multi Tenancy SharePoint 2010 biedt de mogelijkheid om sites en applicaties (Service applications) te delen met verschillende gebruikersgroepen. Multi tenancy isoleert de data van verschillende gebruikersgroepen, terwijl de diensten door al deze groepen gebruikt kunnen worden. Diensten kunnen vervolgens centraal worden beheerd en (verschillend geconfigureerd) worden aangeboden aan verschillende gebruikersgroepen (via Web applicaties). Hierdoor onstaat de mogelijkheid om kosten beter (eerlijker) door te berekenen aan deze gebruikers(groepen).

SharePoint biedt standaard al een verzameling Service Applications, voor diverse doeleinden. Dit zijn onder anderen: Search Service, Excel/Word/PowerPoint/Visio Services, Form (InfoPath) Services en Metadata Services (voor het delen van gezamenlijke metadatasets/taxonomieen).

Wanneer het SharePoint platform al als standaard faciliteiten in gebruik is (op de niveau’s 4 en 5: Managed en Optimizing), is de acceptatiegraad van minder belang. Nu zal nadruk gelegd moeten worden op beheersbaarheid, het voorkomen van wildgroei en het gecontroleerd uitbreiden en aanpassen van de SharePoint omgeving en - diensten.

SharePoint biedt voldoende mogelijkheden om gebruik van data en diensten te monitoren en hiermee een basis te bieden om het platform beter af te stemmen op de huidige en toekomstige (voorspelde) behoeften. Hiermee kan onder anderen bepaald worden of gebruikersgroepen signifcant verschillende dienstenniveau’s/pakketten eisen en dit de ontwikkeling van verschillende standaard dienstenniveau’s (pakketten) kan verantwoorden.

Wat onder anderen gemonitored en gestuurd kan worden is:

·         Bezoek van web pagina’s (bezoekstatistieken)

·         Gebruik van web sites (quota)

·         Gebruik van diensten

·         Gebruik van documenten en records (Document – en Record Management, policies, et cetera)

En ook op deze niveau’s hebben veranderingstrajecten als migraties en reorganisaties invloed op de manier waarop naar kosten wordt gekeken en de behoefte aan aanvullende diensten. Door gebruik van diensten en resources te monitoren kan op deze behoeften worden geanticipeerd.

Over de kostenmodellen kan het volgende worden gezegd:

·         Betaling per gebruiker: goede acceptatie omdat SharePoint als standaard is geaccepteerd en de waarde hiervan breed wordt onderkend. Voor dit kostenmodel zal wel een breed geaccepteerd dienstenpakket aangeboden moeten worden.

·         Betaling per website: goed geaccepteerd, maar als onder druk van een veranderingstraject meer web sites moeten worden aangemaakt kunnen deze kosten als te hoog worden gezien. Hierdoor gaan gebruikers  web sites samenvoegen waardoor de beheersbaarheid van het geheel afneemt.

·         Betaling per hoeveelheid opslagruimte: redelijk geaccepteerd, maar kan eveneens als te hoog worden wanneer extra opslag noodzakelijk is bij veranderingstrajecten.

·         Betaling per dienst: geaccepteerd voor diensten waar relatief weinig gebruikers gebruik van maken, nieuwe diensten, diensten waarvoor kosten door de business verder kunnen worden doorberekend of van relatief dure diensten. Diensten die als “vanzelfsprekend” worden gezien kunnen beter niet apart in rekening worden gebracht.

Gebruikers raken op dit niveau gewend aan een bepaald dienstenniveau/pakket dat regelmatig wordt uitgebreid met diensten die niet meer als “bijzonder” maar als “vanzelfsprekend” worden gezien. Een goede afstemming van geleverde pakketten en kosten op de verwachtingen vanuit de organisatie is hier dan ook van belang.

Voorbeelden van standaard dienstenniveau’s (pakketten)Wanneer de ontwikkeling van verschillende dienstenniveau’s/pakketten verantwoord is, kan gedacht worden aan de onderstaande voorbeelden.

Diensten niveau’s/pakketten waarin onderscheid gemaakt wordt tussen basis web site hosting, applicatie hosting en dedicated applicatie hosting:

·         Basis web site hosting: gebruik makend van out-of-the-box SharePoint functionaliteit en een grote mate van content-, functioneel - en gebruikersbeheer door de gebruikers groep (business) zelf.

·         Applicatie hosting: waarin de business de web applicatie zelf beheerd (dus ook deels technisch beheer) en de ICT afdeling de technische infrastructuur (server, databases, operating system, et cetera) beheert;

·         Dedicated applicatie hosting: waarin de infrastructuur (server, databases, operating system, et cetera) grotendeels door de business wordt beheerd.

In de bovenstaande dienstenniveau’s/pakketten wordt de verantwoording over het platform in toenemende mate bij de business (klant) gelegd. Hierover zullen duidelijke afspraken gemaakt moeten worden om verwachtingen vanaf het begin duidelijk te kunnen managen.

Ook kan onderscheid gemaakt worden tussen de niveau’s waarin SharePoint platform kan worden aangepast en uitgebreid:

• Eenvoudige configuratie: aanpassingen van de SharePoint user interface middels de browser.
• Configuratie: aanpassingen van de SharePoint user interface middels SharePoint Designer en InfoPath.
• Branding: verregaande aanpassing van de look en feel van de SharePoint user interface (logos, styles, kleuren, master pages, page layouts, et cetera) op basis van de stijlgids van een organisatie. Hierbij worden masterpages, page layouts et cetera aangepast.
• Custom coding: wijzigen, uitbreiden van de SharePoint functionaliteit of koppelen van SharePoint met andere applicaties en platforms waarbij gebruik wordt gemaakt van developer tools als Visual Studio.

Het onderscheid in de bovenstaande niveau’s is gebaseerd op het risico dat wordt genomen bij de door te voeren wijzigingen. Risico’s worden bijvoorbeeld gelopen doordat aanpassingen bij migraties moeten worden overgedaan, aanpassingen de stabiliteit en performance van het platform kunnen beïnvloeden en bepaalde aanpassingen niet door Microsoft worden ondersteund.

Microsoft hanteert voor de eigen SharePoint platforms de volgende dienstenniveau’s, waarbij onderscheid gemaakt wordt op basis van de aanpassingen en uitbreidingen die op het platform kunnen worden uitgevoerd (“Microsoft Office SharePoint Server 2007 Hosting”, Technical White Paper, http://technet.microsoft.com/en-us/library/bb735197.aspx).

Silver tier:

·         Supports thousands of customers per server.

·         Allows no server-side customizations.

·         Hosts the utility service at no charge but limits the amount of supported storage.

Gold tier:

·         Hosts several customers on the same hardware but provides isolation via application pools for each customer.

·         Permits some customization on the platform.

·         Distributes the costs of hardware and hosting across customers.

Platinum tier:

·         Hosts dedicated hardware for one or many properties owned by a single business team at Microsoft.

·         Offers the maximum support for server-side customization.

·         Is generally represented by high-value Web properties within the company.

Voor veranderingstrajecten en projecten als migraties, kunnen aanvullende dienstenpakketten worden aangeboden. Voor migraties valt hierbij bijvoorbeeld te denken aan:

Basispakket:

·         Analyse van de migratiebehoefte en de impact die de migratie op de betreffende SharePoint omgeving(sdeel) heeft.

·         Automatische migratie met gestandaardiseerde migratietools, tools die door de ICT afdeling zijn voorgeselecteerd;

·         Beschikbaar stellen van aanvullende diensten als tijdelijke opslagruimte voor content tijdens migraties;

·         Eerstelijns ondersteuning voor handmatige migratie, van bijvoorbeeld aanpassingen aan configuraties en content migratie;

·         Training voor eindgebruikers en functioneel – en gebruikersbeheerders;

·         Ondersteuning van een gebruikers / super user / beheerders community voor het delen van kennis en ervaring;

·         Uitvoeren van audits om de kwaliteit van de migratie te meten en op basis hiervan advies te geven voor verbetering hiervan.

Voorbeelden van aanvullende diensten:

·         Migratie van aanpassingen die niet zondermeer door de klant kunnen worden uitgevoerd. Te denken valt hierbij aan migratie van maatwerk;

·         Ondersteuning van het gebruik van aanvullende migratietools;

·         Dedicated ondersteuning voor handmatige migratie, van bijvoorbeeld aanpassingen aan configuraties en content migratie. In concreto: het detacheren van ICT medewerkers bij de klant;

·         Aanvullende training voor eindgebruikers en functioneel – en gebruikersbeheerders, voor specifieke taken en specifieke functionaliteit.

SharePoint in de CloudWat ook overwogen kan worden is Microsoft SharePoint Online for Enterprises, een online cloud dienst van Microsoft, waarbij SharePoint 2010 door Micosoft gehost wordt aangeboden. De dienst kent ten opzichte van eigen hosting wel wat beperkingen, maar kan in kostenopzicht interessant zijn.

Samenvattend…

In dit artikel wordt grofweg weergegeven wat de voor en nadelen zijn van de kostenmodellen in verschillende situaties. De acceptatie en doeltreffendheid van bepaalde kostenmodellen hangt echter af van de manier waarop SharePoint wordt gebruikt in een organisatie en wat met kostendoorberekenen bereikt moet worden.

Initieel kunnen de kosten het beste laag gehouden worden om de acceptatiegraad van Sharepoint niet te verlagen.

Naarmate SharePoint gebruik volwassener wordt zal het kostenmodel verfijnd moeten worden om kostendoorberekening te kunnen verantwoorden en tot een eerlijker verdeling te komen.

Hierbij moet rekening gehouden worden met het belang dat SharePoint functionaliteit en de daaropgebaseerde applicaties en content heeft in een organisatie, hetgeen direct samenhangt met de waarde van de processen en informatie die door SharePoint worden ondersteund voor een organisatie.

Ook kan rekening gehouden worden met verschillen in het gebruik van SharePoint door verschillende gebruikersgroepen (differentiatie); aan deze verschillende groepen kunnen verschillende diensteniveau’s/pakketten worden aangeboden die op verschillende manieren kunnen worden doorberekend.

Voor veranderingstrajecten als migraties kunnen aanvullende diensten worden aangeboden die apart verrekend kunnen worden.

In het onderstaande overzicht worden de verschillende mogelijkheden compact weergegeven, samen met de verwachtte mate van acceptatie ervan.

Kostenmodel: Volwassenheidsniveau:	Betaling per:
	Gebruiker	Website/Site Collectie/Web applicatie	Hoeveelheid opslagruimte	Dienst	Dienstenpakket
1: Inital (chaos en ad hoc)	--	-	-	-	N.v.t.
2: Repeatable (op basis van ervaringen)	-	+/-	+/-	+/-	N.v.t.
3: Defined (standaardisatie)	+/-	+/-	+/-	+/-	+
4: Managed (kwaliteit wordt gemeten)	+	+	+	+	+
5: Optimizing (fijnafstemming van een goed geoliede machine)	++	++	++	++	++