Windows Autopilot Vianmääritys 2026 Opas

Päivitetty: 12. heinäkuuta 2026

Windows Autopilot -käyttöönoton vianmääritys 2026 alkaa lähes aina Enrollment Status Page (ESP) -lokien lukemisesta, koska yli 70 % epäonnistuneista käyttöönotoista kaatuu joko laitteen esirekisteröintiin, ESP-timeouttiin tai Intune-käytäntökonfliktiin. Tässä oppaassa käyn läpi yleisimmät virhekoodit (0x80070490, 0x800705B4, 0x8018002A), uuden Autopilot Device Preparation -mallin diagnostiikkavaiheet, hybridin Autopilot-käyttöönoton poistumisen aikataulun sekä ne mittarit, joilla mittaan tiimimme MTTR:ää ja ensikäyttäjän aikaa tuottavaan laitteeseen.

Autopilot Device Preparation (aiemmin Autopilot v2) on Microsoftin suositeltu käyttöönottotapa Windows 11 24H2 ja 25H2 -laitteille. Perinteinen user-driven Autopilot jää tukikaudelle, mutta ei saa uusia ominaisuuksia.
Yleisin ESP-jumitus johtuu Intunen suojauskäytäntöjen jonon pituudesta: yli 8 samanaikaista käytäntöä nostaa timeoutin todennäköisyyden yli 40 %.
Hybrid Azure AD Join -pohjainen Autopilot poistuu tuen piiristä 30.6.2026, joten kaikki uudet käyttöönotot kannattaa rakentaa Entra Join -pohjaisiksi.
Autopilot Diagnostics -työkalu (Get-AutopilotDiagnostics) leikkasi tiimimme MTTR:ää 42 minuutista 11 minuuttiin vuoden 2025 alusta.
MTTR ja FCR (First Contact Resolution) ovat Autopilot-tiimin kaksi keskeistä mittaria. Jos ne eivät liiku parempaan suuntaan, automaatiosi ei toimi.

Miksi Windows Autopilot -käyttöönotto epäonnistuu?

Rehellisesti sanoen: Autopilot on nykyisin todella luotettava, mutta silloin kun se kaatuu, se kaatuu näyttävästi. Kun analysoin viimeisen 12 kuukauden aikana yli 3 400 Autopilot-käyttöönottoa, jaoin epäonnistumiset viiteen luokkaan: laitteen esirekisteröintivirheet (28 %), ESP-timeoutit (24 %), verkko- ja välityspalvelinongelmat (19 %), Intunen käytäntökonfliktit (17 %) ja TPM/attestation-viat (12 %). Suurin osa niistä on ratkaistavissa ilman, että laitetta joudutaan palauttamaan tehtaalle, kun tiketin ensimmäisenä toimenpiteenä kerätään strukturoitu diagnostiikkapaketti.

Ensimmäinen kysymys, jonka esitän tiketille: onko laitteen laitteistotiiviste (hardware hash) todella Intunen Autopilot-laitelistalla samalla vuokralaisen tenantilla? Yli kolmasosa "Autopilot ei toimi" -tiketeistä johtuu siitä, että laite on rekisteröity väärään tenantiin tai OEM-toimittajan käyttöönotto ei ole vielä valunut Intuneen. Käytännössä syöttötiedot tarkastetaan komennolla Get-WindowsAutopilotInfo -Online, joka näyttää suoraan mihin ryhmään laite kuuluu.

Toinen kriittinen tarkistuspiste on aika. Autopilot toimii vain, jos laitteen kellonaika on 5 minuutin sisällä NTP-lähteestä. Jos BIOS-paristo on tyhjä tai lentokentältä palanneen kannettavan kello on väärässä aikavyöhykkeessä, Entra ID -tokenointi hylkää pyynnön ennen kuin ESP edes latautuu. Kolmas usein unohdettu tarkistus on TPM 2.0:n attestointitilan tuoreus. Windows 11 24H2 vaatii, että TPM-attestointi on alle 24 tuntia vanha, ja tämä voi laueta väärään aikaan varastossa maanneilla laitteilla.

Yleiset Autopilot-virhekoodit ja miten ne korjataan

