Problemet

Jeg så samme mønster i migrering fra Windows 10 til Windows 11: noen enheter flyttet seg, andre ble stående igjen, og årsakene så tilfeldige ut.

Det første jeg prøvde var å sjekke maskinvare-eligibility alene. Det var ikke nok.

Rotårsaken var tre kontrollfeil blandet sammen:

  1. Tildelingsfeil: Windows-servicing var avhengig av brukerkontekst.
  2. Livssyklusfeil: utdaterte eller delte objekter mellom Intune, Autopilot og Entra ID.
  3. Eligibility-feil: noen enheter var ikke Windows 11-kompatible.

Den effektive løsningen var å behandle Windows-livssyklus som et enhetsproblem, ikke et brukerproblem.

Rammer

  • Blandet enhetsflate: enheter med primærbruker, delte enheter og enheter med svak bruker-affinitet.
  • Eldre tildelingsmodell der update rings var knyttet til brukergrupper.
  • Livssyklusdrift mellom Intune-, Autopilot- og Entra ID-objekter.
  • Maskinvaremiks med både Windows 11-klare og ikke-støttede enheter.

Beslutning

I denne migreringen flyttet jeg kontrollplanet for servicing til enhetsgrupper:

  • Update rings -> enhetsgrupper
  • Windows 11 feature update policy -> enhetsgrupper
  • Brukergrupper beholdes kun for bruker-kontekst (apper/innstillinger), ikke OS-versjonskontroll

Dette følger Microsofts anbefaling om at update rings bør tildeles enhetsgrupper, slik at policy kan gjelde uten å vente på brukerinnlogging.

Implementering

1. Stabiliser målretting først

I Intune admin center -> Devices -> Devices overview, bygde jeg opp servicing-tildelingene på nytt som enhetskohorter.

Eksempel på kohortmønster:

  • W11-Pilot-Devices
  • W11-Broad-Devices
  • W10-Unsupported-Devices
  • W11-Stale-Orphaned-Devices
  • W11-Shared-NoPrimaryUser-Devices

Dette er kun eksempelnavn. Bruk egen navnestandard, men hold segmenteringen tydelig.

2. Bruk Feature Update Policy som versjonsautoritet

Jeg sluttet å stole på at rings alene “til slutt” skulle tilby Windows 11.

I Intune admin center:

  1. Gå til Devices -> Windows -> Feature updates for Windows 10 and later
  2. Opprett policy som peker på ønsket Windows 11-versjon
  3. Tildel først pilot-kohort, deretter bred kohort
  4. Ekskluder ikke-støttet maskinvarekohort

Dette gir eksplisitt versjonsstyring og rapportering av blokker som safeguard hold.

3. Bygg en triagematrise for alle enheter som ikke oppgraderer

Hver enhet som ikke flytter seg skal havne i én status:

  • Ikke målrettet
  • Målrettet, men ikke eligible
  • Målrettet, men blokkert av safeguard hold
  • Målrettet, men blokkert av app/driver-kompatibilitet
  • Utdatert/duplikat/foreldreløst objekt
  • Provisioning-/bruker-affinitetsforsinkelse

Jeg brukte Windows update-rapporter i Intune for å tvinge frem denne klassifiseringen, i stedet for å gjette.

4. Behandle “ingen primærbruker” som datasignal

En enhet kan være fullt Intune-administrert og fortsatt mangle nyttig primærbruker-relasjon for brukerbaserte policyer.

Jeg håndterte dette som datakvalitet, ikke servicing-avhengighet:

  • Hold servicing-tildelinger enhetsbaserte
  • Gå gjennom delte/reimaged/reassignede enheter for affinitetskvalitet
  • Ikke gjør oppgraderingsstyring avhengig av perfekt primærbruker-data

5. Rydd livssyklusobjekter i riktig rekkefølge

For utrangerte/erstattede enheter er rekkefølgen viktig:

  1. Hvis fysisk enhet fortsatt er i drift, stopp og valider management state først.
  2. Hvis enheten er utrangert/erstattet og finnes i Intune: retire/delete i Intune.
  3. Hvis Autopilot-objekt finnes: deregister/delete Autopilot-objekt.
  4. Hvis stale Entra-objekt gjenstår: disable, deretter delete Entra-enhet.
  5. Ha Intune cleanup rules aktivert for å redusere stale Intune-only objekter.

Viktig: Intune cleanup rules rydder ikke Entra ID- eller Autopilot-objekter.

6. Legg ikke-støttet maskinvare i eget felt

Ikke-støttede Windows 10-enheter ble flyttet til en dedikert kohort:

  • Ekskludert fra Windows 11 feature update policy
  • Holdt på støttet Windows 10-servicing
  • Eksportert til utskiftningsliste (modell, serienummer, tildelt eier/bruker, avdeling)

Da gikk vi fra en uklar “noen enheter sitter fast”-situasjon til en konkret utskiftningsprosess.

Målbar effekt

Etter at servicing ble enhetsbasert:

  • Oppgraderingsintensjon ble forutsigbar for både personlige og delte enheter.
  • Rapportene skilte tydelig mellom ikke-støttet, blokkert, ikke målrettet og stale-objekter.
  • Opprydding ble en prosess, ikke ad-hoc arbeid.

Den viktigste gevinsten var operasjonell klarhet: hver enhet fikk ett felt og én neste handling.

Avveininger og fallgruver

  • Policy virker ikke umiddelbart etter provisioning. Gruppemedlemskap og Windows Update-evaluering trenger fortsatt tid.
  • Safeguard holds er legitime tjenestebeskyttelser. Overvåk dem i stedet for å omgå dem.
  • Feil oppryddingsrekkefølge kan gi ghost records og feil eierforhold.
  • Hold spesialenheter/kiosk/delte profiler bevisst ekskludert der det trengs.

Valideringssjekkliste

  • 100 % av Windows servicing-policyer er tildelt enhetsgrupper (ikke brukergrupper)
  • Hver Windows 10-enhet ligger i nøyaktig ett felt: Ready, Blocked, Unsupported eller Stale
  • Intune-rapportering forklarer alle enheter som ikke oppgraderer
  • Ikke-støttede enheter er ekskludert fra W11-targeting og synlige i utskiftningsliste
  • Antall stale objekter går ned over tid i Intune, Autopilot og Entra ID

Drift og rollback

Drift

  1. Start med én pilot-kohort.
  2. Bruk faseutrulling etter at pilot-helse er ren.
  3. Overvåk safeguard holds og deploy-feil i feature update-rapportene.

Rollback

  1. Fjern berørt enhetskohort fra Windows 11 feature update policy.
  2. Behold update ring-baseline.
  3. Legg berørte enheter tilbake i Windows 10-servicingkohort ved behov.

Relaterte lenker