Det gamle SharePoint CDN-domæne: find hardkodede referencer

SharePoint Online har to offentlige CDN-domæner, der kun adskiller sig ved en bindestreg: publiccdn.sharepointonline.com er det gamle, public-cdn.sharepointonline.com det nye. Flytningen til det nye blev meldt den 1. maj 2025 og var færdig i juli 2025. Den 12. november 2025 meldte Microsoft, at det gamle domæne udfases fra 31. marts 2026, og at indhold, der stadig peger dertil, giver 404 (MC1184996). Her er, hvad der er meldt, hvem det rammer, og hvor referencer til det gamle domæne kan findes. Forløbet står også i månedsnoterne for maj 2025 og november 2025.

Forløbet#

1. 1. maj 2025

   Meldt som Important update: SharePoint Online-aktiver flyttes til Azure Front Door med det nye domæne. Udrulning fra begyndelsen af juni til sidst i juli 2025

   Kilde: MC1066155

2. Juni til juli 2025

   Udrulningen. Roadmap-posten står som Launched med generel udrulning i juni 2025, og MC1184996 skriver, at flytningen var færdig i juli 2025

   Kilde: Roadmap 489230, MC1184996

3. 12. november 2025

   Det gamle domæne meldes udfaset. Udrulningen begynder 31. marts 2026 og er færdig sidst i april 2026. Opslaget har 30. marts 2026 som handlingsfrist

   Kilde: MC1184996

4. 8. januar 2026

   Opslaget opdateret som påmindelse. Datoerne er uændrede

   Kilde: MC1184996

Datoerne i MC1184996 er ikke flyttet. Opslaget er ikke ændret siden 8. januar 2026 ifølge versionshistorikken (versionshistorik), og der er ikke fundet nogen senere melding om udsættelse eller om, at udfasningen er gennemført. Om det er sket, er uvist.

Hvem det rammer#

Microsoft nævner tre grupper (MC1184996):

• Programmer, scripts og konfiguration, der har det gamle domæne skrevet ind.
• SPFx-løsninger med en hardkodet cdnBasePath.
• Administratorer med domænebaserede tilladelseslister i netværket. Her skal det nye domæne være med.

Det, der sker, er, at indhold hentet via det gamle domæne giver 404. De samme ressourcer findes uændret på det nye. Microsoft skriver, at fejlen ikke er datatab, kun at adgangsvejen er ændret (samme opslag).

Hvem det ikke rammer#

• SPFx-løsninger med automatisk hosting. Microsoft skriver, at cdnBasePath ikke må hardkodes, hvis aktiverne hostes automatisk via Microsoft 365 Public CDN. Værdien skal stå som pladsholderen "<!-- PATH TO CDN -->" (MC1184996, Microsoft). Med includeClientSideAssets slået til i package-solution.json (standard) pakkes aktiverne i .sppkg-filen og hostes enten fra CDN’et, hvis det er slået til, eller fra mappen ClientSideAssets på appkatalog-webstedet (Microsoft).
• SPFx-løsninger på et eksternt CDN. Her er cdnBasePath en adresse til for eksempel Azure CDN, og den må gerne ændres (MC1184996).
• Tenants uden offentligt CDN slået til. Her hostes SPFx-løsningernes aktiver fra mappen ClientSideAssets på appkatalog-webstedet i stedet (Microsoft).

Hvor hardkodede referencer kan findes#

Microsoft anbefaler at gennemgå programmer, scripts og konfiguration for referencer til publiccdn.sharepointonline.com, og at tjekke netværkstrafikken. Microsoft foreslår også at blokere det gamle domæne bevidst for at se, om alt stadig virker (MC1184996).

En reference til det gamle domæne kan stamme fra en adresse, der er bygget i hånden. Learn skriver, at en CDN-adresse til offentlige aktiver kan konstrueres som https://public-cdn.sharepointonline.com/<TenantHostName>/sites/site/library/asset.png, men at præfikset ikke må hardkodes, fordi det kan ændre sig. I stedet skal det hentes fra sidens kontekst: window._spPageContextInfo.publicCdnBaseUrl i klassiske visningsskabeloner og this.context.pageContext.legacyPageContext.publicCdnBaseUrl i SPFx (Microsoft). Hvor præfikset er skrevet ud i stedet for hentet, kan det gamle domæne stå.

