Styring af SharePoint, der bliver fulgt

En styringsplan for SharePoint bliver typisk skrevet som et dokument: navngivning, hvem der må oprette websteder, hvordan rettigheder gives, hvornår et websted skal lukkes. Dokumentet er grundigt og bliver lagt i et bibliotek. Derefter opretter folk websteder, som de plejer, deler, som de plejer, og giver adgang til den kollega, der spurgte. Planen er ikke forkert. Den står bare et andet sted end der, hvor arbejdet foregår.

De regler, der bliver fulgt, er dem, der ikke kræver, at nogen husker dem. De sidder i den vej, folk alligevel går: bestillingen af et nyt websted, flowet der opretter det, skabelonen, listen over kolonner, indstillingen i administrationscenteret. Så er reglen ikke noget, der skal læses. Den er det, der sker.

Bygget ind i bestillingen#

Da jeg i 2023 byggede selvbetjening til nye websteder, stod reglerne ikke i et dokument. De stod i en konfigurationsliste med én række pr. webstedstype: hvilken skabelon webstedet bygges fra, hvilket præfiks adressen får, og hvilke grupper der får hvilke rettigheder. Den, der bestiller, vælger en type og skriver et navn. Navngivningen, skabelonen og rettighederne følger med, uden at nogen skal slå dem op. Skal en regel ændres, ændres en række i listen, og næste websted følger den nye.

Oprettelsen selv står i Opret et websted med Power Automate og SPSiteManager.

Ens lister, fordi de kommer fra samme sted#

Kolonner og lister, der skal være ens på flere websteder eller i udvikling, test og produktion, bliver ikke ens, fordi det står i en vejledning. De bliver ens, når de oprettes fra samme beskrivelse. I Lister og kolonner fra et Excel-ark med PnP PowerShell er beskrivelsen et regneark, og scriptet opretter, retter og sletter, så webstedet svarer til arket. Indholdstyper fra content type hub’en er samme tanke, med de forhindringer der står i Indholdstyperne fra hub’en kom ikke længere af sig selv.

Rettigheder til grupper, givet af flowet#

En regel, jeg har skrevet før, er at give adgang til grupper og ikke til personer, og at unikke rettigheder skal være undtagelsen (Unikke rettigheder på en mappe i SharePoint). Den holder bedst, når det ikke er et menneske, der giver adgangen. Et flow eller et script, der giver rettigheder ud fra en kolonne eller en konfiguration, giver dem ens hver gang (Bryd og ret rettigheder på et listeelement med Power Automate, Sæt mapperettigheder ud fra metadata med PowerShell).

Det, Microsoft selv kan håndhæve#

Noget af det, der før kun kunne stå i en plan, kan i dag slås til:

• Navngivning af Microsoft 365-grupper. En navnepolitik i Entra ID sætter præfiks eller suffiks på gruppens navn og alias og kan blokere ord. Den gælder for grupper oprettet fra Teams, SharePoint, Outlook og Planner, men ikke for globale administratorer og brugeradministratorer, og den kræver Entra ID P1 for medlemmerne af grupperne.
• Websteder uden ejere og websteder, ingen bruger. Site lifecycle management i SharePoint Advanced Management har politikker for ejerskab, inaktivitet og attestering: ejerne får besked en gang om måneden i tre måneder, og svarer ingen, kan webstedet sættes til skrivebeskyttet og efter en periode arkiveres med Microsoft 365 Archive. Politikkerne sletter ikke selv websteder. Advanced Management følger med Microsoft 365 Copilot-licenser eller købes som tilføjelse.

Det, der stadig skal skrives ned#

Dokumentet forsvinder ikke helt. Nogen skal stadig beslutte, hvem der ejer hvad, hvad der er fortroligt, og hvor længe noget skal gemmes. Men det er få beslutninger, og de kan stå på en side. Resten er ikke tekst, men opsætning: en konfigurationsliste, et regneark med kolonner, et flow, en politik. Hver regel, der flyttes fra dokumentet ind i opsætningen, er en regel mindre, som nogen skal huske.

Et sted at begynde er de to eller tre regler, der koster mest, når de brydes, bygget ind, så de ikke kan springes over. En kort plan, der bliver fulgt, gør mere end en lang, der bliver læst én gang.