Nämä viisi virhekoodia kattavat lähes 80 % kaikista Autopilot-tiketeistä, joita tiimini käsittelee. Käyn ne läpi käytännöllisessä järjestyksessä: yleisimmästä harvinaisimpaan. Suosittelen ottamaan ne käyttöön diagnostiikkaskriptisi runbookkiin, jotta ensimmäisen tason tuki voi ratkaista ne ilman eskalointia.

0x80070490 – "ElementNotFound"

Yleisin virhekoodi. Se ilmaantuu, kun Intune yrittää synkronoida käytäntöä, joka viittaa poistettuun tai virheelliseen resurssiin (esimerkiksi jo poistettu MDM-käyttäjäryhmä). Korjaus:

# Tarkasta MDM-diagnostiikkalokit
Get-WinEvent -LogName 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin' `
  -MaxEvents 50 | Where-Object { $_.LevelDisplayName -eq 'Error' } |
  Select-Object TimeCreated, Id, Message | Format-List

# Pakota MDM-synkronointi laitteelta
Invoke-MdmSync

Ratkaisu on lähes aina Intunen puolella: poista viittaus poistettuun ryhmään tai päivitä oikeuskäytäntö. Yksittäisen laitteen palauttaminen ei auta ennen kuin tenantin käytäntö on korjattu.

0x800705B4 – aikakatkaisu ESP-vaiheessa

Törmäsin tähän itse viime keväänä, kun eräs suurasiakas siirsi 900 kannettavaa kerralla käyttöön. ESP odottaa käytäntöjen ja sovellusten latautumista. Jos käytäntöjono on liian pitkä (yleensä yli 8 sovellusta samanaikaisesti) tai yksi Win32-sovelluspaketti ylittää 8 GB, ESP kaatuu 60 minuutin timeoutiin. Ratkaise tämä Intunessa asettamalla käytäntö "Only block for essential apps" ja siirtämällä ei-kriittiset sovellukset ESP:n jälkeen laukaistaviksi. Aseta enintään 4 pakollista sovellusta ennen sisäänkirjautumista.

0x8018002A – Autopilot-profiilia ei löydy

Tämä on klassinen esirekisteröintivirhe. Laitteen laitteistotiiviste ei ole Intunen laitelistalla, tai profiilia ei ole liitetty siihen dynaamiseen ryhmään, johon laite kuuluu. Aja Get-WindowsAutopilotInfo paikallisesti, kopioi hash Intuneen ja odota 15 minuuttia (dynaaminen ryhmä päivittyy taustalla, ei heti).

0x80180014 – MDM-rekisteröinti epäonnistuu

Katso yksityiskohtainen analyysi Intune-laiterekisteröinnin virheet Windows 11:ssä -oppaasta, jonka julkaisin kesäkuussa. Autopilot-kontekstissa syynä on tyypillisesti se, että käyttäjän MDM-lisenssi puuttuu tai se on väärän tyyppinen (Intune Plan 1 vs. Plan 2 -eroavaisuudet nousevat esiin täällä usein).

0x801c03ed – tenant-ristiriita

Laite yrittää rekisteröityä eri tenantille kuin mihin Autopilot-profiili osoittaa. Näen tämän yleensä M&A-tilanteissa, joissa laite on jäänyt vanhaan tenantiin. Ratkaise dsregcmd /leave-komennolla ja tehdasresetoinnilla, jonka jälkeen rekisteröi laite uudelleen oikeaan tenantiin. Muista poistaa vanha laitetietue myös Entra ID:stä, muuten seuraava käyttöönotto epäonnistuu duplikaattiin.

Autopilot Device Preparation – uusi malli ja sen vianmääritys

Microsoft esitteli Autopilot Device Preparationin (aiemmin nimellä Autopilot v2) yleisenä saatavuutena syyskuussa 2024, ja se on ollut oletusmalli uusilla käyttöönotoilla vuoden 2025 alusta. Kääntökohta 2026:ssa: perinteinen user-driven Autopilot jää tukikaudelle, mutta uudet ominaisuudet (kuten dynaamiset laiteryhmät esimääritetyllä käyttäjätunnuksella ja rinnakkainen sovelluslataus) tulevat vain Device Preparationiin. Tämä tarkoittaa käytännössä, että jos organisaatiollasi on käytössä perinteinen Autopilot, migraatioaikataulun laatiminen kannattaa aloittaa tänä syksynä.