Steder at søge:

1. Kildekode og konfiguration. SPFx-projekternes config/write-manifests.json med cdnBasePath, men også scripts, stilark, JavaScript og HTML, hvor adressen er skrevet ind.
2. Installerede løsningspakker. Findes kildekoden ikke længere, kan .sppkg-filen hentes fra appkataloget og pakkes ud. Filen er et zip-arkiv, og cdnBasePath ligger i manifesterne i den. Fremgangsmåden er beskrevet i et svar på Microsoft Q&A (Microsoft Q&A), som er en sekundær kilde.
3. Netværksloggene. Forespørgsler til det gamle domæne i proxy- eller firewallloggen viser, hvem der stadig bruger det (på linje med Microsofts forslag om at følge trafikken).

 1# Search a local folder (source code, scripts, exported configuration)
 2Get-ChildItem -Path .\src -Recurse -File |
 3    Select-String -Pattern 'publiccdn\.sharepointonline\.com' |
 4    Select-Object Path, LineNumber, Line
 5
 6# A .sppkg is a zip file: unpack a copy and search it
 7Copy-Item .\my-solution.sppkg .\my-solution.zip
 8Expand-Archive .\my-solution.zip -DestinationPath .\my-solution-unpacked
 9Get-ChildItem -Path .\my-solution-unpacked -Recurse -File |
10    Select-String -Pattern 'publiccdn\.sharepointonline\.com' |
11    Select-Object Path, LineNumber

Rette dem#

Microsoft skriver, at de berørte dele skal bruge understøttede og dynamiske endpoints, altså ikke blot et nyt domæne skrevet ind på samme måde (MC1184996). For SPFx betyder det pladsholderen i cdnBasePath. For egen kode betyder det publicCdnBaseUrl fra sidens kontekst, som beskrevet ovenfor.

Svaret på Microsoft Q&A foreslår, for en pakke uden kildekode, at ændre publiccdn til public-cdn i manifesterne og uploade pakken igen i appkataloget (Microsoft Q&A). Det peger på det nye domæne, men er stadig en hardkodet adresse, og Learn skriver, at CDN-adressen kan ændre sig (Microsoft).

Tilladelseslister#

I opslaget fra 1. maj 2025 bad Microsoft om tre ting: at tilføje det nye domæne til tilladelseslisterne, at undlade at hardkode CDN-adresser og at holde det gamle domæne åbent, indtil Microsoft meldte andet (MC1066155). Opslaget fra 12. november 2025 er den senere melding om det gamle domæne, og her står kun, at det nye skal med på listerne (MC1184996). Om det gamle kan tages af listerne, når udfasningen er gennemført, siger opslagene ikke.

Faldgruber#

• Fejlen sidder i de enkelte aktiver. Brugerne får 404 på aktiver, der hentes fra det gamle domæne (MC1184996). Selve siden hentes fra SharePoint som før, så en webdel eller et billede kan mangle, uden at siden fejler. Det sidste er en følge og ikke noget, Microsoft skriver.
• Et CDN-link kan ikke afprøves direkte i en browser. Der kræves en henvisning (referer) fra SharePoint Online. Linket virker, når det står på en SharePoint-side (Microsoft). Den 8. oktober 2026 svarede det nye domæne en forespørgsel uden henvisning med en omdirigering til AccessOutsideSharePointIsNotAllowed, og det gamle domæne svarede 403 på rodadressen (kontrolleret med curl). Det siger ikke noget om, hvorvidt indholdet på det gamle domæne er fjernet.
• Domænet kan ligge i SPFx-pakkerne. Efter pakning står cdnBasePath i manifesterne i .sppkg-filen (Microsoft Q&A), så en løsning, der blev bygget med en hardkodet adresse, bærer den med sig, til den bygges og uploades igen.
• Datoen er forbi. Fristen i opslaget var 30. marts 2026 og udrulningen 31. marts til sidst i april 2026. Er referencerne ikke fundet endnu, er det netværksloggen og brugernes fejlmeldinger, der viser dem.