Site eller en site collection? Thats the question

Jeg kommer i rigtig mange virksomheder hvor jeg ser hele intranettet proppet ned i en site collection. Det er ikke særlig hensigtsmæssigt, denne post forklarer hvorfor.

Det handler om administrative niveauer, altså steder med settings som gør at man kan differentiere funktionalitet og muligheder i SharePoint. En liste over de administrative niveauer vil se ud som følger:

Farm
Web application
Site Collection
Site / Web

Hvis vi kigger nærmere Site collection og laver en hurtig liste over funktionalitet der styres fra Site Collection settings, så vil den se ud som nedenstående:

• Rettigheder - Rettighedsgrupper oprettes og kan ses per Site Collection, Hvis man kun har 1 Site Collection i virksomheden, så vil man typisk opleve at have alt for mange rettigehedsgrupper og brugerne bliver forvirrede. Man skal huske at hver gang en bruger vælger at et subsite skal have unikke rettigheder, så oprettes der typisk 3 nye rettighedsgrupper. Dvs. at har man 500 subsites med unikke rettigheder, så viser oversigten 1500 grupper at vælge imellem! Helt håbløst for slutbrugeren
• Caching - Hvis man vil styre caching så er det en feature der skal aktiveres per Site Collection (Publishing Infrastructure)
• Content Types - Også Content Types styres per Site Collection. Godt nok kan man publicere dem på tværs af web applications og endda farms med Content Type Hubs gennem Managed Metadata Service Application, men hvis man vil differentiere Content Types gennem sin farm, er man nød til at have mange Site Collections.
• Automatisk sletning - af indhold som ikke bruges længere sker på Site Collection niveau gennem central administration.
• Managed Paths - er meningsløse med kun en Site Collection. managed paths kan give virksomheden en sund og meningsfuld URL struktur. 
• Search - kan konfigureres på Site Collection niveau, man kan bygge og tilbyde unikke scopes, keywords og best bets i Site Collections.
• Recycle Bin - Papirkurven er per Site Collection.
• Workflows - en række af SharePoints indbyggede workflows aktiveres per Site Collection.
• Site Collection Features - er den måde du grundlæggende styrer hvilken funktionalitet dine brugere tilbydes er per Site Collection. For eksempel den helt centrale SharePoint Server Publishing Infrastructure. Men også document sets, documet ID's og hele Business Intelligence (PerformancePoint) delen aktiveres per Site Collection.

Der er flere, det her var bare nogle af dem som kan gøre mest ondt ikke at kunne differentiere gennem sin installation. Hvad værre er, er at SharePoint kan få dårlig Performance af en struktur hvor du kun har en Site Collection.

SharePoint 2010 har en anbefalet max database størrelse på 200GB. Hvis denne overskrides kan man opleve et performancetab. Måden man regulerer database størrelsen på er ved at tilføje nye databaser og så flytte site collections ind i dem. Med en arkitektur hvor du kun har en Site Collection så er det jo af indlysende grunde vanskeligt at flytte "nogle" af dine Site Collections da der kun er 1. Site Collection.

Der er også udfordringer med mange Site collection. Man bliver indtil SharePoint 2010 nød til at finde en løsning på navigationen i virksomheden. For Microsoft har ikke leveret "Cross Site Navigation" med i pakken. Det betyder at man ikke i top navigationen er i stand til at vise andre site collections. Mange virksomheder har løst det med at for kodet en menulinie som altid er synlig i toppen af deres installation. I SharePoint 2013 er problemet løst, da Microsoft har gjort det muligt at anvende Managed Metadata som navigation. Jeg har skrevet et blogindlæg her:

SharePoint 2013 - True Global navigation using Managed Metadata

Du kan også komme ud for at udviklere græder over det er besværligt at installere deres løsninger, hvis det er tilfældet må du fortælle dem at de må lære lidt PowerShelll. Powershell kan løse dette men kan også gøre en masse andre ting for dig hvis du vælger en sund arkitektur med mange Site collections, fordi PowerShell er et Powertool til at lave Bulk operationer i SharePoint.

Afsluttende vil jeg bemærke at en stor del af forvirringen kommer fra to kilder. Den første er at microsoft ikke har orden i nomenklaturen. Når man vil lave et subsite også kaldet et web som så skal man klikke på "NEW SITE" i Site Actions menuen. Site er ellers den normale betegnelse for Site Collection. Hvis du netop åbner PowerShell konsollen, så er PowerShell teamet faktisk de eneste som har været konsistente i anvendelsen af Site = Site Collection og Web = Subsite.

Enjoy
Morten Reintoft
http://reiners.dk