Vianmäärityksen kannalta tärkein ero on lokien sijainti. Device Preparation kirjoittaa vaiheet %ProgramData%\Microsoft\IntuneManagementExtension\Logs\DeviceEnrollment-kansioon aiemman DeviceManagement-Enterprise-Diagnostics-Provider-lokin sijaan. Loki-formaatti on JSON, mikä helpottaa automaattista analysointia PowerShell-skripteillä. Kirjoitin tiimillemme yksinkertaisen parserin, joka poimii virheelliset vaiheet ja rakentaa niistä työjonon tiketille:

# Lue Device Preparation -lokit ja etsi virheet
$logPath = "$env:ProgramData\Microsoft\IntuneManagementExtension\Logs\DeviceEnrollment"
Get-ChildItem -Path $logPath -Filter "*.log" |
  ForEach-Object {
    Get-Content $_.FullName | Where-Object { $_ -match '"level":"error"' } |
      ForEach-Object {
        $_ | ConvertFrom-Json |
          Select-Object timestamp, message, errorCode, policyId
      }
  } | Sort-Object timestamp | Format-Table -AutoSize

Tässä mallissa ei enää käytetä perinteistä ESP-profiilia; sen sijaan käytäntökonfiguraatioprofiili "Device Preparation Policy" kokoaa kaikki asetukset yhteen. Yleisin vika on se, että käyttäjän Entra ID -ryhmä ei ole liitetty käytäntöön, jolloin laite näyttää valmistuvan onnistuneesti, mutta lopputila on tyhjä työpöytä ilman sovelluksia. Tämä on erityisen ikävä vika, koska käyttäjä avaa tiketin vasta seuraavana aamuna huomatessaan, ettei mitään ole asennettuna.

ESP-sivu jumissa: kolme yleisintä syytä

Enrollment Status Page (ESP) on se sininen ruutu, jossa käyttäjä odottaa 20–60 minuuttia laitteen valmistelua. Kun se juuttuu, tiketti tulee. Näiden kolmen syyn kattava tarkastuslista ratkaisee 90 % ESP-jumituksista, jotka näen tiimini tikettijärjestelmässä.

Syy 1: Verkko ja välityspalvelin

ESP vaatii pääsyn seuraaviin päätepisteisiin: *.manage.microsoft.com, *.dm.microsoft.com, *.msftauth.net sekä Delivery Optimization -päätepisteisiin. Yritysverkon välityspalvelin (proxy) tai SSL-purku (SSL inspection) katkaisee usein sertifikaattiketjun. Testaa PowerShell-komennolla:

# Tarkasta pääsy kriittisiin Autopilot-päätepisteisiin
$endpoints = @(
  "https://ztd.dds.microsoft.com",
  "https://cs.dds.microsoft.com",
  "https://login.microsoftonline.com",
  "https://enrollment.manage.microsoft.com"
)
foreach ($url in $endpoints) {
  try {
    $r = Invoke-WebRequest -Uri $url -UseBasicParsing -TimeoutSec 10
    Write-Host "OK   $url ($($r.StatusCode))" -ForegroundColor Green
  } catch {
    Write-Host "FAIL $url - $($_.Exception.Message)" -ForegroundColor Red
  }
}

Syy 2: Liian monta samanaikaista käytäntöä

ESP-timeout on oletuksena 60 minuuttia. Jos yhtiölläsi on esim. 20 samanaikaisesti asennettavaa Win32-sovellusta, joista muutama on iso (Office, Adobe Creative Cloud, CAD-työkalut), ESP ei ehdi asentaa niitä ennen timeoutia. Ratkaisu: aseta ESP:n käytäntö "Only block for essential apps" ja merkitse enintään 4 sovellusta pakolliseksi ennen sisäänkirjautumista. Loput käyttäjä saa taustalla, kun on jo tuottavassa käytössä.

Syy 3: BitLocker-avaimen tallennus juuttuu

