Kort svar
Når SharePoint-lageret vokser, bør I ikke begynde med at købe mere plads eller slette filer tilfældigt. Find først ud af, om væksten kommer fra bestemte sites, dokumentbiblioteker, store filer eller versionshistorik. Vurder derefter, hvilke versioner og data virksomheden fortsat skal kunne gendanne.
Hvis I nærmer jer kapacitetsgrænsen, kan Azure Automation bruges til en planlagt kontrol og en proaktiv alarm. Overvågningen bør være adskilt fra oprydningen: Et runbook må gerne advare, men bør ikke automatisk slette versioner eller ændre politikker uden en særskilt beslutning.
1. Find først ud af, hvad der vokser
Start bredt og arbejd jer ned gennem miljøet:
- Se tenantens samlede forbrug, tilgængelige plads og udvikling over tid.
- Sortér de aktive sites efter lagerforbrug og ændring.
- Undersøg de største sites på biblioteks-, fil- og versionsniveau.
- Adskil aktivt indhold, inaktive sites, slettede sites og eventuelt arkiveret indhold.
- Sammenhold observationerne med versionspolitikker, retention og virksomhedens krav til gendannelse.
Microsofts SharePoint Storage-rapport viser tenantens forbrug, kvote og væksttrend. Rapporten er velegnet til overblik, men ikke til hele årsagsanalysen. Microsoft peger også på aktive sites, versionsforbrug og mere detaljerede datasæt som relevante kilder i sin vejledning om SharePoint-lager.
En stor site collection er ikke nødvendigvis problemet i sig selv. Det kan være et enkelt aktivt bibliotek med store, hyppigt redigerede filer og mange versioner. Derfor er den praktiske rækkefølge vigtig: tenant → site → bibliotek → fil → version.
2. Versionshistorik kan være den skjulte lagerpost
SharePoint gemmer tidligere versioner, så brugere kan gå tilbage efter fejl eller uønskede ændringer. Det har reel gendannelsesværdi, men mange versioner af store og ofte ændrede filer kan også optage betydelig plads.
Microsoft beskriver tre overordnede modeller for versionsgrænser:
- Automatiske grænser, hvor ældre versioner udtyndes over tid.
- Manuelle grænser med udløb, hvor både antal og alder styrer, hvad der beholdes.
- Manuelle antalsgrænser uden udløb, som kan give et mere forudsigeligt antal versioner, men også et højt lagerforbrug.
Der findes ikke én rigtig grænse for alle biblioteker. Et område med kritiske dokumenter kan have andre gendannelseskrav end et midlertidigt projektområde. For lave grænser kan fjerne nyttige gendannelsespunkter; for høje grænser kan fastholde unødigt meget data.
Microsoft anbefaler at vurdere effekten, før politikken ændres. Når eksisterende versioner skal fjernes, bliver trimningen lagt i kø som et job, der permanent sletter de berørte versioner. Det er altså en anden handling end blot at ændre standarden for nye biblioteker.
3. Hvorfor er pladsen ikke faldet efter 24 timer?
Manglende ændring efter ét døgn betyder ikke automatisk, at oprydningen er mislykket.
Der er mindst to tidsforløb at holde adskilt:
- Selve trimningen af eksisterende versioner behandles som et baggrundsjob.
- SharePoint Storage-rapporten opdateres ifølge Microsoft normalt hver 48.–72. time.
Det gør rapportens dato lige så vigtig som det tal, der står i den. Kontrollér derfor:
- om trimjobbet er oprettet og har nået den forventede status;
- hvilken rapportdato eller opdateringstid den viste måling har;
- om I ser på tenant-, site- eller biblioteksniveau;
- om retention eller Preservation Hold påvirker det indhold, I forventede at fjerne;
- om nyt indhold eller nye versioner samtidig har øget forbruget.
Microsoft oplyser særskilt, at lageropgørelsen efter sletning af et helt site kan være op til 48 timer om at blive opdateret. Det udsagn bør ikke bruges som en generel garanti for versionstrimning. Der er heller ikke belæg for at love, at enhver trimning bliver synlig efter præcis 24 eller 48 timer.
4. Indbygget advarsel eller proaktiv overvågning?
SharePoint Storage-rapporten viser en banneradvarsel, når forbruget overstiger 80 procent af kvoten. Det kan være tilstrækkeligt, hvis en ansvarlig administrator allerede gennemgår rapporten regelmæssigt og har en dokumenteret proces.
En proaktiv alarm er mere relevant, når:
- ingen logger ind i administrationscenteret på en fast rytme;
- flere personer skal orienteres, før pladsen bliver kritisk;
- udviklingen skal logges og følges over tid;
- tærskel, ansvar og opfølgning skal være en gentagelig driftsproces.
En alarm løser dog ikke lagerproblemet. Den skaber reaktionstid. Organisationen skal stadig beslutte, om næste handling er analyse, ændring af versionspolitik, arkivering, oprydning eller køb af mere kapacitet.
5. Sådan kan Azure Automation-modellen se ud
En enkel arkitektur kan beskrives sådan:
Tidsplan → Azure Automation-runbook → managed identity → godkendt datakilde → tærskelberegning → notifikation og kørselslog
Tidsplan og runbook
Azure Automation kan knytte et runbook til en tilbagevendende tidsplan. Intervallet bør passe til rapportens opdateringsfrekvens og virksomhedens reaktionstid. Hyppige kørsler giver ikke friskere data, hvis kilderapporten endnu ikke er opdateret.
Managed identity frem for en gemt hemmelighed
Runbooket kan autentificere med en system- eller brugertildelt managed identity. Det betyder, at løsningen ikke behøver et klientsecret eller certifikat gemt i selve scriptet. Både Microsofts runbook-eksempel og PnP PowerShells vejledning beskriver denne model.
Managed identity fjerner ikke behovet for adgangsstyring. Identiteten skal fortsat have præcis de nødvendige applikationsrettigheder, og de bør gennemgås som en del af den almindelige governance.
Datakilde og 80-procentberegning
Microsoft Graphs SharePoint storage usage-rapport kan levere en trend for anvendt lager og understøtter perioderne 7, 30, 90 og 180 dage. Den mindst privilegerede Graph-tilladelse til rapporten er Reports.Read.All for både delegeret adgang og applikationsadgang.
Rapporten leverer lagerforbruget, men ikke nødvendigvis hele kvotegrundlaget til en procentberegning. Runbooket skal derfor hente både aktuelt forbrug og den relevante tenantkvote fra godkendte kilder, kontrollere enheder og rapportdatoer og derefter beregne:
forbrugsprocent = anvendt lager / samlet kvote × 100
Hvis PnP PowerShell eller SharePoint-administration bruges til andre dele af målingen, skal rettighederne vurderes særskilt. Et bredt eksempel som Sites.FullControl.All er ikke et fornuftigt standardvalg til en læsebaseret lageralarm.
Alarm, gentagelser og fejl
En brugbar overvågning bør mindst håndtere:
- en tydelig tærskel og den måling, tærsklen bygger på;
- modtagere og ansvar for næste handling;
- gentagelsesbegrænsning, så samme tilstand ikke sender unødige alarmer;
- log af måling, rapportdato, beregning og notifikation;
- særskilt alarm ved manglende data, udløbne rettigheder eller fejl i runbooket;
- test af både normal drift og fejlsituationer.
Hvis runbooket ikke kan hente en gyldig måling, bør det rapportere en overvågningsfejl frem for at antage, at forbruget er nul.
6. En sikker rækkefølge for oprydning og overvågning
Brug denne rækkefølge som arbejdsmodel:
- Dokumentér den nuværende kvote, rapportdato og væksttrend.
- Find de sites, biblioteker, filer og versioner, der driver væksten.
- Aftal krav til gendannelse, retention og undtagelser med dataejerne.
- Vurder effekten af nye versionsgrænser, før eksisterende versioner trimmes.
- Kør oprydning som en kontrolleret, separat ændring.
- Vent på job- og rapportopdatering, og verificér resultatet mod en ny dateret måling.
- Etablér først derefter en tærskelalarm med tydeligt ansvar og fejlhåndtering.
På den måde bliver automatiseringen en del af en driftsproces i stedet for et script, der blot sender endnu en mail.
Ofte stillede spørgsmål
Hvorfor bruger SharePoint mere lagerplads end forventet?
Væksten kan komme fra aktive sites, store filer, mange filversioner, inaktive områder eller regler for opbevaring. Start med tenantens udvikling og de største sites, før du ændrer eller sletter noget.
Hvorfor falder lagerforbruget ikke 24 timer efter versionstrimning?
Versionstrimning køres som et baggrundsjob, og Microsofts SharePoint Storage-rapport opdateres normalt hver 48.–72. time. Der findes derfor ikke en generel 24-timers garanti for, hvornår ændringen kan ses.
Kan Azure Automation advare ved 80 procent?
Ja. Et planlagt runbook kan hente godkendte målinger, beregne forbruget mod kvoten og sende en notifikation. Datakilde, rettigheder, fejlhåndtering og rapporternes opdateringsfrekvens skal være afklaret først.
Skal overvågningen også slette gamle versioner automatisk?
Som udgangspunkt nej. Hold overvågning og sletning adskilt. Ændringer i versionspolitikker og permanent trimning bør godkendes særskilt ud fra krav til gendannelse og opbevaring.
Få et overblik over jeres SharePoint-lager
ALCO kan hjælpe med at kortlægge lagerforbruget, vurdere versionspolitikker og etablere en overvågningsmodel, der passer til jeres ansvar og behov.
Bo Diechmann
CEO