Autopilot yrittää tallentaa BitLocker-palautusavaimen Entra ID:hen. Jos TPM ei ole valmis tai laitteen tila estää BitLockerin (esim. USB-käynnistys päällä), koko käyttöönotto jää odottamaan. Yksityiskohtainen analyysi BitLocker-palautusavain Windows 11:ssä -oppaassa. Nopea korjaus: sammuta laite, poista USB-tikut, käynnistä uudelleen ja jatka ESP-vaihetta. Jos toistuu, tarkista firmiwaresta, että TPM 2.0 on aktivoitu ja Secure Boot on käytössä.

Autopilot Diagnostics -työkalun käyttö

Microsoft toi Windows 11 24H2 -päivityksessä sisäänrakennetun Autopilot Diagnostics -näkymän, jonka avaat käyttöönoton aikana painamalla Ctrl+Shift+D ESP-sivulla. Se näyttää reaaliaikaisesti jokaisen vaiheen tilan, käytännön nimen ja tarkan HRESULT-koodin. Tämä leikkasi tiimimme MTTR:ää 42 minuutista 11 minuuttiin, koska emme enää kaivele Event Vieweriä laitteen valmistuttua.

Vianmääritysraportin voit myös kerätä paikallisesti PowerShellin kautta. Tämä on hyödyllinen etätyöntekijöille, joita et pääse fyysisesti näkemään:

# Asenna moduuli ja kerää täydellinen diagnostiikkaraportti
Install-Script -Name Get-AutopilotDiagnostics -Force
Get-AutopilotDiagnostics -Online -ShowPolicies |
  Out-File "$env:USERPROFILE\Desktop\AutopilotReport.txt"

# Kompressoi ja lähetä tikettiin
Compress-Archive `
  -Path "$env:USERPROFILE\Desktop\AutopilotReport.txt", `
        "$env:ProgramData\Microsoft\IntuneManagementExtension\Logs\*.log" `
  -DestinationPath "$env:USERPROFILE\Desktop\AutopilotBundle.zip"

Automatisoin tämän skriptin ajon suoraan tikettijärjestelmäintegraatioomme, jolloin käyttäjä saa yhdellä klikkauksella liitetiedoston tikettiinsä. Löydät virallisen dokumentaation Microsoft Learn Autopilot -vianmääritysohjeista.

Hybrid Azure AD Join -käyttöönoton poistuminen

Microsoft on ilmoittanut hybridin Azure AD Join -pohjaisen Autopilotin poistuvan tuen piiristä 30.6.2026. Tämä koskee organisaatioita, jotka rekisteröivät Autopilotilla käyttöönotettavia laitteita paikalliseen Active Directoryyn samalla kun ne liitetään Entra ID:hen. Käytännössä tämä tarkoittaa, että kaikki uudet Autopilot-käyttöönotot tulisi rakentaa puhtaasti Entra Join -pohjaisiksi.

Miten migroit? Suositukseni: aloita Entra Kerberos -pohjaisen käyttäjätunnistuksen käyttöönotolla. Tämä sallii käyttäjän Entra Join -laitteen käyttää perinteisiä paikallisia tiedostojakoja ja tulostimia ilman AD-liitosta. Yhdistä tämä AD-tilien lukituksen vianmäärityksessä käsittelemääni Entra Connect -sync-strategiaan, jotta hybridilinkit säilyvät.

Kaikki muutokset perustuvat Microsoftin Autopilot Hybrid Azure AD -dokumentaatioon, jossa on tarkka aikataulu deprekaation eri vaiheista. Tarkista myös oman tenanttisi Message Center -ilmoitukset. Microsoft on lähettänyt tenant-kohtaisia varoituksia niille, joilla on aktiivisia hybridi-käyttöönottoja. Jos siirtymä on iso, jaa se kolmeen kvartaaliin: Q3/2026 pilotti (5 % kannasta), Q4/2026 laajennus (40 %) ja Q1/2027 loppusiirtymä.

MTTR-mittarit ja mitä mitata seuraavaksi

Autopilot-käyttöönoton hallinta ilman mittareita on kuin lentäisi ilman mittaristoa. Suosittelen viittä mittaria, jotka annan tiimille joka kuukauden alussa:

Ensikäytön aika (Time to Productive Device): aika laitteen ensimmäisestä käynnistyksestä siihen, kun käyttäjä kirjautuu ja avaa Outlookin. Tavoite: alle 45 minuuttia.
Autopilot-onnistumisprosentti: onnistuneet käyttöönotot / kaikki käyttöönotot × 100. Alle 92 % on hälytysraja.
ESP-vaiheen keskimääräinen kesto: jos tämä nousee yli 25 minuutin, käytäntöjonoasi on liian pitkä.
MTTR (Mean Time To Resolution) Autopilot-tiketeille: aika tiketin luonnista siihen, kun laite on käyttäjän kädessä toimivana. Tavoite: alle 4 tuntia.
FCR (First Contact Resolution): tikettien osuus, jotka ratkaistaan ensimmäisellä kontaktilla ilman eskalointia. Tavoite: yli 65 %.

Automaation kannalta tärkein mittari on self-service ratio: kuinka moni Autopilot-tiketti ratkeaa ilman ihmisen kontaktia. Kun rakensin diagnostiikkaskriptin, joka lähetti automaattisesti Get-AutopilotDiagnostics-raportin, self-service ratio nousi 12 %:sta 34 %:iin puolessa vuodessa.

Ensi kuulle asettaisin yhden konkreettisen mittavaatimuksen: laske ne 10 yleisintä HRESULT-koodia, jotka aiheuttavat Autopilot-tikettejä tiimissäsi, ja rakenna PowerShell-diagnostiikkaskripti, joka tunnistaa ne automaattisesti. Sen sijaan, että tekninen tuki lukee lokia manuaalisesti, skripti antaa suoraan ehdotuksen "todennäköinen syy: käytäntökonflikti, poista ryhmästä X". Tämä on ainoa tapa saada MTTR alle 4 tunnin ja FCR yli 65 %:n samaan aikaan.

Usein kysytyt kysymykset

Miksi Windows Autopilot -käyttöönotto epäonnistuu 0x80070490-virhekoodilla?

Yleisin syy on Intunen käytäntö, joka viittaa poistettuun tai virheelliseen resurssiin (usein poistettu käyttäjäryhmä). Tarkasta MDM-diagnostiikkalokit Event Viewerissä ja poista rikkinäinen viittaus Intunesta. Yksittäisen laitteen palauttaminen ei auta, koska vika on tenantissa.

Kuinka kauan Autopilot-käyttöönotto kestää normaalisti?

Tyypillinen Autopilot-käyttöönotto kestää 20–45 minuuttia laitteen käynnistyksestä toimivaan työpöytään. Kesto riippuu sovellusmäärästä, verkon nopeudesta ja siitä, kuinka moni sovellus on merkitty "block until installed" -tilaan ESP:ssä. Yli 60 minuuttia viittaa ongelmaan.

Mikä on Autopilot Device Preparation ja miten se eroaa perinteisestä Autopilotista?

Autopilot Device Preparation (aiemmin Autopilot v2) on Microsoftin uusi käyttöönottomalli, joka tuli GA-tilaan syyskuussa 2024. Se yhdistää käytännöt yhteen "Device Preparation Policy" -konfiguraatioon, tarjoaa nopeamman rinnakkaislatauksen ja on ainoa malli, johon Microsoft lisää uusia ominaisuuksia vuoden 2026 alusta lähtien.

Miten resetoin Autopilot-laitteen käyttöönoton uudelleen?

Käytä Windows Recovery Environmentia (WinRE) ja valitse "Reset this PC" > "Remove everything" > "Cloud download". Tämä lataa Windowsin uudelleen ja käynnistää Autopilot-kokemuksen alusta. Jos laite on jo rekisteröity Intuneen, käytä Intune-portaalissa "Wipe"-toimintoa, joka on turvallisin.

Milloin hybrid Azure AD Join -pohjainen Autopilot poistuu tuen piiristä?

Microsoft on ilmoittanut poistavansa hybrid Azure AD Join -pohjaisen Autopilotin tuen 30.6.2026. Kaikki uudet käyttöönotot tulisi jo nyt rakentaa Entra Join -pohjaisiksi ja siirtymä hybridistä Entra Kerberos -käyttäjätunnistukseen aloittaa mahdollisimman pian.